Chapter 1
EAG History

This book isn’t the first attempt to try to organize IT complexity and manage it at an enterprise level. The industry terms for these efforts are “Enterprise Architecture” and “Governance.”

Very few big ideas appear out of a vacuum. My own understanding of enterprise architecture and governance owes a great deal to the dialog that has been going on in this field for the last thirty years. Before adding my own thoughts, I want to sketch some of the foundational work of Enterprise Architecture (EA) and Enterprise Governance. These two disciplines have always been closely related, and are now considered the single topic Enterprise Architecture and Governance, or EAG.

1987 - The Zachman Framework (John Zachman)

John Zachman was an early pioneer in breaking down IT complexity into manageable “chunks.” In 1987, he wrote an article describing A Framework for Information Systems Architecture in the IBM Systems Journal. His conceptual framework organized discussions and work products into six silos: “what” (information), “how” (applications), “where” (technology), “who” (people), “when” (scheduling and priorities), and “why” (motivation and goals). He then divided each of these silos into five levels of abstraction. His framework is shown in Figure 1.1.

For each cell in this grid, Zachman described the decisions required before continuing down to a lower level of detail, and he recommended the artifacts that should be used to document these decisions and share them with other silos at that same level. For example, in the Data column of the grid, a logical model is at a higher level of abstraction than the physical model, and must be completed first. Further, an information architect might document the physical model using an Entity Relationship Diagram (ERD), but pass certain structures to the application architect using an XML document artifact, so that the application architect working at that same level of abstraction can easily incorporate the data structures into the enterprise services they are developing.

The most important concepts Zachman brought to the discussion of Architecture and Governance were:

• Dividing complexity into “domains” of architecture, each with its own subject area experts
• Working through concepts at higher levels of abstraction first before drilling down into detail
• Agreeing on a common standard for documenting and exchanging work products across levels of complexity, and across the domains of architecture

The Zachman Framework is particularly helpful in organizing software development lifecycle (SDLC) functions. In that context, it is just as relevant today as it was thirty years ago, and should be required reading for every architect. It’s less useful for managing other IT infrastructure areas such as the hardware lifecycle functions and security provisioning and de-provisioning functions.

Several software development tool sets support the Zachman Framework. For example, The IBM Rational suite has a data modeling tool and an application development tool that support the UML documentation artifacts proposed by Zachman, and interchange data between domains in the ways Zachman proposed in order to facilitate cross-domain enterprise architecture. It isn’t necessary to purchase a suite of architecture tools like this, but it is necessary to define and manage how the different architectural domains communicate with each other to achieve cohesive software development process results.

Recommended reading:

Enterprise Architecture Using the Zachman Framework (MIS), by Carol O’Rourke and Neil Fishman

1989 - National Institute of Technology (NIST) Model

A couple of years later in 1989, the National Institute of Standards and Technology (NIST) developed a model for enterprise architecture. This model didn’t initially incorporate Zachman’s concept of architectural segments, but did introduce the idea that architecture is hierarchical. According to the NIST model, the flow is:

• Industry - Regulatory or certification requirements
• Corporate - Executive leadership goals, which are typically adjusted annually
• Departmental – Specific projects that support the goals of the executive leadership
• IT - priorities in support of departmental business goals. Within IT, NIST prioritized information first, followed by applications and technology.

According to the NIST model, at the highest level there are governmental and industry requirements and standards which are non-negotiable. You can’t design a complete business solution first, and then pause to consider compliance requirements afterward.

Within those compliance restrictions, the executive leadership of the company will make decisions about how the company will comply and compete. Executive goals typically support one of the big three cross-industry business drivers:

• Increase revenue
• Decrease expenses (both cost and risk)
• Grow the company

Based on the executive leadership decisions, each business unit will then decide how they will contribute to and support the corporate vision with products and services. Then the IT architecture team will design the information systems to support the business unit vision. It’s a bit more complicated than that, the point being that there’s a decision hierarchy in which each layer has the freedom and responsibility to exercise their best judgment and experience, but only in a way that supports decisions made at the next higher level. NIST was the first organization to consistently use the term Enterprise Architecture (or EA) to describe this attempt to organize the chaos of individual departmental or project architectural decisions into a cohesive enterprise vision.

In the NIST model, business architecture drives information architecture, which in turn drives the infrastructure architecture. This is represented in Figure 1.2.

The NIST model continues to evolve and remains very relevant today. In particular, the NIST Cyber Security Framework (NIST CSF) is one of the most widely used security compliance programs.

Recommended Reading:

NIST Enterprise Architecture Model, by Lambert M. Surhone,

Figure 1.2 NIST Enterprise Architecture Model1

1992 - Stephen Spewak – Enterprise Architecture Planning (EAP)

In 1992, Stephen Spewak published his seminal book entitled Enterprise Architecture Planning (EAP) which merged Zachman’s concept of architectural segments with the NIST concept of a hierarchical tree or pyramid of decision-making responsibility. Spewak defined Enterprise Architecture Planning as “the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures.”

