2.3.1 Business Architecture Models

The purpose of this section is to define the target business architecture that is in scope for this exercise. Note: This section may be refined once the business architecture team has been set up. Note 2: The level of granularity at which the artifacts need to be defined is dependent on the level of detail that is required from the business architecture, and thus is a decision for the individual domains. Mandatory/optional: This section is optional as the domain may only wish to produce a current business architecture. Also, a degree of flexibility exists when documenting each of the sub-sections within this section. The domain only needs to produce the relevant artifacts from those highlighted in this section as per their needs. They do not need to produce all the artifacts, views, tables, etc. presented in this section. In terms of quality criteria, this section may make clear: • Any other relevant business architecture documentation • Context around any such relevant business architecture documentation; e.g., validity, ownership, purpose • Any assumptions regarding the business architecture documentation • Relevant views (diagrams) illustrating the business functions in scope for the target business architecture • Description of the business function view(s) • Definitions for the business functions (in table format) in scope for the target business architecture • Relevant views (diagrams) illustrating the organization structure and units in scope for the target business architecture • Description of the organization structure and units view(s) • Definitions for the organization structure and units (in table format) in scope for the target business architecture • Relevant views (diagrams) at the conceptual level illustrating the conceptual business services and their contracts (interactions) in scope for the target business architecture • Description of the conceptual- level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the conceptual business services (in table format) in scope for the target business architecture • Characteristics of the conceptual business services (in table format) in scope for the target business architecture • Descriptions of the contracts (interactions) between the conceptual business services (in table format) in scope for the target business architecture • If required, characteristics of the contracts (interactions) between the business services (in table format) in scope for the target business architecture • Relevant views (diagrams) at the logical level illustrating the business processes in scope for the target business architecture • Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the business processes (in table format) in scope for the target business architecture • Any relationships between the business function categories, business functions, business service categories, and business services that are in scope for the target business architecture • Any assumptions that have been used to define the target business architecture
Value
An agreed target architecture that can be approved by decision makers and consumed by implementors.
mandatory section
Yes
risk type
Cost
Time
Quality
Security
Stakeholder
Senior Leaders
Implementers
Risk Owners
Business Partners
Risk owner
Project Manager
Dependent Section
3. Architecture Requirements Specification

Contract/Measure Catalog

Mandatory
Yes
Security related?
Yes
The Contract/Measure catalog provides a listing of all agreed service contracts and the measures attached to those contracts. It forms the master list of service levels agreed to across the enterprise. The Contract/Measure catalog contains the following metamodel entities: Business Service Application Service (optionally) Contract Measure

Actor/Role Matrix

Mandatory
Yes
Security related?
Yes
The purpose of this matrix is to show which actors perform which roles, supporting definition of security and skills requirements. Understanding Actor-to-Role relationships is a key supporting tool in definition of training needs, user security settings, and organizational change management. The Actor/Role matrix shows the following metamodel entities and relationships: Actor Role Actor performs Role relationships

Process Flow Diagram

Mandatory
No
Security related?
Yes

The purpose of the Process Flow diagram is to depict all models and mappings related to the process metamodel entity.

Process Flow diagrams show sequential flow of control between activities and may utilize swim-lane techniques to represent ownership and realization of process steps. For example, the application that supports a process step may be shown as a swim-lane.

Organization/Actor Catalog

Mandatory
No
The purpose of the Organization/Actor catalog is to capture a definitive listing of all participants that interact with IT, including users and owners of IT systems. The Organization/Actor catalog can be referenced when developing requirements in order to test for completeness. For example, requirements for an application that services customers can be tested for completeness by verifying exactly which customer types need to be supported and whether there are any particular requirements or restrictions for user types. The Organization/Actor catalog contains the following metamodel

Business Interaction Matrix

Mandatory
No
The purpose of this matrix is to depict the relationship interactions between organizations and business functions across the enterprise. Understanding business interaction of an enterprise is important as it helps to highlight value chain and dependencies across organizations. The Business Interaction matrix shows the following metamodel entities and relationships: Organization Business Function Business Service Business Service communicates with Business Service relationships Business Service is dependent on Business Service relationships

Business Event Diagram

Mandatory
No
The purpose of the Business Event diagram is to depict the relationship between events and process. Certain events — such as arrival of certain information (e.g., customer submits sales order) or a certain point in time (e.g., end of fiscal quarter) — cause work and certain actions need to be undertaken within the business. These are often referred to as "business events" or simply "events" and are considered as triggers for a process. It is important to note that the event has to trigger a process and generate a business response or result.
Subscribe to 2.3.1 Business Architecture Models