4. Phase B: Business Architecture
This chapter describes the development of a Business Architecture to support an agreed Architecture Vision.
The objectives of Phase B are to:
- Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
- Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures
This section defines the inputs to Phase B.
4.2.1 Reference Materials External to the Enterprise
- Architecture reference materials (see the TOGAF Standard — Architecture Content)
4.2.2 Non-Architectural Inputs
- Request for Architecture Work (see the TOGAF Standard — Architecture Content)
- Business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
- Capability Assessment (see the TOGAF Standard — Architecture Content)
- Communications Plan (see the TOGAF Standard — Architecture Content)
4.2.3 Architectural Inputs
- Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
- Scope of organizations impacted
- Maturity assessment, gaps, and resolution approach
- Roles and responsibilities for architecture team(s)
- Constraints on architecture work
- Budget requirements
- Governance and support strategy
- Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
- Tailored architecture method
- Tailored architecture content (deliverables and artifacts)
- Configured and deployed tools
- Approved Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
- Architecture Principles (see the TOGAF Standard — Architecture Content), including business principles, when pre-existing
- Enterprise Continuum (see the TOGAF Standard — Architecture Content)
- Architecture Repository (see the TOGAF Standard — Architecture Content),
- Re-usable building blocks
- Publicly available reference models
- Organization-specific reference models
- Organization standards
- Architecture Vision (see the TOGAF Standard — Architecture Content),
- Problem description
- Objective of the Statement of Architecture Work
- Summary views
- Business Scenario (optional)
- Refined key high-level stakeholder requirements
- Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
The level of detail addressed in Phase B will depend on the scope and goals of the overall architecture effort.
New models characterizing the needs of the business will need to be defined in detail during Phase B. Existing business artifacts to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase B.
The order of the steps in Phase B as well as the time at which they are formally started and completed should be adapted to the situation at hand, in accordance with the established Architecture Governance. In particular, determine whether in this situation it is appropriate to conduct Baseline or Target Architecture development first, as described in the TOGAF Standard — Applying the ADM.
All activities that have been initiated in these steps should be closed during the Finalize the Business Architecture step (see
4.3.8 Finalize the Business Architecture). The documentation generated from these steps must be
formally published in the Create/Update the Architecture Definition Document step (see 4.3.9 Create/Update
the Architecture Definition Document).
The steps in Phase B are as follows:
- Select reference models, viewpoints, and tools (see 4.3.1 Select Reference Models, Viewpoints, and Tools)
- Develop Baseline Business Architecture Description (see 4.3.2 Develop Baseline Business Architecture Description)
- Develop Target Business Architecture Description (see 4.3.3 Develop Target Business Architecture Description)
- Perform gap analysis (see 4.3.4 Perform Gap Analysis)
- Define candidate roadmap components (see 4.3.5 Define Candidate Roadmap Components)
- Resolve impacts across the Architecture Landscape (see 4.3.6 Resolve Impacts Across the Architecture Landscape)
- Conduct formal stakeholder review (see 4.3.7 Conduct Formal Stakeholder Review)
- Finalize the Business Architecture (see 4.3.8 Finalize the Business Architecture)
- Create/Update the Architecture Definition Document (see 4.3.9 Create/Update the Architecture Definition Document)
4.3.1 Select Reference Models, Viewpoints, and Tools
Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers and stakeholder concerns.
Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture.
Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication warranted, these may comprise simple documents or spreadsheets, or more sophisticated modeling tools and techniques, such as activity models, business process models, use-case models, etc.
188.8.131.52 Determine Overall Modeling Process
Business modeling and strategy assessments are effective techniques for framing the target state of an organization's Business Architecture (see 3.3.4 Evaluate Capabilities). The output from that activity is then used to articulate the business capabilities, organizational structure, and value streams required to close gaps between the current and target state. As addressed in 3.5 Approach , the frameworks for these maps may already exist and should be leveraged, now using them to characterize gaps and better map business value to achieve the Target Business Architecture.
For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.
Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment
existing models (see 4.5.7 Applying Modeling Techniques). Business scenarios are a useful technique to
discover and document business requirements, and may be used iteratively, at different levels of detail in the hierarchical
decomposition of the Business Architecture. Business scenarios are described in the TOGAF® Series Guide: Business Scenarios.
The techniques described in 4.5 Approach can be utilized to progressively decompose a business:
- Business Capability Mapping: identifies, categorizes, and decomposes the business capabilities required for the business to have the ability to deliver value to one or more stakeholders
- Information Mapping: collecting the information concepts and their relationships that matter most to the business
- Organization Mapping: a representation of the organizational structure of the business (including third-party domains), depicting business units, the decomposition of those units into lower-level functions, and organizational relationships (unit-to-unit and mapping to business capabilities, locations, and other attributes)
- Process Modeling: the activity of articulating business processes of an enterprise, to enable analysis and improvement
- Structured Analysis: identifies the key business capabilities within the scope of the architecture, and maps those capabilities onto business functions and organizational units within the business
- Use-case Analysis: a technique used to identify the requirements of a system or task to be completed, from a user's perspective
- Value Stream Mapping: the end-to-end breakdown of activities that an organization performs to create the value being
exchanged with stakeholders
Value stream maps illustrate how an organization delivers value and are in the context of a specific set of stakeholders, and leverage business capabilities in order to create stakeholder value and align to other aspects of the Target Business Architecture.
The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the Enterprise Architecture effort to determine the level of decomposition.
184.108.40.206 Identify Required Catalogs of Business Building Blocks
Catalogs capture inventories of the core assets of the business. Catalogs are hierarchical in nature and capture the decomposition of a building block and also decompositions across related building blocks (e.g., organization/actor).
Catalogs form the raw material for development of matrices and views and also act as a key resource for managing the business and IT capability.
The TOGAF Standard — Architecture Content contains a detailed description of catalogs which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.
220.127.116.11 Identify Required Matrices
Matrices show the core relationships between related model entities.
Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis.
The TOGAF Standard — Architecture Content contains a detailed description of matrices which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.
18.104.22.168 Identify Required Diagrams
Diagrams present the Business Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.
The TOGAF Standard — Architecture Content contains a detailed description of diagrams which should be considered for development within a Business Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.
22.214.171.124 Identify Types of Requirement to be Collected
Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the business-focused requirements for implementing the Target Architecture.
These requirements may:
- Relate to the business domain
- Provide requirements input into the Data, Application, and Technology Architectures
- Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements
Within this step, the architect should identify requirements that should be met by the architecture (see 13.5.2 Requirements Development).
In many cases, the Architecture Definition will not be intended to give detailed or comprehensive requirements for a solution (as these can be better addressed through general requirements management discipline). The expected scope of requirements content should be established during the Architecture Vision phase and documented in the approved Statement of Architecture Work.
Any requirement, or change in requirement, that is outside of the scope defined in the Statement of Architecture Work must be submitted to the Requirements Repository for management through the governed Requirements Management process.
4.3.2 Develop Baseline Business Architecture Description
Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture. The scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture, and on whether Architecture Descriptions exist, as described in 4.5 Approach . To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see the TOGAF Standard — Architecture Content).
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.
4.3.3 Develop Target Business Architecture Description
Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision. The scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist. To the extent possible, identify the relevant Business Architecture building blocks, drawing on the Architecture Repository (see the TOGAF Standard — Architecture Content).
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.
If appropriate, investigate different Target Architecture alternatives and discuss these with stakeholders using the Architecture Alternatives and Trade-offs technique (see the TOGAF Standard — ADM Techniques).
4.3.4 Perform Gap Analysis
Verify the architecture models for internal consistency and accuracy:
- Perform trade-off analysis to resolve conflicts (if any) among the different views
- Validate that the models support the principles, objectives, and constraints
- Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document
- Test architecture models for completeness against requirements
Identify gaps between the baseline and target, using the gap analysis technique, as described in the TOGAF Standard — Applying the ADM.
4.3.5 Define Candidate Roadmap Components
Following the creation of a Baseline Architecture, Target Architecture, and gap analysis results, a business roadmap is required to prioritize activities over the coming phases.
This initial Business Architecture Roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.
4.3.6 Resolve Impacts Across the Architecture Landscape
Once the Business Architecture is finalized, it is necessary to understand any wider impacts or implications.
At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:
- Does this Business Architecture create an impact on any pre-existing architectures?
- Have recent changes been made that impact on the Business Architecture?
- Are there any opportunities to leverage work from this Business Architecture in other areas of the organization?
- Does this Business Architecture impact other projects (including those planned as well as those currently in progress)?
- Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)?
4.3.7 Conduct Formal Stakeholder Review
Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Business Architecture only if necessary.
4.3.8 Finalize the Business Architecture
- Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
- Fully document each building block
- Conduct a final cross-check of overall architecture against business goals; document the rationale for building block decisions in the architecture document
- Document the final requirements traceability report
- Document the final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
- Finalize all the work products, such as gap analysis results
4.3.9 Create/Update the Architecture Definition Document
- Document the rationale for building block decisions in the Architecture Definition Document
- Prepare the appropriate business sections of the Architecture Definition Document related to the intended scope and use of the architecture
If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.
The outputs of Phase B may include, but are not restricted to:
- Refined and updated versions of the Architecture Vision phase deliverables, where applicable, including:
- Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
- Validated business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content), updated if necessary
- Architecture Principles (see the TOGAF Standard — Architecture Content)
- Draft Architecture Definition Document (see the TOGAF Standard — Architecture
- Baseline Business Architecture, Approved, if appropriate
- Target Business Architecture, Approved, including:
- Organization structure — identifying business locations and relating them to organizational units
- Business goals and objectives — for the enterprise and each organizational unit
- Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
- Business capabilities — the abilities that a business needs to possess or exchange to achieve its goals and objectives
- Business services — the services that support the business by encapsulating a unique "elements of business behavior"; a service offered external to the enterprise may be supported by business services
- Products — output generated by the business to be offered to customers; products include materials and/or services
- Business processes, including measures and deliverables
- Business roles, including development and modification of skills requirements
- Business data model
- Correlation of organization/business functions and business capabilities — relate business capabilities to organizational units in the form of a matrix report
- Views corresponding to the selected viewpoints addressing key stakeholder concerns
- Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including such Business Architecture requirements as:
- Gap analysis results
- Technical requirements — identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix (e.g., guiding trade-off between speed of transaction processing and security); list the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework)
- Updated business requirements
- Business Architecture components of an Architecture Roadmap (see the TOGAF Standard — Architecture Content)
The TOGAF Standard — Architecture Content contains a detailed description of architectural artifacts which might be produced in this phase.
Business Architecture is a representation of holistic, multi-dimensional business views of capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.
Business Architecture relates business elements to business goals and elements of other domains.
A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).
In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.
The scope of work in Phase B is primarily determined by the Architecture Vision as set out in Phase A. The business strategy defines the goals and drivers and the metrics for success, but not necessarily how to get there. That is the role of the Business Architecture, defined in detail in Phase B.
This will depend to a large extent on the enterprise environment. In some cases, key elements of the Business Architecture may be done in other activities; for example, the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.
In such cases, there may be a need to verify and update the currently documented business strategy and plans, and/or to bridge between high-level business drivers, business strategy, and goals on the one hand, and the specific business requirements that are relevant to this architecture development effort.
In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A.
In both of these cases, the business scenarios technique (see the TOGAF® Series Guide: Business Scenarios), or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used.
A key objective is to re-use existing material as much as possible. In architecturally more mature environments, there will be existing Architecture Definitions, which (hopefully) will have been maintained since the last architecture development cycle. Where Architecture Descriptions exist, these can be used as a starting point, and verified and updated if necessary; see the TOGAF Standard — Architecture Content.
Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort. If this effort is focused on the definition of (possibly new) business processes, then Phase B will necessarily involve a lot of detailed work. If the focus is more on the Target Architectures in other domains (data/information, application systems, infrastructure) to support an essentially existing Business Architecture, then it is important to build a complete picture in Phase B without going into unnecessary detail.
4.5.2 Developing the Baseline Description
If an enterprise has existing Architecture Descriptions, they should be used as the basis for the Baseline Description. This input may have been used already in Phase A in developing the Architecture Vision, such as the business capability map or a core set of value streams as introduced in 3.5.2 Creating the Architecture Vision , and may be sufficient in itself for this baseline.
The reasons to update these materials include having a missing business capability, a new value stream, or changed organizational unit that has not previously been assessed within the scope of the Enterprise Architecture project. 4.5.3 Applying Business Capabilities through 4.5.6 Applying Information Maps address the use of core Business Architecture methods to model the Business Architecture driven by the strategy scope from Phase A. Note that putting these methods into action to drive a focus and target state for later architecture work does not mean that the fundamental frameworks from Phase A, such as a common enterprise business capability map, will necessarily change but rather that they are applied in a manner driven by the scope and needs of the specific Enterprise Architecture project.
If no Architecture Descriptions exist, information should be gathered and Business Architecture models developed.
Whatever the scope of the specific project, it is important to determine whether it is the fundamental view of the business that is changing or the usage of those views to determine scope, priorities, and relationships for the specific project in relation to the rest of the enterprise.
4.5.3 Applying Business Capabilities
The business capability map found or developed in the Architecture Vision phase provides a self-contained view of the business that is independent of the current organizational structure, business processes, information systems and applications, and the rest of the product or service portfolio. Those business capabilities should be mapped back to the organizational units, value streams, information systems, and strategic plans within the scope of the Enterprise Architecture project. This relationship mapping provides greater insight into the alignment and optimization of each of those domains (see Relationship Mapping in TOGAF® Series Guide: Business Capabilities).
Another common analysis technique involves heat mapping, which can be used to show a range of different perspectives on the same set of core business capabilities. These include maturity, effectiveness, performance, and the value or cost of each capability to the business. Different attributes determine the colors of each capability on the business capability map (see Heat Mapping in TOGAF® Series Guide: Business Capabilities).
For example, a business capability maturity heat map shows the desired maturity as green for a specific capability, one level down as yellow, and two or more levels down as red. Other colors may indicate status, such as purple denoting a capability that does not exist yet in the company but is desired, or perhaps as a capability that is over-funded and has more resources than necessary. This gap analysis is directly tied to the Enterprise Architecture project underway; a gap is only relevant in the context of the business need and provides focus for more mapping in this phase or priorities for later architecture phases.
4.5.4 Applying Value Streams
Value streams provide valuable stakeholder context into why the organization needs business capabilities, while business capabilities provide what the organization needs for a particular value stage to be successful.
Start with the initial set of value stream models for the business documented in the Architecture Vision phase. Within the scope of the specific Enterprise Architecture project, if sufficiently larger in breadth, there may be a need for new value streams not already in the repository.
A new or existing value stream can be analyzed within the scope of the project through heat mapping (by value stream stage) or by developing use-cases around a complete definition of the value stream (see Baseline Example in the TOGAF® Series Guide: Value Streams). A project might focus on specific stakeholders, one element of business value, or stress some stages over others to develop better requirements for solutions in later phases.
The most substantive benefits come from mapping relationships between the stages in a value stream to business capabilities, then performing a gap analysis for capabilities (such as heat mapping) in the context of the business value achieved by the value stream for a specific stakeholder (see Mapping Value Streams to Business Capabilities in the TOGAF® Series Guide: Value Streams).
4.5.5 Applying the Organization Map
An organization map shows the key organizational units, partners, and stakeholder groups that make up the enterprise ecosystem. The map should also depict the working relationship between those entities, as distinct from an organizational chart that only shows hierarchical reporting relationships. The map is typically depicted as a network or web of relationships and interactions between the various business entities (see Organigraphs: Drawing How Companies Really Work, by Mintzberg and Van der Heyden, 1999).
The business unit is the main concept used to establish organization maps. In keeping with the relatively unconstrained view of what constitutes as enterprise, the enterprise may be one business unit for the project underway, may include all business units, or also include third parties or other stakeholder groups. The interpretation depends on the scope of the architecture effort.
This map is a key element of Business Architecture because it provides the organizational context for the whole Enterprise Architecture effort. While capability mapping exposes what a business does and value stream mapping exposes how it delivers value to specific stakeholders, the organization map identities the business units or third parties that possess or use those capabilities and which participate in the value streams.
Taken together with the methods in 4.5.3 Applying Business Capabilities , 4.5.4 Applying Value Streams , and the associated Guides, the organization map provides an understanding of which business units to involve in the architecture effort, who and when to talk about a given requirement, and how to measure the impact of various decisions.
For further guidance on organization maps, see the TOGAF® Series Guide: Organization Mapping.
4.5.6 Applying Information Maps
Characterizing information in the Business Architecture phase starts with the elements that matter most to the business, such as product, customer, factory, etc. With a list of these key elements, a cross-discipline team can list and map the information that matters most and how it is described using business terms. Domains of information can be derived from groupings or categories that the business terms fall into logically. These domains are a good place to start the information map for completeness and highest value before proceeding later to the details of data types.
Relationships among the information domains can then be added to the map as the next level of understanding for a good baseline information map. The most significant benefit then comes with building matrices between information and business capabilities. The linkage between the information that matters most to the business and the business capabilities that describe the ability to apply that information to create value is a key aspect of Business Architecture. These information maps and relationships to business capabilities will then apply in later architecture phases on data characterization, applications, and infrastructure.
For further guidance on information maps, see the TOGAF® Series Guide: Information Mapping.
4.5.7 Applying Modeling Techniques
The modeling and mapping techniques provided here are extensions that implement the business capabilities, value streams, and organization maps described above in Phase B into the practices of the business. They expand the operating model, which is a representation for how an organization operates across a range of domains in order to accomplish its purpose (see A Method for Identifying Process Re-Use Opportunities to Enhance the Operating Model, M. de Vries et al.).
In addition to the techniques described above (capability maps, value streams, and organization maps), a variety of other modeling techniques may be employed, if deemed appropriate. For example:
- Activity Models (also called Business Process Models) describe the enterprise's business activities, the data
and/or information exchanged between activities (internal exchanges), and the data and/or information exchanged with other
activities that are outside the scope of the model (external exchanges)
Activity models are hierarchical in nature. They capture the activities performed in a business process, and the Inputs, Controls, Outputs, and Mechanisms/Resources (ICOMs) of those activities. Activity models can be annotated with explicit statements of business rules, which represent relationships among the ICOMs. For example, a business rule can specify who can do what under specified conditions, the combination of inputs and controls needed, and the resulting outputs. One technique for creating activity models is the Integrated Computer Aided Manufacturing (ICAM) DEFinition (IDEF) modeling technique.
The Object Management Group (OMG) has developed the Business Process Modeling NotationTM (BPMNTM), a standard for business process modeling that includes a language with which to specify business processes, their tasks/steps, and the documents produced.
business processes and organizational participants (people, organizations, etc.)
The use-case model is described in use-case diagrams and use-case specifications.
- Logical Data Model (or Class Model)
Logical data models describe the entities, their attributes, and the acceptable values for these attributes as well as the relationships between the various entities. Particularly useful is the "is-a" relationship for analyses. For example, if a sedan is a type of car which is a type of vehicle, then a general business rule for all vehicles can be written once and automatically picked up for all types of cars and trucks.
A class model expands the logical data model to include behaviors by including services (methods) unique to the entity (now called a class). Normally applications and information architects will use the class diagram, and Business Architects will use the logical data model.
All three types of model above can be represented in the Unified Modeling LanguageTM (UML®), and a variety of tools exist for generating such models.
Certain industry sectors have modeling techniques specific to the sector concerned.
4.5.8 Architecture Repository
As part of Phase B, the architecture team will need to consider what relevant Business Architecture resources are available from the Architecture Repository (see the TOGAF Standard — Architecture Content), in particular:
- Industry reference models relevant to the organization's industry sector
- Enterprise-specific Business Architecture views (capability maps, value stream maps, organization maps, etc.)
- Enterprise-specific building blocks (process components, business rules, job descriptions, etc.)
- Applicable standards
TOGAF is a registered trademark of The Open Group