Enterprise Architecture, TOGAF 10 & Enterprise Agility

Author(s): Rajesh Verma

Originally published on Towards AI.

Enterprise Architecture is for the Enterprise, not for the Architects.

An “enterprise” is any collection of organizations that has a common set of goals. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The term “enterprise architecture” can be used to denote both: the architecture of an entire enterprise, encompassing all its information systems, and the architecture of a specific domain within the enterprise. In both cases, the architecture crosses multiple systems and multiple functional groups within the enterprise.

An Enterprise Architecture (EA) is developed for one very simple reason: to guide effective change.

Enterprise Architecture is:

• A description of the elements within an organization, what they are meant to achieve, how they are arranged, how they perform in practice, and how they respond to change.
• A framework (structure, approach, and process) for managing change to those elements and their arrangement; to continuously adapt to organizational change in line with strategy (goals and objectives) and circumstances (specific requirements).
• The practice of acting to manage and evolve the Enterprise Architecture at all levels of control, change, and pace.

What are the drivers of Enterprise Architecture?

To ensure efficient change management and business value delivery, the drivers of Enterprise Architecture originate at various stages of the value delivery life cycle, like:

1. Stakeholders identify change initiatives that are required for new business goals to be met. These changes are often complex and involve various systems & processes with multiple inter-dependencies.
2. Without an Enterprise Architecture, it is highly unlikely that all the concerns and requirements will be considered and met, leading to further fragmentation & inefficiency.
3. Enterprise Architecture development is needed to manage the change.

Why use an Enterprise Architecture Framework?

Enterprise Architecture Framework defines how to create and use an enterprise architecture.

Large corporations and government agencies may comprise multiple “enterprises,” and hence there may well be unique enterprise architecture projects.

However, there is often much in common about the information systems in each “enterprise”, and there is usually great potential for gain in the use of a common architecture framework.

To manage the scale and complexity of an enterprise, an architectural framework provides tools and approaches that help architects abstract commonality and uniqueness, both.

What is TOGAF: The Open Group Architecture Framework?

The TOGAF Standard is a framework for identifying and implementing change.

The standard provides:

• A definition and description of a standard cycle of change used to plan, develop, implement, govern, change, and sustain an architecture for an enterprise: the TOGAF Architecture Development Method (ADM).
• A definition and description of the building blocks in an enterprise used to deliver business services and information systems: the TOGAF Content Framework.
• A set of guidelines, techniques, and advice to create and maintain an effective Enterprise Architecture and deliver change through new Solution Architectures at all levels of scale, pace, and detail.

Four architecture domains are commonly accepted as subsets of an overall Enterprise Architecture:

• The Business Architecture defines the business strategy, governance, organization, and key business processes.
• The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
• The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
• The Technology Architecture describes the digital architecture and the logical software and hardware infrastructure capabilities and standards that are required to support the deployment of business, data, and applications services. This includes digital services, the Internet of Things (IoT), social media infrastructure, cloud services, IT infrastructure, middleware, networks, communications, processing, standards, etc.

TOGAF 10 Documentation Structure

The TOGAF Standard document structure is modular and evolving. There is a clear hierarchy from the universal concepts in the TOGAF Fundamental Content to the stable best practice in the TOGAF Series Guides to emerging ideas in the TOGAF Library.

1. The TOGAF Standard fundamental provides essential “scaffolding” and establishes best practices that are stable and enduring.
2. The Series (Domain) guides build upon the general content provided in the TOGAF Fundamental Content by providing guidance for specific topics.
3. Accompanying the TOGAF Standard is a broad portfolio of guidance/reference material, known as the TOGAF Library, to support the practical application of the TOGAF approach. Reference Models and Method Guidance, General How-To- Information, and Establishing an EA Team are some of the documents currently available.

There are many other domains that could be defined by combining appropriate views of the Business, Data, Application, and Technology domains. For example, Information Architecture, Risk and Security Architecture, and Digital Architecture.

TOGAF 10 makes the adoption of best practices easier. The TOGAF framework enables the creation of multi-dimensional views and categorizes them to create specific domains that enable an enterprise to consider the wider scope of its enterprise and capabilities.

TOGAF 10 — Architecture Development Model (ADM)

The core of the TOGAF framework is the TOGAF ADM.

Fundamentally, the TOGAF Standard supports what architects do — they understand, specify, and govern.

Understand

Phase A — Architecture Vision: understand the problem/opportunity, sketch the solution, and identify the broad transition approach.

Phases B-D — Business/Information Systems/Technology Architecture: identity what is needed (Architecture Building Blocks (ABBs)).

During these phases, a recommended practice is to identify the potential solution implementations (Solution Building Blocks (SBBs)).

Specify

Phase E — Opportunities and Solutions: select from the candidate set of SBBs to best fit with the ABBs of Phases B to D and how they will interoperate to deliver the business service levels required, and the most appropriate implementation transitions.

Phase F — Migration Planning: organize the resources to deliver the transitions in a controlled fashion.

Govern

Phase G — Implementation Governance: ensure the reuse/build/acquisition and deployment activities are properly organized and deployed in line with the agreed contract and specifications.

