TOGAF and the history of enterprise architecture

TOGAF, an acronym for The Open Group Architecture Framework, is intended to be a standard way to design and implement architectures for very large computer systems. Today, 80% of Global 50 companies use TOGAF. To say it has a following is an understatement. But, as powerful as TOGAF is, it's not applicable to every situation. Those considering TOGAF need to understand the basics of the framework and the tradeoffs at hand.

[ Learn how to become a Red Hat Certified Architect. ]

In this article, we look at the background from which TOGAF emerged. Then we look at the essentials of the framework. Finally, we discuss what types of projects TOGAF is useful for and, just as importantly, the types of projects where TOGAF is to be avoided.

The genesis of enterprise architecture and TOGAF

The term "architect" is bandied about a lot these days throughout IT departments far and wide. It's also a position to which many aspire. Today you have cloud architects, software architects, solutions architects, security architects, and more. It seems as if there's an explosion of architectural activity on the IT landscape. It all might seem new, but the fact is that designing large-scale software systems is a discipline that's been around for a long time, starting early on with mainframe computers.

Big companies were the first customers of large-scale computing systems. They needed computer systems to survive. To put things in perspective, GM had over half a million employees in 1955. Both General Electric and U.S. Steel employed more than 200,000 people during that time. In terms of production, in 1955, the top automobile manufacturers produced over seven million vehicles. That kind of scale leads to distinct challenges. Not only did employees need to be paid and their tax record reconciled accordingly, but every part that went into a company's products needed to be purchased, distributed, and subjected to inventory control. The manual work required to support businesses at this scale was slow, tedious, and detail-laden. Hence, the introduction of computers and large-scale software systems.

