How the TOGAF® Standard Enables Agility

By Mike Lambert, Fellow of The Open Group and Chair of The Open Group Architecture Forum

The Open Group TOGAF® Standard – Version 9.2 was published April 16, 2018. A common misconception voiced by several people at that time was that Enterprise Architecture in general and the TOGAF Standard are barriers to enterprise agility.

This paper addresses that misconception by reference to specific sections of the standard; it does not assume the adoption of any specific agile method.

Why is Agility Important?

Increasingly there is a demand for enterprises to deliver benefits more quickly. There is an imperative to respond quickly to drivers for change, and to be able to change direction quickly and safely.

What role does Enterprise Architecture play?

Enterprise Architecture provides a framework for change, linked to both strategic direction and business value. Enterprise Architecture provides a sufficient view of the organization to manage complexity, support continuous change and manage the risk of unanticipated consequences.

The demand for agility is not new.

The US Clinger-Cohen Act of 1996 was a major driver for the adoption of Enterprise Architecture, because it required investment in new IT systems (in the US Public sector) to demonstrate fit with existing systems. Almost immediately, it was recognized that it is not practical to develop a full Enterprise Architecture “top down”; it is necessary to break the work down into “segments” related to the specific needs of the enterprise at particular points in time, and to have some form of “Integration Architecture” to ensure that the segments fit together and are aligned with the strategic direction of the enterprise.

The TOGAF Standard has embraced Agility from Version 1

From version 1, the TOGAF Standard has embraced the concept of architecture partitions. [1] In summary,

This states that every architecture initiative needs to be scoped to address the specific needs of the segment to be addressed. (Section 4.5 of the TOGAF Standard).

The major scoping dimensions are

• Breadth of the enterprise
• Depth; level of detail
• Time Period
• Relevant Architecture Domains

The TOGAF Standard, Version 9, published in 2009, built on this by including a model for developing architecture partitions at various levels of detail [2]:

Specifically, this model introduced the term Capability Architecture reflecting the need to be able to deliver (small) increments of capability “continuously” to meet the evolving need of the enterprise.

However, it stressed the need for an understanding of the overall strategic direction of the enterprise at a very high level and the context within which the capability increment needs to fit, to avoid unanticipated consequences.

How does that relate to the call for increased agility in 2018?

There is an ongoing demand for the size and timescale of architecture segments and increments of capability to become ever shorter.

This in turn is resulting in a tendency for enterprises to skip the development of strategic and segment architecture, which in turn is resulting in some high-profile IT Failures because of the unanticipated consequences of what appeared to be minor changes.

The Keys to Successful Agility

There are two major factors to achieving successful agility:

1. Managing Scope, understanding when a new capability is needed, how much of the enterprise is impacted and how different parts of the enterprise interact.
2. Having a “Big Picture” showing the overall strategic direction of the enterprise, key business capabilities and significant relationships that must be protected. Without this, the lack of understanding of key dependencies may result in unanticipated consequences and piecemeal development and change may detract from the overall strategy for the enterprise. Having a “Big Picture” enables an impact assessment of any proposed change.

Levels of Architecture Enable Agility

Top-down, The Enterprise Strategic Architecture provides a high-level view of the area of the enterprise impacted by change; the Capability Architectures are detailed descriptions of (increments of) capability to be delivered. These are Sprints in the agile world. They are sufficiently detailed to be handed to developers for action. As the diagram shows, sprints can occur in parallel.

A key consideration is achieving is that the sprints are time-boxed and aimed at addressing a set of bounded objectives. The Capability architectures should be tightly scoped to address those objectives.

The higher levels show the relationships and dependencies between capability increments and provide the framework for the management of risk of unanticipated consequences. They provide the information needed to assess the overall impact of a proposed change.

Bottom-up, there is feedback from the implementation of capability increments which influences the higher levels. The enterprise strategic architecture may evolve as a result of experience gained from the deployment of each and every capability increment.[3]

The strategic architecture is not static. It must be evolved as the strategy of the enterprise evolves; in an agile environment, that is likely to be more frequent than a “traditional” long term strategic plan.

