What’s sad and surprising about architecture is how seldom anything good comes of it.

Or, for that matter, how seldom anything at all comes of it.

I have no statistics, only experience … personal and anecdotal … and that experience says most attempts to institute an enterprise technical architecture management (ETAM) function die on the vine.

And of those that don’t die, most turn into bureaucracies — ivory-tower white-paper factories that demonstrate the brilliance of their authors much more than they promote effective technology implementations.

What goes wrong?

It starts, I think, with the goal of most ETAM implementations. They take the classic consulting approach: Document current state, design desired future state, document the gaps, and develop a plan to close them.

This is, to all appearances, perfectly logical. And familiar.

It’s also perfectly waterfall, complete with waterfall’s crushing shortcoming: By the time you reach the finish line, not only has the finish line moved somewhere else entirely but you aren’t even playing the same game anymore.

By the time you’re able to start implementing the ideal future state you’ve designed it’s already lost relevance.

Finish implementing it? If you have a good pair of binoculars you can see the continuously evolving ideal future state accelerating into the distance, the rate with which you can close the gap paling in comparison to the rate with which the gap grows in magnitude.

And that doesn’t take into account the additional delays that result from the corporate project governance process. After all, architecture-driven projects have to flow through it right along with all the others, competing for staff, budget and capital with everything else that might provide important business value.

So tear out the goal. ETAM’s purpose isn’t to get the enterprise to its ideal future state because it can’t ever get the enterprise to its ideal future state.

Agile ETAM sets a different goal: To shape events so that the enterprise is constantly migrating to a better architectural state.

Don’t sneeze at better. Better is better than not getting any better. Far better.

Which is why, for the past several years, I’ve been developing an agile approach to enterprise technical architecture management.

Not enterprise technical architecture management in support of Agile, which is a different matter, although Agile ETAM does support Agile development quite nicely.

Agile ETAM is, in fact, doubly agile. It (1) improves the enterprise technical architecture iteratively and incrementally, and (2) implements an ETAM function within IT iteratively and incrementally as well.

It starts with a foundation, as most architectures do that are intended to support enduring structures and not tents or movie sets. In this case the foundation consists of:

• A sketch of the business architecture and strategy IT has to support (a sketch is generally sufficient for IT’s needs).

• Current-state issues (for example, here).

• Design goals — a consolidated view of what support for the business strategy and architecture plus remediation of current state issues looks like.

• Design principles — what “good” means.

The design principles are the stable core of it. Business strategies may come and go, but IT’s decision to (for example) adopt an ERP-centric application and information layer instead of a federated architecture will inform project design decisions throughout.

As will the principle it leads to: “Use the module that comes with the ERP suite when it’s close enough, and when it isn’t, buy when we can and build when we have to.”

Many enterprises adopt the principle of never upgrading to stay current, only when new capabilities that will provide direct business value warrant it.

It’s almost always a mistake, because once you’ve skipped a couple of releases, getting current is almost as painful as converting to a different product entirely. Regardless, one of your principles should be about release currency, and just in case this isn’t clear, “we’ll make case-by-case decisions” is the opposite of operating from a stable core principle.

Once you’ve established a core set of design principles — maybe a dozen of them — you’re in a position to influence things, because from this point forward every project team has the design principles to use as a touchstone against which to gauge its design decisions.

The rules here are simple:

1. Every project has to make design decisions consistent with the design principles.
2. Every project has to leave the technical architecture more consistent with them than it was when the project started.

Is this all there is to Agile ETAM? Of course not.

It’s akin to Agile development methodologies, which start by building the smallest irreducible core of a system and then add on to it.

This is ETAM’s smallest irreducible core.