The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 870 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

The TOGAF Standard is a proven enterprise methodology and framework used by the world’s leading organizations to improve business efficiency.

This document is a TOGAF^® Series Guide: Enabling Enterprise Agility.

It has been developed and approved by The Open Group.

The high-level structure of this document is summarized as follows:

The audience for this document is Enterprise Architects requiring information on how to adapt and use the TOGAF framework to support an Agile enterprise.

The TOGAF^® Series Guides contain guidance on how to use the TOGAF Standard and how to adapt it to fulfill specific needs.

The TOGAF^® Series Guides are expected to be the most rapidly developing part of the TOGAF Standard and are positioned as the guidance part of the standard. While the TOGAF Fundamental Content is expected to be long-lived and stable, guidance on the use of the TOGAF Standard can be industry, architectural style, purpose, and problem-specific. For example, the stakeholders, concerns, views, and supporting models required to support the transformation of an extended enterprise may be significantly different than those used to support the transition of an in-house IT environment to the cloud; both will use the Architecture Development Method (ADM), start with an Architecture Vision, and develop a Target Architecture on the way to an Implementation and Migration Plan. The TOGAF Fundamental Content remains the essential scaffolding across industry, domain, and style.

Enterprise agility is a commonly used term but the exact definition differs among practitioners. The most common characteristics include:

Regardless of how the term enterprise agility is defined, it is important because it enables an enterprise to better react to change by being more customer and product-centric, more efficient, and better able to ensure regulatory compliance.

The term Agile is typically associated with the Agile Software Development Process derived from the Manifesto for Agile Software Development [2]. While Agile principles and techniques can be applied to adapt the TOGAF framework, enterprise agility is a broader context than Agile. Therefore, additional techniques are employed in adapting the TOGAF framework to an Agile enterprise.

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

Enterprise Architecture is:

The TOGAF Standard is a framework for identifying and implementing change, and provides:

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 from the “top down”; it is necessary to structure work into smaller units to respond to the specific needs of the enterprise in a timely manner, and to have some form of “integration architecture” to ensure the pieces fit together and are aligned with the strategic direction of the enterprise.

The TOGAF framework has embraced the call to respond to the needs of the enterprise in a timely manner, through the concepts of “partitions” and “levels”. Partitions define how the work is broken down into multiple architecture initiatives. Levels define how the overall architecture can be developed at different levels of granularity and detail.

Each architecture initiative needs to be scoped to address the specific needs of the enterprise to be addressed.

The major scoping dimensions are:

The TOGAF Standard allows users to use the TOGAF ADM in an iterative way. The ADM can be used to deliver value incrementally following different iteration approaches. The concept of iteration is deep-rooted within the TOGAF ADM; as described in the TOGAF Standard – Applying the ADM (Applying Iteration to the ADM) [1].

Iterative development, such as Agile practices like sprints with shorter iterations, is a useful technique to obtain early stakeholder feedback and results. It enables the Enterprise Architects to deliver value earlier and iteratively, whether in a planned or emergent manner.

Dividing work into sprints does not only mean dividing work into small pieces, but also learning by doing in short cycles and adapting the work accordingly.

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 Architectures, which in turn is resulting in some high-profile IT failures because of the unanticipated consequences of what appeared to be minor changes.

The TOGAF Standard recognizes the need to recursively break down the Enterprise Architecture into more granular levels that can be architected following an Agile approach.

Partitioning the architecture work is key for Agile delivery and implies the definition of segmentation based on the Strategic and Segment Architecture concepts as explained before.

These smaller pieces, that cover a specific area of the organization, can then be more easily specified and implemented following an Agile approach, enabling a cross-cutting view across the TOGAF domains.

The first step is to identify the segments scoped to address specific needs keeping the alignment with the Strategic Architecture. Once these segments have been identified they can be refined further into Capability Architectures that can be specified and implemented following an Agile approach.

These Capability Architectures, delivered in increments, can be used to iteratively construct the final outcome (product, service, or solution). These iterations can be conducted in parallel depending on the level of interdependency between them. And, as stated in the TOGAF Standard – Applying the ADM (Applying Iteration to the ADM), Capability Architectures corresponding to a Segment Architecture can also be performed in parallel.

The following chapters will explain these concepts in more detail; see in particular Section 4.1.

To move/change quickly and easily, often to provide value-generating outcomes.

A member of an Agile product team responsible for defining user stories and prioritizing the backlog, ensuring these are understood by other team members while maintaining the conceptual integrity of the features or components for the delivery team. In the TOGAF framework, product has a wider context, but is used here in the Agile product context.

An architecture that enables the delivery of product features with just enough content to be deployed in a given phase of a project and satisfies known requirements (especially quality attribute requirements), and no more.

