The goal of Application Portfolio Management is to reduce the cost of owning the portfolio. The fundamental premise is this:
- We own a lot of code.
- It costs a lot to maintain our code. (too much)
- Management wants to be able to make cuts in the maintenance budget.
- We don’t know which costs are optional and which costs are necessary
- APM answers that question, allowing us to cut unnecessary maintenance costs
Something like that anyway. (OK… it’s a bit over simplified. sue me).
There are some problems with the notion, problems that show up in the details. Systems are not simple marbles that you can remove from your bag and sort into neat little buckets. They are tied to business problems that need to be solved. They are part of a solution that automates activities in a business process. The criticality of those business processes, and their rate of change, does more to drive the cost of maintenance than most other factors in play.
Yet, most APM tools are simply catalogs where you write down things about the app, but don’t do much to help you to analyze the importance, or rate of change, of the business processes that they are attached to.
And thus, all the data collection in the world won’t help without that analysis that puts things into perspective.
Some folks do that analysis, and they see costs decline… sometimes by large margins. Others expect the tools to help, or they measure the wrong things, and costs don’t drop.
My gut tells me that APM will only succeed when it is tied to tangible analytic methods like Six Sigma. Without that tie… it may not do very much. A car, without an engine, won’t get you to the church on time.