Enterprise Architecture: From Folklore to Facts: Part I of II

Untitled Document

Once upon a time there was a brave consultant who traveled to many companies across many distant lands. Even though the companies she visited were diverse in their pursuits, she encountered many a common theme. She would ask the same question to different business units within the same company and get terrifyingly different answers. She noted that meeting new strategic initiatives was a guaranteed scary proposition and that IT was viewed as that multi-headed monster better known as a bottleneck. Amazingly, information was almost never available at the right place to the right people at the right time, and if it was it really could not be trusted! To add insult to injury, no matter how hard the employees seemed to work they always seemed to be one step behind from where they needed to be.

Then one day this brave consultant came upon a company where IT was a strategic partner with the business supporting such amazing capabilities as portability, interoperability, and extensibility. IT value was completely justified; there was a sense of reduced risk and an unprecedented amount of flexibility in make, buy, and sourcing decisions. Employees in this company worked less, were more relaxed, and yet they managed to stay ahead of their peers in their market. How could this be? And it was that fateful day that she discovered the wonders of enterprise architecture!

Hmm...is this déjà vu?

Alas, if only the above narration were just a story! Unfortunately, this "story" is my experience and more than likely the experience of each and every one of you reading this article. Yes, it is true that a deliberate enterprise architecture can really transform the way a company does business. It can provide a strategic foundation that realizes the company's operating model, and can incorporate the necessary governance processes to ensure the continued alignment of the enterprise architecture with the operating model as it evolves.

Such claims of positive transformation are supported by numerous surveys conducted by reputed institutions such as Gartner, Infosys, Harvard Business School, etc., which show that companies with a well-articulated, deliberate enterprise architecture consistently outperform their peers who lack such an enterprise architecture by achieving higher profitability, better productivity, and lowered IT costs. All this sounds great, but unfortunately, have you ever heard of a free lunch? Veteran architects will undoubtedly attest to the fact that enterprise architecture is a complex undertaking that takes hard work and commitment from all levels of an organization, especially from the higher levels. The good news is that there is a broad base of knowledge to leverage in the field of enterprise architecture, most of which is encapsulated in well-known enterprise architecture frameworks such as TOGAF, Zachman, and others.

So, with this context in mind, let us now embark on the journey that our brave consultant might have taken as she discovered the promise of enterprise architecture.

Defining "architecture"

First things first - it's really hard to talk about enterprise architecture without leveling what we mean by the term "architecture". Honestly, sometimes I feel that we architects spend more time defining and re-defining concepts than professionals in any other field. Just look at the many diverse and interesting definitions of architecture you can find at the following web page maintained by the Software Engineering Institute: http://www.sei.cmu.edu/architecture/definitions.html.

For our discussion, let's take a look at how architecture is defined by four authoritative sources: the Software Engineering Institute (SEI), IEEE, the Rational Unified Process (Grady Booch et. al.), and The Open Group (TOGAF).

The Software Engineering Institute (SEI): The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

ANSI/IEEE Std 1471-2000: The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Grady Booch et. al. in the Rational Unified Process (RUP): An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition.

The Open Group (TOGAF): The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. A detailed plan of the system at component level that can guide its implementation.

Each of these definitions attributes architecture with three common themes:

  • It is the structure of a system
  • It includes the relationship between these structures
  • It includes the principles and guidelines that govern the design and evolution of the system

Defining "enterprise"

Putting enterprise architecture in context requires one to understand two distinct concepts: architecture, which we already looked at, and an enterprise. Simply put, an enterprise is any collection of organizations that has a common set of goals and/or a single bottom line. Based on this definition, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. Nowadays people often refer to the concept of an extended enterprise, which not only includes the organization itself but also includes the organization's partners, suppliers, and customers.

Moving on to enterprise architecture

The MIT Center for Information Systems Research defines enterprise architecture as "the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm's operating model." As you might notice, this eloquent definition brings together the key concepts from both the "architecture" and "enterprise" descriptions.

