Introduction
The Open Group Architecture Framework (TOGAF) provides a structured approach to enterprise architecture, emphasizing the importance of aligning solution delivery with the overall architecture of the organization. This guide focuses on the critical aspects of guiding the delivery of solutions, including the integration of Solution Building Blocks (SBBs), the management of architectural styles, and the governance of solution delivery projects.
1. Integration of Solution Building Blocks (SBBs)
Definition of SBBs
Solution Building Blocks (SBBs) are components or services that are delivered by solution suppliers and must be integrated into the enterprise architecture. They can include microservices, software applications, or any other technology that contributes to the overall solution.
Key Concept
- Integration with Ecosystem: Any SBB delivered must seamlessly integrate with the existing ecosystem of the enterprise. This requires careful planning and assessment to ensure compatibility and functionality.
Example
In a retail organization implementing a new point-of-sale (POS) system, the SBB would include the POS software, hardware, and any associated services. The integration process would involve ensuring that the new system communicates effectively with inventory management and customer relationship management (CRM) systems.
2. Transition Architecture and Future Work
Importance of Transition Architecture
Transition architecture (n+1) refers to the architecture that will be in place after the current solution is delivered and evaluated. It is essential to assess how the current work may evolve into an SBB.
Key Concept
- Assessment and Refinement: Do not rush to create an SBB before the solution is delivered. Instead, assess and refine the architecture based on the actual performance and integration of the delivered solution.
Example
In a healthcare setting, if a new electronic health record (EHR) system is implemented, the transition architecture would evaluate how this system interacts with existing patient management systems and whether it can be classified as an SBB based on its performance and integration capabilities.
3. Utilizing Architecture Styles and Patterns
Microservices and SOA
Microservices and Service-Oriented Architecture (SOA) are architectural styles that can be considered when defining SBBs. Each microservice can be treated as an individual SBB or aggregated into a larger SOA service.
Key Concept
- Flexibility and Modularity: By adopting microservices, organizations can achieve greater flexibility and modularity in their architecture, allowing for easier updates and integration.
Example
A financial services company may implement a series of microservices for different functions, such as payment processing, fraud detection, and customer onboarding. Each microservice acts as an SBB that can be independently developed, deployed, and scaled.
4. Ownership and Governance of Integration
Critical Success Factor
Retaining ownership of integrating solution blocks within the enterprise is crucial. Delegating this responsibility can lead to governance issues and project management challenges.
Key Concept
- Governance and Accountability: The architecture team must ensure that they maintain control over the integration process to avoid misalignment and ensure compliance with architectural standards.
Example
In a telecommunications company, if a third-party vendor is responsible for integrating a new billing system, the in-house architecture team must oversee the integration to ensure it aligns with existing systems and meets regulatory requirements.
5. Defining Core Information and Data Management
Core Information
The superior architecture should define what constitutes “core” information for the enterprise. This decision impacts data retention, management, and the overall operating model.
Key Concept
- Data Governance: Not all datasets need to be retained or controlled by the enterprise. Identifying core data helps streamline operations and reduce unnecessary complexity.
Example
In a logistics company, core information may include shipment tracking data and customer information, while less critical data, such as historical shipping logs, may not need to be retained.
6. Continuous Population of the EA Landscape
EA Landscape
The Enterprise Architecture (EA) landscape should be continuously populated with decisions made regarding solution delivery. This includes documenting interactions across solution blocks and the level of granularity required.
Key Concept
- Dynamic Documentation: As decisions are made, the architecture should evolve to reflect these changes, ensuring that all stakeholders have access to up-to-date information.
Example
In a manufacturing organization, as new automation solutions are implemented, the EA landscape should be updated to reflect how these solutions interact with existing production systems and the overall architecture.
7. Resource Allocation and Financial Attributes
Importance of Resource Data
While the architecture team may not be responsible for mastering resource allocation data, capturing attributes such as cost to procure, deliver, and operate is essential for enterprise planning.
Key Concept
- Financial Insights: Using an EA tool to capture financial data related to solution delivery projects aids in trade-off analysis and budget management.
Example
In a software development project, tracking the costs associated with different development teams and technologies can help the organization make informed decisions about future investments
8. Trade-offs and Constraints in Solution Delivery
Understanding Trade-offs
Trade-offs are inherent in any architectural decision-making process. They involve balancing various factors such as cost, performance, scalability, and compliance. Recognizing these trade-offs is essential for effective governance and decision-making.
Key Concept
- Impact Assessment: Each choice made during the solution delivery process can have significant implications for the overall architecture. Practitioners should assess how these choices affect large functional areas, such as enterprise resource management and planning.
Example
In a retail organization, choosing a cloud-based inventory management system may offer scalability and reduced upfront costs but could introduce concerns about data security and compliance with regulations. The architecture team must weigh these factors and decide whether the benefits outweigh the risks.
9. Continuous Interaction Between Practitioners
Importance of Collaboration
Continuous interaction between the Architecture Practitioner and Implementation Practitioner is vital for proactively addressing barriers and ensuring alignment throughout the solution delivery process.
Key Concept
- Agile Governance: Establishing a collaborative environment allows for quick adjustments to the architecture as new information and challenges arise during implementation.
Example
In a financial institution, if a new regulatory requirement emerges during the implementation of a risk management system, the Architecture Practitioner and Implementation Practitioner must work together to adapt the architecture and ensure compliance without delaying the project timeline.
10. Governing the Solution Delivery
Objective of Governance
The primary objective of governance in solution delivery is to ensure that the architecture is developed to the extent necessary to guide and control the solution being delivered. This includes defining viewpoints that facilitate communication and governance.
Key Concept
- Monitoring Implementation Risks: It is essential to monitor risks associated with the implementation and ensure that appropriate controls are in place to mitigate these risks.
Example
In a healthcare project, as a new patient management system is implemented, the governance team should monitor risks related to data privacy and system interoperability, ensuring that controls are established to protect sensitive patient information.
11. Phases of Solution Delivery
Phases B, C, D, and E
The work performed to deliver the solution primarily spans Phases B (Business Architecture), C (Information Systems Architectures), D (Technology Architecture), and E (Opportunities and Solutions) of the TOGAF Architecture Development Method (ADM).
Key Concept
- Innovation and Alternatives: While innovations and alternatives are considered during these phases, they do not go through rigorous architecture control. Instead, they operate within the constraints defined by the architecture specification.
Example
In a telecommunications project, the architecture team may explore various technologies for network optimization. While they may consider innovative solutions, the final selection must align with the existing architecture and comply with established standards.
12. Conclusion
Guiding the delivery of solutions within the TOGAF framework requires a comprehensive understanding of integration, governance, and the continuous evolution of the architecture landscape. By focusing on the integration of SBBs, defining core information, and maintaining continuous interaction between practitioners, organizations can ensure that their solution delivery aligns with the overall enterprise architecture.
This guide serves as a resource for Architecture Practitioners and Implementation Practitioners, providing key concepts and examples to navigate the complexities of solution delivery effectively. By adhering to these principles, organizations can enhance their architectural governance, optimize resource allocation, and ultimately achieve their strategic objectives.