Understanding TOGAF®

Even though TOGAF® came nearly two decades after the Zachman Framework (https://www.zachman.com/about-the-zachman-framework) was introduced, it dominated the market very quickly and became one of the most important standards in the EA domain. John Zachman was the first to introduce the concept of EA in the mid-eighties and defined an EA framework carrying his name. For many reasons, the Zachman Framework was not adopted by many architects, but the idea remained in many people's minds.

TOGAF® started to gain popularity in late 2002 when The Open Group® introduced version 8.0. From there onward, it continued to gain popularity and started to become the de facto standard in the EA domain especially when The Open Group® released version 9.0 in early 2009, followed by 9.1, and finally 9.2 in 2018. TOGAF® became popular because it provided enterprise architects with rich content that guides their development journeys and makes implementing EA achievable.

Architects chose to follow TOGAF® for many reasons, which we will talk about later in this section. However, implementing TOGAF® was not a straightforward journey for many, and it brought new challenges and difficulties to the architects. As a result, many EA projects ended up with massive scope creep, unneeded outcomes, and useless acronyms. Therefore, many EA projects got terminated due to low return on investment and more people lost faith in EA as a practical approach even with TOGAF®. In this section, we will talk about the following:

• The benefits of using TOGAF® as a framework for implementing EA projects
• The drawbacks that make implementing TOGAF® challenging

While you read this section, I am sure that you will recall similar situations that you or your team have faced in your EA implementation journey.

TOGAF® implementation benefits

The following features are some advantages that made TOGAF® the preferred choice over other frameworks for many architects:

• Complete online documentation that is freely available.
• An easy-to-follow process.
• It fits architects with different experience.
• A rich content metamodel.
• It's loaded with guidelines and techniques.
• It encourages learning.

We will look at each benefit individually in the following subsections and see why more than 111,000 individuals from over 144 countries have chosen to use TOGAF® and be certified in it (according to https://togaf9-cert.opengroup.org/certified-individuals on the date of writing this paragraph).

Complete online documentation that is freely available

The Open Group® has provided all the TOGAF® versions online and for free with anonymous access. This makes it possible for people at all levels of experience to explore, read, and learn the framework at their own pace without feeling constrained by costly subscriptions or time-limited trials. You do not even need to register on the website to be granted access to the content, which is something that not all frameworks provide. Some frameworks require paid memberships, and some require at least creating a profile, but this is not the case with TOGAF®. EA practitioners also find it very convenient to have the material online and accessible anytime, anywhere, and on any device.

Note

Even after being TOGAF® certified for years and practicing it continuously for about 15 years, I always have the website bookmarked in my browser.

An easy-to-follow process

One of the core TOGAF® components is the Architecture Development Method (ADM), which is a series of phases, each with a defined set of inputs, steps, and outputs. Architects find it easy to follow the ADM, especially architects coming from an IT background. They all know that if you want to build a solution, you need to first envision it, define its requirements, plan it, design it, build it, deploy it, and then operate it, which is very well known as the System Development Life Cycle (SDLC). The ADM has a similar concept to the SDLC, but the objective is to architect the entire enterprise and not a single IT solution.

The following diagram represents the ADM cycle as defined by TOGAF® here: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap04.html, using ArchiMate® 3.1 notation:

Figure 1.1 – An ArchiMate® representation of the ADM cycle (The Open Group®)

As you can see, the ADM cycle starts with the Preliminary Phase, which establishes the EA practice and formalizes the choice of tools and methodology. It is then followed by eight iterative phases that cover one part of the enterprise at a time.

It fits architects with different experience

Architects coming from different backgrounds and with different experience can all find something useful in TOGAF® that they can use in their area of expertise. Solution architects who have TOGAF® experience will have a better understanding of a business and be able to provide it with the right solutions that address its requirements and strategic directions. A second example would be project managers with TOGAF® experience, who will find it easy to upgrade their project management skills to program and portfolio management because understanding TOGAF® helps them understand how the enterprise works and how to have a holistic view of the different moving parts. IT operations managers with TOGAF® experience can use its Technical Reference Model (TRM) to categorize and classify the technology stack in their organizations using an industry-standard method, which helps them make the right decisions.

The list of examples can include every single member within the enterprise, so TOGAF® is an extremely useful and flexible framework that offers something for every practitioner, and each person will benefit from it differently.

A rich content metamodel

The metamodel provides architects with a foundation that tells them what the components of the enterprise are and how they are related to each other.

The TOGAF® metamodel, along with the taxonomy, provides architects with a better understanding so that they can describe the enterprise with consistency even if they look from different perspectives. Classifying and categorizing the elements and relationships of the enterprise is the heart and soul of EA. Here is the full TOGAF® 9.2 content metamodel: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html#tag_30_03.

Additionally, TOGAF® provides a taxonomy and definition for all the keywords that architects use, which helps in unifying the language among different architects and makes their communications and documentation easier. People from different backgrounds can still argue the meanings of these definitions based on their interpretations but having a taxonomy can dramatically reduce these arguments. The Open Group® has even extended the TOGAF® taxonomy through ArchiMate®, which makes the combination of the two a complete and detailed set.

Important Note

This book will use the taxonomy defined by The Open Group® in both the TOGAF® 9.2 and ArchiMate® 3.1 materials as they are and will elaborate more for greater clarity.

It's loaded with guidelines and techniques

TOGAF® has tried to address all the issues that enterprise architects may encounter during their implementation engagements. It provides a set of useful tools, materials, and techniques, such as the following:

• A set of principles that enterprise architects can start with and modify as needed.
• Stakeholder management techniques and a proposed set of artifacts that can be of interest to different stakeholders.
• Patterns and techniques to segment and control the scope and size of the EA practice.
• A high-level governance model that can fit any size organization and team.
• A general structure of the EA content repository that can be scaled up or down as needed.

The complete list of guidelines and techniques is too long to be covered in this book and you may have already experienced some or all of them. Please refer to https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap17.html if you want to learn more about them.

It encourages learning

With more people showing an interest in TOGAF®, The Open Group® wanted to encourage practitioners to be distinguished by becoming certified in the framework. With the increasing demand for experienced enterprise architects, becoming TOGAF® certified is a desire and sometimes a requirement by employers when hiring or contracting.

Just like anything good in life, the benefits of the framework come with a cost, which can outweigh the benefits if not handled with care. After having a quick look at the benefits of using TOGAF®, let's review some of the drawbacks that can be associated with TOGAF® implementations.

TOGAF® implementation drawbacks

Even with all the materials that TOGAF® offers, not every implementation project ends as planned, if it ends at all. Some EA implementations end up delivering something different than what was originally planned, some end up in a massive scope creep that overwhelms the project with infinite tasks and activities, and some remain within the drawers of the EA team until the sponsors decide to pull the plug.

In this section, we will highlight the things that may contribute to these results, and will provide you with some example traps that some architects may have fallen into; you may have witnessed or experienced some of them during your EA journey:

• The ADM is a giant waterfall process.
• The lack of practicality.
• High cost-to-value ratio.
• TOGAF® is mostly adopted by IT people.

Let's look at each of these in more detail in the following subsections.

The ADM is a giant waterfall process

As mentioned earlier, the ADM is a major factor in the success of TOGAF®. However, ADM is a sequence of phases, which turns out to be a waterfall method by nature. Therefore, TOGAF® provided a chapter explaining how to use the ADM iteratively (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap18.html), and another chapter on Architecture Partitioning to help keep the scope of work under control by dividing it into smaller partitions (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap36.html). Even with these techniques, there is still huge room for making scope mistakes because following a phased approach can end up with one phase requiring completion before starting the next. Attempting to finish a phase with all the details, inputs, steps, and outputs that are defined in the ADM can leave you and your team with an infinite set of tasks to do.

Note

Please keep in mind that I am talking from practical experience and how I have seen things ending up in most cases. The problem is not in TOGAF® itself, but with the wrong interpretation by the practitioners of how many details need to be defined for each ADM phase.

For example, in the ADM, architects start with the Preliminary Phase, which has an objective to define and establish the detailed processes and resources for Architecture Governance (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html). Having this objective is understandable because, without governance, no project will be completed.

Establishing the Architecture Governance Board (AGB), which is the governance body that approves or rejects changes to the architecture, and defining their roles and responsibilities, their job descriptions, the governance processes, and the key performance indicators can take anywhere between a single day and 6 months, which is what I like to call the Effort Blackhole. This refers to a situation in which all the effort that you and your team put into finishing the phase will never end and there will always be the need for more.

Additionally, having this objective in the Preliminary Phase before the project is officially started makes it difficult for stakeholders and governance board members to understand how to govern something that does not yet exist. They can outline some processes and assign responsibilities, but that must start at a high level, then they'd need to get details as the organization's architecture maturity level increases. They may easily end up spending their time defining and refining these processes because it is not clear yet what to govern. The Effort Blackhole starts to form when the EA lead insists that all tasks in the Preliminary Phase must be completed before moving on to the next phase.

Another example is also in the Preliminary Phase of the ADM, which defines a tailored architecture framework as one of its outputs. A tailored architecture framework includes the following:

• A tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Architecture principles, including business principles
• Configured and deployed tools

That is according to section 5.4 in Chapter 5 in the TOGAF® online documentation (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html). If this statement is not handled properly by the lead enterprise architect, it can result in a massive scope creep that can keep the entire team of architects busy for months in tailoring the architecture framework they plan to use. The EA team can easily end up building a new EA framework instead of following TOGAF® to deliver EA artifacts, that is, being trapped in another Effort Blackhole.

The last example I will mention in this context is in phase B (Business Architecture), which takes Business Principles, Business Goals, and Business Drivers as inputs (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html). These elements can usually be found in the organization strategy, and if they are not, the architecture team will find themselves busy redefining (or just refining in the best case) the organization strategy, which is a project by itself and can lead to another massive scope creep and distraction to the team from their main EA objectives.

The lack of practicality

Another big problem that enterprise architects deal with when they plan to follow and implement TOGAF® is the lack of practical examples and document templates to use. Most frameworks impart theoretical information only to remain as generic and as neutral as possible. This leaves architects with huge gaps between the theory and the practice and in some cases, they deliver documents and presentations that are very theoretical and disconnected from the real world. This situation makes stakeholders perceive the EA office as the ivory tower office, indicating its disconnect from reality.

TOGAF® is full of terminologies that are either all new to many stakeholders or are defined slightly differently from other standards. For example, the definitions of object and service according to TOGAF® – and ArchiMate® – are a bit different from how Object Management Group (OMG) defines these two keywords. This usually confuses the stakeholders and results in the enterprise architects communicating using a language that no one else understands and delivering presentations that no one gets.

High cost-to-value ratio

Enterprise architects usually charge high rates and EA projects take long periods of time before anyone sees tangible deliverables, especially if done in a waterfall approach. According to the Glassdoor careers website, the average annual salary of an enterprise architect is about $110,000 in the United States (https://www.glassdoor.com/Salaries/enterprise-architect-salary-SRCH_KO0,20.htm). This number is an average and can go up to $220,000 per year for a senior director enterprise architect position according to the same source. If you have a team of four working in your EA office, that will cost your organization nearly $1 million per year if we consider the additional benefits and cost overheads. Additionally, most EA tools are very costly to procure with average license prices of around $10,000 per user (we will talk about EA tools later in this chapter).

Taking into consideration all the aforementioned points, the outcomes of EA projects can be bulky documents that are expensive, theoretical, boring to read, difficult to understand, and do not help in resolving any of the ongoing issues. The decision-makers find it difficult most of the time to justify huge EA investments for the relatively small added value.

TOGAF® is mostly adopted by IT people

Even though EA is an enterprise-level practice and aims to align business and IT within the organization, the reality is that it has mostly been adopted by IT people. This by itself is not an issue because life is full of examples of people who succeeded in different careers and people who quickly gained the required skills and expertise in new domains. IT professionals have always proven that they can lead the trending wave even if it is not just for IT – project management and EA are two examples of that.

The real issue is that IT enterprise architects kept focusing on IT operation and software development, and for them, every deliverable or artifact must serve as an IT solution. You can see this very clearly when browsing the job descriptions of enterprise architect positions on any recruitment website. You will see that most of the offered positions are titled enterprise architect, but the description is mainly looking for deep software development and programming skills or core network operations skills. This usually ends up with EA as a subdivision under the IT unit and the enterprise architect reporting to the IT manager or the Chief Technology Officer (CTO) in the best-case scenario. EA in this case will be limited to IT and will fail to achieve the most important goal it is established for, which is bridging the gaps between business and IT and aligning IT to business strategies.

After having this quick overview of TOGAF®, highlighting its benefits and drawbacks, it is time to introduce a solution that utilizes all of the benefits keeping you away from the drawbacks.