Enterprise technical architecture management — an old new idea

Ever meet someone who just has to have a strong opinion on every subject, whether or not they know anything about it?

Those known for expertise are particularly prone to this ailment. Some of us, having learned one subject in great depth (in my case the behavior of electric fish), use that experience to recognize our lack of depth in other subjects.

But then there are those who figure their expertise in anything make them worth listening to about everything.

If they limited their indulgence of this hobby to bars, pubs, and taverns they’d be less tiresome. But sadly, some use blogs and other forms of on-line presence instead.

Take, for example, McKinsey & Company, which recently published a missive titled, “Why business needs should shape IT architecture,” (Helge Buckow and Stephane Rey, McKinsey Quarterly, April, 2010).

This Highly Original Thought (HOT) was considered obvious more than a dozen years ago, when I led development of a technical architecture management methodology for Perot Systems. The proposition hasn’t become more controversial, nor more worthy of elaboration since then. Whether business needs should shape IT architecture isn’t and never has been in question.

The question isn’t whether. It’s how, and McKinsey’s solution — put a CTO with political acumen in charge so business executives can read an executive summary and not have to understand anything complicated (I’m paraphrasing) — is, shall we say, somewhat less than complete.

Not to brag or nuthin’, but more than a decade ago I published a book (IS Survival Guide, Bob Lewis, Macmillan/SAMS, 1999), containing this profundity: “The scope of technical architecture … begins with an understanding of business goals and ends with the establishment of specific standards.”

It also provides a somewhat more thorough methodology for traversing this complex landscape.

And the landscape is complex, for three major reasons.

The first is that Enterprise Technical Architectures are intrinsically complicated. A typical mid-size business will find that its three architectural layers (application, information, and platform) will be required to provide several hundred technical functions and services to get the job done. That’s functions, not products.

If the distinction isn’t clear: One platform-layer function might be “provide secure remote access.” To provide that function, IT can choose from among at least these three competing technologies: classic VPN, SSL-based VPN, and remote desktops. Once it has chosen its preferred technology (remote desktop) it’s then ready to standardize on just one solution (Citrix).

It’s this thought process that leads to an organization’s target architecture — the functional view, resolved to classes of technology, for which specific standard solutions have been chosen. Creating and maintaining the target architecture is one of the core responsibilities of any enterprise technical architecture management practice.

That’s the first driver of complexity. The second is that there is no straight line connecting business goals and architectural decisions. The lines connecting the two describe a many-to-many relationship — each business goal affects many different architectural decisions; each architectural decision must take into account many different business goals.

This means there is no purely analytical way to derive the ideal enterprise technical architecture from business requirements. The process takes more than analysis — it requires synthesis, a far more challenging thought process.

The third driver of complexity comes from business executives being human beings, IT having to depend on those human beings for financial support, and those pesky human beings’ having bought into the capitalist philosophy of “what’s in it for me?” as part of how they approach business life.

It’s this: Good architecture doesn’t happen through the chartering of architecture improvement projects. It happens by investing in architectural improvement as part of all of the projects a company would undertake anyway.

That investment adds time, effort and money, and doesn’t benefit the project sponsor at all. The better architectural decisions implemented in projects A, B, and C this year will benefit the sponsors of projects Q, R, and S several years from now — their projects will cost less to achieve the same outcomes than they would have with an accidental architecture, because that’s what good architecture does for companies.

As an ancient Greek proverb has it, “A civilization flourishes when people plant trees under whose shade they will never sit.” For businesses to achieve excellence in enterprise technical architecture management, they first must be civilized.

It’s something that doesn’t happen by accident. In the world of business, far too often it doesn’t happen at all.