Enterprise Architecture

Component 4: Enterprise Architecture Methodology

At a minimum, an Enterprise Architecture methodology must address developing and sustaining an enterprise architecture. A complete method will include planning the implementation of the changes and governing all implementation projects. A comprehensive methodology will include guidance on work management.

Component 4: Enterprise Architecture Methodology includes:

• Architecture Development Methodology
• Planning integration
• Governance Framework
• Work Management

Architecture Development Methodology

The TOGAF Architecture Development Method provides the industry standard method for developing and sustaining an enterprise architecture. The TOGAF ADM for the core of the TOGAF Standard.

At its root the TOGAF ADM uses an information flow model. Each Phase in the ADM exists to sustain the creation of information. The classic TOGAF ADM graphic is a simplified representation of essential information flows.

As an information flow, the ADM is inherently incremental and iterative. You need to craft the information flow onto a process model. Your process is test if you have sufficient knowledge, if so use it. If not, produce it. The TOGAF ADM is not an activity sequence. Far too many people look at the TOGAF ADM graphic and misunderstand it as a linear waterfall process model.

Every time the EA team is undertaking any activity to develop the information that comes from an ADM Phase, they are executing a Phase. An Enterprise Architect always needs to consume the mandatory inputs and produce the mandatory outputs. This applies to all ADM phases.

Using the TOGAF ADM as an information model helps the enterprise architect achieve maximum efficiency and productivity.

Each Phase in the TOGAF ADM is designed to create the necessary information

Phase A: Defining Architecture Vision

Do not be surprised if you have over one architecture alternative expressed as different Architecture Visions. You rarely have enough information to select the best-path in Phase A.

Phase A Deliverables provide the basis of governing architecture development.

Phase B: Developing the Business Architecture

The outcome of Phase B is the candidate business architecture.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

The business architecture domain describes the target business structure. It will typically include elements like business capability, organizational design, process, and information flows. It often addresses motivations like strategy, goals and objectives. These components will be documents as Business Architecture Models.

Download a free Business Architecture Capability Assessment Guide.

Phase C: Developing the Information Systems Architecture

Information Systems Architecture includes both the application Architecture domain and the data architecture domain.

The outcome of Phase C is the candidate application architecture and candidate data architecture. Together these create the candidate information systems architecture.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

The Application Architecture will help answer the following questions:

• How the application portfolio enables value capture – Application Development Model
• Where cost is injected into the IT Portfolio - Functional Model
• Where rigidity is injected into the IT Portfolio - Integration Model
• How the enterprise runs – System Model
• Systems required to deliver the product or service – Product Model
• The things an organization must be able to do - Functional Model
• The flow of information to required to perform an enterprise' activities - Integration Model
• The complete activities an enterprise performs, typically grouped to show how they relate to each other – Service Model
• What the software portfolio is – Physical Software Model

Phase D: Describing and Developing Technology Architecture

The outcome of Phase D is the development of a candidate technology architecture.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

Most often we see weak Technology Architectures, largely comprised of physical models. In most of our work we are aligning Phase D with Cloud Architecture. For the other domains core work products like, a System Model and Service Model, are the same.

The technology architecture will help answer the following questions:

• How the infrastructure portfolio enables value capture – Infrastructure Service Model
• How the infrastructure is delivered – Infrastructure Provider Model
• Where cost is injected into the IT Portfolio - Interface Model
• Where rigidity is injected into the IT Portfolio - Lifecycle Model
• The things an infrastructure must be able to do – Infrastructure System Model
• Constraints on acquiring and using Technology – Standards Catalog
• How to use the infrastructure to perform an enterprise’ activities – Interface Model
• The complete activities an infrastructure does grouped to show how they relate to each other – Service Model
• What the Infrastructure Portfolio is – Physical Infrastructure Model

Phase E: Identifying Opportunities and Solutions

The objective of Phase E is to move past the simplified Architecture Vision. It was only expected to show promise. By developing an architecture roadmap with your stakeholders you will identify potential changes that should be abandoned. In fact, most changes should be abandoned. They will fail one or more value tests:

• Too much work for the return
• Success is too uncertain for the return
• The return is only nice to have

The outcome of Phase E is an Iarchitecture roadmap and supporting candidate enterprise architecture.

Table from TOGAF Framework TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