However, it is vital to have appropriate governance to maintain the link between the strategic architecture and the business needs of the enterprise.

Transition Architecture Manage Risk

Transition Architectures provide a way of managing risk.[4] Transition Architecture document the architectural state after delivery of each sprint, mapping each increment of capability to the desired end state and demonstrating the stability of the complete system.

The TOGAF Architecture Development Method

The iconic graphic of the TOGAF ADM reinforces the perception that Enterprise Architecture is a long “waterfall” process.

However, the TOGAF Standard does not:

• Mandate that the steps must be performed in the sequence shown
• Mandate a “waterfall” method
• Specify the duration of any phase or cycle of architecture development

The standard does recommend that the ADM be adapted to meet the needs of the enterprise; agility is one such need.[5]

The standard identifies how the ADM can used iteratively to develop a comprehensive enterprise architecture landscape.[6]

Enterprise Architecture in an Agile Environment

A traditional view of Enterprise Architecture shows a number of stages:

In terms of the TOGAF ADM,

• Phases B, C and D define the baseline and target
• Phases E, F and G deploy the target
• Phase H manages change

In an agile environment it is likely that these activities may be a continuous managed process:

The TOGAF standard already includes guidance which is directly relevant to this “architecture style”:

	“The scope and level of detail to be defined will depend on the extent to which existing elements are likely to be carried over into the Target Architecture.”[7] Agile development is high risk in the absence of a sufficient understanding of the baseline. How to speed up this stage: ·      Progressive development of the baseline architecture description ·      Understand the big picture ·      Segment the problem ·      Develop detail as required to support subsequent work ·      Consider defining Target first to scope work on Baseline They key measure is understanding the “Minimum Viable Architecture” necessary to manage trade-offs and risk.
	“The scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist.”[8] How to speed up this stage: ·      Progressive development of the target architecture ·      Within the context of the big picture ·      Develop detail as required to support subsequent work – only the needed detail ·      Guided by enterprise strategy and prioritized backlog Again, the key measure is understanding the “Minimum Viable Architecture”.
	“Ensure that the systems development method enables feedback to the architecture team on Designs.”[9] Adopt one the many successful Agile development methods: ·      Make sure that people have the necessary skills ·      Ensure that there is appropriate collaboration and governance to deliver the desired business value How to manage risk: ·      Maintain linkage to architecture descriptions ·      Ensure sufficient feedback to assess conformance to architecture ·      Maintain Transition Architectures through an efficient and agile change management process
	“(Drivers for change) Experience with previously delivered project increments.”[10] ·      Assess impact of change on higher level architectures ·      Evolve higher level architectures based on experience of each sprint (capability increment) ·      Monitor changing requirements, but maintain alignment to strategy and linkage to the “big picture”

In Conclusion

This paper has demonstrated that the TOGAF ADM can be adapted to support enterprise agility.

Indeed, over the last few years, there have been numerous presentations at quarterly members meetings of The Open Group of the successful application of the TOGAF ADM in an agile environment.

Mike Lambert is a Fellow of The Open Group and Chair of The Open Group Architecture Forum.

@theopengroup  www.opengroup.org

The Open Group TOGAF® Standard – Version 9.2

[1]Chapter 36 of the TOGAF Standard, Version 9.2

[2]Chapter 19 of the TOGAF Standard, Version 9.2

[3]Section 15.5.1 of the TOFAF Standard, Version 9.2.

[4]Section 12.3.10 of the TOGAF Standard, Version 9.2

[5]Sections 4.2 and 4.3 of the TOGAF Standard, Version 9.2

[6]Sections 18.1 and 18.2 of the TOGAF Standard, Version 9.2

[7]Sections 7.3.2, 9.3.2, 10.3.2, 11.3.2 of the TOGAF Standard, Version 9.2

[8]Sections 7.3.3, 9.3.3, 10.3.3. 11.3.3 of the TOGAF Standard, Version 9.2

[9]Section 14.3.2 of the TOGAF Standard, Version 9.2

[10]Section 15.5.1 of the TOGAF Standard, Version 9.2