The smallest possible outcome that generates acceptable learning, delivery of value to the customer (internal or external), and is a basis for future extension.

An outcome generated by the business to be offered to customers. Products include materials and/or services.

The TOGAF framework presents a model identifying three levels of detail that can be used for partitioning architecture development:

These levels are illustrated in Figure 2.

This model must not be confused with the architecture domains; Business, Data, Application, and Technology Architectures may exist at all levels of detail.

Top-down, the Enterprise Strategic Architecture provides a high-level view of the area of the enterprise impacted by change. It enables understanding of the overall strategic direction of the enterprise at a high level, and must be sufficiently broad to establish the context within which the segments and capabilities fit. It is necessary to plan and design the entire endeavor, and to avoid unanticipated consequences.

The middle layer, the Segment Architectures, typically provide direction at the portfolio, program, or product level. These large-scale segments are often aligned to natural boundaries of functionality.

The bottom layer, the Capability Architectures, are detailed descriptions of (increments of) business capabilities [3]. These may align to delivery sprints, or multiple sprints may be needed to deliver a capability. They are sufficiently detailed to be handed to developers for action. Sprints may occur at any level, but are most commonly associated with the delivery of capabilities or increments of capability. Sprints can occur in parallel.

A key consideration is that sprints are time-boxed and aimed at addressing a set of bounded objectives. The Capability Architecture increments should be tightly scoped to be achievable within sprint time boxes. More detailed guidance relating to sprints can be found in the TOGAF^® Series Guide: Applying the TOGAF ADM using Agile Sprints [4].

The higher-level Enterprise Strategic and Segment Architectures should show the relationships and dependencies between capabilities and capability increments and provide the framework for planning and design, and the management of risk. They then provide the information needed to assess the impact of a proposed change. The Capability Architectures then show the relationship between capability increments.

Bottom-up, there is feedback from the implementation of capability increments which influences the higher levels. The Capability, Segment, and Enterprise Strategic Architectures may evolve as a result of experience gained from the deployment of each capability (or capability increment).

The Strategic Architecture is not static. It must evolve as the strategy of the enterprise evolves. In Agile enterprises, this will be more frequent than a “traditional” long-term strategic business plan.

It is vital to have appropriate governance to maintain the link between the business needs, Enterprise Architectures, and the Agile solution developments of the enterprise.

Two major factors to achieving successful agility at an enterprise level are:

A Transition Architecture is a formal description of one state of the architecture at an architecturally significant point in time (see Figure 3), usually including a number of capability increments. It describes the roadmap to the desired outcome and ensures the stability of the complete system after its implementation. In Agile, the capability increments are usually implemented using sprints. Transition Architectures also provide a way of managing risk by helping to understand the incremental states of delivery. Transition Architectures are related to releases of business value to the stakeholders.

A practical and proven approach to applying the multi-level approach through a hierarchy of ADM cycles is illustrated in Figure 4.

As described in the previous section, TOGAF ADM phases do not have to proceed in sequence. The activities around defining Segment Architectures can start as soon as the relevant areas have been identified in the Strategic Architecture. Even if not all of these segments have been defined, architecture work can start in those that had already been identified. In a similar way, work on defining Capability Architectures need not wait until all Segment Architectures have been defined. Work on different segments and capabilities may proceed in parallel. The Strategic, Segment, and Capability Architectures are explained in more detail in Section 4.4.

Experience gained when developing a Capability Architecture should influence the higher-level Segment Architecture. Experience gained when developing a Segment Architecture should influence the higher-level Strategic Architecture.

Agile delivery teams should collaborate closely with architects to ensure that the sprint teams understand and comply with architecture specifications (which may be expressed as guardrails or runways), and to enable rapid feedback to future architecture iterations.

It is important to keep in mind the big picture to ensure implementation teams remain aligned to the overall strategy. Therefore, a balance must be made between providing sufficient detail at each level, to give clarity and maintain alignment, versus exploring too much detail too soon (“Big Design Up Front” (BDUF)) without the benefit of feedback from delivery sprints. This is often referred to as the Minimum Viable Architecture.

As previously described, the TOGAF ADM can be applied to deliver architecture iterations in parallel and partitioned across different levels of detail and change using Strategy, Segment, and Capability Architectures that can be also developed using techniques such as SAFe and Scrum.

Agile techniques consider that development and delivery work can progress based on one integrated team across all levels (business, technical, solution, build, and delivery) working in single connected sprints or across the types of boundaries shown in Figure 5^[1] that may have connected but distinctly separate styles of sprints. The exact arrangement will depend on the complexity and scale of each enterprise and the implementation of the Agile approach.

