10 Walk Through Architecture to Support Solution Delivery
10.1 Introduction
The success of this architecture and its outcome are driven by the degree of coordination between Architecture Practitioner and the Implementation Practitioner. The Architecture Practitioner hands over a well constrained, yet with sufficient room for creativity and innovation, box to the Implementation Practitioner. It is the duty of the Implementation Practitioner to not break the box or to morph its shape or appearance. It is the duty and responsibility of the Architecture Practitioner to define the context of this box within the EA Landscape, defining all of the push and pull forces. The candidate Architecture Project is now the Target Architecture.
Note that there will be minimal discussion on Phase G in Table 9. All of these activities occur in the context of Phase G. The table informs how activities in other phases enable delivery of the solution and drive closure to an Architecture Project. Actual closure is triggered from Phase H, either identifying a new effort or signaling achievement of target state.
Table 9 summarizes the activities and use of appropriate steps from the ADM phases. The content of the table is discussed in detail in the rest of this chapter.
Table 9: Summary Table: ADM Phases and Architecture to Support Solution Delivery
|
Topic |
Mapping to TOGAF ADM Phase |
|
Align Implementers |
Partial Capability Level Phase A Project context:
Partial Capability Level Phase B, C, D Program context:
Partial Project Level Phase G Program context:
|
|
Guide Delivery |
Partial Project Level Phases B, C, and D Project context:
EA Capability specific context:
Partial Capability Level Phase E Project context:
Partial Capability Level Phase G Project context:
|
|
Realizing the Solution |
Partial Project Level Phase H Program context:
Partial Project Level Phase F Project context:
Partial Enterprise Level Phase H Program context:
EA Capability specific context:
|
Simple guidance for the Implementation Practitioner is to keep an eye on the target of the superior architecture. Be absolutely clear what the architecture is trying to optimize and what it is being asked to deliver. It may be tempting to remove all sub-optimization choices in the current delivery cycle. Refrain. Validate that sub-optimization is intentional and future work will address such concerns. All it takes is one bad driver to upset miles of traffic. Understand that the Solution Architecture is one of the many concurrently moving parts in the Enterprise.
Top concerns to be addressed in developing and delivering this architecture are covered in the following sections.
10.1.1 Scoping
- What are the conditions under which a change can be triggered to architecture work?
- Having identified the neighbors and their interactions, what is the frequency of interaction and integration?
- What can and cannot give?
- Are the stakeholders and portfolio guidance still relevant (recency)?
10.1.2 Function Purity and Solution Innovation
- Are there multiple solution providers in this project? And who is providing what solution?
- What kind of detail is needed in the viewpoints to align solution providers and the superior architecture?
- How to drive integration across SBBs?
- How to select the best solution that aligns with the overall operating model (custom in-house, custom managed service, standardized managed service, standardized in-house)?
- What does governance mean in this context?
10.1.3 Handover and Closure
- When does the engagement end?
- What is the appropriate value report?
- What are the lessons learned and impact to gaps in EA?
10.2 Aligning Implementers
It is imperative that the Architecture Practitioner and Implementation Practitioner verify that the bottom-up view of the architecture aligns well on the “recency” measure. The next step is to validate the recency measure of the lateral set of architectures. The Architecture Project defines the boundary conditions to limit the impact to the overall architecture, accounting for all trade-off choices that would be made by the implementation architect. This doesn’t mean that there cannot be changes to how each solution interacts with another. The impact does not require reprinting all of the training manuals and redoing the training schedule for the users of the solution.
In most cases, there would be more than one player; a solution provider and a solution consumer. The dynamic nature of business could ask for changes to the solution proposed mid-stream. The Architecture Project and hence the Solution Architecture clearly define the conditions that could trigger a change, stakeholder review, and architecture approval. A sizeable fraction of the projects will involve more than one solution implementer. Develop the architecture to identify, clarify, constrain, and liberate each of the solution implementers from the other. The Solution Architecture articulates conditions for integration and acceptance of the total solution.
In-house or third-party solution implementers deliver against this architecture. When supplied by a third party, the onus is still on the in-house team to validate, integrate, and accept the solutions. At the end of the day, the consumers and end-users do not care who supplied the solution. Their question is: “Does this meet my expectations, does what it says, available as stated and defined?” Make sure that architecture, the governance plan and implementer are totally aligned on value proposition, conditions for trade-off, and the stakeholder matrix.
If the solution delivery project is validating a concept, the primary outcome is unearthing all points of failure; the secondary outcome is feasibility of the idea; and the tertiary outcome is scalability of the idea to meet usage demands. If the solution delivery project is building a bridge, its primary objective is enabling transportation under most environmental conditions; its secondary objective is to set terms of use. The variances across the solution delivery project are so vast that this Guide cannot provide a sufficient set of examples to emphasize alignment with neighbors and completing the bottom-up view.
There is the least amount of work done in Phase A. It is all about affirming scope, stakeholders, currency, and value proposition.
10.3 Guiding Delivery
Any SBB delivered by solution suppliers will have to be integrated with the rest of the ecosystem of the Enterprise. Until the solution is delivered and evaluated against future work (transition architecture n+1), it will not be clear that some of the current work could become an SBB. Do not work to create a building block. Assess and refine once the solution is delivered and put to work.
In terms of architecture styles and patterns available at the time of writing, you may consider each Microservice or an aggregation of Microservices (SOA service) as an SBB.
When the superior architecture indicates availability of ABBs and SBBs, reach into the Enterprise Repository to reuse and conform to the architecture. When the ABBs point to implementations outside the Enterprise, guide industry collaboration and context-specific trade-off to guide development and delivery of Enterprise-specific SBBs.
Critical to success of architectures is retaining the ownership of integrating solution blocks within the Enterprise. Delegating the responsibility to any other party will lead to project management and governance issues, resulting in failed architecture.
Architecture to Support Solution Delivery is where all realizations and regulatory compliance needs are met. Naturally, the next critical long-term success factor for the Enterprise is identification of core information and data that should be retained in-house. The superior architecture should define the “core” for the Enterprise. All other datasets need not be retained, mastered, or controlled by the Enterprise. This choice drives other decision points in the operating model. Should the solution be treated as a black box for the Enterprise (a managed service) or specialized in-house or an expert team employed? Superior architectures need not resolve this choice. The choice and selection of solution provider is made at the time of developing and delivering the solution. Some of the solution provider choices may be constrained by the Enterprise’s preference to restrict the number of suppliers. The Practitioner should not feel compelled to use a solution provider just because a constraint exists. Priority is fitness to deliver and accelerate time-to-market.
Choice of integration, definition of “core” information, and managed service versus in-house decisions guide the level of granularity needed to describe the architecture.
Populate the EA Landscape continuously; as each decision is made, the level of granularity of the architecture is arrived at, and interactions across solution blocks are defined. Quantifying and documenting the resource required by each solution block may not be the direct concern of the Implementation Practitioner or the Architecture Practitioner. Attributes like cost to procure, cost to deliver, and cost to operate are required by the Enterprise planning organization. It is a sensible option to capture these attributes within the EA tool. Financial investment data for each solution delivery project aids and reduces time to complete the trade-off analysis, roll-up and roll-down of budget, among other benefits.
It is not the recommendation of this Guide that resource allocation data for solution delivery projects be mastered in the EA tool or the EA team to take responsibility. This Guide is calling out a dataset that enables the Practitioner to be productive and purposeful. The source of truth for resource allocation should be determined by the Practitioner, following the guidance set by the Enterprise. A good content model and EA tool are normally capable of capturing this data point at the lowest level of granularity, and enable roll-up and trade-off analysis. It is the position of this Guide to use an EA tool to do the computations that inform and impact trade-off analysis, instead of using other methods to speed up the time to inform trade-off.
Another set of trade-offs and constraints that impact this architecture is the existence of solution families in the Enterprise. The choice of a supplier or technology for data hosting services or ERP package constrains other building blocks that can be employed in the project and sometimes across the Enterprise. Take an assessment of such solution families from the superior architecture. When not available, the Implementation Practitioner and the Architecture Practitioner should spend time identifying, analyzing, and escalating impact of choices on large functional areas like Enterprise resource management and planning.
Even though the Architecture Project defines the boundary and the interface, change is bound to happen. Continuous interaction with the Architecture Practitioner and Implementation Practitioner is required to proactively mitigate barriers.
The objective is to develop the architecture to the extent needed to govern the solution being delivered. Do not feel compelled to define the solution as well. Define and employ viewpoints necessary to communicate, guide, and govern the Solution Architecture. Monitor implementation risks and the controls being implemented for Enterprise risks. Every trade-off and implementation choice made impacts and potentially modifies the Target Architecture. Governing the selections impacts the gap in the Target Architecture, the roadmap, and therefore the Architecture to Support Portfolio of the following fiscal year.
Work performed to deliver the solution mainly spans Phases B, C, D, and E. Innovations, research, and alternatives considered and employed follow the steps in Phase E. It is just that they do not go through rigorous architecture control. The alternatives are constrained by the architecture specification. Hence, it is a question of the ability to operate within constraints and not about controlling the selection. Specification created by following the steps in Phases B, C, and D assures appropriate selection.
10.4 Realizing the Solution
Contractually, this is the post-rollout, warranty period. Depending on the solution delivery method used in the Enterprise, this may be a parallel path to Guiding Delivery. It is the period of putting the solution in the hands of the beneficiaries (customers, end-users, support personnel, partners, etc.). The engagement of the Architecture Practitioner comes to a conclusion or shifts gear only when the solution is put to use. Depending on the appetite of the Enterprise, successful usage may be defined as the first 30, 60, or 90 days.
At the end of this period, the Architecture Practitioner initiates a gap analysis between the realized architecture and the Baseline Architecture to be used for solution delivery. It is only at the end of this analysis that a determination can be made about releasing key resources – the project manager, the implementation architect, supplier representative, technology resources reserved for developing the solution, etc. Closure of the Architecture Project is achieved as soon as the Implementation Practitioner accepts the superior architecture. However, the oversight provided by the Architecture Practitioner is retained until the solution delivery completion criteria are met.
Use the basis provided by the Architecture Project to report the value realized from time to time. Document the lessons learned, mainly the gaps in the description of the superior architecture that were filled while delivering the Solution Architecture. Document controls and constraints that accelerated overall delivery of the solution.
Update the cascading impact of the project to the EA Landscape and roadmap. As needed, validate, close and update the Enterprise backlog.
10.5 Project Request for Architecture Work Originating from the Wild
Requests for Architecture Work from the wild for Architecture to Support Solution Delivery are typically not done. Instead, there is a fully-baked Implementation Project with a proposed solution. In this case the Practitioner has to assess the fully-baked solution against the superior architecture. This becomes more of fitment analysis with its own political implication. See Section 8.6 and Table 10: Example of Summary Governance Reporting for a broader discussion and assessment reporting example.
10.6 Conclusion
Many Architecture Practitioners fail in their role when supporting solution delivery. It is quite normal to confuse their role with SME, auditor, stakeholder, and proxy for the Enterprise stakeholder and decision-maker. Review Chapter 11 and Section 15.2.
The realized solution is the new baseline. It is the basis for evolving and analyzing the roadmap to the Target Architecture. All the development that happened in the Enterprise, and the industry, that were kept away from impacting solution delivery is added to the assessment set. This assessment is the next critical activity the Architecture Practitioner performs. It is this work that justifies closure of the current Architecture Project, Implementation Project, and resources. It also justifies the Request for Architecture Work for the next set of initiatives to achieve the target transition state (n+1). Involve all stakeholders, decision-makers, and implementers to complete the assessment, and gain the sign-off to close the effort.
return to top of pageTOGAF® is a registered trademark of The Open Group