10   Process Model

It is a prerequisite to create a process model for EA Capability to integrate with the enterprise’s operational processes and business cycle. To create a process model, a logical model of the TOGAF Architecture Development Method (ADM) should be transformed to align with appropriate processes of the business cycles with which the EA Capability interacts.

To provide an actionable process model, the following questions must be answered:

10.1      What are the Touch-Points with Existing Enterprise Processes?

Enterprise planning and budgeting and the operational and change processes all have connections with the EA Capability. The nature of this connection will depend upon the purpose of the EA Capability identified in Chapter 5 (Business Objectives for the EA Capability).

This Guide uses a simple model for considering process integration – all planning and budgeting processes are considered as decision-making processes. Change and operational processes are considered execution processes. This simple model highlights the basic interaction of the process with the EA Capability. The type of decision-making and execution processes will direct the form of interaction.

In all cases, the critical process alignment is to have the EA Capability work products provided before a decision and before the beginning of change execution activity. Keep in mind the TOGAF framework concept of iteration; for example, the architecture work required to support budget planning, project planning, and solution delivery have different levels of detail. As the enterprise moves through a business cycle more detailed work is required. The correct EA needs to be done at the right time in the business cycle.

10.1.1 Decision-Making Process Integration Model

EA Capability provides advice and illuminates constraints to support the decision-making process of the enterprise. All planning and budgeting processes are considered as decision-making processes. The specific type of decision-making will direct the form of interaction. The interaction is divided into advice and constraints feeding decision-making, and reporting feeding governance of the decision.

Advice provided for decision-making is usually in the form of trade-off analysis, views, and an architecture roadmap. This advice leads to decisions, usually in the form of approval of a candidate architecture. Most constraints are prior decisions, often stated in the form of an architecture requirement specification.

Supporting governance activity, the EA Capability provides reporting within the scope of the target architecture on decisions made by the appropriate process. This reporting is used to confirm execution, drive change to the target architecture, or changes to execution.

Decisions direct the architecture support. Where there are subsidiary decisions the input will be guided and constrained.

Figure 17: Decision-Making Process Integration

The interaction model described above and represented in Figure 17 remains constant with all decision-making processes. The interaction is dependent upon the type of decision-making process. The World-Class Enterprise Architecture White Paper classifies four decision-making processes with which an EA Capability can connect. The nature of this connection will depend upon the purpose of the EA Capability identified in Chapter 5 (Business Objectives for the EA Capability):

Section 10.1.3 through Section 10.1.9 provide a discussion of how the EA Capability engages with decision-making processes.

10.1.2 Execution Process Integration Model

For execution processes, the EA Capability provides advice, direction, and constraints. All change and operational processes are considered execution processes. The type of execution processes will direct the form of interaction.

Direction to execution processes is provided in the form of what needs to be done – gaps to be filled and work packages. Constraints are defined in the form of an architecture requirements specification. Advice is primarily provided in the form of implementation guidance and non-compliance recommendations. The set of advice, direction, and constraints is used in the execution of change efforts and operations.

Supporting the governance processes, the EA Capability provides reporting within the scope of the target architecture on changes made by the execution process. This reporting is used to confirm execution, identify potential need to change the target architecture, or introduce early changes to execution. Reporting is also provided to the appropriate decision-making processes.

Regardless of the type of execution process and major transformation project, the interaction model described above and represented in Figure 18 remains constant. The interaction is dependent upon the type of execution process, and when the execution is taking place. The World-Class Enterprise Architecture White Paper classifies four execution management processes with which an EA Capability can connect. The nature of this connection will depend upon the purpose of the EA Capability identified in Chapter 5 (Business Objectives for the EA Capability):

Figure 18: Execution Process Integration

Section 10.1.3 through Section 10.1.9 provide a discussion of how the EA Capability engages with execution processes.

10.1.3 Strategy Development Process

An EA Capability that is chartered to support strategy will be tightly integrated with strategy development processes. Strategic decision-making tends not to closely follow fixed cycles – this requires the EA Capability to be nimble.

Supporting governance will be reporting on execution against the roadmap and value realization embedded within the target architecture supported by the roadmap.

Predictable deliverables will be required before the budget planning process. Supporting strategy development decision-making would provide insight into the impact of the changes to existing initiatives, portfolios, and the extension of roadmaps. When the roadmap is extended, identify and recommend key work packages that deliver value.

10.1.4 Portfolio and Program Management Processes

An EA Capability chartered to support portfolio will be tightly integrated with portfolio/program planning and budget cycles. This requires the EA Capability to be working well ahead of the decision-making cycle to ensure that necessary advice is available during and throughout the budget process.

Governance of the portfolio and program execution is split between ensuring projects deliver on expected work packages and fill necessary gaps and reporting on success that creates the conditions for value realization.

Ad hoc work will be required to support portfolio and program management activity. Central activity is to support the ongoing alignment of approach, jockeying the enterprise roadmap to ensure that all dependency is addressed and synergy maximized.

10.1.5 Project Initiation, Project Management, and Change Management Processes

