IT Architect: Metaphor or Oxymoron?

by Jeff Tash, ITscout

What if John Zachman, the world's leading expert on Enterprise Architecture (EA), is wrong? Recognized as the “father” of EA, Zachman is credited with being the first person to apply the lessons learned from the field of traditional “architecture” in the construction industry to the world of IT planning and design. This notion that traditional architecture and enterprise architecture share common traits is rarely, if ever, challenged. But, what if these two disciplines really are not all that alike?

Traditional architecture is “customer-driven.” The traditional architect takes a client’s desires, applies knowledge regarding construction principles, and then draws up a set of blueprints that contractors and subcontractors responsible for construction can read and understand. Traditional architects don’t have to wear nearly as many hats as their IT counterparts. It’s true that they need to be thoroughly familiar with building codes. They also must understand the nature and properties of various building materials. Traditional architects have to know what can and can’t be built. But, still, they get to depend on engineers to certify that their aesthetic designs can withstand the scrutiny of gravity and stress.

In the construction industry there are clear lines of demarcation -- essentially a code of conduct. Everyone tacitly understands their own responsibilities. In this established system of intersecting roles, architects have immense authority.

Traditional architects play a “central” role in construction projects. They’re in charge of creating multiple different layers of blueprints. The individual subcontractors doing the actual construction work only need to see their portion of the big picture. Each one is only interested in their individual set of blueprints. But, in the end, it’s the architect’s responsibility to make certain that everything “works” -- that the final structure does not collapse under its own weight.

Now, by contrast, turn your attention to IT. These architects are “self-driven.” In other words, IT is driving the architecture process -- not the client. Furthermore, unlike traditional architects, IT architects have almost no authority. They must operate chiefly from a bully pulpit -- hoping to rally support for their ideas and methods.

In the world of IT, there are no legislated building codes. There are no engineers to certify what can and cannot be developed because there are no “laws of computer science” comparable to the “laws of physics.” The computer is the ultimate general-purpose machine. It can do anything, or be anything, provided, of course, you have enough money, time, and talent to program it accordingly.

Rather than trying to satisfy a client’s desires, IT architects are supposed to support overall business drivers and requirements. One of their biggest obstacles, however, is they have no way of easily explaining to business people what can and cannot be done. As a result, they’re often squeezed between what’s needed and what can realistically be delivered. It doesn’t help that the people on the business side are clueless. Those folks just want IT to support their needs, and when IT comes back and says they can’t deliver something, these business people generally can’t understand why.

Unlike in the construction industry, the rules and roles governing IT are much more elusive and ambiguous. IT architects may have responsibility but they lack capability. There simply are no established techniques or standard methods for creating sets of blueprints that can be shared and understood by all the different parties involved in an IT project. Builders need to understand blueprints. Clients need to understand blueprints. Somehow, some way, everybody has to get on the same page. Unfortunately, we currently aren’t even close to solving this problem. The bulk of the issues IT architects face stem from their ineffectual communication with the non-technical business people they must support.

IT is burdened with an unreasonable responsibility. Business management perceives IT as purely a support function. And unlike with construction projects, IT architects rarely get to respond back with regard to what can or cannot be accomplished. Business people feel they know what they have to have. Meanwhile, they look at IT as this huge cost center. The typical exchange usually begins with the business honchos telling IT, “You guys are costing us a fortune. Here’s what we need and it had darn well better work.” On the other side the CIO is saying to himself, “Alright, how the heck am I supposed to do this? I don’t have the resources. I don’t have the capabilities. How am I going to go back and tell these guys we can’t deliver what they want?”

One thing is certain. Nothing is going to improve until this gap between IT and business people is bridged. Before IT architecture can begin to emulate traditional architecture, a solution must be found so that business people can understand what their choices are and what the costs are going to be. Only then will IT architects possess real authority like their brethren in the construction industry. Ignoring this need will only result in the continuation of today’s hostile environment where both sides wave at each other, but only with one finger on each hand.