Following the precedent set by NIST, Spewak insisted that a business-oriented (rather than IT-oriented) approach to architecture planning is critical to providing an architecture that supports the business and contains costs. To Spewak, enterprise architecture exists to better use information in support of the business.

Unlike Zachman, Spewak used only four architectural areas, saying that the business architects owned the who, when, and why columns of Zachman’s framework. Spewak arranged the architectural segments as follows.

1. Business Architecture (Zachman’s People, Time, and Motivation domains)
2. Information Architecture (Zachman’s Data domain) in support of the business
3. Application Architecture (Zachman’s Function domain) in support of the information
4. Technology Architecture (Zachman’s Network domain) in support of the applications

We now know these four architectural areas as the domains of enterprise architecture and governance, or EAG. In the Zachman Framework, the domains were equal peers.2 In Spewak’s model, the business architect is in the driver’s seat. The architect determines which feature is most pressing, how that function should work, and when it must be available. Note that this function falls to a “business architect,” rather than to the more generic “business.” This architect is a business professional especially selected to give strategic direction to the IT organization.

Based on the direction provided by the business architects, the information architects will determine what data needs to be collected to support the business and how the different data elements relate to each other. Then the application architects will decide how to implement the business processes that the business architects have defined, using the information that the information architects have defined. Finally, the technology architects will define components such as servers, disks, and networks necessary to support the information and application required by the business process.

Spewak’s work left a significant contribution to the discussion of enterprise architecture and governance: he defined four architectural domains and their precedents. He seemed to view the IT organization as an orchestra of different IT instruments, all under the control of the business conductor.

This is an accurate metaphor for IT management. You’ve probably heard those moments before a conductor takes the stand when all the various musicians are warming up, each practicing the section they consider most important. It’s a cacophony of noise and an accurate picture of many IT organizations. Then the conductor takes the stand, focuses all the players on the same page, and the chaos is transformed into a beautiful symphony.

Spewak’s organization of IT into three domains under the control of the business is still a best practice today.

Recommended Reading:

Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, by Steven H. Spewak and John A Zachman, 1993, Wiley.

1994 - The Open Group Architectural Framework (TOGAF)

In the early 1990’s, businesses in every industry were feeling the pain of internal systems that did not play well with each other or adequately support real business needs. Everyone was ready to invest in enterprise architecture and governance in order to solve this problem. At the time, the problem was that EA was defined in theory, but not in practice. EA frameworks offered no real guidance on how to get from point A (inefficient IT chaos) to point B (well-managed, flexible IT that supports the business efficiently). Everyone wanted to see an example of a successful EA/EAG program, complete with strategies, policies, processes, standards, and roles all documented, so that they could copy it and modify as necessary. If you want to build a custom house that meets your needs, it’s far easier to modify plans of an existing house than to start with a blank sheet of paper. This is where TOGAF came in.

In 1994, The Open Group attempted to address the need for a practical EAG implementation by taking some Department of Defense standards as a starting point to build The Open Group Architectural Framework (TOGAF). In the minds of many, this was less a framework than it was a sample implementation.

TOGAF consisted of a technical reference model and a list of recommended standards. TOGAF also provides much more guidance on governance policies that the previous frameworks lacked. As we will discuss later, these robust policies and standards made TOGAF the transition point between Enterprise Architecture (EA) and Enterprise Architecture and Governance (EAG).

Version 9.1, introduced in 2011, adds some level of guidance that was previously missing, but in reality, TOGAF is still a reasonably generic published implementation of EAG that a company can look at to get an idea of how they might solve similar problems in a way that works for them. As of 2016, The Open Group claimed that 80% of the global 50 and 60% of the Fortune 500 companies employ TOGAF.3 That’s no doubt true, but in most cases, what that really means is that these companies have all looked at the detailed blueprint for the TOGAF house and stolen ideas they thought would work well with minimal modification in the house they were building. They didn’t actually build the TOGAF blueprint. No one really adopts TOGAF as an enterprise framework – they just copy large parts of it to use in their own architecture and governance framework.

That said, TOGAF is extremely helpful, especially its standards for the technology domain. I suspect this is because technology architecture concepts transfer easily from industry to industry. A bank and a utility company have very different business models, information, and applications, but the technology in their computer rooms will look very similar.

Nevertheless, while TOGAF is a very interesting architectural blueprint, it isn’t as helpful in guiding you through the thought process of changing your current architecture to more efficiently and effectively serve the needs of the business.

Finding a blueprint with design ideas you like is great, but you’ll still need a lot of additional knowledge and experience before you can tear down the walls of the house you currently live in. TOGAF provided the design ideas, but not the systematic implementation guidance.

Figure 1.4 TOGAF Architecture Development Methodology4

Recommended reading:

TOGAF Version 9.1, by Van Haren Publishing.

1996 - Control Objectives for Information Technology (COBIT)

The International Systems Audit and Control Association (ISACA) released its “Control Objectives for Information and Related Technologies” in 1996. The “and Related” was soon dropped from common usage, and the standard became known as COBIT. This standard supposedly provided an implementable “set of controls over information technology and organized them around a logical framework of IT-related processes.”5

