Demystifying TOGAF: A Guide to Streamlining Architecture Processes

The Open Group Architecture Framework (TOGAF) is a methodology used by companies worldwide for streamlining their architecture processes. At its core, TOGAF relies on the so-called Architecture Development Method (ADM).

Now, you may be wondering what the ADM actually means. Simply put, it’s a process model that guides enterprise architects and business/IT leaders through the crucial steps of shaping the future of their organizations. It can be applied to the whole company, or on a smaller scale on the individual sub-areas. Interested in learning how? Keep reading this blog post and discover how to make the most out of TOGAF in a simple way.

ADM begins with a setup phase. It then proceeds through the different phases in which gaps are identified, ending with a target state of the organization getting designed, agreed on and implemented. The different phases include: defining the business structures, designing the information systems, planning technology integration and applying governance mechanisms.

In this phase, the overall vision of the organization is defined. One could also say that this is where the strategy is set.

Business architecture is developed, often focusing on understanding and defining the organization’s value flows, business processes and the relationships among them.

Information systems architecture is created, encompassing data and application architecture as well as their interactions, in order to enable the business architecture.

In this phase, the technology infrastructure to support the information systems is defined, including hardware, software, network components, but also machines, robots and IoT elements.

Potential solutions and opportunities are identified and analysed, considering the business requirements and constraints, leading to the development of a high-level implementation and migration plan.

A plan for transitioning from the as-is architecture to the target architecture is developed, focusing on sequencing, timing, and dependencies of the projects.

Implementation projects are executed as planned, and governance mechanisms are established to ensure that the architecture vision is effectively implemented.

Changes are managed and controlled, ensuring that the enterprise architecture continues to align with the organization’s goals and objectives over time.

Finally, the requirements are managed systematically as the last step.

In a nutshell, TOGAF is a set of tools that are used to create a blueprint for an organization’s architecture, both in terms of its business and its underlying technology. While doing so, it relies on ADM, which can be easily explained as a set of steps you follow when using the TOGAF toolbox to create and manage an organization’s architecture. In other words, TOGAF provides the tools and best practices for Enterprise Architecture, while ADM is the step-by-step method you follow to use those tools effectively in designing and managing your organization’s structure and technology.

TOGAF is truly widely used and globally recognized. However, there are also points of criticism. These should not remain unmentioned.

• Complexity: TOGAF is very comprehensive and can be too complex for smaller organizations. Its implementation often requires a significant learning curve and resources.
• Theoretical vs. Practical: Critics argue that TOGAF can be overly theoretical and may not always provide clear, practical guidance for actual implementation.
• Rigid Structure: Some complain that TOGAF is too rigid and does not offer enough flexibility. Adapting it to specific organizational needs could be challenging.
• Overemphasis on IT: TOGAF originated in the IT domain, and some argue that it still heavily focuses on IT architecture rather than encompassing the entire enterprise.
• Lack of Innovation: Critics claim that TOGAF does not respond quickly enough to new developments in technology and business, potentially hindering innovation.

In short, it’s not considered very purpose-oriented and simple.

But, what can be done to make TOGAF more lightweight? How can we ensure that our initiatives are not seen as a predetermined, lengthy road without any shortcuts? Or in other words: How to achieve agility in our architectural endeavors?

Our solution is something we call EA Services. EA services do not only foster agility but also inspire teamwork and engage people from both the business and IT. They do not force anyone to understand the entire ADM.

Too good to be true? What do we mean by EA services? Let’s give you a few examples that we’ve already presented in previous blogs:

Successful businesses need to adapt and dynamically respond to their business environment. Scanning the business environment is a key step for strategy definition. PESTLEweb is one of the proven techniques in that regard.

Before embarking upon a detailed architecture design, it is important to understand and evaluate the business capabilities of the organization in order to identify weak spots and opportunities as a whole and design your vision respectively.

Strategic Roadmaps define which business capabilities need to be developed to meet the needs of the future business, and in prioritizing the corresponding requirements.

The TIME model is a method for evaluating and categorizing software applications based on their business and technical fit. The technical fit pertains to the quality of the application, its maintainability, and its compatibility with other systems. The business fit refers to how well the application aligns and supports business capabilities.

If one digs deeper, target designs of the organization need to be defined and aligned. For this purpose, operating models have proven their worth. This design is one of the essential services offered by Enterprise Architects.

Keep reading to find out how this relates to TOGAF and ADM.

The best part is: you don’t have to reinvent the wheel! TOGAF does not need to be rewritten for this. All parts are already there. The ADM phases remain the same. However, they are managed through services. Services that are designed in a way that:

• Many stakeholders can participate, not only the architecture experts.
• No training is needed to participate neither for the business nor the IT people.
• Institutionalization and replicability are encouraged, and consistent and comparable deliverables across the enterprise are fostered.
• They can be processed independently. You do not need to have gone through all the previous phases to use a service. However, the results can be reused cross-service and enterprise-wide.

The ADM serves as a point of orientation. However, you do not have to stick to it a 100%. You can rather define your own paths as a chain of services. Suitable for the respective task and challenge at hand.

Let’s think of such challenges. Take “Align our company with ESG goals” as an example.
A walk-through could look like this:

• Sustainability-related environmental factors affecting the business are identified and discussed in a PESTLEweb workshop.
• All relevant factors are mapped against the organizations capability map.
• A roadmap is defined to represent the change.
• The most important requirements are prioritized and planned using techniques such as the Value-Effort or the Eisenhower-Matrix. A detailed design can be helpful for the implementation of individual requirements. This can be described in the form of an operating model.

It works the same way for more IT-focused initiatives, such as Application Rationalization. Applications are cataloged and evaluated using the TIME method. Based on the assessments, requirements are defined and translated into a roadmap.

Understanding TOGAF as a concrete guiding framework often leads to enterprise architects struggling with stakeholder engagement. This ultimately results in a lack of clarity about how enterprise architecture supports other disciplines to make business decisions. EA is perceived as heavyweight and complex. But this is not the idea of TOGAF. Combined with the concept of our EA services and with a clear value proposition, it becomes an agile approach.