An EA Capability chartered to support solution delivery and project must be tightly integrated with the enterprise’s project initiation process and change process. A common problem for enterprises embarking on EA Capability initiatives is aligning the EA Capability after project initiation – architecting after decision. Performing high-value work after decisions is impossible.

The second challenge is aligning with the change processes at the right level of detail. Many enterprises have change processes that are variable based upon the scope, objective, and sponsorship of the project. Best practice requires the EA Capability to engage ahead of decisions. Where the EA Capability supports strategy, portfolio, and program there is an additional governance activity. This activity is focused on highlighting misalignment of any change activity with the work packages and roadmap.

Two key elements of advice must be provided before initiation. First, the final definition of the project (architecture to support project), or the solution architecture (architecture to support solution deployment). Second, integration and alignment between projects within the context of their portfolio and program. Alignment with project and solution delivery requires a high level of ad hoc work to support project initiation and governance activity within a project.

Governance activity should be integrated within the project reporting and control scope. Best practice governance requires EA Capability personnel assigned to the project to remain neutral and not report to the project. Performing effective governance requires independence from the pressures of project delivery.

Keep in mind that all change activity, whether a capital project or operational change, needs to be governed by the architecture requirements specification.

10.1.6 Budgeting Processes

One of the demands from the EA Capability is to support the budgeting process, either for the fiscal year or for the entire planning horizon. As always, the EA Capability will be operating before decisions, advice, and supporting governance are confirmed. Best practice support requires the EA Capability to deliver the initial version of its advice before the start of any budget conversations.

Integrating with budgeting processes is closely aligned with the integration for portfolio and program management processes.

10.1.7 Operational Management Processes

The primary association with operational processes is information capture during architecture analysis and ongoing governance of operational change.

The EA Capability requires connections with any operational processes that are within the scope of the EA Capability. The primary connection is gathering and identifying value realization metrics; for example, is the specified architecture generating the value expected by the stakeholders? This can be a difficult relationship with an operational team when the architecture is specifying a value that does not align with the parochial preferences of an operational team.

A secondary connection is operational change, and ensuring this change aligns with the architecture requirements specification.

10.1.8 Governance Processes

A high-functioning EA Capability is dependent upon engagement with the enterprise’s governance processes. The EA Capability requires engagement at all points in the lifecycle of a target architecture.

Governance is required for both the focus of the EA Capability and the architecture projects undertaken. How the Leader directs and controls the focus of the EA Capability is critical to realizing the available value. A high-functioning EA Capability works on the optimal mix of architecture projects.

Approval of the target is one of the most important governance functions. IT-oriented teams routinely create an architecture board that is positioned with a decision-making role on both the target architecture and conformance of change projects. This pattern is unlikely to succeed, unless the EA Capability is restricted to IT functions, and specifically to infrastructure.

At the core of good architecture is the set of preferences expressed by stakeholders. The target architecture must address the optimal set of stakeholder requirements – this optimal set requires trade-off between stakeholder requirements. When the EA Capability is chartered to support strategy and portfolio, the decision-making body to perform the trade-off will constantly face the breadth and variety of cross-domain stakeholder requirements.

The most successful architecture boards work to control the process. A high-functioning architecture board will be structured to confirm that:

  1. The EA Capability is working on the highest value architecture projects.
  2. The EA Capability addressed the correct stakeholders for a given architecture project.
  3. The EA Capability appropriately works with other implemented enterprise frameworks, such as ERM.
  4. The architecture description, supporting model, views, and architecture requirements specification are internally consistent.
  5. The implementation and migration plans conform to the roadmap.
  6. The architecture contract associates the gap, work package, and appropriate architecture requirements specification to programs and projects.
  7. Appropriate stakeholders review conformance reviews.
  8. Decisions taken by a stakeholder based upon a non-conformance result in a change to the target architecture or the change initiative’s execution approach, or an exception.

One of the most important activities of governance is reporting to appropriate stakeholders. This reporting needs to include:

Make sure that the views, dataset, and controls used for the target architecture and value of the target are used to represent the baseline as well. This might appear counter-intuitive. It is easier to communicate what did not exist or what was eliminated; hence the value of the baseline is less than the target.

Consider using summary reporting with a high visual impact. Below is an example of reporting against architecture principles. The same summary can be used for value, roadmap, and execution activity.

Table 6: Example of Summary Governance Reporting

Principle 1

Principle 2

Principle 3

Portfolio: Assess the enterprise within the scope of a portfolio.

Conforms

Violates

Not Applicable

Project: Assess the enterprise within the scope of a project.

Violates

Not Applicable

Conforms

Component: Assess the components within the baseline architecture.

Not Applicable

Conforms

Violates

10.1.9 Enterprise Risk Management (ERM) Process

A central role of the EA Capability is to facilitate creation of an environment where operational risk can be optimized for maximum business benefit and minimum business loss. This requires close integration with the enterprise’s risk management approach and an understanding of the scope and interests of ERM. Tight integration with ERM facilitates tilting the EA to improve realization of objectives, and the reduction of uncertainty.