Stated differently, enterprise architecture is the blueprint that translates an enterprise's strategic goals and operating model into an executable architecture of processes and infrastructure. If this reads like a mouthful, just imagine the complexity of actually defining and then implementing the enterprise architecture. As luck would have it that is exactly where enterprise architecture frameworks such as TOGAF help save the day. Enterprise architecture frameworks such as TOGAF encapsulate a broad body of knowledge in the form of standard methods, defined processes, common vocabulary, guidelines, best practices, case studies, tools, and technologies that enable the architect in designing and implementing the right enterprise architecture.

So without further ado, let's examine TOGAF, one of the leading enterprise architecture frameworks available today.


The Open Group Architecture Framework, TOGAF, is developed and maintained by The Open Group Architecture Forum and its 350 members. TOGAF may be reproduced freely by any enterprise wishing to use it to develop a broad range of enterprise architectures. The first version of TOGAF, developed in 1995, was based on the U.S. Department of Defense Technical Architecture Framework for Information Management (TAFIM). Since then TOGAF has continuously evolved such that it has become the de facto global standard for assisting in the acceptance, production, use, and maintenance of architectures.

As shown in Figure 1, TOGAF identifies four types of architecture as subsets of the overall enterprise architecture discipline:

  • A business (or business process) architecture that defines the business strategy, governance, organization, and key business processes
  • A data architecture that describes the structure of an organization's logical and physical data assets and data management resources. Data architecture does not include the design of the actual physical data stores (or database)
  • An applications architecture that provides the blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. The application architecture in TOGAF is not concerned with the actual software applications but rather limits the term application to a logical grouping of functionality
  • A technology architecture that describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Figure 1: The TOGAF Enterprise Architecture Puzzle

The TOGAF 8.1.1 enterprise architecture framework consists of three core components as shown in Figure 2.

Figure 2: TOGAF 8.1.1 Core Components

Let's look at each of the three components starting with the ADM.

The Architecture Development Method (ADM)

The key to TOGAF is the TOGAF Architecture Development Method (ADM) that explains how to create an organization-specific enterprise architecture that addresses business requirements. The ADM provides:

  • A reliable, proven way of developing the architecture
  • Architecture views which enable the architect to ensure that a complex set of requirements are adequately addressed
  • Linkages to practical case studies
  • Guidelines on tools for architecture development

The ADM is structured as a series of nine phases plus a requirements management phase that interacts with each of the nine phases throughout the ADM lifecycle. The ADM is shown in Figure 3.

Although, based on Figure 3, the ADM might appear sequential or "waterfall" in nature, in reality the ADM is iterative, over the whole process, between phases, and even within phases.

The Enterprise Continuum

The Enterprise Continuum, which is another core component of TOGAF, is a "virtual repository" of all architecture assets -- models, patterns, architecture descriptions, and other artifacts -- that exist not only within the enterprise itself but also in the IT industry at large. Artifacts in the Enterprise Continuum provide a valuable foundation to build upon and leverage as the enterprise charges forward in its enterprise architecture endeavor. The TOGAF ADM works synergistically with the Enterprise Continuum by providing constant reminders as to which assets from the Enterprise Continuum the architect should use as they progress through the ADM.

The Enterprise Continuum comprises of two "sub continuums," the Architecture Continuum and the Solutions Continuum. The Architecture Continuum offers a consistent way to define and understand the generic rules, representations, and relationships in an information system. It:

  • Represents a structuring of re-usable architecture assets
  • Shows the relationships among foundational architectures (such as the TOGAF Reference Model, TRM), common systems architectures (such as the III-RM), industry architectures, and enterprise architectures
  • Serves as a useful tool to discover commonality and eliminate unnecessary redundancy

The Solutions Continuum provides a consistent way to describe and understand the implementation of the Architecture Continuum. It:

  • Defines what is available in the organizational environment as re-usable Solutions Building Blocks (SBB)
  • Addresses the commonalities and differences among the products, systems, and services of implemented systems

As shown in Figure 4, the Architecture Continuum guides the Solutions Continuum in the types of products and solutions that are needed by the enterprise. Conversely, the Solutions Continuum supports the Architecture Continuum with specific capabilities needed to translate the architecture vision into an executable reality.

Figure 4: Synergistic relationship between the Architecture and Solutions Continuum

The Resource Base

