B: Business Architecture
1: Approach (Key Considerations)
1.1: General
Business Architecture serves as a comprehensive representation of an organization’s capabilities, end-to-end value delivery processes, information flow, and organizational structures. It illustrates the relationships among various business elements, such as strategies, products, policies, initiatives, and stakeholders. Understanding the Business Architecture is fundamental for any architecture work across other domains—Data, Application, and Technology—making it the first critical step in the architecture development process.
Scope and Objectives of Phase B
Alignment with Architecture Vision:
The scope of work in Phase B is guided primarily by the Architecture Vision established in Phase A. This vision outlines the strategic direction and high-level objectives that the Business Architecture must support.
The business strategy defines goals, drivers, and success metrics, while the Business Architecture outlines the paths to achieve these objectives.
Assessment of Existing Work:
In some organizations, elements of Business Architecture may already be documented through enterprise planning or business strategy activities. In such cases, it is crucial to verify and update these documents to ensure they align with the current business context.
Conversely, in less mature environments, the architecture team may need to conduct foundational work to identify key business objectives and processes. This may involve research, stakeholder engagement, and validation of the business context.
Utilization of Business Scenarios:
Employing techniques like business scenarios can illuminate key business requirements and indicate the associated technical requirements for the IT architecture. This helps in bridging the gap between high-level strategic goals and specific business needs.
Reusability of Existing Materials:
Wherever possible, the architecture team should aim to reuse existing documentation and architecture definitions. If previous Architecture Descriptions are available, they should be verified and updated to reflect the current state and requirements.
Information Gathering:
The architecture team should focus on collecting only the information necessary for informed decision-making relevant to the architecture development effort. Depending on the focus of the work (new business processes vs. supporting existing architectures), the level of detail required may vary significantly.
Key Activities in Phase B
Defining Business Capabilities: Identify and document the core capabilities necessary to achieve strategic objectives.
Mapping Business Processes: Create models that represent key business processes and how they deliver value to stakeholders.
Analyzing Organizational Structures: Document and analyze the organizational structures that support business operations and decision-making.
Identifying Stakeholders: Identify all stakeholders involved and assess their concerns, needs, and the impact of proposed changes.
Establishing Relationships: Illustrate the interrelationships among business elements to facilitate understanding and communication among stakeholders.
Deliverables of Phase B
Business Architecture Description: A comprehensive document outlining the business capabilities, processes, information flows, and organizational structure.
Updated Business Strategy: Verification and potential revision of the existing business strategy to ensure alignment with architectural efforts.
Stakeholder Analysis: Documentation of stakeholder needs and how they relate to the business architecture.
Business Process Models: Diagrams or models that represent key business processes and value delivery mechanisms.
Capability Models: Detailed descriptions of business capabilities and their interconnections.
Phase B of the TOGAF ADM is critical for establishing a solid foundation for subsequent architecture work across other domains. By effectively defining the Business Architecture, organizations can ensure that their IT investments align with business strategies, thereby maximizing return on investment and supporting ongoing business transformation. This phase emphasizes the importance of collaboration, thorough analysis, and the reuse of existing materials to create a coherent and actionable Business Architecture.
1.2: Developing the Baseline Description
Purpose of the Baseline Description
The Baseline Description serves as the foundation for understanding the current state of the organization's business architecture. This description captures existing architecture elements, such as capabilities, value streams, processes, and organizational units. It is essential for identifying gaps and opportunities for improvement as the enterprise transitions to its Target Architecture.
Steps for Developing the Baseline Description
1. Leverage Existing Architecture Descriptions
Utilization of Existing Materials: If the enterprise has existing architecture descriptions, these should be the primary reference for the Baseline Description. Existing documents may include:
Business Capability Maps: Representations of the organization’s capabilities aligned with its strategic objectives.
Value Streams: Diagrams illustrating how value is delivered through the organization’s processes and activities.
Review and Update: The architecture team should review these existing documents to ensure they accurately reflect the current business environment. Updates may be necessary if there are:
Missing Business Capabilities: New capabilities required to meet current business needs.
New Value Streams: Emergent processes that add value to the organization but were not previously documented.
Organizational Changes: Restructured units or teams that affect how business architecture is perceived or utilized.
2. Conduct a Gap Analysis
Identify Changes: Determine whether the changes in the baseline are due to shifts in the fundamental view of the business or adjustments in how these views are used for project scope and priorities.
Assess Impact: Evaluate how these changes impact relationships between various business elements, including capabilities, processes, and organizational structures.
3. Gather New Information (if Necessary)
Data Collection: If no existing architecture descriptions are available, the architecture team must gather information through:
Stakeholder Interviews: Engaging key stakeholders to understand their perspectives on current capabilities and processes.
Workshops: Conducting collaborative sessions to define and visualize business architecture elements collectively.
Documentation Review: Analyzing any available business strategy documents, operational manuals, or process documentation.
4. Develop Business Architecture Models
Modeling Techniques: Utilize established business architecture methods to create models that illustrate the current state. Common techniques include:
Business Capability Models: Mapping out the capabilities needed to achieve business objectives.
Value Stream Mapping: Detailing the flow of value through various processes and identifying any inefficiencies or gaps.
Organizational Charts: Visualizing the structure of the organization and how different units interact and collaborate.
5. Document the Baseline Description
Comprehensive Documentation: The baseline description should be meticulously documented to ensure clarity and alignment among stakeholders. This documentation should include:
Overview of Business Capabilities: A summary of existing capabilities and any updates made.
Value Streams and Key Processes: A description of how value is created and delivered across the organization.
Organizational Structure: An outline of the current organizational setup and any changes made.
Validation with Stakeholders: The draft baseline description should be reviewed with stakeholders to ensure accuracy and completeness. Feedback should be incorporated to refine the document further.
Developing the Baseline Description is a critical step in the architecture development process within TOGAF Phase B. By leveraging existing architecture descriptions and gathering necessary new information, the architecture team can create a comprehensive view of the organization’s current state. This baseline provides the necessary foundation for identifying gaps and defining the Target Architecture, ensuring alignment with the overall strategic goals of the enterprise. As a living document, the Baseline Description should be regularly reviewed and updated to reflect the evolving business environment.
1.3: Applying Business Capabilities in TOGAF
The application of business capabilities is a crucial aspect of developing a comprehensive Business Architecture within the TOGAF framework. This process involves mapping, analyzing, and optimizing business capabilities to ensure alignment with organizational goals and strategies.
Key Steps in Applying Business Capabilities
1. Mapping Business Capabilities
Developing the Business Capability Map: The business capability map serves as a foundational tool that offers a high-level view of what the organization can do, independent of how these capabilities are executed.
Mapping to Organizational Units: Once the capability map is created, it should be mapped to:
Organizational Units: Identifying which parts of the organization are responsible for each capability.
Value Streams: Linking capabilities to the value streams they support, ensuring clarity on how capabilities contribute to delivering value.
Information Systems and Applications: Establishing connections between capabilities and the systems that enable them, facilitating better understanding of technological support.
Strategic Plans: Aligning capabilities with strategic objectives and initiatives to ensure that they support the overall vision of the enterprise.
2. Relationship Mapping
Analyzing Relationships: By mapping the relationships between business capabilities, organizational units, value streams, and information systems, the architecture team can gain insights into how these domains interact and where there may be redundancies or gaps.
Optimization Opportunities: This analysis can reveal opportunities to optimize processes, reallocate resources, and enhance collaboration between units, ultimately leading to more efficient operations.
3. Heat Mapping Techniques
Understanding Capability Performance: Heat mapping is an effective analysis technique that provides a visual representation of the status of business capabilities across various dimensions:
Maturity: Assessing how developed each capability is, with color coding to indicate levels of maturity (green for desired, yellow for moderate, and red for underdeveloped).
Effectiveness: Evaluating the success of each capability in meeting business objectives.
Performance: Measuring the operational performance of capabilities.
Value or Cost: Assessing the financial implications of each capability to identify overfunded or underfunded areas.
Example of Heat Mapping:
Maturity Heat Map: A capability that has reached the desired maturity level is marked green, one level down is yellow, and capabilities significantly behind may be colored red. Additional colors may represent capabilities that are desired but currently non-existent (e.g., purple).
4. Conducting Gap Analysis
Identifying Gaps: The heat mapping and relationship mapping will help identify gaps between the current state and desired state of capabilities. This analysis focuses on business needs rather than just technical capabilities, ensuring relevance to the ongoing Enterprise Architecture project.
Prioritization for Improvement: Gaps identified through this process can inform prioritization for improvement efforts in future phases of architecture development. By focusing on areas that need enhancement, the architecture team can allocate resources effectively and align initiatives with business objectives.
Applying business capabilities within the TOGAF framework provides a structured approach to align organizational resources, processes, and technologies with strategic goals. By mapping capabilities to organizational units, analyzing relationships, utilizing heat mapping techniques, and conducting gap analyses, organizations can enhance their operational effectiveness and adaptability in a changing business environment. This structured approach not only supports immediate architecture efforts but also lays the groundwork for ongoing improvement and strategic alignment in the future.
1.4: Applying Value Streams
In the TOGAF framework, value streams play a crucial role in aligning business capabilities with organizational goals and providing insight into how these capabilities deliver value to stakeholders. Here’s how to effectively apply value streams in your enterprise architecture efforts.
Key Steps in Applying Value Streams
1. Establishing Initial Value Streams
Starting Point: Utilize the value stream models documented during the Architecture Vision phase as a foundation. These models provide context and clarity about how value is delivered within the organization.
Identifying Gaps: Assess whether there are additional value streams that should be included within the project scope. If the enterprise architecture project is significant in breadth, it may be necessary to define new value streams that reflect current organizational needs.
2. Analyzing Value Streams
Heat Mapping:
Conduct heat mapping for each stage of the value stream to evaluate performance and effectiveness. This involves analyzing metrics such as speed, cost, quality, and stakeholder satisfaction for each stage.
Use color coding to represent various performance indicators, allowing stakeholders to easily visualize areas that require improvement or investment.
Use Case Development:
Develop use cases for each value stream to fully articulate the needs and expectations of stakeholders at each stage. This involves detailing the interactions and processes involved, which helps identify specific business requirements and technical needs.
Focus on key stakeholders to clarify their expectations and desired outcomes from the value stream, ensuring that their perspectives are adequately represented in the architecture development.
3. Mapping Relationships to Business Capabilities
Mapping Process: Establish connections between each stage of the value stream and the corresponding business capabilities required to deliver that value. This relationship mapping helps clarify which capabilities are essential for each part of the value stream.
Understanding Interdependencies: Identify how capabilities interact and support each other across different value stream stages, which is essential for optimizing resource allocation and operational efficiency.
4. Conducting Gap Analysis
Evaluating Current Capabilities: Perform a gap analysis to determine how well the current business capabilities support the desired outcomes of the value streams. This analysis focuses on identifying deficiencies or areas where capabilities do not align with stakeholder needs.
Using Heat Mapping for Gaps:
Extend the heat mapping technique to visualize capability gaps in relation to the value streams. This method allows for a clear understanding of where improvements are needed and which capabilities require enhancement or development.
Prioritize the gaps based on their impact on value delivery to stakeholders, ensuring that the most critical areas are addressed first.
By applying value streams effectively within the TOGAF framework, organizations can create a comprehensive view of how their business capabilities align with stakeholder needs and organizational goals. This approach not only enhances the understanding of value delivery but also informs the architecture development process by identifying critical gaps and opportunities for improvement.
Through the analysis of existing value streams, development of use cases, and mapping of capabilities, organizations can ensure that their enterprise architecture is closely aligned with their strategic objectives, ultimately leading to greater operational efficiency and stakeholder satisfaction.
1.5: Applying the Organization Map
The organization map is a crucial tool in the TOGAF framework, particularly in the Business Architecture phase. It provides a holistic view of the key organizational units, partners, and stakeholder groups within the enterprise ecosystem, illustrating their interactions and relationships beyond hierarchical structures. Here’s how to effectively apply the organization map in your enterprise architecture efforts.
Key Steps in Applying the Organization Map
1. Define the Scope of the Organization Map
Identify the Relevant Business Units:
Determine which organizational units are relevant to the architecture effort. This can include one specific business unit, all units within the enterprise, or external partners and stakeholders, depending on the project's scope.
Engage stakeholders to ensure that all relevant units are included and accurately represented.
Clarify Relationships:
Define the nature of relationships between the different entities. This goes beyond mere reporting lines to include collaboration, communication, and other working relationships.
2. Construct the Organization Map
Visual Representation:
Create a visual representation of the organization map, ideally in a network or web format, to clearly illustrate the relationships and interactions between units.
Use tools or software that can easily depict complex relationships, making it easier for stakeholders to understand the interconnectedness of various entities.
Highlight Key Interactions:
Indicate the types of interactions (e.g., operational, strategic, communicative) that occur between units. This will help in identifying key stakeholders for specific requirements or decisions within the architecture effort.
3. Integrate with Business Capability and Value Stream Maps
Link to Capabilities and Value Streams:
Cross-reference the organization map with the business capability map and value stream models. This helps to clarify which units are responsible for specific capabilities and how they participate in delivering value.
Ensure that the relationships between capabilities, value streams, and organizational units are clearly articulated in the maps.
4. Identify Stakeholder Engagement Opportunities
Determine Stakeholder Involvement:
Use the organization map to identify which business units and stakeholders need to be engaged in various phases of the architecture effort. This ensures that relevant perspectives are considered, enhancing the quality of decision-making.
Establish a communication plan based on the organization map to facilitate effective stakeholder engagement throughout the architecture development process.
5. Assess Impact and Dependencies
Evaluate Impact of Decisions:
Analyze how changes in the architecture may impact different organizational units and their relationships. This includes understanding dependencies and potential disruptions to existing workflows or collaborations.
Use the organization map to facilitate discussions about the implications of architectural decisions, ensuring that all stakeholders understand their roles and responsibilities.
The organization map is an essential component of the Business Architecture within the TOGAF framework. By providing a clear picture of the organizational landscape, it enables architecture teams to engage the right stakeholders, understand key relationships, and assess the impact of their decisions. When combined with capability and value stream maps, the organization map offers a comprehensive view of how the enterprise operates, supporting informed decision-making and effective architecture development.
Incorporating these steps ensures that the organization map serves as a valuable tool in the architecture process, fostering collaboration and enhancing the overall effectiveness of the enterprise architecture effort. For further guidance on organization mapping techniques, refer to the TOGAF® Series Guide: Organization Mapping.
1.6 Applying Information Maps in TOGAF
In the context of TOGAF, applying information maps is an essential activity during the Business Architecture phase. It helps organizations characterize the information that is vital for their operations, establish connections between information and business capabilities, and lay the groundwork for future architecture phases. Here’s a detailed approach to effectively create and utilize information maps.
Steps to Create and Apply Information Maps
1. Identify Key Business Elements
Gather Stakeholders:
Assemble a cross-discipline team that includes representatives from various business units. Their insights are crucial for identifying which elements are most significant to the business.
List Key Elements:
Create a list of key business elements, such as:
Products
Customers
Suppliers
Factories
Services
Regulatory requirements
2. Develop Information Domains
Group and Categorize:
Organize the identified key elements into logical groupings or categories. This helps to form the foundation of the information domains.
Examples of potential domains may include:
Product Information
Customer Information
Operational Data
Compliance Data
Map Information Domains:
Create an initial information map that represents these domains visually. This map should depict the key elements and how they relate to one another.
3. Define Relationships Among Information Domains
Establish Linkages:
Identify and add relationships between the information domains to the map. This step helps provide a clearer understanding of how information flows between different business areas.
Consider relationships such as:
How customer information is tied to product sales
How operational data impacts inventory management
4. Build Matrices Between Information and Business Capabilities
Link to Business Capabilities:
Create matrices that illustrate the connection between information domains and the business capabilities they support. This is a critical step in understanding how information contributes to business value.
For example, map the customer information domain to capabilities like:
Customer Relationship Management
Product Development
Marketing Strategies
Analyze Gaps:
Use the matrices to identify any gaps where critical information may be missing or underutilized, facilitating a targeted approach for improving information management.
5. Iterate and Validate the Information Map
Review with Stakeholders:
Validate the information map with relevant stakeholders to ensure its accuracy and completeness. Gather feedback and make adjustments as necessary.
Update Documentation:
Ensure that the final information map and its accompanying matrices are documented thoroughly. This will serve as a reference for future phases of the architecture process.
6. Use Information Maps in Future Architecture Phases
Transition to Data Characterization:
Leverage the information map as a basis for the subsequent phases focused on data characterization, application architecture, and technology infrastructure.
Facilitate Data Management Strategies:
Use insights from the information map to inform data governance, management strategies, and the integration of data across the enterprise.
Applying information maps is a vital step in the TOGAF framework that bridges the gap between business needs and data management strategies. By systematically identifying key business elements, defining information domains, and establishing relationships, organizations can create a clear and comprehensive understanding of how information supports business capabilities.
The resulting information maps not only provide value in the Business Architecture phase but also set the stage for more detailed architecture work in subsequent phases. By aligning information with business capabilities, organizations can enhance their ability to leverage data for strategic decision-making and value creation.
For further guidance on information mapping techniques and best practices, refer to the TOGAF® Series Guide: Information Mapping.
1.7 Applying Modeling Techniques in TOGAF
Modeling techniques are vital for translating the high-level concepts of business capabilities, value streams, and organization maps into actionable representations that can be implemented in an organization’s operating model. In TOGAF, these techniques provide a structured approach to understand how an organization operates and how its processes and data interact to achieve its objectives. Below is a detailed overview of several key modeling techniques that can be employed in Phase B of the TOGAF architecture framework.
Key Modeling Techniques
1. Activity Models (Business Process Models)
Description:
Activity models depict the enterprise’s business activities and the flow of data and information between these activities. They illustrate both internal and external exchanges of information.
Structure:
These models are hierarchical, breaking down complex processes into simpler activities. They capture the Inputs, Controls, Outputs, and Mechanisms/Resources (ICOMs) for each activity.
Business Rules:
Activity models can be enhanced with business rules, which clarify the relationships among ICOMs and specify conditions under which activities are performed.
Techniques:
Common techniques include:
IDEF: Integrated Computer-Aided Manufacturing Definition (ICAM) modeling technique.
BPMN: Business Process Modeling Notation™, a standard developed by the Object Management Group (OMG) for modeling business processes.
2. Use-Case Models
Description:
Use-case models describe the interactions between actors (which can be people or systems) and the business processes of the enterprise. They provide a perspective on how different stakeholders engage with various processes.
Structure:
Use-case models include:
Use-case Diagrams: Visual representations that show the relationships between actors and use cases.
Use-case Specifications: Detailed descriptions of each use case, including the main flow of events, alternative flows, and pre- and post-conditions.
Benefits:
These models help clarify requirements, identify user needs, and ensure that the designed processes align with stakeholder expectations.
3. Logical Data Model (Class Model)
Description:
Logical data models outline the entities within the organization, their attributes, acceptable values, and the relationships among these entities. They provide a foundation for understanding the data that supports business capabilities.
Structure:
Key features include:
Entities: Represent objects or concepts (e.g., Customer, Product).
Attributes: Describe properties of entities (e.g., Customer Name, Product Price).
Relationships: Define how entities relate to each other (e.g., a Customer places an Order).
"Is-a" Relationships:
These models effectively capture inheritance and classification through "is-a" relationships. For example, a "Sedan" is a type of "Car," which in turn is a type of "Vehicle," allowing shared rules to apply across all vehicle types.
Expansion to Class Models:
Class models extend logical data models by incorporating behaviors (methods) associated with entities, which is particularly useful for application development.
Standardization:
Both logical data models and class models can be represented using the Unified Modeling Language™ (UML®), which provides a consistent framework for model development.
4. Industry-Specific Modeling Techniques
Description:
Certain industries may have unique modeling techniques tailored to their specific needs. These techniques should be integrated into the architecture practices where applicable.
Examples:
Techniques may vary based on sector requirements, such as healthcare, finance, or manufacturing, necessitating specialized approaches to modeling business processes and data.
Implementing the Techniques
Select Appropriate Techniques:
Assess the specific needs of the architecture project and choose modeling techniques that best align with the goals of the organization.
Gather Stakeholder Input:
Collaborate with relevant stakeholders to ensure the models accurately reflect business processes and requirements.
Iterate and Refine:
Continuously review and refine the models to incorporate feedback and adapt to changing business environments or strategic goals.
Integrate with Other Models:
Ensure that activity models, use-case models, and data models are interconnected, providing a cohesive view of the enterprise architecture.
Utilize Modeling Tools:
Leverage software tools designed for modeling, which can facilitate the creation, visualization, and maintenance of models, ensuring accuracy and consistency.
Applying modeling techniques in TOGAF’s Phase B is crucial for developing a comprehensive understanding of how an organization operates. By effectively utilizing activity models, use-case models, and logical data models, architects can create clear representations of business processes, stakeholder interactions, and data structures. This foundational work enables organizations to align their architecture with business capabilities, streamline processes, and enhance decision-making, ultimately leading to greater organizational effectiveness and efficiency.
1.8 Architecture Repository
As part of Phase B in the TOGAF architecture development method (ADM), the architecture team must leverage existing resources from the Architecture Repository. This is crucial for ensuring that the Business Architecture aligns with industry standards and the specific needs of the enterprise. Below is an overview of the key resources to consider during this phase:
1. Industry Reference Models
Definition:
Industry reference models provide a framework that outlines common business processes, structures, and functions specific to an industry sector.
Importance:
These models serve as benchmarks for best practices and standards within the industry, enabling the architecture team to:
Align the enterprise's business architecture with proven industry practices.
Identify gaps and opportunities for improvement based on industry norms.
Examples:
Frameworks like the Business Process Model and Notation (BPMN), SCOR Model (Supply Chain Operations Reference), or specific models for sectors such as healthcare or finance can be utilized.
2. Enterprise-Specific Business Architecture Views
Components:
Capability Maps: Visual representations of the business capabilities of the organization, detailing what the enterprise can do.
Value Stream Maps: Diagrams that illustrate how value is delivered to stakeholders through business processes.
Organization Maps: Models showing the relationships and interactions among various organizational units and stakeholders.
Purpose:
These views provide a tailored understanding of the enterprise's operational structure, making it easier to:
Identify existing capabilities and processes.
Map relationships and dependencies among different business functions.
Facilitate discussions with stakeholders regarding architecture needs and requirements.
3. Enterprise-Specific Building Blocks
Definition:
Building blocks represent reusable components within the business architecture that can be combined to support various processes and functions.
Types:
Process Components: Standardized processes that can be implemented across different areas of the organization.
Business Rules: Defined guidelines that dictate how business processes should be executed, ensuring compliance and consistency.
Job Descriptions: Outlines of roles and responsibilities that clarify expectations for personnel involved in business processes.
Benefits:
Leveraging these building blocks enables the architecture team to:
Enhance efficiency by reusing established components.
Maintain consistency across business processes and functions.
Reduce development time for new initiatives by utilizing existing frameworks.
4. Applicable Standards
Description:
Applicable standards refer to established guidelines, protocols, and best practices that govern how business architecture and processes should be designed and executed.
Significance:
Adhering to industry standards ensures that the architecture is compliant, interoperable, and aligned with both regulatory requirements and industry norms.
Examples:
Standards such as ISO 9001 (Quality Management Systems), COBIT (Control Objectives for Information and Related Technologies), or ITIL (Information Technology Infrastructure Library) may be relevant depending on the organization’s operational focus.
Implementation Steps
Gather and Review Existing Resources:
Collect relevant documents, models, and building blocks from the Architecture Repository.
Analyze Alignment with Business Goals:
Ensure that the collected resources align with the organization’s strategic objectives and business goals outlined in Phase A.
Involve Stakeholders:
Engage with key stakeholders to validate the relevance and applicability of the industry models, enterprise-specific views, building blocks, and standards.
Document and Integrate:
Document the resources and findings in the Architecture Definition Document and integrate them into the overall architecture development process.
Iterate and Update:
Regularly revisit and update the Architecture Repository to reflect changes in business strategy, industry standards, or operational practices.
Incorporating the relevant resources from the Architecture Repository during Phase B of the TOGAF ADM is essential for developing a robust Business Architecture. By leveraging industry reference models, enterprise-specific views, building blocks, and applicable standards, the architecture team can create a comprehensive and aligned representation of the organization’s business capabilities and processes, ultimately supporting effective decision-making and strategic initiatives.
2: Steps
1. Determining the Overall Business Architecture Modeling Process
Business Modeling and Strategy Assessments:
Business modeling and strategy assessments are crucial for defining an organization’s target state.
These outputs help outline the necessary business capabilities, organizational structure, and value streams to close the gap between the current and desired state.
Leverage existing frameworks to identify gaps and better map business value to reach the Target Business Architecture.
Viewpoint Selection and Modeling:
For each viewpoint, select the models needed to support the specific views required, using appropriate tools or methods.
Ensure that stakeholder concerns are comprehensively addressed; if not, create or modify models as needed.
Business scenarios can be iteratively used to identify and document requirements at different levels of detail.
Techniques for Business Decomposition: Several methods and techniques can be used to progressively break down business complexities:
Business Capability Mapping: Categorizes and decomposes the capabilities needed to deliver value to stakeholders.
Information Mapping: Focuses on the relationships and concepts most important to the business.
Organization Mapping: Represents the structure of the organization, showing business units, functions, and relationships to capabilities and locations.
Process Modeling: Articulates business processes for analysis and improvement.
Structured Analysis: Maps business capabilities onto business functions and organizational units.
Use-case Analysis: Identifies the requirements of a system or task from the user’s perspective.
Value Stream Mapping: Breaks down end-to-end activities that create stakeholder value, leveraging business capabilities to align with the Target Business Architecture.
Level of Decomposition:
The degree of decomposition varies depending on the enterprise’s goals, scope, and purpose of the architecture.
Architects must tailor the level of detail based on the enterprise’s specific objectives and the nature of the Enterprise Architecture effort.
These steps ensure that the modeling process comprehensively captures the organization’s business architecture, addresses gaps, and aligns stakeholder requirements with value delivery.
1.2 Identifying Required Catalogs of Business Building Blocks
Catalogs serve as structured inventories of core business assets, helping to organize and manage both business and IT capabilities. These catalogs are essential in Business Architecture, acting as the raw material for developing matrices and views that support decision-making.
Hierarchical Nature of Catalogs:
Catalogs are inherently hierarchical, capturing the decomposition of individual building blocks.
They also show relationships across different building blocks, such as organizational structures and actors.
Purpose of Catalogs:
Catalogs help track core assets and resources.
They provide essential input for the development of more complex views, such as matrices and architectural views.
Catalogs are critical for managing both business and IT capabilities effectively.
TOGAF Catalogs:
According to the TOGAF Standard, Architecture Content describes catalogs in detail.
It relates catalogs to entities, attributes, and relationships within the TOGAF Enterprise Metamodel.
TOGAF provides guidelines for the types of catalogs that should be considered when developing a Business Architecture.
By organizing the essential building blocks and their relationships, catalogs help in aligning business capabilities with organizational goals and IT infrastructure, offering a structured way to manage complexity.
1.3 Identifying Required Matrices in Business Architecture
Matrices are essential tools in Business Architecture as they capture the relationships between different model entities. These relationships provide a foundation for developing more detailed views and conducting impact assessments, particularly during gap analysis.
Purpose of Matrices:
Matrices illustrate the core relationships between interconnected model entities.
They serve as a basis for the development of architectural views, helping architects visualize relationships in a structured way.
Matrices are crucial resources for conducting impact assessments, helping to understand how changes in one area affect others, particularly during gap analysis.
Role in Gap Analysis:
During gap analysis, matrices enable architects to assess the alignment or misalignment of current capabilities with the target architecture.
They help identify gaps between current and desired states, aiding in the prioritization of actions.
TOGAF Matrices:
The TOGAF Standard — Architecture Content provides detailed guidance on the types of matrices to be developed within a Business Architecture.
These matrices are described in relation to entities, attributes, and relationships within the TOGAF Enterprise Metamodel.
By capturing and visualizing relationships between different business elements, matrices are valuable tools for impact assessments and decision-making, helping businesses align their operations and processes with strategic goals.
1.4 Identifying Required Diagrams in Business Architecture
Diagrams play a crucial role in Business Architecture by visually presenting information from different perspectives, tailored to the needs of various stakeholders. These diagrams help communicate complex information clearly, aligning architecture work with stakeholder concerns.
Purpose of Diagrams:
Diagrams provide visual representations of different components of the Business Architecture, such as processes, capabilities, or organizational structures.
They help present business information from multiple viewpoints, making it easier to understand and address the requirements of diverse stakeholders.
Stakeholder-Oriented Perspectives:
Depending on the needs of specific stakeholders, different diagrams may be required to highlight aspects such as operations, management, or financial structures.
These diagrams simplify the communication of key elements, such as value streams or business processes, aiding in strategic decision-making.
TOGAF Diagrams:
The TOGAF Standard — Architecture Content provides a detailed overview of the types of diagrams that should be developed as part of the Business Architecture.
These diagrams are connected to entities, attributes, and relationships defined in the TOGAF Enterprise Metamodel, ensuring consistency in how the architecture is represented.
By leveraging appropriate diagrams, architects can effectively communicate the architecture’s structure and strategy, addressing stakeholder concerns and supporting the successful implementation of business goals.
1.5 Identifying Types of Requirements to be Collected in Business Architecture
After developing the necessary catalogs, matrices, and diagrams in the Business Architecture phase, the next step is to formalize the business requirements that will guide the implementation of the Target Architecture. These requirements help ensure the architectural design aligns with the organization's goals and is effective during implementation.
Types of Requirements:
Business Domain Requirements:
These requirements are specific to the business operations and processes.
They reflect what the business needs to achieve, such as improved efficiency, scalability, or process automation.
Input for Data, Application, and Technology Architectures:
Business requirements often provide crucial input for other architecture domains like Data, Application, and Technology.
For instance, a requirement for better customer data management may influence both the data architecture and the technology used to manage it.
Guidance for Design and Implementation:
The collected requirements should offer detailed guidance to ensure the architecture remains aligned with business objectives during its design and implementation.
They ensure that solutions developed later in the process will address the original business needs.
Requirement Collection Process:
During the Architecture Vision phase, the scope of the requirements should be clearly defined in the Statement of Architecture Work.
Requirements that arise beyond the scope of the original work should be directed to the Requirements Repository and managed through the Requirements Management process.
The architect should ensure that any new or changing requirements are handled with proper governance to maintain alignment with the overall architecture.
By identifying and managing these types of requirements, architects can ensure that the Business Architecture is effectively translated into practical, implementable solutions that meet organizational goals.
2. Developing the Baseline Business Architecture Description
Purpose of Baseline Business Architecture: The goal is to develop a Baseline Description of the current Business Architecture to support the development of the Target Business Architecture.
Scope and Detail: The scope and level of detail for the Baseline Architecture depend on:
The extent to which existing business elements will be retained in the Target Business Architecture.
Whether existing Architecture Descriptions already exist to guide the process.
Use of Existing Resources: Where possible, relevant Business Architecture building blocks should be identified by referring to the Architecture Repository, as per the TOGAF Standard — Architecture Content.
Creating New Models: If new models are needed to meet stakeholder concerns, follow the models identified in Step 1 as a guideline to create new architecture content for describing the Baseline Architecture.
3. Developing the Target Business Architecture Description
Purpose of Target Business Architecture: Develop a Target Description of the Business Architecture necessary to support the Architecture Vision.
Scope and Detail: The scope and level of detail depend on:
The relevance of business elements in achieving the Target Architecture Vision.
The existence of prior architectural descriptions that can be referenced or adapted.
Use of Existing Resources: Identify relevant Business Architecture building blocks using the Architecture Repository, as per the TOGAF Standard — Architecture Content.
Creating New Models: If new models are required to address stakeholder concerns, follow the models outlined in Step 1 to guide the creation of new architecture content for the Target Architecture.
Exploring Architecture Alternatives: Investigate and discuss different Target Architecture alternatives with stakeholders using the Architecture Alternatives and Trade-offs technique from the TOGAF Standard — ADM Techniques.
4. Performing Gap Analysis in Business Architecture
Verification of Architecture Models:
Ensure internal consistency and accuracy of the architecture models.
Conduct trade-off analysis to resolve conflicts among different views.
Validation Against Principles and Objectives:
Confirm that models align with organizational principles, objectives, and constraints.
Note any changes in the viewpoint represented in the models, and document these updates.
Completeness of Architecture Models:
Test the architecture models for completeness by comparing them against the business requirements.
Identifying Gaps:
Perform a gap analysis to identify discrepancies between the baseline and target architecture, following the technique described in the TOGAF Standard — Applying the ADM (Architecture Development Method).
5. Defining Candidate Roadmap Components
Business Roadmap Creation:
After developing the Baseline Architecture, Target Architecture, and completing the gap analysis, a business roadmap is necessary.
This roadmap helps prioritize activities and guide the upcoming phases.
Purpose of the Business Architecture Roadmap:
Serves as an initial outline for planning and prioritization.
Provides raw material for further refinement and consolidation in the Opportunities & Solutions phase.
Cross-Discipline Integration:
The roadmap will evolve into a more detailed, cross-functional plan, ensuring alignment across various disciplines as part of the overall architecture process.
6. Resolving Impacts Across the Architecture Landscape
Assessing Broader Impacts:
Once the Business Architecture is finalized, it is crucial to evaluate its effects on other parts of the Architecture Landscape.
Impact on Existing Architectures:
Check if the new Business Architecture affects any pre-existing architectures or if recent changes in those architectures impact the Business Architecture.
Opportunities for Leverage:
Identify areas where work done in the Business Architecture can be used in other areas of the organization.
Project Impact Considerations:
Assess if the Business Architecture impacts any ongoing or planned projects.
Determine whether other projects may influence the Business Architecture in any way.
7. Conducting Formal Stakeholder Review
Review Architecture Motivation:
Revisit the original goals and motivations for initiating the architecture project.
Compare the proposed Business Architecture against the Statement of Architecture Work to ensure alignment.
Assess Fitness for Purpose:
Determine if the proposed Business Architecture is suitable for supporting work in other architectural domains, such as Data, Application, and Technology Architectures.
Refinement if Necessary:
Refine and adjust the Business Architecture only if it is deemed necessary after the review, ensuring it continues to meet the project’s objectives and stakeholder expectations.
8. Finalizing the Business Architecture
Select Standards for Building Blocks:
Choose standards for each Business Architecture building block, prioritizing reuse from reference models in the Architecture Repository.
Document Building Blocks:
Thoroughly document each building block, ensuring all details are captured for future use.
Cross-Check Against Business Goals:
Perform a final check of the architecture against business goals to ensure alignment.
Record the rationale for decisions made regarding building blocks in the architecture document.
Requirements Traceability Report:
Prepare and document the final requirements traceability report to ensure that all business requirements are addressed.
Architecture Repository Mapping:
Identify reusable building blocks, including practices, roles, and relationships, and publish these in the Architecture Repository for future reference.
Finalize Work Products:
Complete and finalize all architecture work products, including gap analysis results and any related documentation.
9. Creating/Updating the Architecture Definition Document
Document Rationale for Decisions:
Provide justification for the choices made in selecting specific building blocks within the Architecture Definition Document.
Prepare Relevant Business Sections:
Draft business-related sections of the document to reflect the scope and intended use of the architecture. This ensures alignment with the overarching business objectives and vision.
Utilize Modeling Tools:
Where applicable, use modeling tools to generate reports or graphical representations. These visuals help demonstrate key architectural views, offering stakeholders a clearer understanding of the design.
Stakeholder Review:
Route the document to relevant stakeholders for review. Incorporate their feedback to refine the architecture and ensure it meets the project’s objectives effectively.
Last updated
