I’m working on a (probably) three-part sequence on technical architecture, to be part of the IT Management 101 series I’m writing for CIO.com. As a famous person once said about health care, who knew architecture is so complicated?

This isn’t a substitute for it. It’s more along the lines of stray thoughts you might find helpful in assessing and managing technical architecture in your own organization.

Beware the seductive siren call of metaphor. The parallels between technical architecture and what professional building designers do are limited at best, and dangerous at worst.

The work of professional architects begins with a sketch and ends with blueprints. Technical architects don’t create blueprints, and if they did they would be embracing waterfall methodologies.

Agile methodologies don’t rely on blueprints of any kind. They often do rely on the equivalent of a sketch, but if so it’s the business analyst / internal consultant who draws it.

Crowdsourcing is a dicey way to gather data. Given how much information you’re going to want about each component in your portfolios, crowdsourcing it … sending out questionnaires to subject matter experts … is tempting.

Given that many enterprises can have a thousand or more components across all of their portfolios, crowdsourcing might not just be tempting – it might be unavoidable.

So if you do crowdsource your data-gathering, make sure you educate all of your information sources in the nuances of what you’re looking for.

And, assuming they do complete your questionnaires, curate the daylights out of the information they provide.

Version is data. Currency is information. You should include in your technical architecture database how current each component is, “current” meaning whether it matches what the vendor currently ships (fully current) or, descending through the possibilities, whether it has fallen out of support (obsolete).

Keeping track of which version of a component is deployed in production is relatively straightforward – just make sure than any time the responsible team installs an update they know to update the architecture database to match.

But what you care about is how current the component is, and you can only determine that if you know the product’s full version history, so you can match your production version to its position in that history.

Currency scores are, of course, perishable. As they change each time a vendor issues a new release, someone needs to keep track of this across every commercial product in every portfolio in your architecture.

It isn’t just your technology that has to stay current. You have to keep every piece of information you collect about each component in your architecture current, too.

You collect information about each component of your technical architecture. Some of it is constant. But quite a lot may change over time. For example, you’ll probably want to know how well each application supports the business functions it’s associated with. But business functions change, which means an application’s business function support score changes along with it.

So your information-gathering process has to operate on a cadence that balances the sheer effort required with the rate of decay of information accuracy.

Bob’s last word: Speaking of balancing effort and information it’s tempting to collect a lot of data about each component in the architecture. Tempting, that is, until you pivot from collecting it the first time to updating it on a regular cadence, over and over again.

In the framework I use, I’ve identified about 30 attributes just for the application layer of the architecture. That’s a starting point. An important part of the process is whittling them down to the essentials.

Because 30 is too big a number. Ten will usually do the trick.

Bob’s sales pitch: I’m still whittling down the CIO.com architecture articles to their essentials. I’ll let you know when they’re available for your reading enjoyment.

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.