In applying the TOGAF ADM, each level of planning and delivery may cycle through all of the TOGAF phases from A to G but each of the three levels will often focus on specific elements of the cycle. In the Strategic level, the focus is more on the Preliminary Phase (if architecture capability changes are needed) and Phases A and B to provide the basis to define the cross-enterprise and strategic change time horizon view. This generates a series of strategic high-level plans known as courses of action.

Agile techniques typically address this with concepts such as high-level strategic themes, and the highest level of an enterprise product portfolio backlog. In this level, interdisciplinary teams (business and technical teams and those that create, implement, and operate) must be involved to develop an Enterprise Architecture that meets both the business goals and objectives of the enterprise and is also potentially deliverable.

In the Segment level, the focus is on partitioning the courses of action across the relevant organization units (based on an understanding of the desired business capabilities and value streams and following each enterprise’s chosen approach to partitioning – capability/product, service/process, or function etc.) such that the work of delivering the change can be effectively and efficiently organized. Where the information acquired by performing Phases A and B is insufficient for this activity there may be more emphasis on further exploring Phases B, C, and D in greater detail.

Work can be approached by factoring work to self-organizing teams at various levels (in line with the chosen organization unit structure) along with a high-level iteration through Phases C and D, that provides more detailed information for the product or solution delivery, going deeper into smaller organization areas (segments). Outputs of this iteration are the Epics that reflect large or long-running user stories, and the segment-based initial portfolio and/or backlog. The output from this level can be used to test and experiment with new products (if necessary), delivering descriptions for prototypes to test ideas into the relevant segment market.

In the Capability level, a more specific solution-oriented architecture specification, including the ABBs, is identified through Phases B, C, and D, covering both the functional and non-functional aspects of the solution to be implemented. These architecture specifications are then further developed in Phases E and F as the basis for the SBBs, and their integration into the desired solutions/services/products. These are finalized and their associated contracts are then developed to direct their reuse/acquisition/build and deployment. The implementation units are aligned with increments of capability that will deliver specific outcomes such that each “chunk” of work produces an implementation of agreed value with the relevant stakeholders and sponsors. This approach to fast continuous implementation at the smallest level of capability creates a Transition Architecture of deliverable units similar to the sprints in the lowest level of backlog in the Agile style approaches. This smallest level of capability is often referred to as Minimum Viable Product in Agile style approaches.

The backlogs are (if needed) usually refined down to an equivalent of the Scrum concept of a sprint backlog of deliverable sprints that will be ready for implementation in weeks, or at most one month. These sprints will take the specification from the equivalent of the TOGAF Phases A and/or B, C, D, and E through to implementation. The focus is on creating integrated teams and environments such that the further design, build, implementation, and operation processes interact seamlessly enabling continuous integration and implementation as delivery of each unit of the Minimum Viable Product is completed.

The Capability level is operationally completed in Phase G, Implementation Governance. This ensures that the agreed contracts have delivered the expected capability, in line with the contractual agreements, and that all of the required information for operating and changing the product/solution/service is properly created, stored, and made accessible to support faster and higher quality change in the future. The Capability level confirms benefits realization in Phase H, Architecture Change Management. This ensures that operational and business performance is evaluated to confirm that the value has in fact been delivered and that the users of the product/solution/services are satisfied with the business outcomes of that capability increment. It further ensures that the evolving or completed wider Segment and/or Strategic-level change projects are operating within the appropriate boundaries (or guardrails) set up when planning the change.

There may be pressure to move forward beyond the end of the runway defined by the Capability Architecture at a given point in time. This can store up problems in the management of poorly documented or architecturally dislocated products/solutions/services in the future. This is a type of technical debt, and like any debt, needs careful management to ensure that the debt does not get out of control. This should be addressed in Phase H, Architecture Change Management.

Set-Based Concurrent Engineering (SBCE) from Lean Product and Process Development [5] can be accommodated by adapting the TOGAF framework. Both the Open Agile Architecture™ Standard [6] and SAFe^® promote the practice of SBCE. In SBCE, the overall solution is divided into a number of sub-systems, broad targets are established for each sub-system, and multiple alternatives for reaching those targets are identified and developed concurrently. The set of alternative designs is evaluated iteratively over time, eliminating weaker options in each iteration, until the final, strongest design is selected. For each alternative, enough architecture is done to properly assess the competing alternatives, ensuring that good decisions are made. Architectural alternatives and elaborations are done using ADM iteration cycles and sprints. An ADM iteration is done for each alternative, with only enough architecture done within the iteration to evaluate the trade-offs for that alternative. When an alternative is selected, ADM iterations and sprints are done to further elaborate the architecture for the selected approach. Further explanation on how to handle alternatives using the TOGAF Standard can be found in The Open Group TOGAF Standard [1] – ADM Techniques, Chapter 10, “Architecture Alternatives”.

