TOGAF - Transition Planning Iteration

In previous post some tips on Architecture Development Iteration been summarized. TOGAF's Enterprise Architecture Development Method (ADM) Transition Planning Iteration will be the subject of this post.

Transition planning develops plans to move the architecture from the baseline to the target state. As a matter of course, the transition plan should be context-sensitive while also referencing previous transitions' key elements. So, we need to be more serious about architecture and implementations. The iteration is divided into two stages: phase E is known as the Opportunities and Solutions Phase, and phase F is known as the Migration Planning Phase.

This iteration transforms enterprise architecture into solution-specific architectures that may be executed by one or more projects. One or more enterprise projects scope, appraise, fund, and implement these solutions. A migration plan or set of plans is produced to guarantee a smooth implementation shift. This iteration helps create explicit change roadmaps for a given architecture. This ensures that parties affected by the architecture changes are appropriately involved.

You will obtain buy-in from impacted stakeholders, agree on transition architectures, and refine the opportunities to fit the stated business objectives as you progress through many transition planning iterations. This iteration allows for fine-tuning migration strategies based on stakeholder feedback.

Phase E – Opportunities and Solutions

These Phase E objectives are easy if you're familiar with best practices for change management:

• The first step is to generate a complete or preliminary version of the architectural road map. This is performed by utilizing the results of the preceding phases.
• If an iterative approach is necessary, build a list of potential work packages that can be picked up and delivered by designated enterprise initiatives. If this is the case, you will determine the transition architectures that will provide continued business value, then
• Based on the architecture building blocks, develop a set of overall solution building blocks that will conclude the target architecture.

Approach

The following is a broad approach to Phase E:

• assessing the change's impact on parties and their propensity to migrate. This is because the influence of enterprise architecture changes often spreads across multiple organizations that interface with enterprise Eco-Systems. The entities we cover here are therefore enterprises, encompassing business activities and IT departments inside the enterprise, suppliers, partners, and clients. They also focus on:
  • the magnitude of an entity's influence and, if any, its role in transition planning
  • the extent to which an enterprise architecture team may have influence over those entities and
  • the impact that culture, technology, skill sets, and other factors have on this iteration
• You'll also want to identify assisting and impeding forces, such as resistant and supportive stakeholders or any divisional or business unit level actions that can stymie or speed architectural conclusion.
• You should also identify any business restrictions, such as governance policies or budgets, that may have a significant impact on architectural completion.

There are numerous things going on in the business that could have an impact on the opportunities and solutions. As an architect you must continually be alerted about anything that could have any sort of impact.

Documentation of implementation elements that can affect the architecture is crucial. TOGAF suggests recording this data in a matrix artifact: The Implementation Factor Assessment and Deduction Matrix. This matrix is a repository for implementation decisions. It contains the implementation factor, its description, the beneficial or hindering consequences, and what needs to be done for the element to succeed:

An integrated gaps solution and dependencies matrix are also suggested by TOGAF. This matrix collects and documents earlier architecture development cycle gaps. It also identifies solution building blocks to address the proposed architectures' capability gaps. This matrix can be used to plan work packages:

Work packages are made up of Solution Building Blocks (SBB). To make it happen, a preliminary migration plan is created that shows the interdependencies, priorities, and progress of work within and across initiatives for communication and input on the migration plan. There are a few ways that are examined when developing an overall implementation and migration plan that will lead the adjustments required to accomplish the target architectures:

• Greenfield implementation, which is a completely new implementation,
• revolutionary approach that represents a major shift,
• as well as the evolutionary approach of introducing additional capabilities. Updates to the process, tools, skills, or process activities would constitute an evolutionary approach. This is the most popular, safest, and simplest way. It depicts steady, intermediate target states and is gradual.

TOGAF advises utilizing a transition architectures state evolution table to capture architectural state transitions. This will display the proposed state of the domain architectures at different levels of detail. Each transition state is intended to gradually improve the enterprise's capabilities. These would subsequently be implemented via various enterprise initiatives.

The architectural definition increments table captures the incremental accumulation of capabilities through architectures, increments across many enterprise activities.

Guidelines and Techniques

Work Packages (WP) are logically arranged sets of activities tied to one of the previously outlined techniques (Greenfield, Revolutionary and Evolutionary). It moves architecture from requirements to business improvement. They are a way of breaking down architectural solutions into manageable chunks of work that may be picked up and implemented by enterprise projects. They connect enterprise architectures, enterprise projects, and portfolio management capabilities which can take many forms such as program, project, use case, epic story, etc. This is where other frameworks like ITIL, DevOps and project management frameworks can be utilized. Understanding how to collaborate with implementation teams when creating work packages is also critical. The primary premise is to include key stakeholders while designing work packages. Here's a sample to illustrate what I mean:

You have seen the image, as you can tell, there are various architectural work packages, with names that correspond to the applicable layers, initiatives, programs, and projects to which they are assigned. There are logistics industries that a business in this example would like to take advantage of. There are also business units that are attempting to work efficiently with vendors while maintaining constant contact with their customers. The procedures, apps, and tools that support the top layer are in the intermediate layer. Finally, the lowest layer reflects the infrastructure defined at each layer's level relevant work packages.