An Architecture Roadmap will help answer the following questions:

• When will value be delivered – Transition States
• What change to pursue given different criteria – Architecture Roadmap Type 4: Scenarios
• What work will deliver value, and the cost and uncertainty – Architecture Roadmap Type 1: Heatmap
• When work, change, and value delivery will occur – Architecture Roadmap Type 2: Lifecycle
• What is the dependency & impact of work and change – Architecture Roadmap Type 3: Impact & Dependency
• What decisions are deferred – Architecture Roadmap Type 4: Scenarios
• What kind of change are we pursuing – Implementation Strategy

Planning integration

The TOGAF ADM Phase F: Crafting a Migration Plan addresses planning integration. It highlights that the architecture approach needs to integrate with your organization's planning approach. Most of the time you will fit into standard portfolio and project planning. However, if you are architecting a transformation expect the standard planning approaches will not be used.

The outcome of Phase F is an Implementation Plan and supporting Architecture Contract.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

An Implementation Plan will help answer the following questions:

• When change will happen – Implementation Plan’s Projects
• What must and must not change – Implementation Plan’s Projects
• What kind of change will happen – Implementation Strategy
• What set of work is focused on specific outcomes – Implementation Plan’s Portfolio
• What set of work will be executed together – Implementation Plan’s Program

An Architecture Contract will help answer the following questions:

• What tangible and intangible benefit is expected – Architecture Contract - Benefit
• When constraints limit the freedom of the implementers – Architecture Contract – Architecture Specification
• How risks and uncertainty will be addressed – Architecture Contract - Control
• What change is expected – Architecture Contract – Implementation Strategy
• What change is out of bounds – Architecture Contract - Transition & Benefit

Governance Framework

All governance follows a model of direction and control. Direction and control at selection. Direction and control at implementation.

Simply extend the governance framework to include governing developing  architecture and governing implementation.

Your architecture development will make decisions ,or selections. Your implementation projects will make selections. Are these decisions in compliance with direction? What is your control?

>>> Download the Enterprise Architecture Governor's Guide

Architecture Development Governance

All decision rights belong to your Stakeholders. Use your Enterprise Architecture Governance Board should manage process. It should use the architecture development governance checklists. The checklists are a control to demonstrate the architect followed direction.

Architecture Implementation Governance

The TOGAF ADM has a specific phase to address implementation governance: Phase G: Governance Implementation. The Outcome of Phase G is a successful change.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture

The role of the enterprise architect is to guard value through implementation governance. You test the designer's and implementer's choices by comparing to documented Gaps, Architecture Requirements Specifications and Controls. Don't invent new architecture during a project.

The three completion essentials of Phase G:

• First, a successful implementation project that delivers expected value within the architecture's constraints.
• Second, a cancelled project. When a project cannot provide expected value, an enterprise's scarce change resources should be re-allocated as soon as possible.
• Third, a change of the target architecture. Extend the expected value, or pull it in to what we can realize. Relax or tighten constraints.

When there is a problem, the enterprise architect provides a recommendation of what the stakeholder should do. The Stakeholders only have three choices:

1. 1. enforce compliance with the target architecture
   2. provide relief and allow the project to ignore the target architecture (which is usually a weak method of changing the target)
   3. change the target architecture

Extended Governance Controls over Value Realization

The TOGAF ADM provides extended controls in Phase H: Architecture Change Management. This extended value realization activity is a an architecture control.

See TOGAF Phase H - Applying Agile and our recorded Webinar True Life EA Webinar: Agile COVID-19 Response for real-world realization of Enterprise Agility

Work Management

When we develop EA Teams we obsess over productivity. We focus on the guidance in TOGAF about essential knowledge. To improve productivity we use a Kanban knowledge manufacturing approach.

Following Kanban's best practices, we break the work down. Each work product will have an accountable resource and due date.

We start with Phase A:

1. What is the question?
   Question or Problem Space. What are the bigger questions or prior decisions that constrain us.
2. Who are the stakeholders?
   How will they assess the potential changes? What are their Concerns?
3. What information do we need?
   What is in the repository? What is missing? How will we gather it?
4. What analysis do we need?
5. What work products will help our stakeholders understand their choices?
   Architecture Views

Then we execute. With Kanban we have a backlog. Work-in-Progress is limited to what can be completed.