Implementation Plan Models, Tools, and Techniques

The TOGAF ADM Phase F delivers the Implementation Plan and Architecture Contract. This Phase exists to enable action.

Phase F is a translation of the Architecture Roadmap and the Target Architecture to action. There are five central Implementation Plan crafting techniques that help stakeholders understand the how to realize the target architecture’s benefits.

• Portfolio Grouping
• Program Grouping
• Benefit Realization
• Risk Mitigation
• Architecture Contract
• Implementation Strategy Model
• Using Architecture Roadmap Techniques

Implementation Plan Techniques

Taken together, the techniques will highlight everything the Enterprise Architects have to contribute to crafting the Implementation Plan. The Enterprise Architect’s role nets down to guarding the value of the change.

Portfolio Planning / Portfolio Grouping

The Project Management profession uses Portfolio and Program to enable managing a complex set of projects. Project Sponsors and the Implementers look at the project’s explicit deliverables.

Portfolio Planning groups the projects by outcome. As a specified Portfolio someone can be accountable for the outcome. This increases the possibility of success and enables implementation governance.

The Portfolio creates a natural authority structure. The rest of the organization will adopt the authority structure and outcome-based reporting.

Program Planning / Program Grouping

Program groups projects for execution. Just like Portfolio, you will reach a person accountable for managing a set of related projects. An execution-oriented natural authority structure is created. The rest of the organization will adopt the authority structure and execution-based reporting.

Benefit Realization

We always align benefits of the enterprise architecture to the deficiency that started the current architecture development. We use the Architecture Roadmap and the Enterprise Architecture to govern implementation. This requires separating expected benefits from the project’s that are expected to deliver the benefit.

In Navigate™ we align a benefit to Work Package. We link Work Package to the Gap it is filling and the Project that will deliver it.

We routinely find that during Project Initiation and Project Execution, the work that will deliver a Benefit is de-scoped, while the Benefit continues to appear on the Project’s PowerPoint slides. This is especially true when the Project Sponsor will not receive the Benefit.

Enterprise architecture exists to guide effective change. Effective change realizes the Benefits.

When crafting the Implementation Plan, we look for the work that will explicitly fill a Gap and deliver a Benefit. No work, and you have an unfilled Gap and a missing Benefit.

Risk Mitigation

We have two uses of the term Risk. First, it is the effect of uncertainty on meeting your objective. This is the definition used by the Risk Management Profession. We find it resonates most strongly with enterprise architecture. Second, is the normal usage where a Risk is a bad thing that can happen. We find most people think of Risk as a Threat, or Bad thing. It doesn’t matter how you use Risk. We find uncertainty and threat are addressed the same way. You address it with a control, and that control must be implemented through a Work Package.

In Navigate™ we align a Risk either an Asset or an Objective. A Control mitigates the Risk. A Work Package implements Controls.  We link Work Package to the accountable Project.

Objectives are why we are doing the change. Missing means the change was pointless. When you have an uncertainty of meeting the objective, what are you doing to reduce the uncertainty? Addressing uncertainty is critical Implementation Planning and implementation governance activity.

Again, we separate the Risk and Control from the Project. We link through Work. This allows us to plan and monitor for de-scoping.

We routinely find that during Project Initiation, and Project Execution Objectives and Assets that are not directly tied to the Project and Project Sponsor will be de-scoped. This is especially true when the Project Sponsor does not own the Objective.

We routinely expected change initiatives to develop capabilities, reduce agility draining friction, lower ongoing operational costs. Yet they routinely fail. They fail because we deliver work through focused projects. Each focused project is bound by the Iron Triangle and will aggressively de-scope. We have never seen a descoping presented as a threat to an enterprise objective. They always present it as an improvement to the project.

Enterprise Architects must address uncertainty of reaching objectives during Implementation Planning. Without this, they cannot perform implementation governance activity.

Architecture Contract

TOGAF’s concept of the Architecture Contract is incredibly powerful. Often it is presented as some form of documented agreement between the EA Team and the Project. While documenting it is useful, the contract is between the Stakeholder and the Project. It is never between the Project and the EA Team.

When we craft an Architecture Contract, we ensure it includes:

• Benefit

What Benefits will the Project deliver through what Work packages?
This provides visibility to the Implementers, the governance process, and the Stakeholder expecting the Benefit who is accountable, and what they are doing to deliver their accountability.

• Control

What Controls will the Project deliver through what Work Packages? What these Controls mitigate Risks?
Just like the Benefit, this provides visibility to the Implementers, the governance process, and the Stakeholder expecting to realize the Objective who is accountable, and what they are doing to deliver their accountability.

• Architecture Specification

What constraints remove freedom from the implementers?
This clarifies where a project team must follow guidance that contradicts the logic of their project. If their project’s logic will drive them to follow the constraint, we do not need the Architecture Specification. We use the Architecture Specification, where the logic of the project would cause a poor choice for the enterprise.