Architecture Roadmap

Now A thorough examination of Roadmaping is in order. An architectural road map is a visual representation of how architecture initiatives progress from a baseline state to a target state that is based on a timeline. A road map can be built at several degrees of abstraction. It might be at a very high level, spanning the entire enterprise, or it could focus on a specific business, domain, or business unit:

Let’s read above sample roadmap. The Planning Horizon is the period an organization will consider while designing an architectural roadmap. This relies on numerous things, including the sort of business and the road map's focal area, which could be the entire enterprise or a single unit within it. The horizontal lines reflect investing themes, with further details available by selecting a line. Each investment item may represent a different architectural development stage. In addition, the diagram illustrates the point at which a particular capability, such as a minimal viable product, becomes operational. This paper will act as a master plan for the entire enterprise.

Input and Outputs

This is an extremely intensive and collaborative phase. There are numerous inputs and outputs involving numerous types of stakeholders, and who these stakeholders are will depend on the project's scope. Key stakeholders in a general circumstance might include change managers and change authorities from various business units.

Rationally, inputs would include the analysis of the outputs from the previous phases. This phase would bring all of those reports together in order to define opportunities and prioritize the upcoming work. This data will be available in the architectural repository. Here's what this phase might employ the followings:

• A request for architectural work,
• a statement of architectural work,
• a tailored architecture framework,
• architecture vision document,
• business scenarios,
• planning methodologies,
• and governance models and frameworks,
• a communication plan,
• a business strategy,
• a capability assessment,
• draft architecture definitions,
• requirements and change requests,
• and candidate architectural road maps from phases, B, C and D.

Among many others this phase's outputs would include the following:

• an architectural roadmap,
• transition architectures,
• consolidated gaps,
• solutions and dependencies,
• solution building blocks,
• implementation recommendations,
• work packages,
• initial architecture migration plans,
• updates to vision,
• and statement of architectural work.

Phase F – Migration Planning

It's time to wrap up the series of tasks that began with the architecture vision phase and bring it all together. In this phase, you as an EA will address how to move from the baseline to the target architecture by concluding the Implementation and Migration plan that you have started in phase E. Additionally, this phase signals the end of an iteration of stages B through F and the end of the F iteration.  After this phase, implementation teams use the plans to carry out the actual project work. The plans can be reviewed for adjustments that match with the corporate goals and objectives.

This phase's goal is to align the architectures with the goals and objectives set at the start of the architecture development process. This phase's aims would most likely include finalizing solution building blocks and work packages, as well as their sequence and priorities, as well as ensuring that these building blocks meet both architecture and project priorities when they are being moved into implementation.

Another objective would be to broaden and collect endorsements for architectural roadmaps and transition architectures, to engage relevant stakeholders in Phase E, and to collaboratively evolve and flesh out the migration plan to a point where the architecture and plans are relevant, achievable, and aligned with the business need's original intent.

The migration plan is a crucial product of this phase. As a result, the original migration plan is reviewed and modified to ensure that it is consistent with other enterprise frameworks that are in use. This includes wide range of frameworks such as ITIL, POMBOK, DevOps, Agile, Lean, COBIT, and so on.

Another step would be to identify the resources needed to accomplish architecture objectives and enable the activities defined in business-aligned and prioritized work packages. You'd also want to get the stakeholders' approval and consensus on the migration plans, as well as update the migration plan, architecture definition documents, the architectural roadmap, and other documents to reflect the new understanding based on the current consensus.

The architecture would subsequently be handed over to the implementation teams at this point. In addition, activities will shift from architecture development to architecture governance. If additional ADM cycles are required to improve the architectural design, a new iteration would be begun to trigger relevant phases to focus on specific domains.

Business Value Assessment

The Business Value Assessment approach is used to prioritize work packages. It starts with business value. All architectural work must be linked with enterprise business needs to guarantee that implemented architectures and work packages produce business value. The business value evaluation maps work packages against Value and Risk indices. The value index is a calculated value that measures a work package's conformity with business principles, values, ROI, strategic alignment, and competitive advantages. The risk index is a determined value that encompasses characteristics including such implementation complexity, work, organizational capability, learning experience, business readiness, external dependencies, and so on.

Take a look at this straightforward illustration of a company value index. When analyzing the business value of any initiative, the business chooses the elements and criteria, as well as the weight or importance of a collection of factors. In this sample Score is a 5 if it's really significant, and 1 if it's not at all important. The weighted score is determined by multiplying the weight by the score, yielding a weighted score:

In the same way, the profile of risk will be established. On a value risk table, the projects are mapped using bubble charts to show relative significance, with some already underway or in proposal stage, while others are stalled for various reasons.

Input and Outputs

Phase E findings are crucial inputs for phase F migration planning. During this stage, the following items are generated primarily as output:

• a finalized and endorsed architecture migration plan,
• a finalized architectural roadmap and transition architectures,
• a finalized architecture definition document,
• a finalized architecture requirement,
• reusable architecture and solution building blocks,
• a request for architecture work if more ADM cycles error required,
• and an implementation governance mode.

Cheers,
Mohammad Malekmakan

Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.