A few weeks ago I moderated a webinar on Application Portfolio Management (APM) featuring Phil Murphy, Principal Analyst at Forrester Research.
It contains some excellent information on how to think about APM and I encourage you to download the presentation and the audio track. What follows are some thoughts about what I think is a fundamental misunderstanding of what APM is. In other words, how not to do APM.
For starters, think about this question for a moment: What information about the portfolio do you need to make better decisions about Application A over here? Really. What exactly?
If you know all there is to know about Application A, don’t you have enough information to do everything you need to do to it – retire/replace or modernize? Why does information about other applications in your portfolio matter to the decisions you make about Application A?
It would be nonsensical to ask such a question when you’re managing a financial portfolio. That’s because the best way to stay on the efficient frontier of highest return for the lowest risk is to pay attention to how the securities in your portfolio are interconnected – in particular, the extent to which their risks are correlated .
Whatever you think about Modern Portfolio Theory (the theoretical underpinnings of financial investment), surely you couldn’t be doing that in an application portfolio! Apps are not like securities. There are some essential difficulties even when you put aside the fact that it seems damn near impossible to calculate the “return” on an application. And if you’re not using a measurement platform like CAST, I’d be really curious to hear from you on how to calculate the risk of an application.
First off, securities are fungible – if you don’t like one you can replace it with another in your portfolio. They're exactly the same except for their risk/return profiles. There is a finite transaction cost to making the change, but the process of making the change can be accomplished by clicking a mouse. To reduce your exposure you can sell some shares of a particular stock in your portfolio. I don't know exactly what that is analogous to in an application portfolio, but try doing something like that to your application portfolio without ruining your weekend.
The problem is that even when applications are interconnected in some ways, they're not really amenable to being treated like stocks in a financial portfolio. Again, if you know how to measure risk (and more about that at the end), you may find some correlations between application risk values. But I doubt it.
I’m simply mystified by the utility of those ubiquitous two-by-two bubble charts showing all the applications in the portfolio. The thing is, to know that an application has low business value and high cost, you don’t need to know anything about any of the other applications. So what’s the point? Seeing all my applications in one “dashboard” is pretty but useless.
At best, if you want to keep thinking about it in this way, I suppose you could think of APM as akin to managing a financial portfolio where the transaction costs are orders of magnitude greater than what you would expect in a financial portfolio.
But applications are related, you’re thinking. And you would be right, except that there’s not much you can do, practically speaking, with these inter-relationships.
So how are applications inter-related? There are a handful of ways:
- Transactional Interdependency: Two or more applications might be part of a critical business transaction. They need to work together to accomplish the task.
- Sharing Functionality: Two applications might be using the same service or bunch of services. So messing with these services can have some nasty ripple effects.
- Functional Dependency: Application A might depend on the outputs of Application B. Or it might send its outputs to Application B.
- Resource Dependency: The skills and expertise levels it takes to work on Application A might be the same as for Application B.
- Shared Patterns of Success and Failure: On review of your defect logs, you find that the kinds of problems that beset one application are similar to those that beset another. Similarly, applications that share a particular architectural quality might perform really well. You can detect these pockets by looking at all the apps together.
But so what? Practically speaking, it’s tough to switch resources from one application to another or sequence activities on applications based on the portfolio view. For ages, IT execs have pitched their business VPs in vain on how financing a bit of extra work on “shared plumbing” can really benefit the applications that run their businesses.
As Kelly Cannon, former VP of Shared Applications Services at Kaiser Permanente puts it, “Every CIO has been in annual discussions with business partners over where to allocate IT funds. Should we put it toward maintaining the critical operating platforms on which the business runs, or build new business functionality? The business always wins this one - the answer is new business functionality.”
So here’s what I suggest. Forget the inter-connections between applications. Forget the ubiquitous bubble charts. They’re nice in theory but you can’t win any arguments (much less win any funding) with them. Focus on single applications. Do measure risk and do measure return as best you can. Measure them on the applications you care about, not all your applications.
And stay tuned for a forthcoming book from Capers Jones – The Economics of Software Quality. There are frameworks in there for making both kinds of measurements -- risk and reward.