Enterprise architecture: do it without the checklists, analyst urges

Does 'checklist architecture' result in rigid thinking that misses business goals?

Checklists have a vital role to play in the monitoring the performance of many systems, from commercial aircraft to nuclear power plants to healthcare. Many things would be missed if human operators did not have checklists to keep things organized.

But here's something to cross off your list of things that should to be managed with checklists -- enterprise architecture. At least that's the cautionary warning sounded by ZapThink's Jason Bloomberg in a new post. Jason explains what checklist architecture is, which is "endemic" to government organizations, and creating problems within private sector companies as well:

"Checklist architecture occurs when there are a fixed set of goals for the architectural initiative, either final goals or interim milestones, where the goals only indirectly correlate to the business drivers for the initiative. Problems arise when the architecture team drives toward the goals without heeding the underlying business problems, especially as those business problems change over time."

Jason cites the Department of Defense Architecture Framework (DoDAF), developed primarily in response to the Clinger-Cohen Act, which mandated Enterprise Architecture at the federal level. What's wrong with DoDAF? Jason says "DoDAF compliance means creating a number of 'views,' or architectural artifacts of various sorts. And while these views should help drive a successful architecture implementation that meets the business needs of the organization, far too often the views are the end result, rather than tools for achieving true business value."

Examples of checklist architecture in commercial organizations: "Performance Objectives" which become an end in itself, versus encouraging people to increase value to the business. Jason offers this piece of advice:

"Move away from the 'business requires X so we build X' mentality, and move toward a 'business desires the ability for requirement X to change so we deliver a system that can deliver X as well as whatever changes to X the business requires' way of thinking."

This requires changes in corporate culture and management style, of course. But checklist architectures end up fixing more technical requirements without addressing business requirements.

It's the same nagging problem that's been cropping up in organizations for some time regarding SOA -- many service-oriented efforts address technology specifications, but aren't quite tuned to the business. Sort of like running a great engine room down in the bowels of the Titanic, but not helping guide things upstairs, right?

(Illustration: Mizusumashi, via Wikimedia Commons)