[ A complimentary guide from Red Hat: The automation architect's handbook. ] 

Computer-driven business systems provided enormous benefits in reducing manual labor and speeding up business processes. However, when it came to creating the software systems needed, there was a lot of reinvention of the wheel going on. It wasn't the same as having a 40-year history of making automobiles.

Back then, there was no history for designing software systems, so a lot of time was spent figuring things out from scratch. But, figuring things out from scratch wasn't the same as figuring things out randomly. Those early designers were professional business process engineers with formal training in logistics, procurement, accounting, and organizational management. They understood the value of creating design methodologies that were repeatable and controllable.

At the start, these companies may not have had the know-how to build computer systems, but they did know how to make other things well on a very large scale. Remember, Ford Motor Company had the organizational wherewithal during World War II to produce one B-24 Liberator every hour on a 24/7 basis. This incredible pace was powered by business processes and efficiency possible only with standardization. Thus, standardizing design methodology was the next step in creating large-scale software systems for what was to become known as the enterprise. This drive to standardize led to TOGAF.

What is TOGAF?

The TOGAF standard describes an enterprise architecture. It's published and updated by the Open Group. The Open Group is an international organization with over 600 members from a broad variety of disciplines, including business, government, and academia, with companies such as ExxonMobil, Lockheed Martin, Nissan Motors, and even organizations typical of the software space, such as Microsoft, Oracle, and Amazon Web Services.

The first version of TOGAF was published by the Open Group in 1995. The current version of TOGAF as of this writing is version 9.2, which you can read here as a registered user. The TOGAF specification is huge. The TOGAF documentation is divided into seven parts and contains 52 chapters. Also, the publication has appendices that describe terms, definitions, and abbreviations.

What makes TOGAF unique in terms of an architectural framework is that it puts satisfying business needs as the central concern of all design activities. While this might seem like the obvious things to do, you need to remember that in very big companies, when it comes to systems design and implementation, a lot of things can get lost in translation. It's the nature of the beast.

As Yuval Harari asserts in his book, Sapiens, the maximum number of people you can have in a group where all members know each other is about 150, which is about the size of a growing early-stage startup. When the group is small, accurate word-of-mouth communication is possible. Beyond that threshold, groups need to find other ways to share knowledge and foster cooperation among employees who are essentially strangers.

Thus, large companies rely on documentation in various formats, everything from policy and procedure manuals, HR guidelines, disaster recovery plans, and sales tax regulations to investor newsletters, quarterly financial statements, and strategic white papers at the executive level. As necessary as these forms of communication are, their effectiveness is only as good as their availability, and many times their availability is less than optimal. Without a clear understanding of a business's goals, operating procedures, and constraints, it's entirely possible to create a software system that misses the mark completely and wastes years of time and money.

This is the critical value proposition of TOGAF. It's an architectural framework that, when followed correctly, ensures that the digital system created aligns with the business's goals. Remember, TOGAF is intended to be used to design and implement an enterprise architecture; the software is but a component of the greater whole.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

The four architectural domains of TOGAF

The way that TOGAF achieves its intended goal is to divide enterprise architecture into four Architectural Domains: Business, Application, Data, and Technical. Table 1 below describes the details of each domain.

1. Business

Formulates key business processes, governance guidelines, organization structure, and business strategy into a well-defined, well-understood, unified whole. Describes how the current business processes work and how they should work to meet the intended business goals according to the Architectural Vision document. The purpose of the Architectural Vision document is to "develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture."

2. Application

Provides a blueprint of the application(s) that need to be developed to support the business goals defined within the Architectural Vision document. The intended blueprint describes the logical service definitions of the application(s) to be created or refactored as well as a description of the interfaces that represent the given service.

3. Data 

The architectural domain under which logical and physical data models are developed. Activities include developing new data modes and refactoring existing ones. Identifies data management tools and technologies.

4. Technical

Defines the hardware resources required to realize the intended architecture. This includes computing, network, and storage resources.

The TOGAF Architecture Development Model (ADM)

Not only does the TOGAF define what's to be created in an enterprise architecture, which is the purpose of the four Architectural Domains, but the framework also specifies how the architecture is to be created. This specification is called the Architecture Development Method (ADM). The ADM is an eight-phase, sequential process, which is illustrated below in Figure 1.

Image

The way that the ADM works at a high level is that an organization's employees work collaboratively in each phase to create the work product specific to the given phase. Contributions are made to each phase according to the roles and expertise relevant to that phase. For example, senior business and technical staff work on the first phase, Architectural Vision, while business analysts and key departmental contributors work on the second phase, Business Architecture.

As shown above in Figure 1, each phase has a set of deliverable work products. These work products are not static. The ADM is intended to be iterative. Thus, the work products created at each phase of the ADM during a particular iteration are adjusted to reflect new information and discoveries.

How do I learn more about the TOGAF Architecture Development Model?

The ADM is an extensive and comprehensive specification intended to cover every aspect of designing and implementing an enterprise architecture. You can view a detailed explanation of each phase of the ADM on the Open Group website here.

What is TOGAF good for?

In short, TOGAF is good for implementing very big systems in very big companies. It literally attempts to leave no stone unturned when it comes to creating architectures intended to run at an enterprise scale.

TOGAF assumes it will be used by companies with many departments and that are hierarchical in terms of structure and decision-making. Thus, the framework maps directly onto these types of organizational structures. For example, a whole chapter is devoted to describing how to establish and operate an Architectural Board. An Architectural Board is a central planning committee that oversees the design and implementation of the enterprise architecture. There're chapters about Risk Management, Architecture Partitioning, and Architectural Contracts. Remember, as mentioned earlier, TOGAF has 52 chapters. It's exhaustive. However, while TOGAF is highly structured, it can accommodate other methodologies, such as Agile and DevOps. TOGAF understands it's best for companies that are highly structured organizations, but it also understands that no two companies are alike.

TOGAF supports versatility. TOGAF accepts the iterative model, which is a critical component of Agile. In fact, there is a chapter in TOGAF titled "Applying Iteration to the ADM" that discusses the nature and implementation of iteration in the Application Development Model. Also, DevOps can be accommodated by TOGAF.

[ Download now: Enterprise automation DevOps checklist. ]

TOGAF does not require the use of specific technologies and practices. It tries to stay at a very high level of abstraction. There is no direction to use a Waterfall release pattern or something along the lines of an iterative release controlled by a DevOps approach. Instead, TOGAF essentially says you can use any approach that makes sense in terms of the Architectural Vision as long as the approach is well-defined and well-known. TOGAF also requires that the risks inherent in a technical decision are identified, and mitigation plans are put in place.

TOGAF is big, detail-laden, and abstract. These qualities allow it to be applied to a variety of companies. Bear in mind, however, TOGAF is not everything to everybody. It does have limitations.

What are the limitations?

As mentioned at the start of this piece, TOGAF is designed for very big companies that want to implement very big enterprise architectures. Remember, the systems that are built according to TOGAF usually affect thousands of employees. It's not unusual for an enterprise architecture to have a budget that starts at millions of dollars. Hence, the key limitation of TOGAF is the price. A company needs to have deep pockets to accommodate the expense. If yours is a company with $100,000 in seed money, TOGAF is not for you. You'll eat that $100K on meetings alone.

Another limitation of TOGAF is that it's designed for companies that are hierarchical and departmentalized. Suppose you have a company with a flattened management hierarchy and an independent-minded workforce, such as those smaller companies found in the open-source landscape. In that case, TOGAF is probably not for you.

The final limitation of TOGAF is that it takes a lot of time to learn the specification's details. The TOGAF specification is over 800 pages. That's a lot of information to absorb and remember.

Typically, companies intent on using TOGAF want their enterprise architects to be TOGAF-certified. To get certified, candidates need to take an exam that is divided into two parts. Part 1 is a 40-question multiple-choice test that examines your basic knowledge of the TOGAF framework. Part 2 is a scenario-based test in which you are given eight scenarios that describe various situations in which TOGAF will be used. Each scenario comes with a multiple-choice question to answer. Unlike Part 1, where answers are either right or wrong, the answers to questions in Part 2 are awarded points according to the degree of correctness.

As you can see, it takes a considerable amount of time to learn TOGAF and even more time to get the experience necessary to work with it competently. If you have the time and wherewithal to learn TOGAF and want to work for a big company that will benefit from it, then TOGAF is for you. Otherwise, its professional value is limited.

Putting it all together

Enterprise architecture (EA) is a difficult undertaking. According to EA expert Ken Geisi in an article in Forbes magazine, "...EA is about the skillful manipulation of an enterprise's structure and behavior within a complex environment."

When you get to be the size of Boeing or Hewlett Packard, you can't make it up as you go along. You need a framework such as TOGAF to provide the formality, structure, and discipline that big companies need to implement enterprise architectures that affect tens or maybe hundreds of thousands of employees. The risks are too significant to do otherwise. It is not by accident that TOGAF is used by 60% of Fortune 500 companies. TOGAF is intended to do big things in big companies in a big way.

While there are detractors that say that TOGAF is nice in theory but rare in practical implementation, the fact remains that there are over 77,000 TOGAF-certified enterprise architects in the world today. TOGAF remains a significant presence in the enterprise architecture landscape. While it's a highly-structured framework, it's not static. It's been through nine revisions since it debuted in 1995. Hopefully, as its history demonstrates, it will continue to change. The enterprise needs TOGAF, and it needs it to change to keep up with the new technologies and trends that will appear in the enterprise in the years to come.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

TOGAF is a registered trademark of The Open Group.