TOGAF - Architecture Development Iteration

In previous post TOGAF Architecture Capability been discussed and this post summarizes the some tips on the second iteration; Architecture Development Iteration.

You can find a refresher on TOGAF ADM here before progressing further possibly.

In the Architectural Development Iteration, five phases are considered: phase B (Business Architectures), phase C (Information Systems Architecture) which encompasses applications and data, phase D (Technology Architecture), phase E (Opportunities and Solutions), and phase F. (Migration Planning). As illustrated in the image above the Transition Planning is a sort of sub-iteration comprised of phases E and F. Having said that it won't be exaggeration to say that this iteration is at the heart of the ADM. 

The architecture team takes up on the vision, goal, and objectives from the prior two phases and begins to construct and describe a relevant architecture under the guidance of a lead architect. Phases B, C, and D concentrate on distinct but interconnected architectural domains which are Business, Applications, Data, and Technological domains with common set of aims:

• A goal is to come out of this iteration with a hand full of architecture concept that can later be implemented.
• Another purpose is to develop a practical roadmap to achieve the identified target state architecture by looping through the phases of Business, Information Systems, and Technology Architecture.
• A further goal is to produce architecture content by iterating through the B, C, and D phases.

Multiple architectural development iterations guarantee that the design is viewed as a whole, and it is consistent with the basic goals outlined in the preliminary and vision phases. Furthermore, it will guarantee that stakeholder concerns are addressed across the architecture development and all upgrades to it. You got to be sure that the stakeholders are ready for adopting the change. What I want to emphasize is that implementation should be incorporated into the design.

Each phase and associated architectural domain necessitate the construction of baseline and target state architectures (Refer to the Baseline and Target Architectures’ definitions further down).

Approach

Here is we are dealing with two approaches:

Baseline first approach

This initial baseline analysis can be used to make modest adjustments to the existing architectural landscape. In a simpler word change to the architecture is incremental and starts with the baseline architecture.

Target first approach

This is the approach by which the target architecture is developed first and then mirrored back to the baseline architecture. This approach will be utilized to support large-scale transformation sort of projects/programs.

As a general rule, whether you adopt a baseline first or target first approach, you should identify and repurpose as much as humanly possible. Experience tells that a superb architecture will be built in tandem with the development of a business strategy. In other words, architecture motivation is characterized by business strategy, and EA should adapt to and facilitate the delivery of business strategy whether the aforementioned business strategy is stable or in constant flux.

There is no amount of forewarning that will suffice when it comes to changes. They can have an impact on architectures and can come from anywhere, such as people, procedures, technology, economics, and so on.

In any case, approaches are specified through the use of architecture building blocks. Let’s have a closer look:

Architecture Building Blocks

As previously stated, a building block is a term often used to refer to business or IT architecture components that are theoretically reusable. Please distinguish between Architecture Building Block and Solution Building Block, which refer to architecture implementations.

Assume you wish to design a ticket management system; from a business standpoint, the entire ticket management system can be considered one application building block or it can be decomposed into solution building blocks that will be defined in implementing mentioned ticket management system. Maybe you will have business building blocks and information system building blocks, and then further subdivide them into technology building blocks, which can be subdivided further as required.

This approach assists you in expressing the baseline and target state architectures, which leads to the TOGAF-recommended phase, which is the Gap Analysis. (will look into this a bit further)

Architectural building blocks (ABB) have various qualities that allow them to be utilized in more than one implementation and across multiple architectural models, enabling architecture design implementations more efficient, effective, and error-free, plus stakeholder buy-in is smoother because it has been used previously. They could also adapt to accept technological changes and respond to changing business requirements. Furthermore, they can be combined with other building blocks to make a bigger reusable building block or blocks and can be used as part of a bigger building blocks.

In closing, I believe that building blocks have the capacity to deliver architectures and solutions.

Gap Analysis

The focus of the Gap Analysis is on gaining a comprehensive knowledge of the discrepancies seen between Baseline and Target state architectures from phases B, C, and D which give phase E (Opportunities and Solutions) enough material and focus to review the analysis. Via this Gap analysis the responsible architect will need to document what is missing which will be different for each phase due to the fact that:

• Phase B’s focus is on the business functions, capabilities, processes, services, people, …
• Phase C (the interplay between data and application capabilities) tends to focus on application portfolio and legacy applications to be replaced or upgraded, redundancies, integrations, applications that share data and functionality, inefficiencies and deployment processes, data insufficiencies, non-availability, data quality, accuracy issues, and totally existing problems in the applications.
• Phase D is concerned with capability and capacity gaps in end-user environments such as networks, hosting, and cloud services, among other things.

TOGAF recommends for each phase to represent gaps using a matrix of all the architecture building blocks with

• baseline building blocks on the vertical axis and
• target state building blocks along the top horizontal axis.
• This includes the bottom row labeled new added to the baseline architectures,

and a final column added to the target architecture columns labeled Eliminated.

It is entirely up to you how you fill out the cells... Here are some guidelines from TOGAF:

• where an architecture building block is present in both the baseline and target architectures, record this with included at the intersecting cell
• where a baseline architectural building block is lacking in the target architectures; each must be reviewed:
  • Mark it as such in the appropriate eliminated cell if it was correctly eliminated.
  • If it was not an unintentional deletion in the target, architecture was discovered that must be addressed by reintroducing the architecture building block in the next iteration of the architecture design. This would be marked as eliminated,
  • Where an architecture building block from the target state is not found in the baseline architectures, mark it at the intersection with a new row as a gap that must be closed by developing or acquiring the building block.

Whenever this exercise is finished, everything under eliminated or new is a gap that should be either explained as correctly eliminated or indicated as seeking attention by reinstating, developing, or acquiring the function. Following clearance, the next step is to develop a road map.