IT architects didn’t develop COBIT. It was initially developed by auditors who would go into various companies to document and assess those companies’ processes. These auditors needed a standard list of questions to ask about IT functions, and a standard way to document policies, standards, processes and roles so that the documentation produced by all the different auditors could be compiled into a cohesive and unified whole.

One of the new ideas that COBIT brought to the table was their focus on processes, rather than the information, applications, and technology used by those processes. The real focus is on the risks inherent in the process and the controls that mitigate those risks – hence the name “Control Objectives for IT.” The original intent of COBIT was controlling the risks in IT processes.

COBIT is a set of best practices for documenting processes and evaluating their maturity, including:

• A standardized way of documenting roles and responsibilities for a process using the “RACI” model, specifying personnel details including:
  • Responsible – Who does the actual work?
  • Accountable – Who must sign off/approve work?
  • Consulted – Which experts have the necessary knowledge and skills?
  • Informed – Who should know the results?
• A standardized way of assessing the maturity of a process during an audit, which can be described by the following stages:
  • Level 0 – Non-Existent. Management processes are not applied at all.
  • Level 1 – Initial. Processes are ad-hoc and disorganized.
  • Level 2 – Repeatable. Processes follow a regular pattern.
  • Level 3 – Defined. Processes are documented and communicated.
  • Level 4 – Managed. Processes are monitored and measured.
  • Level 5 – Optimized. Best practices are followed and automated.

COBIT isn’t a list of processes that you can pick up and drop into your company so much as it is a way to develop, document and asses the processes you already have. Think of it as a best practice for documenting and evaluating processes. COBIT isn’t an enterprise architecture framework; it’s a way of documenting the processes and roles in an enterprise architecture framework. COBIT can’t tell you what roles to use; it tells you how to document those roles.

Regardless, COBIT has a lot of outstanding information when it comes to thinking about the processes in your architecture. They are thought leaders for documenting IT governance and measuring risk and maturity. COBIT belongs in the toolkit and on the bookshelf of every architect and technical writer.

Recommended reading:

• COBIT 5 Framework, by ISACA.
• Enterprise Governance of Information Technology – Achieving Alignment and Value Featuring COBIT 5, by Steven De Haas and Wim Van Grembergen.

1989-1996 - Information Technology Infrastructure Library (ITIL)

Between 1989 and 1996, the UK government’s Central Computer and Telecommunications Agency (CCTA) published a series of recommendations to standardize IT services management, controlling and managing the services IT used to support the business. In their Information Technology Infrastructure Library (ITIL), a “service” is something performed by IT, but it is defined in a way that describes a service provided to the business.

Figure 1.5 The ITIL library6

ITIL isn’t an enterprise architecture framework in the sense that it can be used to document and manage all of your company-specific IT processes, but it does include definitions, best practices, and standards for many processes that need to be included in any IT architectural framework. It maintains a very good focus on the fact that these services exist to support the business, and it contains a strong emphasis on continuing process improvement.

ITIL is one of the most useful frameworks for ensuring completion of processes (both in breadth and depth of detail) for most IT functions. For relatively common, cross industry processes such as change management and disaster recovery, the ITIL library is a fantastic template to use to make sure you are considering everything you need to include in your architecture and governance programs.

Unfortunately, ITIL isn’t nearly as helpful for less common processes that are specific to your particular industry. A 2004 survey of companies that had adopted ITIL revealed that 77% agreed, “ITIL does not have all the answers.”7

While ITIL is extremely valuable, it is also extremely proprietary. CCTA and a professional services company now jointly own the ITIL framework and the books and training have become quite expensive.

Many other frameworks for managing IT services have emerged since the inception of ITIL, including Business Service Management (BSM) and IT Service Management (ITSM), FitSIM (lightweight service management), ISO/EIC 20000 and the Microsoft Operations Framework (MOF). Each of these has strengths and weaknesses. The main obstacles with leaning on these frameworks for your enterprise architecture are:

• The services are very generic. In order to be widely useful to companies across all industries, the framework must be rather generic. Generic guidelines trap adopters in a mindset of applying guidelines exactly as documented, regardless of industry or company-specific constraints.
• They may become quickly outdated. At the time of their development, they reflected the best practices in technology. Technology is advancing all the time, and a very detailed, complex set of guidelines just can’t keep up with the advances. The more time and effort a framework invests in describing best practice detail, the harder it is for the framework to keep these details updated with rapidly changing technology.
• They stop you from dreaming. They tend to focus on what you should do today, not how to determine what you should do tomorrow. They address governance of today, but not strategy for tomorrow. If you give up your architecture to a third party, you become dependent on them to build your future. You stop making plans to respond to disruptive innovations like big data, blockchain, and cloud and simply wait for the third party to tell you how to respond.
• They don’t provide a roadmap. They describe what you should be doing, but don’t provide any recommendation on how to implement change. They describe how much greener the grass is on the other side, but don’t describe the path to get there from where you are today.

In the next chapter, we’ll try to assimilate all of these various standards and best practices into a single, comprehensive framework, in what I believe is a logical next-step in the evolution of the attempt to manage IT complexity on behalf of the business.