In all cases, the EA Capability needs to test the candidate architecture, roadmap, and value against the ERM. While close interaction with a robust ERM process should be undertaken, Table 7 identifies key areas to test.

Table 7: Key Touch-Points with Enterprise Risk Management (ERM)

Candidate Architecture

Roadmap

Value Realized

Key Risk Areas

Flags areas of special concern

Flags areas of special concern

Perform more detailed value assessment

Risk Appetite

Aligns with risk appetite

Aligns with risk appetite

Aligns with risk appetite

Business Impact Analysis

Not applicable

Roadmap aligns with & informs impact analysis

Not applicable

Risk Assessment

Performs as appropriate

Performs as appropriate

Value aligns with risk assessment

10.2      How is ADM Iteration Realized in Practice?

An often-misunderstood element of the TOGAF framework is actioning the ADM and the concept of iteration. The TOGAF ADM graphic provides a stylized representation that is often interpreted as a linear waterfall. To demonstrate the flexibility inherent in good practice, diagrams showing levels and fish-ladders up the waterfall have been used. The key point is that the ADM graphic shows essential information flow and is not a representation of activity sequence.

The important thing to realize is every time the EA Capability is undertaking any roadmap development; it is exercising the steps in the TOGAF ADM Phase E (Opportunities and Solutions). It is expected to consume the mandatory inputs and produce the mandatory outputs. This applies to all ADM phases. Simply don’t worry about activity sequence; worry about information inputs and outputs.

Consider the stylized Gantt chart in Figure 19. The inter-dependent nature of EA requires all ADM phases that develop a candidate architecture to be executed simultaneously until the candidate architecture is tested for acceptance against the stakeholders’ requirements. They close to allow specific elements of supporting domains to be completed. This provides a process-oriented view of ADM iteration.

Figure 19: Stylized Architecture Development Gantt Chart

Keep in mind this is a simple stylized example. The real world is always more complex and aligns to the objectives that EA Capability is chartered to deliver.

The process created is not dependent upon the work the EA Capability undertakes to produce, but the timing of completion. The essential question is when an EA Capability must deliver specific work products. Table 8 provides a summary of work products that are actively consumed by key enterprise processes.

Table 8: Work Product Alignment with Key Processes

Practice Supports

Strategy

Portfolio/Program

Project

Solution Delivery

Phase A
Work Product:
Vision

Key deliverable

Before framing of a strategic planning session

Refresh before initiation of program budgeting

Key deliverable

Before start of budget planning

Often not used

Activity to produce a vision overlaps with portfolio/program candidate architecture and roadmap

Technique may be used at initiation of business case

Limited use

Primary use is early in implementation cycle (via internal providers or execution partners)

Phase E
Work Product:
Candidate Architecture

During strategic planning session

Refresh as required in program budgeting

Key deliverable

Before start of budget planning

Primary use is stakeholder acceptance of target and definition of gap

Before project initiation and finalization of business case

Primary use is creation of architecture requirements specification

Before engagement of execution partners (including internal providers)

Primary use is creation of architecture requirements specification

Roadmap

During strategic planning session

Refresh as required in program budgeting

Before start of budget planning

Refresh as required to support budgeting and program management

Limited use

Can be used as an input to projects with multiple interactive changes

Before engagement of execution partners (including internal providers)

Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement

Phase F
Work Product:
Architecture Contract & Architecture Requirements Specification

Likely not used

Limited use

Key deliverable

Before completion of project initiation

Key deliverable

Before engagement and contracting

Implementation & Migration Plan

Likely not used

During portfolio budgeting

Refresh as required to support budgeting and program management

Key deliverable

Before project start

Key deliverable

Before engagement and contracting

Phase G
Work Product:
Conformance Assessment

Likely not used

Likely not used

Key deliverable

At key points in project that allow reporting to stakeholders and obtaining decisions for non-conformance

Key deliverable

At key points in project that allows reporting to stakeholders and obtaining decisions for non-conformance

Phase H
Work Product:
Value Assessment

Before governance review, framing a strategic planning session and program budgeting

Key deliverable

Before governance review and program budgeting

Refresh as required to support program management

Limited use

Scope of significant architecture change and value often does not cleanly align to projects

Limited use

Scope of significant architecture change and value often does not cleanly align to solution deployment

As mentioned in the World-Class EA Practitioner’s White Paper, purpose-based architecture delivery exercises each of the ADM phases to the extent necessary, starts in Phase F, and performs work in Phase B, C, and D. Table 8 informs the Leader which deliverables are important for which purpose-based architecture and from which phase the deliverable is produced. When designing the process model for the EA Capability, align the steps to develop the architecture to the business cycle and the deliverables required to support decision-making and governance processes.

Once the process model is created, use this checklist to validate completion of the customized EA method and a framework for related functions in the organization:

Leaving out any one of these will cause problems at later stages of execution, as the team will be splitting its capacity to address the process gap, build the architecture, and provide confidence to decision-makers.

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>