The final core component of TOGAF, the Resource Base, is a set of resources -- guidelines, templates, background information, etc. -- to help the architect in the use of the ADM. Excellent information is included on a broad spectrum on relevant topics such as:

  • Architecture Boards, Architecture Compliance, and Architecture Contracts
  • Architecture Governance and Architecture Maturity Models
  • Architecture Patterns and Principles
  • Architecture Skills Framework
  • Developing Architecture Views
  • Case Studies and Business Scenarios
  • Other Architectures and Frameworks
  • Tools for Architecture Development
  • Detailed information on using the ADM with the Zachman Framework
  • TOGAF -- Integration with Other Frameworks

Although TOGAF is quite comprehensive in what it offers, it is not designed to be an island by itself. Rather, a well thought out integration of TOGAF with another framework can lead to a very potent combination. Let's take a quick look at two such examples where TOGAF is integrated with another well-known industry framework.

TOGAF and the Zachman Framework

The Zachman Framework was created by John Zachman in 1987 with the goal of standardizing the structuring and organization of the massive amounts of data collected in an enterprise architecture effort. It is used extensively in both the commercial and federal civilian worlds and has rapidly become the de facto standard for classifying the artifacts developed in enterprise architecture. As shown in Figure 5, it is organized as a six-by-six matrix structure with the columns representing various aspects of the enterprise that can be described or modeled and the rows representing the various viewpoints.

To enlarge Figure 5, click here.

As one peruses the Zachman Framework, it becomes quite obvious that the scope of the four architecture domains of TOGAF align very well with the first four rows of the Zachman Framework. It also becomes evident that the Zachman Framework could serve as an excellent gap analysis tool in a TOGAF initiative for analyzing the current state (baseline) of an enterprise, identifying risk areas, and prioritizing effort.

Conversely, the Zachman Framework says nothing about the processes for developing viewpoints or conformant views, or the order in which they should be developed as one starts filling out the matrix structure. If you've been following the article so far, you should be thinking to yourself at this point that the TOGAF ADM can very easily fulfill this void. If you would like to learn more about the integration between these two exciting frameworks, please refer to chapter 39 in the TOGAF documentation in the References section.


The Rational Unified Process (RUP) is a mainstream software development process framework well known within the software engineering community. A mapping between TOGAF and RUP has several benefits:

  • TOGAF, and for that matter enterprise architecture in general, is still not as mainstream of a discipline like software development. Therefore, it might be much easier to convince an organization of a TOGAF-based enterprise architecture effort when it is mapped to a better-known process such as RUP.
  • Although well-documented, TOGAF, by design, lacks specificity in several areas, such as tools and artifacts. As an example, TOGAF does not have a comprehensive artifact library available. Mapping TOGAF to RUP can help fill in such blanks.
  • Many of the architects involved in (and oftentimes leading) an enterprise architecture effort have a software engineering background. Of these, most are familiar with RUP (or some variation of it). In these cases, mapping TOGAF to RUP can help alleviate some of the initial apprehension of embarking on the enterprise architecture journey.

The integration between TOGAF and RUP can be either "black box" or "white box." Discussing the specifics of either method is well beyond the scope of this article.


So, it was a fateful day indeed when our brave consultant discovered enterprise architecture in a company where business and IT walked side-by side, hand-in-hand creating an environment in which day-to-day operations were performed more efficiently, employees were under less stress, and market leadership was part of "just how things were done." She also discovered that although establishing the "right" enterprise architecture could be a daunting task, an enterprise architecture framework such as TOGAF would greatly help in her new found mission of enlightening others as to the limitless possibilities with the "right" enterprise architecture. Thus, it was from that day on that she spent the remainder of her consulting years going from company to company helping each company realize the promise of enterprise architecture. The world was finally at peace and everyone lived happily ever after.

About the Author

Tarak Modi, currently Vice President and Chief Technology Officer at CALIBRE systems - an employee owned management and technology services company, is an industry thought leader in IT transformation and modernization technology such as enterprise architecture, SOA and cloud computing. In this podcast, we pick up on our cloud computing discussion from our very first pocast with Tarak to see how the Federal government has continued along its journey towards the adoption of Cloud Computing.

More by Tarak Modi