Enterprise Architecture / Enterprise Technical Architecture Cage Match

Which matters more, enterprise architecture or enterprise technical architecture? EA has the altitude, but ETA pays the bills.

ManagementSpeak: We run a lean organization here.

Translation: We have far too few people doing way too much work, and none of it is done particularly well.

Translating “lean organization” wasn’t much work for this week’s anonymous contributor.

It’s the Edison Ratio again — Thomas Edison’s famous explanation of genius as one percent inspiration and ninety-nine percent perspiration.

The Edison Ratio is why I haven’t yet written about the subject suggested by long-time correspondent Bob Ballard, enterprise architecture.

Way back when I developed what I thought was an enterprise architecture methodology for my then employer, Perot Systems. Its goal was to rationalize and create a plan for the evolution of a client’s portfolio of installed technologies, strongly connected to the client’s business direction.

It worked well — well enough that I based the “Managing Technology” section of my old IS Survival Guide book on it.

Turns, out, though, that in the eyes of most practitioners I’d mistaken the tail for the dog and vice versa.

What I’d been calling enterprise architecture was really enterprise technical architecture. Enterprise architecture refers to how the business is put together, not how the technology is put together. According to much of what I read about enterprise architecture, it’s by far the more important discipline.

And it is, assuming your measure of a subject’s importance is the importance of the people you sell it to. Enterprise architecture is an executive-suite trade, which means, among other things, that enterprise architects charge more for their services than enterprise technical architects.

Whether that makes sense is a different question, because while enterprise architecture calls for hard choices, it doesn’t call for complicated choices. Which is fine: Most of the time, which choice a company’s leaders make is less important than making one and sticking to it.

Enterprise technical architecture, on the other hand, is intrinsically complicated and only works when its practitioners sweat the details.

Hundreds of details.

More than that, those who have to plan and manage a company’s technology portfolio know something strategic consultants rarely figure out: The vast majority of the decisions they have to make do not depend on the enterprise architecture in any important sense. They depend much more on intrinsic engineering logic and characteristics of the business that are so well-known and obvious that no formal strategic statement is needed.

Which isn’t to say enterprise architecture is entirely useless. In fact, it serves an important purpose. That’s to replace case-by-case decision-making complicated by conflicting hidden assumptions with principle-driven decision-making guided by a consensus view of how the business works.

One of the better-known books on the subject, Enterprise Architecture as Strategy (Ross, Weill and Robertson, 2006) exemplifies both the good and the bad of enterprise architecture.

The bad: It derides enterprise technical architecture efforts that rely on “… mind-numbing detail represented in charts that look more like circuit diagrams than business descriptions.” Now this is just an opinion: While many business executives might prefer oversimplified views that look good in the PowerPoint, there’s nothing businesslike about oversimplifying what’s complicated.

As noted, enterprise technical architecture is intrinsically complicated. That’s because it describes all of the business problems to be solved with technology, and the technology problems to be solved with an underlying layer of supporting technology. Then it describes the solutions to those problems. Even a simple organization has dozens of business problems to be solved that result in hundreds of underlying technical problems to be solved.

The complaint about the enterprise technical architecture view of things is not that it isn’t businesslike. It’s that it’s too businesslike: It’s a reflection of the business described in sufficient detail to guide the real-world engineering decisions IT has to make.

This deriding of the ground-level view is just pandering to an audience that shouldn’t be receptive to it, but too-often is. It tells top-level executives that detail is beneath them, best left to technicians who lack the vision and strategic capacity to deal with important matters.

Just ignore the pandering. What enterprise architecture does have to offer is a framework for deciding what about the business will provide enduring competitive advantage in an unpredictable marketplace, so it knows where to invest deeply in supporting infrastructure.

That’s an important decision to make, and belongs in the executive suite besides.

So enterprise architecture does have a useful role to play in the world of business planning … if and only if the people who run the business see it as how they decide where to place their bets.

In this, it’s very similar to IT’s enterprise technical architecture function: It either guides and constrains every decision, or it turns into an academic, ivory-tower white-paper factory that adds no actual value to anything while serving as an irritating nuisance to everyone who has important work to do.

Bob Lewis is author of Keep the Joint Running: A Manifesto for 21st Century Information Technology, Bare Bones Change Management: What you shouldn’t not do, and six other books on business, information technology, and where they intersect. He is president of IT Catalysts, Inc., a consultancy specializing in these and related areas.