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:
- Every project has to make design decisions consistent with the design principles.
- 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.
You are right on re: ETAM current state! Will agile ETAM work? For some, yes. However, many will get bogged down trying to answer the foundational questions (sketch of business strategy, design goals and design principles.) I have seen weeks just debating the differences between mission, vision, strategy, goals, tactics…
I believe that most “design problems” are the result of incomplete analysis. Virtually *no one* takes the time to do real system analysis; neither of the existing system nor of the desired system. It is a lost art.
Everyone is too busy developing to stop and take a look at what they are trying to accomplish. When questioned about the lack of an in-depth design, I know one project leader who said “We will know more once we start coding.”
I’m guessing you aren’t a big fan of Agile development?
I like the approach that you have come up with
All good points, especially the one about racing toward a target that is moving away from at the same rate !
One of the points I’d highlight is that often (very often !) the business themselves don’t really know what the issues are that are facing them.
They make assumptions about the problems and then tell IT to solve them. The Architecture is then built based on these assumptions and as a result it will probably fail to realize any business value (‘probably’ because sometimes you might get lucky and actually deliver tangible business benefit !)
Very few businesses actually take the time to study the flow of work and to actually trace it from end to end. Instead they rely on assumptions of how things work which means they often state as fact things that they’d like to happen – but that they know probably don’t !
Understand the flow of work and what demands are placed on the business environment and you’re in a much better place to actually understanding what problem you’re you actually need to solve !
I think you’re on the right track. MaineDOT has used a set of 4 architecture principles, (e.g. “MaineDOT is a single enterprise”)elaborated with brief rationale, implications for decision making, implications for design, and value proposition since 2007. That 4 page document has been invaluable to the Dept.
It would be nice to get more example of useful design principles, if they are the core of your article.
Because, it sounds a bit like things you read in “airport MBA” books, like “To succeed, you must execute.” Yeah, of course…
Not sure I see the parallel between deciding on an ERP-centric vs federated architecture and “To succeed you must execute.” The former is a profound choice that affects every product and design decision IT makes. The latter is a seemingly obvious reality some executives don’t seem to have grasped.