• Implementation Plan Strategy

How to approach change
Just like the Architecture Specification, how must an Implementer approach the project? This is especially true where the project logic will lead them to another approach.

• Transition

When are we deliberately stopping short? Every minute of work on change past a Transition point is probable waste. We craft transition points to be Value Resting Points. Points in the change where the Stakeholders can delay, stop, or change direction. We use transitions for implementation governance. They help when the project logic, or preferences of the Project Sponsor will drive a project to go further than is expected. Usually with an explanation of efficiency. However, if the Sponsors, delay, stop, or change direction and the next complete Value Resting Point is not reached the project built another half-bridge.

Implementation Strategy

Whether you include the Implementation Strategy in the Architecture Contract, the Implementation Strategy is critical when crafting an Implementation Plan. The three types of change (Evolutionary, Revolutionary, and Greenfield) will drive the project design and system design.

For example, if you require starting from scratch (Greenfield), you are expecting organization, process, and system change. You are deliberately throwing away the existing organization, process, and systems. Your project had better be designed to craft something new and lead the change management through the change.

Frankly, legacy systems, poor processes, and rigid organizations are sustained by typing a change to the Project’s easy path (Evolutionary).

Using Architecture Roadmap Techniques

The different techniques to develop an Architecture Roadmap are used to provide different guidance and constraint when crafting the implementation plan.

• Architecture Roadmap Type 1: Tagging with Recommendation and Heatmaps

Heatmaps will provide guidance and constraint from attributes like value, work, risk, or transition state. They drive project design.

• Architecture Roadmap Type 2: Lifecycle Charts

Lifecycle charts provide guidance and constraint about time. Whether the Lifecycle chart is about a system or a change, it highlights the boundaries for starting and stopping. They are powerful when a change event is needed by a certain time. It is surprising how often a late change is worthless. If you can’t have the new system in time, a new system late loses its value.

• Architecture Roadmap Type 3: Work Package Impact & Dependency

Dependency models provide guidance and constraint about dependency. Whether the dependency is work, organization, systems, or transition states. A dependency diagram will often help you understand required-by dates in a Lifecycle Chart.

• Architecture Roadmap Type 4: Scenario Analysis across Multiple Candidates

Scenario roadmaps are rarely useful when developing an Implementation Plan.

Complex visualization of work packages, architecture options or transition state options. Rad plot will typically represent concerns or attributes such as value, work, or risk. Points on the plot will usually represent architecture options or transition state options.

Learn more about Conexiam’s Architecture Roadmap Workshops

Transition Architecture

Transition Architecture provides guidance and constraint about stopping points. To deliver a value resting points, you structure projects to reach the transition state together. The most important dates in any Transition State are the ‘required by’, or ‘drop-dead’ dates.

Gap & Solution

Gaps explain what deficiency we need remediated. They help a project define scope and outcome.

Solutions simplify design. If there is an expected solution, or solution attributes, it simplifies scope and design. This is especially true when you have selected a Greenfield, or Revolutionary, Implementation Strategy.

Implementation Plan Techniques Aligned to Enterprise Architecture Purpose

Architecture teams support different purposes. Whether you support Portfolio questions or Solution Delivery will change how you develop and use architecture roadmaps. For example, Architecture to support Solution Delivery won’t use an Architecture Roadmap Type 1: Heatmap to develop decisions. We will use it as superior architecture and a set of constraints on the architecture development and any implementation. Good architects always work within the constraints of superior architecture.

	Architecture to Support Strategy	Architecture to Support Portfolio	Architecture to Support Project	Architecture to Support Solution Delivery
Portfolio Planning	Key Deliverable	Key Deliverable	Superior Architecture	Superior Architecture
Program Planning	Key Deliverable	Key Deliverable	Superior Architecture	Superior Architecture
Benefit Realization	Key Deliverable	Key Deliverable	Important Deliverable & Superior Architecture	Superior Architecture
Risk Mitigation	Key Deliverable	Key Deliverable	Important Deliverable & Superior Architecture	Superior Architecture
Architecture Contract	Important Deliverable	Key Deliverable	Key Deliverable & Superior Architecture	Key Deliverable & Superior Architecture
Implementation Strategy	Superior Architecture	Superior Architecture	Superior Architecture	Superior Architecture
Architecture Roadmap Type 1: Heatmap	Superior Architecture	Superior Architecture	Superior Architecture	Superior Architecture
Architecture Roadmap Type 2: Lifecycle Chart	Superior Architecture	Superior Architecture	Superior Architecture	Superior Architecture
Architecture Roadmap Type 3: Dependency	Superior Architecture	Superior Architecture	Superior Architecture	Superior Architecture
Architecture Roadmap Type 4: Scenario	Superior Architecture
Transition Architecture	Superior Architecture	Superior Architecture	Superior Architecture	Superior Architecture
Gap & Solution		Superior Architecture	Superior Architecture	Superior Architecture

