Dear Dr. Yeahbut …

Okay, I get it. APR (Application Portfolio Rationalization) is only half of straightening out the application layer of my organization’s technical architecture. I understand we also need holistic design as a complementary approach to figuring out which applications we need to support, and you gave enough hints last week that my team and I can figure that part out.

I think we’ve also figured out how to integrate APR and holistic design. Check me on this: We treat each business functional area’s applications as a separate “sub-portfolio,” and perform separate APRs on each of them. And for the bigger business functions we split them down more, into sub-sub-portfolios, assigning health scores and dispositions to the applications in each of them.

Are we close?

And we have one more question: Last week you said there’s a lot more to the APR story than integrating it with holistic design and producing a remediation roadmap.

But just the thought of what’s needed for the remediation roadmap is enough to make my head hurt.

So c’mon, give us a break. Or at least a hint.

– Seeker of More Free Wisdom

Seeker …

So far as integrating APR and holistic design you’re on the right track. There’s a lot more to it than that … establishing, a small but powerful set of design principles (whether you’re implementing a hub-and-spoke vs federated architecture, for example), and agreeing on the criteria that make an application healthy … but you’ve made a good start of it.

But then there’s the APR roadmap. The secret to success: don’t create one.

Feel better?

It’s an Agile vs Waterfall kind of thing. It’s also a project-orientation vs operations-orientation kind of thing.

Imaging you’ve just wrapped up your APR/holistic design project, complete with a well-defined and designed remediation roadmap.

Now what?

The answer, more often than not, is nothing. It’s nothing because of a business construct you might have heard of, namely, the budget.

Long before your APR roadmap came along, the company’s queue of proposed projects already had enough in it to completely consume three to five years worth of the budget and staff effort needed to clear it.

If your company is like most, there isn’t a dime left in the pot to execute your roadmap.

Which leaves you with three choices:

Freeze: Put a bunch of projects already in the queue on hold for a few of years to clear space for the APR roadmap.

Refocus: Redefine the APR roadmap so it’s purpose is business optimization by way of removing whatever barriers the current application portfolio imposes on effective business functioning.

Agility: Recognize that an APR roadmap is, at its core, a Waterfall approach to planning change, replete with the usual line-up of Waterfall fallacies. but in particular the fallacy that a two- or three-year change plan is predicated on the assumption that business planners can accurately forecast now what the business will need three or more years from now.

Freeze isn’t going to happen. The already-approved projects in the queue were approved because they promise to deliver clear, identifiable business value, and will deliver it to executives who have quite a lot more clout than the CIO.

Refocus should have been in the APR charter all along: Identifying where application limitations drive process limitations means APR isn’t an engineering sales pitch. It’s a revenue enhancement, cost reduction, and improved risk management sales pitch.

That leaves Agility. The way that works is to view the application sub-portfolios and sub-sub-portfolios the way you view Agile epics, and the individual applications and their dispositions the way you view Agile user stories.

Bob’s last word: If you’re going to go through the time and effort of assessing your applications portfolio your analysis had better include how each application contributes to the health and effectiveness (or the ill-health and ineffectiveness) of the business processes, practices, and functions it supports.

Combine that perspective with Agile planning and your problem won’t be a roadmap you’ll never get approved.

It will be a backlog you can’t clear fast enough.

Bob’s sales pitch: Want more insights into how to apply Agile thinking to more than application development? You need chapter 3 – “Fixing Agile” – of There’s No Such Thing as an IT Project.

Dear Dr. Yeahbut …

Every time I turn around I read that IT needs application portfolio rationalization (APR).

I’m the newly appointed CIO in a mid-size (~$5B revenue) financial services enterprise. I’ve been reading the usual sources for these things and find the logic in favor of APR compelling. On the other hand(s) I find the logic in favor of another half-dozen or so management initiatives equally compelling. And I’ve been reading KJR long enough to remember your thoughts on the importance of maintaining focus (“Nailing governance,” 8/7/2006), which I find even more compelling.

I know we can’t do everything we really ought to do, which brings me to my question: What’s your take on APR? Should this make my top-three list?

You’re a consultant, so I know your answer will be “It depends.” What I want to know is what it should depend on.

– Seeker of Free Wisdom

Seeker …


Before I can answer we’ll have to wade through something that’s frequently misrepresented or misunderstood, starting with the phrase itself.

APR is built around a metaphor – that IT can manage its application portfolio the way investors analyze their financial portfolios.

If you’re an investor, you assess and constantly reassess the funds and individual equities that constitute your portfolio. You determine their health and anticipated future value, use that insight to assign a disposition – buy, hold, partially divest, sell – to each of them, and act according to those dispositions.

APR theory says you should do think about your applications portfolio the same way – assess each application’s health, assign dispositions accordingly, and act on those dispositions.

This theory isn’t so much wrong as it is, as someone once put it, insufficiently right.

The applications your enterprise relies on to get its work done do constitute a portfolio. But (I am, after all, Dr. Yeahbut) that isn’t all they constitute.

That’s because of a fundamental and retrospectively obvious difference between a financial portfolio and an applications portfolio: With financial investments, buying or selling shares in a particular fund or equity has little impact on your investments in any of the other funds and equities you own. But in a portfolio of applications, you can’t decommission an application or replace it with another with impunity.

Beyond the portfolio view of its applications, IT also needs to consider them from the perspective of holistic design.

Holistic design is the difference between a pile of lumber, Romex, screws, nails, and so on and a structure you can inhabit. (Okay, this isn’t the best metaphor I’ve ever come up with, but let it go – it isn’t a rabbit hole worth falling into.)

Holistic design is how you figure out which collections of applications the enterprise needs to support each of its major areas of functional responsibility, how the applications within each collection interconnect to provide complete solutions, and how the collections interconnect with all of the other collections to support the enterprise-level need for information integration and process standardization.

In theory, if you’re handling holistic design well you wouldn’t need APR, because your holistic designs would determine exactly which applications you need and where you need them.

But as Benjamin Brewster once said, “In theory there is no difference between theory and practice, while in practice there is.”

Bob’s last word: When it comes to an organization’s applications environment, it turns out the holistic and portfolio views aren’t just equally important.

They’re complementary.

More than that: APR is usually chartered as a once-and-done project. It takes the application inventory and, if you’re smart, your holistic application design as inputs, and produces a remediation roadmap as its primary output.

But (there’s that word again) … there’s a lot more to the story than that. But we’re out of our self-allotted space this week, so the rest will have to wait.

Bob’s sales pitch: This is a big, complicated subject, and there’s only so much I can handle in these weekly bite-size chunks. So more next week. And if you need a more in-depth conversation than what fits into this format, you know who to call.