Enterprise Architecture vs. Technology Architecture

by Jeff Tash, ITscout

What’s more difficult? Teaching a business person about technology or teaching a technologist about business? My guess is the answer depends largely on which group you ask.

The view of many CIOs, confident in their command of technology, is that they are well-suited to serve as catalysts for business-oriented strategic thinking. On the other hand, according to a recent Gartner report (Improving the CEO's view of the CIO ), CIOs rank last among senior executive positions which CEOs think are important to the strategic direction of their enterprise. I don’t know about you, but for me, personally, I’d surely hate to be a business person trying to figure out what IT is talking about most of the time.

Take, for example, the term enterprise architecture. What exactly does that phrase mean?

John Zachman, usually considered the father of enterprise architecture, would tell you it’s a 6x6 matrix. The columns correspond to the following six questions:

  • What?
  • How?
  • Who?
  • Where?
  • When?
  • Why?

The rows of the matrix refer to what Zachman calls:

  • Scope
  • Business Model
  • System Model
  • Technology Model
  • Detailed Implementations
  • Functioning Enterprise

Frankly, I have never been able to figure out what the exact boundaries are that differentiate one row from another within the Zachman Framework, especially as you go from System Model down to Functioning Enterprise. In other words, deciding which row something belongs in often seems pretty arbitrary.

In my experience, the Zachman Framework is most useful for strategic planning initiatives. Scope, the top row, presents a pretty good big picture overview. The second row, Business Model, does okay describing business processes. However, as you move down the rows away from a business-oriented perspective and toward a more technology-oriented view, the Zachman Framework becomes increasingly less effective.

I personally challenge Zachman’s fundamental assertion that complex IT systems somehow mimic architecture and construction. They do not. Nor are IT systems similar to engineering and manufacturing. In fact, in my opinion, the limitations of the Zachman Framework stem directly from John Zachman’s complete lack of any experience actually developing software systems.

I can only imagine what the cognitive model must look like inside Zachman’s head that he uses when he thinks about or talks about software. Then again, it wouldn’t surprise me to discover that his cognitive model is quite similar to that of most non-IT business managers. That’s probably been the key to the Zachman Framework’s success.

A different definition of enterprise architecture, one that I personally prefer, comes from an organization called The Open Group. They describe enterprise architecture as consisting of four types of subset architectures:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

Business Architecture is very similar to the Business Model in the Zachman Framework. It focuses primarily on describing business processes. Unfortunately, current state-of-the-art techniques for modeling processes are not very good. What we do know is that the tried-and-true approach of functional decomposition, which has performed so marvelously for engineering and manufacturing, simply does not work well for IT.

The second architecture subset deals with data. IT has, since the very beginning of computing, always separated process and data. For example, COBOL had an explicit DATA DIVISION and PROCEDURE DIVISION. Systems Analysts had entity-relationship diagrams and flowcharts. Historically, the best indicator of an IT organization’s overall success was not how good its process models were, but rather, how good the data models were.

Data models represent real-world things, called entities. For example, customers, parts, policies, contracts, employees. One job of Data Architecture is to model these real-world entities, as well as the relationships among entities. There are many kinds of relationships. Some involve one-to-one, one-to-many, and many-to-many relationships between entities. Others describe relationships among metadata (the data about the data), such as inheritance (i.e., generic-to-specific) or composite (i.e., whole-to-part). In addition to describing an organization's logical and physical data assets, Data Architecture also encompasses data management resources.

A third key element is Applications Architecture. It’s a blueprint for individual application systems, their interactions, and their relationships to the core business processes of the organization.

Then, finally, there’s Technology Architecture. What exactly is it?

The first word is technology. Let’s leave the definition of that term to each individual reader. In essence, like what the Supreme Court said about pornography, technology is very difficult to define, but you know it when you see it.

The second word is architecture. The most familiar definition deals with the art and science of designing and erecting buildings. Obviously, IT has little to do with that. Rather, the word architecture as it applies to IT, describes the orderly arrangement of parts. The obvious question then is what parts? For me, Technology Architecture parts are the individual investments that collectively makeup an enterprise’s technology portfolio.

My definition of Technology Architecture is driven by the need to bridge the gap between IT and business people. Both groups must share a sufficiently rich and expressive cognitive model so that they can engage in effective and meaningful communication about IT matters.

What boggles my mind are the pundits who preach how enterprise architects need to be able to model the relationships between business initiatives, goals, processes, organizations and policies, and the actual underlying IT infrastructure. What chutzpah, coming as it does from IT organizations that can’t even explain, rationalize or visualize their enterprise’s existing technology portfolio to business management so that those non-IT people can understand where all their past technology investment money has gone.

I advocate that IT begin by first providing visibility into infrastructure, applications, and data so that non-IT people can see what they already own. Stop trying to shroud IT with a veil of sugar-coated business-speak. Instead, provide business people with a cognitive roadmap so that they can better navigate and understand IT. Businesses cannot afford to leave technology decisions to IT. That approach is what’s gotten us into the mess we’re in today. If an organization were forced to choose between making IT more business savvy or making business more IT savvy, I’d suggest you’d get much more bang for the buck by pursuing the latter.

Therefore, Technology Architecture needs to concentrate on bridging the gap between IT and business by providing a common framework that will assist in improving understanding and communication. How? First, organize, classify, and categorize existing technology investments. Why is that important? So you can identify redundancies and reduce computing complexity. Second, use Technology Architecture to communicate standards. The combination of standards and consolidation will typically reduce an enterprise’s technology portfolio costs by at least 10%. That’s something non-IT business people will immediately understand.


Jeff Tash is CEO of Flashmap Systems, Inc. (www.FlashmapSystems.com) and creator of two free interactive sites: ITscout (www.ITscout.org), provides a formal way of organizing, classifying and categorizing the multitude of products within the computer industry in a way that both technical and non-technical people can easily understand; and the Architecture Resource Repository Site (www.ITscout.org/architecture) that provides information specific to IT architecture, including descriptions of products, consultants, concept definitions, glossary terms and more.  Jeff is a Microsoft MVP Architect and an IASA Fellow.