I heard an interesting comment from an executive at one of the big services firms – that application portfolio management (APM) efforts must begin by mapping business processes for the applications. I really don't agree, but thought it would make an interesting topic to discuss here. Part of the argument stems from how services firms are routinely engaged – to take action against one application or a group of applications to transform, re-engineer business processes, reengineer, refactor or otherwise modernize an application. All are useful activities and techniques, but they are not portfolio management techniques – they are modernization techniques. Modernization and APM live together on a continuum of application activity that includes in order:
- Modernization – the actions we can take against an existing application – monitor & maintain, modernize in some way, replace (rewrite/pkg) or retire.
- APM – which collect metrics about all of the applications to enable better management of the apps in the portfolio. APM collects metrics on all apps, but the goal is to isolate anomalies (duplicate apps, waste, costs not in line with business value, etc)
- Rationalization is streamlining the portfolio and driving better modernization decisions – the actions that stem from th transparency created by APM
- Strat Planning aligns the application information to business perspectives – the goal being to completely recharacterize business/IT discussions so that spending occurs in the context of business need (not necessarily business-unit need).
Interest in APM has grown over the past several years because IT orgs:
- Don't know what they own – in fact they don't even have a basic, accurate apps inventory
- Don't have any metrics about the apps (condition, cost, value to business, resource consumption, number of duplicate apps) So decisions are made based on technical criteria or seat-of-the-pants
- Spend too much on the portfolio, but cannot defend where, when or why to the business – the portfolio is a black hole for resources
APM is not equivalent to BP, does not begin with BP, and cannot take a back-seat to BP mapping activities. In fact I argue that APM should be established first as a governance mechanism:
- Why would you map business process against 10 duplicate apps? (I worked with a client who owned 17 duplicate apps in 16 geographic locations.)
- Why map BP for applications you plan to retire or replace with a package?
I see and appreciate the value of mapping BP in the right cases – to match features required in a new or replacement package, make sure we don't lose a function through application retirement and as a prelude to consolidating 2 apps, etc. but that makes them techniques for modernization, not the starting place for APM. What are your thoughts?