Implementation Plan Techniques for Enterprise Architecture Use Cases

Implementation Plan techniques provide better support for different enterprise architecture use cases. Depending on the use case, enterprise architects are more efficient in helping their stakeholders with different techniques.

While every enterprise architecture use case is about change, the type of change and drivers are different.

	Strategic Change	Incremental Change	Improve Cost	Improve Quality	Improve Enterprise Agility	Mitigating Technology Risk	IT Modernization	Digital Transformation	Application Portfolio Rationalization	Acquisition Integration
Portfolio Planning	Critical	Useful			Critical	Useful	Useful	Critical	Useful	Critical
Program Planning	Critical	Very Useful	Useful	Useful	Critical	Very Useful	Critical	Critical	Critical	Critical
Benefit Realization	Critical	Very Useful	Critical	Critical	Critical	Very Useful	Very Useful	Critical	Useful	Critical
Risk Mitigation	Critical	Very Useful	Critical	Critical	Critical	Very Useful	Very Useful	Critical	Useful	Critical
Architecture Contract	Critical	Useful	Useful	Useful	Critical	Critical	Useful	Critical	Critical	Critical
Implementation Strategy	Critical	Useful	Useful	Useful	Critical	Critical	Critical	Critical	Useful	Useful
Architecture Roadmap Type 1: Heatmap	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful
Architecture Roadmap Type 2: Lifecycle Chart	Critical	Critical	Useful	Useful	Critical	Useful	Useful	Critical	Useful	Critical
Architecture Roadmap Type 3: Dependency	Critical	Critical	Useful	Useful	Critical	Useful	Useful	Critical	Useful	Critical
Architecture Roadmap Type 4: Scenario	Limited Use				Limited Use			Limited Use		Useful
Transition Architecture	Critical	Critical	Useful	Useful	Critical	Useful	Useful	Critical	Useful	Critical
Gap & Solution	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful	Useful

Applying Enterprise Architecture Principles to Implementation Plan Development

Your architecture principles will drive and constrain your Implementation Plan. Our consulting practices identified 7 Architecture Principles every enterprise architect should know. The following table provides a simple example of how an Implementation Plan is constrained by superior architecture.

Any Implementation Plan that doesn’t conform to the letter and spirit of superior architecture needs to be caught by enterprise architecture governance and reworked.

	Implementation Plan Implication
Don’t Mess With Success	All change needs to be assessed by the possibility it will damage current success. Potential improvement needs to be constrained to ensure the baseline is maintained.
Focus On Excellence	Change must be focused. All change without a direct line to enterprise value must be questioned. Use value definitions supporting excellence to assess the potential value of a change. Do not be afraid to identify changes that do not improve enterprise excellence as ‘value free.’
Why Not One?	Changes that create duplication need to be challenged, with value delivery decreased. Changes that remove duplication need to have the value delivery increased.
Data is an Asset	Ensure control of the data model is not surrendered in ways that diminish the value of data asset.
Systems Work Where We Work	Work location and work style are foundational measures of value. Any change that cannot meet location and style needs value delivery decreased.
Painless User Experience	Change costs need to be reviewed to ensure that user impact is properly assessed. Carefully look at change impact compared to potential benefit. You will always pay for impact, while you might not receive the expected benefit.
Self Service	Self-service is an enterprise value measure. Look at self-service delivery through the baseline, transition, and target states. Adjust cost and benefit assessments to reward provisioning self-service and penalizing and damage to existing self-service. You always pay for damage. You might receive a benefit.

How does TOGAF Phase F align with Agile Development?

Every Implementation Plan will provide multiple constraints and guidance for agile development. We see Enterprise Architecture and Agile Development intersecting in four areas. There are four areas where there is an intersection:

1. define the agile approach
2. guide the backlog in sprint
3. constrain choices inside the sprints
4. solve for cross product dependency

The Implementation Plan will significantly affect defining the agile approach. For example, the Implement Strategy Model will force or prohibit using agile development.

Transition states and expected Benefits will inform product development or product release, which will guide the backlog.

How does TOGAF Phase F enable Enterprise Agility?

Enterprise agility  is your organization’s ability to respond to the unexpected. Implementation Plans are responding to the expected. Strong planning skills help you respond to the unexpected. There is a direct correlation in the enterprise agility model to the ability to gather information and make a resolution decision. These are planning skills.

Enterprise Agility Model

1. Alertness – Can you detect opportunities and threats?
2. Accessibility – Can you access relevant information in time to respond?
3. Decisiveness – Can you decide using the available information?
4. Swiftness – Can you implement your decisions in the time available?
5. Flexibility – What are you doing to reduce the barriers to action?