Introduction
The success of an architecture project and its outcomes hinges on the effective coordination between the Architecture Practitioner and the Implementation Practitioner. The Architecture Practitioner is responsible for delivering a well-defined architecture that allows for creativity and innovation while maintaining the integrity of the design. This guide will explore the key activities involved in supporting solution delivery, the importance of collaboration, and the steps necessary to ensure successful implementation within the Enterprise Architecture (EA) landscape.
The Role of the Architecture Practitioner
Defining the Context of the Architecture
The Architecture Practitioner must clearly define the context of the architecture within the EA landscape. This involves understanding the various push and pull forces that influence the architecture, including organizational goals, stakeholder needs, and external market conditions.
Example: In a retail organization implementing a new inventory management system, the Architecture Practitioner must consider factors such as supply chain dynamics, customer demand fluctuations, and integration with existing sales platforms.
Handing Over the Architecture
The Architecture Practitioner hands over a “box” to the Implementation Practitioner, which contains the architecture specifications, principles, and guidelines. This box should be constrained enough to provide clear direction but flexible enough to allow for innovation during implementation.
Example: The box for the inventory management system might include specifications for data integration, user interface design, and performance metrics, while allowing the Implementation Practitioner to choose specific technologies and tools.
Summary of Activities in the ADM Phases
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: Verify recency, reaffirm stakeholders, outcomes, timeline, communicate value proposition | Partial Capability Level Phase B, C, D |
| Program context: Elaborate architecture specification, reaffirm risk controls, communicate SBBs | Partial Project Level Phase G |
| Program context: Initiate project governance, guide delivery | Partial Project Level Phases B, C, and D |
| Project context: Continuously update EA Landscape, refine SBBs and solution boundaries, monitor controls | EA Capability specific context: Update EA Repository (contents and models), update standards and reference architectures, distribute resources |
| Project context: Analyze impact of trade-off with superior architecture, update risk matrix | Partial Capability Level Phase G |
| Project context: Conduct stakeholder review, obtain architecture approval, validate alignment of solution to vision | Realizing the Solution |
| Partial Project Level Phase H | Program context: Assess solution for gaps, assess risk closure, update Enterprise roadmap |
| Partial Project Level Phase F | Project context: Baseline transition state architecture, complete lessons learned, close architecture work |
| Partial Enterprise Level Phase H | Program context: Assess changes to Enterprise roadmap, as required, create backlog for architecture work |
| EA Capability specific context: Engage stakeholders, update EA roadmap |
Aligning Implementers
Project Context
- Verify Recency: Ensure that the architecture specifications are up-to-date and reflect the current state of the organization and its goals.
- Reaffirm Stakeholders: Engage with stakeholders to confirm their needs and expectations.
- Communicate Value Proposition: Clearly articulate the benefits of the architecture to stakeholders.
Example: In the inventory management system project, the Architecture Practitioner might hold a meeting with stakeholders to review the architecture specifications and confirm that they align with current business objectives.
Program Context
- Elaborate Architecture Specification: Provide detailed specifications that guide the implementation process.
- Reaffirm Risk Controls: Ensure that risk mitigation strategies are in place and understood by the Implementation Practitioner.
- Communicate SBBs (Solution Building Blocks): Clearly define the components that will be used in the implementation.
Example: The architecture specification for the inventory management system might include specific SBBs such as cloud storage solutions, data analytics tools, and user interface frameworks.
Guiding Delivery
Project Context
- Continuously Update EA Landscape: Regularly review and update the EA landscape to reflect changes in the organization and its environment.
- Refine SBBs and Solution Boundaries: Adjust the SBBs and boundaries of the solution as needed based on stakeholder feedback and project developments.
- Monitor Controls: Keep track of risk controls and ensure they are being followed during implementation.
Example: The Implementation Practitioner might discover that a new data analytics tool is available that better meets the project’s needs. The Architecture Practitioner would then need to update the architecture specifications to include this new SBB.
Analyzing Trade-Offs
Project Context
- Analyze Impact of Trade-Offs: Assess how changes to the architecture may impact the overall solution and its alignment with the enterprise architecture.
- Update Risk Matrix: Revise the risk matrix to reflect any new risks introduced by changes in the architecture.
Example: If the Implementation Practitioner proposes using a different cloud service provider for the inventory management system, the Architecture Practitioner must analyze how this change affects data security, integration capabilities, and compliance with existing standards. The risk matrix should be updated to reflect any new risks associated with this trade-off, such as potential vendor lock-in or data migration challenges.
Conducting Stakeholder Reviews
Project Context
- Conduct Stakeholder Review: Regularly engage stakeholders to review the architecture and ensure it meets their needs and expectations.
- Obtain Architecture Approval: Secure formal approval from stakeholders to proceed with the implementation based on the finalized architecture.
- Validate Alignment of Solution to Vision: Ensure that the proposed solution aligns with the overall vision and goals of the enterprise architecture.
Example: After refining the architecture for the inventory management system, the Architecture Practitioner might organize a stakeholder review meeting to present the updated specifications. During this meeting, they would seek feedback and approval, ensuring that the solution aligns with the organization’s strategic objectives.
Realizing the Solution
Assessing Gaps and Risks
Program Context
- Assess Solution for Gaps: Evaluate the proposed solution to identify any gaps between the architecture and the actual implementation.
- Assess Risk Closure: Determine whether identified risks have been adequately addressed and mitigated.
- Update Enterprise Roadmap: Revise the enterprise roadmap to reflect any changes resulting from the implementation.
Example: After the inventory management system has been implemented, the project team conducts a gap analysis to identify any discrepancies between the expected functionality and the actual performance of the system. They also review the risk management plan to ensure that all identified risks have been effectively mitigated.
Closing Architecture Work
Project Context
- Baseline Transition State Architecture: Document the architecture as it stands after implementation, capturing any changes made during the process.
- Complete Lessons Learned: Conduct a retrospective analysis to identify lessons learned throughout the project, documenting successes and areas for improvement.
- Close Architecture Work: Formally conclude the architecture project, ensuring that all deliverables have been met and that the implementation is on track.
Example: Once the inventory management system is fully operational, the Architecture Practitioner compiles a final report that includes the baseline architecture, lessons learned, and recommendations for future projects. This report is shared with stakeholders and archived for future reference.
Engaging Stakeholders and Updating the EA Roadmap
EA Capability Specific Context
- Engage Stakeholders: Maintain ongoing communication with stakeholders to ensure their needs are continuously met and to gather feedback for future improvements.
- Update EA Roadmap: Revise the EA roadmap to reflect the outcomes of the implementation project and any new initiatives that may arise.
Example: After the successful implementation of the inventory management system, the Architecture Practitioner schedules follow-up meetings with stakeholders to discuss their experiences and gather feedback. They also update the EA roadmap to include new initiatives aimed at further enhancing inventory management processes based on stakeholder input.
Conclusion
Walking through the architecture to support solution delivery requires careful coordination between the Architecture Practitioner and the Implementation Practitioner. By defining the context of the architecture, aligning stakeholders, and ensuring that the implementation adheres to the established architecture specifications, organizations can successfully navigate the complexities of change.
The activities outlined in this guide, including stakeholder engagement, risk assessment, and continuous updates to the EA landscape, are essential for ensuring that the architecture remains relevant and effective. By following these steps, practitioners can facilitate successful solution delivery and contribute to the overall success of the enterprise architecture.
Final Thoughts
As you embark on your next architecture project, remember the importance of collaboration, communication, and flexibility. By maintaining a clear focus on the architecture vision and engaging stakeholders throughout the process, you can ensure that your organization is well-equipped to implement change effectively and achieve its strategic objectives.