Roadmap

A roadmap is essentially a list of specific activities, or what TOGAF refers to as Work Packages (A set of actions identified to achieve one or more business objectives), that will allow the organization to realize its target state architectures. This would consist of:

1. the timeline that illustrates and exhibits the evolution from baseline to target architectures
2. It links work packages to business values,
3. Also, the transition architectures or intermediate states required to actualize the final goal state architectures are included in this roadmap.

The architectural roadmap is incrementally developed throughout phases, E opportunities and solutions and F migration planning. It's also informed by readily identifiable roadmap components from B, C and D within the architecture development method. Keep in mind that

• Roadmaps depict how architecture will evolve through intermediate steps to achieve the desired state,
• Roadmaps are a useful tool for beginning to consider practical ways in which architecture could be achieved,
• and roadmaps expose discrepancies between the enterprise's strategic vision and its current and near-term tactical and operational priorities.

This could result in a rethinking of the architecture as well as a novel strategy to implementation. This roadmap will then be utilized as a jumping-off point for a more specific solution during the opportunities and solutions phase.

Guidelines and Techniques

Capabilities-based planning is a key technique used in this ADM iteration that you will find useful to understand and become comfortable with. Capability planning is a top-down strategy planning tool. Capability planning enables one to see the enterprise solely through the lens of what the enterprise does. Capability-based planning is concerned with the development, engineering, and delivery of strategic business capabilities to the enterprise. It is driven and directed by the business and brings together the necessary efforts from all areas of business to attain the required capabilities. Capability-based planning can suit most enterprise business models. Business scenarios are commonly used to discover and refine these requirements. Capability-based planning deconstructs higher-level enterprise needs and processes into several components. It allows you to conceptually split an enterprise from the top down and aggregate from the bottom up, depending simply on the actions that occur within it.

There could be numerous hierarchical levels of capability. In this example, we begin at a relatively high degree of abstraction. Organizations employ approximately six levels of capacity, with levels 1, 2, and 3 generally employed for strategic planning purposes:

Levels 4 to 6 are substantially more granular and are thus utilized to relate strategy to implementation:

Using a capacity model, also known as a capability map, will take you from a high-level plan to a thorough implementation of changes. Business capability maps have been dubbed the "Rosetta Stone" of business and IT alignment; this is due to the fact that architects apply capacity mapping across stages A through D to arrive at feasible architectural solutions:

Capability modelling and mapping starts with defining an enterprise's end state capabilities in order to achieve a set of business strategic objectives in a set of business scenarios. As a result, architects conduct extensive architectural analysis to identify capability gaps in each domain, taking into account input from various perspectives such as operational considerations, technological considerations, strategic, tactical, internal and external uncertainties, and overall forces influencing the enterprise, as well as real and perceived risks. This research will yield a number of theories and verified options to help fill previously identified capability gaps. Each option is then assessed based on how effectively and efficiently it may fill the gap and address the challenges identified in the previous documented scenarios, as well as how well it addresses stakeholder concerns and how closely it is aligned with the strategic drivers and business objectives:

Inputs and Outputs

Phase B – Business Architecture Phase

The approved statement of architectural work and the architecture vision document are two critical elements in business architecture phase B. As a prerequisite for this phase, all outcomes from phase A, as well as the availability of the architectural repository and any existing relevant artifacts, would be crucial inputs.

The following are key deliverables/outputs of the business architecture phase (phase B):

• a proposal or early version of the Architecture Definition Document that specifies the building blocks of business architecture:
  
  • Architecture models for business stakeholders displaying existing and future state business architectures,
  • Gaps were found, and architecture solution choices were provided. This would cover the advantages and disadvantages of each, as well as any preliminary recommendations,
  • any restrictions that may apply to other domains of architecture,
• In addition, this phase will generate a prospective architectural roadmap just from the standpoint of business architecture. These outputs are intended for utilization by business stakeholders because their feedback is required for the subsequent phases to be successful, i.e. effective and efficient in terms of their contribution to enterprise architecture.

Phase C – Information System Architecture Phase

The identical inputs to phase B as well as the outputs of phase B would be key inputs to the information systems, architecture, or phase C. This would particularly apply to:

• the architecture vision,
• the architectural statement of work
• and the architectural repository.
• In addition, along with the reference models, this phase must make use of current data and any existing information system architectural artifacts already available in the architecture repository.

Phase C deliverables/outputs will aid in the further formulation of architecture definition documentation and data and application architecture building blocks, providing greater details on the current and target state architectures as well as describing the gaps that exist. Typically, this will result in the formation of:

• enterprises data inventory
• logical reference models
• application portfolio catalog
• interoperability requirements
• integration requirements
• change is required in the business architectures
• and constraints on technology architectures.

Phase D – Technology Architecture Phase

Step D will receive the majority of the inputs and outputs from phases B and C. Internal and external reference models, as well as other reusable architectural artefacts relevant to the current project's portion of the enterprise architecture, are also used in phase D's technology architecture.

The following are the results of the technology architecture phase:

• a contribution to the architecture definition paper focusing on the domain of technology architectures. Here is a list of some of the architectural elements that it will define:
  
  • a technology stack for the implementation of the solution.
  • The linkage between technology and information system building blocks in order to facilitate and maintain hosting environments.
  • Pipelines for deployment and deployment considerations at various phases of deployment
  • The expected load.
  • The requirements for capacity and performance.
  • The specifications for servers, storage and networks and other infrastructure components,
• as well as the technology architectural Roadmap.

Enterprise Capability will assure that the strategy is well articulated and that the tactical and operational plans are all in sync with it. By summarizing this iteration the next would be Transition Planing Iteration which I am going to take my note on it.

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.