These iteration cycles with accommodation for SBCE support an Agile delivery style. For instance, a Segment Architecture could be defined in Agile sprints and each one of those sprints would be an ADM iteration cycle.

This document describes how to apply the TOGAF methodology and framework within an Agile delivery environment. However, different delivery styles exist, and it may be that some projects or programs are not appropriate for Agile delivery. The TOGAF Standard is intentionally flexible to accommodate these different styles.

The TOGAF ADM is a framework with a set of possible elements that can be applied to different scales of change, from meta to micro.

The meta/micro cycle distinction is usually of characteristic delivery style, dependent upon the needs of each change activity; such as:

As Figure 6 shows, the highest level of architecture begins with an architecture vision and strategy at the enterprise level, which provides a long-term view of the target state and surrounding business landscape. The development of the vision and strategy can be done in an Agile style, through multiple iterations as architects collaborate with their business partners. Typically, architecture delivered at this level is visionary and conceptual, and often provides a lot of flexibility to architects who use this vision to prepare more detailed architectures. The release of such high-level deliverables can span a long duration, and an indicator of organizational agility is the speed with which vision and strategy can change.

The speed of change also depends on the impact of the change. Changes that are non-disruptive to the current vision and strategy are relatively quick and easy to complete. Changes that create a huge pivot in the current strategy and vision should be assessed to see how much disruption they may cause to the currently derived or in-flight architectures. Such changes could have a trickle-down effect as many derived architectures at lower levels are impacted. The frequency and the amount of changes to the architectures at the highest levels should be less than those at the lower levels. How much change is feasible depends on the organization’s tolerance to the amount of agility.

Business partners and architects collaborate constantly to produce transition state architectures and align on the aspirational target states. Architects should also align to business goals and evolve the architectures such that every transition state provides an incremental business value.

As discussed in the previous chapter, Agile Enterprise Architecture uses an iterative, incremental approach to create architecture artifacts. Specific skills and management approaches must be put in place for this to succeed. The primary objective of the Preliminary Phase of the ADM is to establish or adapt the Enterprise Architecture capability to the specific architecture work to be carried out. Some considerations for the Preliminary Phase in Agile delivery are:

The Preliminary Phase includes the establishment of a set of Architecture Principles (general rules and guidelines intended to be enduring and seldom amended) that inform and support the ways in which an organization sets about fulfilling its mission. The Architecture Principles for any style of architecture reflect the specific characteristics of that style. The principle of a single product owner should be established in this phase to ensure that requirements are clearly articulated and understood, and to prioritize the Agile development of the system components in later phases.

Chapter 5 of the Open Agile Architecture Standard [6], “Intentional Architecture”, sets out principles that intentional architecture within Agile delivery should follow.

As shown in Figure 7, a traditional, generalized view of Enterprise Architecture contains a number of stages.

In terms of the TOGAF ADM:

In an Agile environment it is likely that these activities will be a continuously managed process with activities proceeding in parallel, as shown in Figure 8.

It is not necessary to complete the problem definition before starting other activities. Enough of the problem needs to be defined to provide context for other activities. As other activities are initiated, work can proceed to further elaborate and extend the problem definition.

Clearly, there are dependencies. It is not possible to deploy any part of the target until the parts of the baseline and target describing that part of the target have been sufficiently defined.

More practical guidance about different architecture styles of support can be found in the TOGAF Standard [1] – Applying the ADM.

In an Agile environment and within supporting organizations that have adopted an Agile delivery approach, it is likely that the activities presented in Section 5.2 will be a continuously managed process handled in parallel and focusing more on the outcome with architecture as the vehicle to support product delivery.

For an Agile approach the stages to follow are similar but performed in a different way. Enterprise Architecture iterations support this product definition and product architecture.

The problem is defined at the Strategic and Segment level, then at the Segment and Capability level a target is defined, and at the Capability level a target is deployed by Agile teams supported by the architect and the Capability Architecture definition.

As explained in Section 4.4, at the Strategic level a high-level architecture specification is defined – strategic themes, epics, that will guide the subsequent problem definition. At the Segment level, the backlog is defined in alignment with the strategic definition (problem definition). This backlog should be refined further to produce the sprint backlog that will be delivered using any Agile technique. This Agile delivery is supported by a Capability Architecture supporting Agile solution delivery.

The TOGAF Standard – Architecture Content describes the TOGAF Content Framework. In general, the artifacts and their relationships apply equally to Agile delivery as to other delivery lifecycle approaches. However, the tooling and format may need to be adapted for Agile delivery.