Dr. Yeahbut says:

We’ve been talking about APR (application portfolio rationalization) for two weeks now, and we could easily keep on talking about it for months without ever getting to the finish line.

So this week I’ll try to clean up a few odds and ends that might either help you get started or else might help you finish, starting with the most important:

Don’t undertake an APR project at all. Instead, set up an application portfolio management (APM) practice – a small group that manages the application disposition backlog, taking responsibility for (1) the guiding and governing principles of your technical architecture’s application layer; (2) the application layer’s ongoing holistic design and portfolio assessment; and (3) a mechanism through which all projects that make changes to the application layer do so in ways that improve it.

The APM practice could be a separate organization; it could be a new responsibility or focus of your enterprise architecture function; or it could be a re-launch of your architecture review board (ARB).

But be careful. The APM practice should provide leadership. Experience tells me that, as often as not, the APM practice does little more than add yet another flaming hoop teams have to jump through to get their work done – it becomes a bureaucratic barrier, not a facilitator.

Integrate integration. “Let’s talk about your application interfaces,” I asked a client application team. “Do you have the usual spiderweb to deal with?”

“Oh, no,” they told me. “We haven’t had a spiderweb in a long, long time. We call our interfaces ‘the hairball.’”

No matter how poor your application portfolio’s health, there’s high likelihood your integration is in even worse shape.

So before you start to rationalize your applications, set up a well-engineered integration framework. Every time you touch an application, make it an opportunity to clean up another corner of your interface spiderweb (or hairball).

What is an application, anyway? “Application” is a set with fuzzy boundaries and inclusion criteria. The confusion hits from several directions. The view from here: It’s an application if someone launches it to help them get work done. Some complicating factors and situations:

Some products are both platforms and applications. Take SharePoint. It is an application – you interact with it to get work done. But it’s also a platform you can use to build applications.

As you assess your application portfolio, include SharePoint-as-application. Also include applications built on the SharePoint platform. Don’t try to count the applications built on SharePoint as “SharePoint.” Each is a separate application.

Installed clients are … what, exactly? As more and more applications present their user interfaces through browsers this is less and less of an issue, but it hasn’t gone away entirely. If you have client/server-style applications that are still in production you’ll have to decide whether to include the client-side and server-side applications as a single entity or separately.

Either answer will work. Just be consistent about it.

Microservices are … what, exactly? Just my opinion: this is a rabbit hole you should step around carefully. Fall into it and you’ll never be seen again.

You’re better off dealing with microservices as platforms, not applications. This doesn’t make dealing with them easy. It makes them Someone Else’s Problem (or your problem but on different days of the week).

Keep track of your microservices the way you keep track of libraries. Applications rely on them, mucking them up can do a lot of damage, but they aren’t applications.

Avoid SPAs (single page architectures). I know it’s tempting. I’ve drawn these myself – diagrams that show all components of the application portfolio along with their affinities and interconnections, all in one place.

That is, SPAs usually turn into collections of dozens of boxes connected by multiple dozens of lines and arrows, all labeled in 6-point Arial type or smaller.

And all completely unverifiable.

Without exception, every architecture diagram should obey the rule of 7 plus-or-minus 2: It should include no more than between five and nine boxes; each box may be explored more deeply with a separate page that also contains between five and nine boxes.

Bob’s last word: Apply the rule of 7 plus-or-minus 2 to every kind of diagram, not just architecture diagrams – process flow “swim-lane” diagrams, for example. Human beings can make sense of seven connected boxes and be confident they’re right. We can’t make sense of seventy, even if our eyes are good enough to resolve their mousetype labels.

Bob’s sales pitch: CIO recently ran a piece by yours truly about the importance of a culture of honest inquiry for achieving your analytics goals. You’ll find it here, assuming you’re interested enough to click.

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.