Ask Dr. Yeahbut, APR Edition, Part 3

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.