Phase H — Architecture Change Management: ensure that the change is properly planned, structured, and delivers the business value that is expected.

TOGAF 10 — Architecture Content Framework

Architecture Principles, Vision, Motivation, and Requirements models are intended to capture the surrounding context of formal architecture models, including general Architecture Principles, a strategic context that forms the input for architecture modeling, and requirements generated from the architecture.

Business Architecture captures architecture models of the business, looking specifically at factors that motivate the enterprise, its structure, and its capabilities.

Information Systems Architecture models capture architecture models of IT systems, looking at applications and data in line with the TOGAF ADM phases.

Technology Architecture models capture technology assets that are used to implement and realize information system solutions.

Architecture Realization/Transformation models capture change roadmaps showing the transition between architecture states and binding statements that are used to steer and govern the implementation of the architecture.

Architecture Change Management models capture value realization management events, internal and external, that impact the Enterprise Architecture and the generation of requirements for action.

TOGAF 10 — Enabling Enterprise Agility

TOGAF framework enables, agile EA practices to support business strategy, process, & system alignment.

It is important to note that TOGAF ADM “does not”:

1. Mandate that the steps must be performed in the sequence shown.
2. Mandate a “waterfall” process; i.e., that each phase must complete before the next begins.
3. Specify the duration of any phase or cycle of architecture development.

The TOGAF framework “does”: recommend that the ADM be adapted to meet the needs of the enterprise; agility is one such need.

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

• Enterprise Strategic Architecture provides a high-level view of the area of the enterprise impacted by the change. It enables an 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. 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.

ADM Levels and Phases Mapped to Agile Concepts

Strategic Architecture

In an Agile enterprise, Strategic Architecture is a high-level iteration supported by the TOGAF ADM Phase A, Architecture Vision. Strategic direction for the enterprise is defined in this iteration to support decision-making, and which may be further elaborated in Phase B to provide a high-level view of the organization landscape.

Key advantages for an Agile enterprise doing Strategic Architecture are:

• Provides an understanding of the organization context needed to define the strategic themes, epics, and drivers; identifies value streams, high-level requirements, and other broad features of the strategic direction and vision.
• Confirms the basis to define guardrails for the product/service/solution delivery
• Identifies the high-level organizational capabilities necessary to deliver the entire endeavor: people skills, tooling, management tools, governance principles, etc.
• Provides an understanding of the organization landscape to shape migration planning roadmaps when loosely-coupled components are involved, thus providing the organization landscape to identify and implement the collaboration and integration needed between the relevant associated teams.
• Input to define the backlog for the different segments (typically functional or organizational areas) that will be covered in subsequent iterations.

Strategic Architecture provides a context for lower-level architectures.

Segment Architecture

A Segment Architecture is typically the specification of the product or business solution. It should be just enough architecture to identify features and functional and non-functional requirements. If 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.

Key advantages for an Agile enterprise doing Segment Architecture are:

• Support for the definition of Capability-level backlogs
• Identify the capabilities/enablers and then the features and functionalities needed to deliver the product/service/solution.
• Define the Key Performance Indicators (KPIs) needed to ensure value is delivered in accordance with the vision and business objectives
• A segment consists of one or more products and SBBs. Just enough architecture should be delivered to enhance solution design, performance, and usability and provide guidance for inter-team design and implementation.
• Specification at this level should be oriented to grouping things together at the portfolio level to support Agile concepts that include epics, concurrent engineering, and planning for continuous delivery and integration of the target solution.

Segment Architecture helps shape the products and solutions for every segment. Outputs of segment iterations are backlog items that will be the base upon which Agile teams can work on the product and solution implementation.

Capability Architecture

A Capability Architecture delivered by a sprint or even by a set of sprints, depending on the scope, should be incrementally and iteratively integrated into a delivery pipeline. This is a more specific solution-oriented architecture specification, including the ABBs 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.

Key advantages for an Agile enterprise doing Capability Architecture are:

• Provides just enough detail from the higher-level architectures to define the implementation and provides feedback to update the higher levels where necessary.
• Developed Just-In-Time (JIT), to provide a forward “solution runway” for delivery sprints to consume while avoiding unnecessary constraints.
• Defines and refines the user stories that will be implemented by the different Agile teams.
• Enables quality assurance and compliance activities for solution deployment.
• Enables traceability to confirm that the original objectives of the Strategic Architecture are being met.

Capability Architecture is the solution specification that will be constructed and deployed on demand following the architecture guidelines, metrics, and compliance considerations by Agile teams.

Summary

TOGAF Standard, 10th Edition is significantly easier to adopt, a useful body of stable, proven enterprise architecture practice. The body of proven practice addresses broad uses, but in some areas — like Security and Business Architecture — it goes deeper. TOGAF 10 enables agile enterprise architecture practices to support business strategy, process, & system alignment.

Reference:

1. “The TOGAF® Standard — Digital Edition — Introduction.” n.d. Pubs.opengroup.org. https://pubs.opengroup.org/togaf-standard/.

---

Enterprise Architecture, TOGAF 10 & Enterprise Agility was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI