9 Walk Through Architecture to Support Project
In this context, the architecture is used to clarify the purpose and value of the project, identify requirements to address synergy and future dependency, assure compliance with architectural governance, and to support integration and alignment between projects.
This chapter describes development of architecture for one project within a portfolio. The effort starts with identifying the context, the superior architecture that defines the visions, the scope, and the value the project should deliver. Without initial exploration about where the project sits inside of the EA Landscape, Architecture to Support Project is in a volatile state. It is the responsibility of the Practitioners working in the Architecture Project to gather hints of uncovered barriers to the project. The project lies inside the roadmap at some linear point in a sequence of work packages. There are many hints from the roadmap alone of where to see danger ahead and who to ask about any unknown warning signs.
The purpose is to highlight the level of detail, time, and breadth during the ADM cycle phases for developing an EA as a focus of support to project architecture and governance. Most of the effort happens in the context of Phase F.
Table 8 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 8: Summary Table: ADM Phases and Architecture to Support Project
|
Topic |
Mapping to TOGAF ADM Phase |
|
Ascertain Dependencies |
Partial Capability Level Phase A Program context:
Partial Capability Level Phases B, C, and D Enterprise context:
Program context:
|
|
Balance Options and Suppliers |
Partial Capability Level Phases B, C, and D For each capability:
Partial Capability Level Phase E For each project in the portfolio:
|
|
Finalize Scope and Budget |
Partial Capability Level Phase F For each project in the portfolio:
Partial Capability Level Phase G For each project in the portfolio:
Level Phase A For each project in the portfolio:
|
|
Prepare for Solution Delivery Governance |
Partial Program Level Phase F Program context:
|
For Architecture to Support Project, the critical focus points are:
- Scoping:
— What is the origin for the receipt of a Request for Architecture Work?
— Where will I have overlap? Who are my neighbors (EA Landscape)?
— Where do I look (EA Landscape: depth, breadth, detail)?
— Are my stakeholders/portfolio guidance still relevant (recency)?
- Domain-specific stakeholders’ concerns and architecture elaboration:
— Viewpoints/Stakeholder Map
— What do I need to know/solve for?
— Resolve impacts across architectures
- Finalizing the target transition architecture and its value:
— Creation of requirements and specifications
— Securing a Request for Architecture Work for the solution delivery architecture
9.1 Ascertain Dependencies
Throughout the entirety of the ADM, it is recommended to have a close look at the superior architecture in the EA Landscape. It is possible that Practitioners of superior architecture have already specified a list of things which the Practitioners of the preceding architectures are able to pull down to include as new inserts of an architecture description.
There is not much need to explore a reason to do architecture when the purpose of the project has already been specified within a roadmap. The Practitioner may find that they already have a sufficient Architecture Vision from the work that has been done in the portfolio architecture. However, the Practitioner must take responsible action to confirm the Architecture Vision along with a number of portfolio-level Target Architecture components to assess the impact of recency (see Section 3.2.1).
Assessing recency is the pulse of the Architecture Project. It will involve looking “bottom-up” at the current work in the EA Landscape to assess the impacts of recency to prior EA. Look at the set of Architecture Visions from the Architecture to Support Portfolio. The following set of questions will guide assessing the impacts of recency to prior EA work for the purpose of use:
- What EA is parallel in development?
- Which targets are in the process of being realized?
- Which targets have been approved?
- What is effect of recency on prior EA?
After prior EA work has been reviewed, reaffirmed, or replaced, the effect of recency is reset and mitigates the risk to the Architecture Project significantly.
9.1.1 Project is not a Magical Place to Swap Out Stakeholders
Who are the complete set of stakeholders across the architecture? The stakeholders in the portfolio level will need to be reaffirmed.
It is common to find organizational leaders who, at the start of an Architecture Project, feel a strong need to replace the stakeholders identified in their superior architecture with stakeholders which have a high enough power to block or advance a project but not the architecture; see the TOGAF Standard – ADM Techniques (Classify Stakeholder Positions).
This will introduce new project-specific concerns into the architecture. It cannot be stressed enough, to hold on to the distinction between the stakeholders that have high power in the Architecture Project and those that have high power only in relation to the Implementation Project. At the end of the day, the Practitioner addresses the concerns of the empowered stakeholders holding the key to the success of the Architecture Project because they have the power to shape any Implementation Project in order to conform with the approved target. It may be useful to identify the project-specific stakeholders’ concerns if we can solve for both and get something for free. Solving for an Implementation Project-specific concern is what can be called a “nice-to-have”.
9.1.2 Stakeholders versus Key Players
Look at the previous Stakeholder Map from the portfolio. Assess recency. Map the complete set of stakeholders of the Architecture Project against their known concerns.
Do not include an Implementation Project-specific set of stakeholders (otherwise known as key players to the Architecture Project) in the Stakeholder Map. If desired, map the key players to any additional Implementation Project-specific concerns separately. Having more than one set of key stakeholders completely blocks the ability to perform trade-off.
9.1.3 Viewpoints and Requirements
The most important piece before doing any work; knowing what you need to know. Once you have a complete set of views which describe the stakeholders’ concerns, you know exactly what you need to do, or at the very least, where to go look to find out what needs to be done.
When selecting viewpoints from the viewpoint library or developing new viewpoints, ask if the viewpoint represents the complete set of stakeholder concerns to the Architecture Project. Are all the stakeholders’ classes representative of those which own the approval rights around the Target Architecture and decision rights around the Implementation Project?
Are the concerns consolidated and constrained into topic areas derived from the Enterprise’s strategy, which will be consistent across Architecture Projects?
Does the viewpoint give a point of reference for what you need to know and where to look in the EA Landscape?
Once the Practitioner knows what information is needed and where to find it, it is safe to continue doing work without the fear of stepping on a figurative land mine.
Review the Architecture Repository for resources, especially architecture specifications, requirements, and work packages from the superior architectures to address the stakeholders’ concerns for the Architecture Project.
9.1.4 Go Talk to the “Neighbors”
In developing a candidate architecture, the key to success is to be aware of the neighbors of the Architecture Project in the EA Landscape and to assess the “neighborhood” for recency. How much room is there for the Architecture Project until there would be an overlap or collide with another one?[31] When must you go and have a conversation with the neighborhood and assess their work for recency?
To add complexity, what is the current status of the neighboring architectures? Are the neighboring Architecture Projects approved, in transition, or becoming realized? You may not have to worry about rubbing shoulders with a neighboring Architecture Project until one of them enters a transition state.
Have the necessary conversations with the neighbors periodically to make the process of resolving impacts across Architecture Projects easier. The later these conversations with the “neighbors” takes place, the more likely the Practitioner will incur harder decisions, which would have been easily avoided; such as de-scoping decisions. The Practitioner must check the candidate architecture’s flexibility to withstand the volatile environment shared with other Architecture Projects undergoing a number of transitional states.
9.1.5 Delivery and Acceptance Ability Assessment
This is an opportune time to assess the readiness of the organization to actually start to execute and realize the change. It involves identifying whether the work packages cover the necessary changes to business processes, operating procedure, training, and everything that has to happen once the solution is delivered. The assessment is narrowly focused to test the scaffolding the neighbors should have in place. A second set of assessment is the ability of the solution delivery team, internal or external, to deliver to the needs of the architecture specification. The project manager and the product owner are fully aware of the trade-off criteria to retain value; aware of dependencies from the neighbors to this effort and from this project to others; and the risks and controls to mitigate them.
9.2 Balance Options and Suppliers
Architecture to Support Project is to answer a set of problems in a box; the answers are expected to stay within the box. The Practitioner must elaborate all domain architectures just enough to assure that the architecture is addressing all of the work. The project cannot move forward until it is proven that the project will be a success. Gather the estimates of all resources required to deliver the project. All of the bridge will be built, not just some of the bridge. Remember, the focus is to clarify and confirm the purpose and value of the project. Part of the bridge does not serve any purpose or add any value.
The up-side is the Practitioners involved in the Implementation Project have blinders on that only allows them to see the distance from where they are standing to the horizon. The horizon is the work needed before implementation begins. In the context of the Implementation Project, the Practitioner’s line of sight is always the horizon, including the distance to get there. It is already understood what “success” will look like, standing on the horizon. What is the work that will take us there?
9.2.1 Performing Trade-Off
As the saying goes “you can’t step in the same river twice”; the water’s always changing, always flowing. Without discovery of where the candidate Target Architecture stands before finalization within the EA Landscape, it is harder to guide projects from running off waterfalls and large cliffs.
Only until the Practitioner looks “downstream” are they in a position to perform a trade-off, resolve impacts across the Target Architecture, and choose the smoothest course. Doing a consistent reconnaissance of the EA Landscape will enlighten the Practitioner to where the project can avoid disaster further down the river.
In order to perform, the Practitioner is chasing the barriers to deliver and realize value. This is too early to define the architecture for solution delivery. This is definitely not the place to define and design the solution. Implementation is not architecture. The architecture is assuring resilience to risks and guidance to implementers. Any recommendations of ABBs and SBBs to accelerate value realization and improve conformance are identified and included in an architecture specifications.
If it is discovered that the Implementation Project’s candidate Target Architecture is impacting or will be impacted by a finalized Target Architecture of another project in-flight, always assess recency, confirm, and do a trade-off analysis. Keep in mind that when doing a trade-off analysis and resolving impacts across the Target Architecture that the Implementation Project is already heavily constrained and may need to mold a path down the river around the other projects that have been approved and have taken root along the river bank. Then, given any new discoveries to the Implementation Project, if any, create the architecture specifications for the Implementation Project to assure avoidance of overlap and conflict.
9.2.2 Managing the Current Approach towards Implementing the Change
Once impacts have been resolved, create the views necessary to convey to the stakeholders that their concerns have been addressed with the necessary constraints and guidance developed prior to initiation of solution delivery for it to be successful.
The Practitioner’s analysis of the Target Architecture cannot have assessed every circumstance, or change option possible. There will always be an infinite number of things to discover about the Architecture Project. The Practitioner’s job is to show that a sufficient level of scrutiny led to the deliverables of the Architecture Project for the solution delivery architecture to succeed. The Practitioner should only assess to the extent of avoiding major cliffs. Once you start assessing the Architecture Project for all the subtle bumps, you have exceeded the sufficient level of scrutiny and are wasting valuable resources.
Prove to the stakeholders that when the Architecture Project is consumed by the solution delivery architecture, their requirements have been met and changes to the Enterprise will be guided and constrained efficiently. Identify and secure approval for the resources necessary to begin allocating the budget for the solution delivery architecture to begin.
The Practitioner will know that the Architecture Project is a success upon receipt of the Request Architecture Work for solution delivery.
9.3 Finalize Scope and Budget
Implementation planning (Phase F) is the most critical piece in executing a walk through the ADM for the Implementation Project. Practitioners must rationalize for their Architecture Project what resources are required.
Package the project’s architecture specifications, which includes the subsequent controls that mitigate the identified Implementation Project’s risks. The package is then handed off to the Implementation Practitioner. It is the responsibility of the Architecture Project Practitioner to set up the Implementation Practitioner with everything they need to implement the project successfully.
If one or more work packages have not already been assigned to the Implementation Project, do so and seek approval. Be familiar with which gaps the work package(s) are filling and the purpose of their sequence in the roadmap. It may also be necessary to be familiar with the work packages the project will not be filling. Identify the risks within the work packages and subsequently within the Implementation Project.
Architect the “package” for the purpose of the Implementation Project. Create architecture specifications to the extent that an Architecture Project will not go off the rails on a crazy train. On the other hand, the railroads must not be easily scoured or constrained to the point of inflexibility of the volatile environment of the EA Landscape. Keep the Implementation Project on the tracks while maintaining the railways of the Architecture Project.
The Practitioner should package the architecture specifications including the principles, requirements, and controls within the context of the light shining down from the Architecture Vision of the portfolio, in the review of the Stakeholder Map, and the undertakings of the EA Landscape.
Refine the estimates and timeline for the project within the acceptable variance limits of the Enterprise. Cascade the update to project scope, trade-offs, and timelines to the Enterprise roadmap. Consult the requisite SMEs and stakeholders, and complete the architecture review. Populate the governance and approval plan for the solution delivery effort.
9.4 Prepare for Solution Delivery Governance
The maximum value is to be delivered by the Architecture Practitioner to the Enterprise in this step. Having finalized the scope and budget, make sure that the backlog information is complete for the project; trade-off, and decision criteria for the product owner, product manager, scrum master, or the project manager (whatever the role and title is) and the Implementation Practitioner is fully defined and understood; decision-makers and organizational leaders are fully aware of the barriers they must work to remove.
Any outstanding proof-of-concept work at this time should be limited to understanding an approach to the solution, not the architecture. Provide sufficient measurement criteria, indicators to warn of any variances, escalation, and deployment of SMEs, and implementation governance.
Initiate steps to close the Architecture Project. The Architecture Project’s scope is limited to change management and governance. From that aspect, the project is not completed. This is also the time the architecture team and most of the Practitioners withdraw themselves from the limelight and pass the baton to Implementation Practitioners. Provide any required support for the Implementation Practitioners to defend the project during budget allocation. The work is not complete until the budget is allocated and the Implementation Project charter is signed.
9.5 Project Request for Architecture Work Originating from the Wild
The most common Requests for Architecture Work from the wild are for Architecture to Support Project. The central question for the Practitioner is to identify the proposed project’s alignment to expected value and the opportunity cost for the organization. See Section 8.6 for a discussion.
return to top of pageTOGAF® is a registered trademark of The Open Group