How is the TOGAF 9.2 Framework Impacted by Digital Transformation?

As mentioned in one of my last posts, The Open Group Architecture Framework (TOGAF) has recently published an updated version of its framework. After the last version 9.1 from 2011, the update 9.2 in April 2018 has been the first update in the last seven years. In the context of IT, Digital, and the increased pace of change that we face today, seven years is for sure a long time. I will therefore use todays post to analyze, how TOGAF has actually reacted to the Digital Transformation and how the framework has been impacted by the changes in the last seven years. 

 

What Does TOGAF Say? 

TOGAF provides a frequently asked questions (FAQs) page. It is stated that major improvements include some corrections, structure improvements, and the removing of obsolete content. Also, there have been key enhancements to the Business Architecture and the Content Metamodel. Overall, the version 9.2 with its 532 pages is much smaller than version 9.1 with more than 692 pages. TOGAF achieved this by restructuring the content into smaller publications that are included in separate guides that support the TOGAF Standard version. 

TOGAF states that it has put an additional focus on the topics of digital trends and business transformation beyond IT. It has also amended the topics of business capabilities, value streams, security architecture, as well as adding new reference models.

TOGAF states that the TOGAF series guides are evolving guides that can be industry-, architectural style-, purpose-, or problem-specific. The following topics already have a TOGAF Series Guide available: 

  • The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability
  • A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM
  • Value Streams
  • Using the TOGAF Framework to Define and Govern Service-Oriented Architectures
  • The TOGAF Technical Reference Model (TRM)
  • Business Scenarios
  • The TOGAF Integrated Information Infrastructure Reference Model (III-RM): An Architected Approach to Boundaryless Information Flow

The following additional TOGAF Series Guides will be published in the course of 2018:

  • Business Models
  • Business Capabilities
  • Architecture Project Management

Especially the guide about business capabilities will be very interesting and hopefully worthy to look at, as the topic of business capabilities is – although being really trendy – a topic in which there is still much standardization and best practices work to be done. I hope that TOGAF will contribute with this piece of work to improve the situation. 

 

Taking a Look at the New Standard: What has Changed…

The overall structure of TOGAF now recognizes that there are topics that are stable over time and topics that need adaptions that are more frequent. By excluding the TOGAF Series Guide from the TOGAF Standard, TOGAF acknowledges that the content of the Standard is the constant, while the guides have a shorter lifecycle and are more specific.

In the introduction chapter, TOGAF mentions Digital Transformation as one of the reasons why an organization should adapt an architecture framework. (e.g. because enterprise architecture helps to plan strategically which is needed because Digital Transformation brings challenges) It also states that the framework helps to increase the effectiveness and efficiency of the Digital Transformation due to the effective enterprise-wide management, landscape harmonization, lower costs in some areas, as well as improved integration and security. Although it is only an introduction chapter, those adaptions seem rather high level and the content has not much changed toward a more Digital view. 

The “Architecture Development Method” (ADM) is the TOGAF approach for how to develop and govern enterprise architecture. Three of the nine phases have received an update: The phase of architecture vision, as well as business architecture have additional content on the topics of business capabilities, value streams, and organization maps that should help to develop a business architecture. The technology architecture phase has an additional abstract on emerging technologies and their impact on change; however, there is no tangible advice in the new content, but rather a generic statement about today’s Digital environment. Generally, the ADM includes some additional topics (TOGAF calls them artifacts) and their definitions addressing the early phases of the approach. The later phases, including the opportunities and solutions, implementation governance, migration planning, and change management have hardly changed since the version from 2011. 

The ADM Guidelines & Techniques chapter has been reduced in size with most of the removed content moved to the TOGAF Guide Series and some minor text adaptions. There has been no change regarding the Digital Transformation. 

The content metamodel, which is a recommended structure for how to store enterprise architecture contents, now includes additional topics (entities), such as business capability, course of action, and value stream. There have been some minor wording changes in addition (e.g. “Platform Services” are now “Technology Services”). 

Similarly, there are new architectural artifacts: Business model diagram, business capability map, value stream map, business capability map, value stream map, business capabilities catalog, value stream catalog, value stream stages catalog, value stream/ capability matrix, strategy/ capability matrix, capability/ organization matrix, and organization map. Adding these artifacts is a clear result of a stronger footprint of the business capabilities topic among companies, as well as the desire to achieve a tighter business-IT alignment. 

 

Conclusion

TOGAF pays tribute to changes in the IT environment by adding newly emerged concepts and terms to its standard. In addition, TOGAF updated several definitions to achieve a better fit for today’s understanding of Enterprise Architecture. Another helpful move is the new structure, which reduced the size of the standard by a lot and separates the content into a stable and a more adapting part. 

On the contrary, TOGAF keeps its overall structure, approach, and most parts of its content the same. There have been some amendments of the standard in order to address the Digital Transformation and related concepts; however, these amendments do not seem well connected to the rest of the book. They might change the view on enterprise architecture a bit, but the actual content on enterprise architecture stays pretty much the same. It would have been helpful if TOGAF had added additional information about integration platforms or about API Management. APIs and application platforms are mentioned along the Technical Reference Model (TRM) topic, but, overall, the chapter does not sound very helpful. Both topics have a much higher importance today than they had in the past and it would have been a big help if TOGAF gave more guidance and details on those. 

Cloud is another aspect that is hardly addressed. Although TOGAF provides some content outside the standard on cloud computing, in my eyes such an omni-present topic must be considered more deeply in the main piece of work. 

In addition, TOGAF could have addressed today’s Internet of Things requirements to architecture. They could have addressed the difference between Systems of engagement vs. Systems of record and they could have addressed what the requirements from machine learning, automation, agility, scaling, artificial intelligence, or big data is on the overall enterprise architecture. If there was no impact, companies could still have the architecture that they had 10 years ago. 

Also other organizations give advice on architecture topics, but try to adapt to changes in the environment. One of these examples is Amazon Web Services with its “Well-Architectured Framework” for cloud environments. In one of my next posts, I will explain what that is.