7 Walk Through Architecture to Support Strategy
7.1 Introduction
The objective of this architecture is to define an end-to-end Target Architecture and a roadmap to achieve it constrained by the planning horizon (normally three to ten years). This architecture will drive creation of several targeted change initiatives, define the boundary conditions for governance, and acceptance criteria for value reporting. Activities to develop this architecture will iterate the ADM at least once at the Enterprise level and once for the EA Capability.
On most occasions, EA initiatives are triggered in the middle of a business cycle. It is most likely performed by an Enterprise that has been operating for many years. A logical point to start the architecture work is to understand the rationale for EA work. Table 5 summarizes how the ADM phases are executed and to what outcome. The content of the table is discussed in detail in the rest of this chapter.
Table 5: Summary Table: ADM Phases and Architecture to Support Strategy
|
Topic |
Mapping to TOGAF ADM Phase |
|
Understand Context |
Partial Strategic Level Phase H Enterprise context:
Partial Strategic Level Phase A Enterprise context:
Context specific for the EA Capability:
|
|
Perform Assessment and Analysis |
Partial Strategic Level Phases B, C, and D Enterprise context:
Partial Capability Level Phases B, C, and D Enterprise context:
Context specific for the EA Capability:
Partial Strategic Level Phase A Enterprise context:
Partial Strategic Level Phase G Enterprise context:
|
|
Define Approach to Target State |
Partial Strategy Level Phases B, C, and D Enterprise context:
Partial Strategy Level Phase A Enterprise context:
Context specific for the EA Capability:
Partial Strategy Level Phase E Enterprise context:
Partial Strategic Level Phase G Enterprise context:
|
|
Finalize Architecture Vision/Target State |
Partial Strategic Level Phase F Enterprise context:
|
7.2 Understanding Context
Implicit roadmaps and direction have been used to execute the current year’s initiatives. Most of them are meant to address a gap. Most likely the progress or the impact concerns triggered the need for architecture work. Document such concerns and initiatives as the draft Request for Architecture Work. Those concerns are probably valid even now.
When approaching Architecture for Strategy, achieving the goals of the Architecture Vision phase is arguably the most important step for achieving a proper rollout of the next phases of the ADM as well as setting the stage for success for subsequent architectures. An implicit constraint to developing the strategic architecture is the duration of planning horizon. The Target Architecture should be commensurate with the ability of the Enterprise to look into the future, competition, investment strengths, etc. Another aspect is the existing models for governance and risk management. It may not be defined or stated explicitly. It is the fastest path to getting the efforts off the ground. If the EA Capability has not documented the model, spend the time to get it done.
The scope of a strategy architecture usually involves a wide breadth, a shallower depth, and a long timeframe. In order to define what is inside and outside the scope of the baseline and Target Architecture efforts, the following must be defined:
- The breadth, depth, and timeframe of the architecture landscape
- The level of detail to be covered in each of the architecture domains
- The partitioning characteristics of the architecture
- The known constraints
- The architectural assets to be leveraged, such as assets available elsewhere in the industry like frameworks, system models, etc.
As always, stay on top of what creates value for the Enterprise – meaning match the architecture to the problem at hand. The scope will limit the architecture to exactly what is needed to achieve the goals and no more.
A key deliverable to this step is the creation of a Stakeholder Map which should clearly state the stakeholder concerns, requirements, and viewpoints as well as their classification and level of involvement. Other inputs from gaining an understanding of stakeholders are cultural factors, which can help the EA team understand how to present and communicate the proposed architecture.
This step is very important to strategy architecture since having a clear understanding of stakeholder needs, interests, visions, etc. will dictate how strategy architecture is understood by its sponsors and guide the EA team to act accordingly.
From a strategy perspective, it is important to ask whether the context of a business aligns with the mission. Do the capabilities match to the project scope? Are we carrying baggage from a previous project or from a different part of the company that is outside the confines of the architecture? Knowing the context of the work can help fine-tune the vision of the strategy architecture.
Finally, validate that the models specified by the EA Capability to analyze processes, engage with stakeholders, and deliver the architecture are relevant and current.
7.3 Assess the Enterprise
This is the core of the effort required to deliver Architecture to Support Strategy. Working across the breadth of the Enterprise, identify, define, and articulate as clearly as possible the operational state. This analysis covers capabilities, business processes, information systems, technology, business terms, security, service providers, customer satisfaction, etc. For each of these, gather the desired operational state that would enable the Enterprise to achieve most or all of its objectives.
Completing the assessment may require use of techniques like Strategy Map or Five Forces. The outcome from such exercise will change the strategy statements and objectives. When the initial analysis does not provide the growth amplification expectations of the stakeholder, employ these techniques to guide the stakeholder to explore new ways to play in the market. The architecture being delivered is driving a change, but the analysis is just a path to identify a right change to introduce. Some or all work products created while developing the architecture may not go into the Architecture Repository or become a deliverable.
The assessment should be performed to address key concerns of the stakeholders. If the Enterprise is chasing agility, assess for current and desired[28] agility levels. If it is after operational stability, assess current and desired. If the need is the ability to replace suppliers with ease, assess it. It is perfectly acceptable to state that one or more capabilities or information systems or processes are not needed in the desired state. Likewise, it is acceptable to move a capability or service from being a differentiator from competition to “on par” with competition. These are indirect statements of direction the Enterprise is planning to take. Validate that the value proposition, objectives, and the assessment values for the desired state are consistent.
What the Enterprise is after is defined in the context and Request for Architecture Work. It is likely that stakeholders may state new concerns to be assessed. Refine and finalize the Request for Architecture Work after assessments. Remember that the goal is to capture just enough data to identify the gaps. How the outcome of each process, application, service, or capability measures against the concern is sufficient to complete the assessment. Going after who made the application or what version is deployed in the data center are noise and should be avoided.
The chasm between current state and desired state is the chasm the Enterprise has to cross to achieve its objectives. The chasm has to be acknowledged and agreed upon by all stakeholders.
In order to communicate what concerns were assessed across what capabilities, processes, information systems, etc., identify appropriate viewpoints. Validate that the team performing the assessment followed the documented EA processes and consulted requisite and relevant SMEs and stakeholders.
In order to provide confidence to the stakeholders of the completeness of analysis and resultant development of the target state and roadmap, have a detailed trail of the personnel consulted. Employ any of the standard techniques like interviews, surveys, inspections to gather the current and target state information. For each of these techniques, there are well researched metrics for the number of stakeholders and SMEs to be consulted. Completeness and confidence in the assessment is the Achilles heel of this architecture.
7.4 Define an Approach to Target State
With all the data gathered, look at the whole picture: where the Enterprise wants to go, the forces acting on the Enterprise from outside and within, resources it possesses, and finally the structural and behavioral changes needed. Each providing new specification. Each refining the view of the gaps. Some of the requirements may be not vetted against the desired state. As long as it is not in violation of the desired state and the objectives, it is a candidate that needs to be recorded.
An architect adds most value in correlating the facts, and identifying a potentially new operating model, organization model, and capabilities the Enterprise should invest and improve upon.
7.4.1 Confirm Enterprise Change Attributes
This step looks at how to implement an architecture taking the organization culture into consideration when assessing the business units and overall Enterprise in terms of their transition capabilities and skill sets. These assessments should be documented in an Implementation Factor catalog so that it can be used as an archive and record of decisions taken. Culture is very important to strategy architecture since strategies are long term, and often culture is set for the long term. Getting these two in sync is paramount to building a successful architecture. Other components of this step that are relevant to the strategy architecture include assessing the context that shaped the need for the strategy and performing a gap analysis of the Architecture Vision to the candidate architecture.
7.4.2 Develop Value Proposition
It is important that not only the value proposition for strategy architecture be understood by stakeholders but also the effort needed is accepted in its entirety. Consent and understanding should be manifested in a simple Solution Concept diagram that illustrates the major components of the solution and how the solution will positively impact the business. Since the value proposition is specific to stakeholder interests and concerns, it is important to pay close attention in this step as well-defined value propositions are key to strategy architecture success. For any architecture, sub-steps involve:
- Risk Assessment – leverage risk management processes to determine the level of risk appropriate to the vision
- Determine Value – link value to work packages as they pertain to stakeholders or stakeholder groupings
- Determine Key Performance Indicators (KPIs) – can be associated with concerns, risk assessment, and value
Determining the KPIs is necessary in the strategy architecture in connection to governance.
Determining the value proposition and how it is linked to various stakeholders and deliverables will help formulate very high-level definitions of the baseline and target environments from multiple points of view. Strategy is all about high-level concepts, but agreement on these concepts is key for a successful vision to be formulated and adhered to.
7.4.3 Identify and Sequence Work Packages
Logically group the various activities into work packages. This way the missing business capabilities can be assessed and, in the solutions column, proposed solutions for the gaps and activities that might orient towards a new development can be recommended. This step allows us to prepare for solution delivery, as the new developments might already hint at using external service providers.
Having done the sequencing and sifting down to relevant architecture requirements, the candidate roadmap and candidate Target Architecture are ready to construct the Architecture Vision. Create the initial version of the roadmap by consolidating the work packages from the previous steps while keeping in mind that this roadmap will link to subsequent phases. At the broadest level, the roadmap should define where the business wants to go, how it will get there, and by which means. Keeping an eye on the sufficient level of detail needed for this roadmap to be implemented should forbid the architecture to transition to different results.
7.5 Finalize Architecture Vision and Target Architecture
Tie-up any loose ends or mismatch in work packages and capabilities; resolve the impacts to the candidate architecture, and resolve impacts across the Target Architecture by performing stakeholder concern trade-off analysis. The roadmap should be significant in breadth for clear outcomes but shallow enough in depth to outline work packages without going into too much detail. The transition and migration plan must likewise demonstrate a minimum activity necessary to realize the roadmap. It is key to take the context of the Enterprise into account when formulating the implementation plan since there will be different approaches to consider depending on the business.
Sub-steps to follow for both of these points include:
- Context Assessment – assess the roadmap components and work packages in the context of the capability, value, and risk assessment
- Describe Candidate Transition Architecture – where there are significant points being changed in the Target Architecture along the roadmap, create a transition architecture that supports new models, identify building blocks to be used in the transition, identify views that address stakeholder concerns, and identify specifications
- Resolve Impacts Across the Architecture – determine the impact and interact with risk management to create a plan for the transition
- Perform Trade-off Analysis – interact with the requirements management process to update requirements and with risk management to update risk based on these trade-offs
- Have the Target State Approved by the Appropriate Stakeholder(s) – you do not have a roadmap until the organization has signed up to do the work. Without an agreement to do the required work you only have an intention to change
7.6 Conclusion
Communicate the Architecture Vision and populate the governance model and process with stakeholders, review cycle, and objectives. Ensure that stakeholders and decisions-makers understand, agree with, and provide the license to proceed with populating the EA Landscape. This license to proceed with the stated vision, Target Architecture, and the roadmap constrains and guides all future architecture work. Creation of a value chain, , value streams, organization maps, strategy map, or balanced scorecard can be completed meaningfully when the Architecture to Support Strategy is ready.
A list of duplicative efforts that require rationalization and a graph of sustain and improvement capabilities are populated into the roadmap. The stakeholders have successfully directed the creation of the architecture and have populated the governance details for further detailing and implementation of the architecture. This is the superior architecture[29] that will guide and direct the Architecture to Support Portfolio.
Success is measured by alignment on the target state and clear understanding by the decision-makers and stakeholders of the effort required to achieve the target state.
return to top of pageTOGAF® is a registered trademark of The Open Group