In the world of TOGAF, all architectural ideas can be represented by the following three types of graphics.
- Catalogs
- Matrix
- Diagram
The essence of its architecture diagram is to communicate with the business team through the architecture diagram; to communicate with the architect through the architecture diagram, and to communicate with the development and testing team through the architecture diagram. Worth a thousand words. The above three types actually correspond to the three-dimensional geometric physical space. The directory is a list, so it is a one-dimensional expression space; the matrix is a table and a two-dimensional expression space. There are various forms of graphs, but they are actually two-dimensional. The extension allows it to express three-dimensional ideas and even more architectural ideas.
Closer to home, then in the business architecture, are there any best practices or routines that allow us to use some standard diagrams to describe the architecture? In fact, there are many, such as the following types:
-
Organization/Actor catalog [Organization/Actor catalog]
A clear list of all actors who interact with information technology, including users and owners of information technology systems. It contains the following metamodel entities. Organizational unit, actor location (may be included in this directory if no separate location directory is maintained). -
Driver/Goal/Objective catalog [Driver/Goal/Objective catalog]
A cross-organizational reference of how an organization achieves its actual drivers through goals, objectives and (optional) measures. It contains the following metamodel entities: Organizational Unit, Driver, Goal, Purpose, Purpose, Measure (optionally included). -
Role catalog [Role catalog]
The purpose of the role catalog is to provide a list of all authorization levels or areas within an enterprise. Often, an application's security or behavior is defined in terms of locally understood authorization concepts that combine on the user's desktop to have complex and unintended consequences. It contains the following metamodel entities: Role -
Business Service/Function catalog [Business Service/Function catalog]
function decomposition diagram is a function decomposition form that can be filtered, reported and queried, and is a supplement to the graphical function decomposition diagram.
It contains the following metamodel entities. Organizational Units, Business Functions, Business Services, Information System Services (optionally included here). -
Location catalog [Location catalog]
A list of all locations where an enterprise conducts business operations or houses infrastructure-related assets such as data centers or end-user computing equipment.
It contains the following metamodel entities, Location -
Process/Event/Control/Product catalog [Process/Event/Control/Product catalog] Process/Event/Control
/Product catalog provides a hierarchy of processes, events that trigger processes, outputs of processes, and controls applied to process execution. The catalog provides a complement to any flowchart created and allows businesses to filter, report and query across organizations and processes to identify scope, commonalities or impact. It contains the following metamodel entities. process, event, control, product -
The Contract/Measure catalog
lists all agreed service contracts and (optionally) the measures attached to those contracts. It forms the master list of agreed service levels across the enterprise. It contains the following metamodel entities: Business Service, Information System Service (optional), Contract, Measure -
Business Interaction Matrix [Business Interaction matrix]
The purpose of this matrix is to describe the interactive relationship between the organization and the business functions within the enterprise. -
Actor/Role matrix [Actor/Role matrix]
This matrix shows which actors play which roles, supporting security definitions and skill requirements. -
A business footprint diagram (similar to a chain of pain) [Business Footprint diagram]
describes the linkages between business goals, organizational units, business functions, and services, and links these functions to the technical components that provide the required capabilities. Present only the key facts between organizational unit functions and delivered services, and serve as a communication platform for top-level (CxO) stakeholders. -
A business service/information diagram (similar to a data flow diagram) [Business Service/Information diagram]
shows the information needed to support one or more business services. Shows the data consumed or produced by the business service, and optionally the source of the information. Shows the initial representation of the information present in the schema and thus forms the basis for elaboration and refinement in Phase C (Data Schema) -
Functional Decomposition Diagram (similar to a level 1 flowchart, describing the organizations involved in the process) [Functional Decomposition diagram]
It shows on a single page an organization's capabilities, which relate to architectural considerations. By examining an organization's capabilities from a functional perspective, it is possible to quickly model what the organization does without being dragged into lengthy debates about how the organization does it. -
Product Lifecycle Diagram [Product Lifecycle diagram]
This helps to understand the life cycle of key entities within the enterprise.
When it comes to environmental issues, legislation and regulations, understanding the life cycle of products is becoming increasingly important as products must be tracked from production to disposal. Likewise, in the process of developing a business architecture, organizations creating products that involve personal or sensitive information must have a detailed understanding of the product life cycle to ensure rigor in controls, process and program design. Examples of this include credit cards, debit cards, debit cards, store/loyalty cards, smart cards, user credentials (ID card, passport, etc.). -
Goal/Objective/Service Diagram (similar to a Goal Decomposition Tree) [Goal/Objective/Service diagram]
This defines how a service contributes to achieving the corporate vision or strategy.
Services are linked to the drivers, goals, objectives, and measures they support, enabling businesses to understand which services contribute to similar aspects of business performance. This also provides a qualitative input for high performance of specific services. -
Use Case Diagram [Business Use-Case diagram]
This shows the relationship between consumers and providers of business services.
Business services are consumed by actors or other business services, and business use case diagrams provide richer content for describing business capabilities by illustrating how and when the capability is used. They help describe and verify the interactions between actors and their roles on processes and functions. As the architecture evolves, use cases can evolve from the business level to include data, application and technical details. Architecting business use cases can also be reused in system design efforts. -
Organization Decomposition Diagram (similar to an organization chart, with descriptions of roles and positions) [Organization Decomposition diagram]
This describes the links between actors, roles and positions in the organizational tree. An organizational map should provide the chain of command for owners and decision makers in the organization. -
Flowchart [Process Flow diagram]
This describes all models and mappings related to process metamodel entities.
It shows the sequential flow of control between activities and can leverage swimlane technology to represent the ownership and implementation of process steps.
In addition to showing the sequence of activities, process flow can be used to detail the controls applicable to the process, the events that trigger or complete the process, and the products resulting from the execution of the process. -
Event diagram [Event diagram]
This depicts the relationship between events and processes. Certain events—such as the arrival of information (such as a customer's sales order) or a certain point in time (such as the end of a fiscal quarter) lead to work and actions within the enterprise.
In summary, TOGAF (The Open Group Architecture Framework) is an enterprise architecture framework used to guide organizations in planning, design, implementation and management in achieving their business goals. TOGAF defines a set of good practices and specifications for describing enterprise architectures, including business architecture diagrams.
-
TOGAF Business Architecture Diagram is used to describe the business structure of an enterprise, including business processes, functions and organizational structure. According to the definition of the TOGAF framework, business architecture diagrams can be divided into the following categories:
-
Capability Map (Capability Map): Describes the enterprise's capability structure and business processes, as well as the relationships and dependencies between them. Capability architecture diagrams typically include elements such as organizational units, business processes, functions, and skills.
-
Value Stream Map (Value Stream Map): Describes the enterprise's value processes and their relationship to customer needs. Value stream architecture diagrams usually include elements such as value processes, customer needs, business activities, and services.
-
Business Scenario Diagram: Describes the activities, roles, resources and other elements of an enterprise in a specific business scenario. Business scenario architecture diagrams are often used to illustrate an enterprise's business goals and strategies, and an action plan to achieve those goals and strategies.
-
Organization Map: Describes the organizational structure and functions of an enterprise, as well as the relationships and dependencies between them. An organizational chart typically includes elements such as organizational units, roles, and functions.
-
Business Information Architecture Diagram (Business Information Diagram): Describes the business information structure and process of an enterprise, as well as the relationships and dependencies between them. A business information architecture diagram usually includes elements such as business information objects, business processes, and data storage.
It should be noted that the TOGAF framework emphasizes the comprehensiveness and consistency of enterprise architecture, so these business architecture diagrams are usually interrelated and interdependent, and need to be considered and used comprehensively.