Business modeling

The key purpose of the class diagram is to depict the relationships among the critical data entities (or classes) within the enterprise. This diagram is developed to clearly present these relationships and to help understand the lower-level data models for the enterprise. This is a class diagram, where the main notion is the "Business Entity".

The TOGAF class diagram as defined is situated at an early, conceptual stage. The highest level allows the essential business notions of enterprise to be represented, without being distracted by organizational or historical complexities specific to each organization. This conceptual level enables you to think about the business, in order to define an ideal organization with regard to this particular business. These entities will be used to define business processes (products handled by processes), and will be derived to define service application components, exchange data between services and repository data schemas.

Note : This diagram is at a high level of representation (conceptual). We are interested here in modeling the main business entities, their properties and relationships. The persistency model (typically for RDB) will be inferred later at the application layer.

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the

IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; in other words, services that encapsulate data and reside in an application, or services that reside in an application and access data encapsulated within the application.

Note: Data dissemination diagrams are a kind of architecture diagram, where data entities are connected to application components. First, drag & drop application components from the application architecture, and then drag and drop business entities, either within the application components to show their localization, or beside them, with dependency links.

The data lifecycle diagram is an essential part of managing business data throughout its lifecycle, from conception through disposal, within the constraints of the business process. The data is considered as an entity in its own right, detached from business processes and activities. Each change in state is represented in the diagram, which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified, thereby enabling more effective resource sharing to be achieved.

Defining the lifecycle of business entities enables better formalization of these business entities, as well as the determination of the steps that are essential to their management. This very simple state model will be a guide in the definition of business processes, since these processes will themselves have to respect the constraints defined for transitions between states: if a business entity has not passed through all its states within the business processes that handle it, then these are incomplete. If the business processes transgress the lifecyle of the business entities, then they are incorrect.

Note: Identify the possible states of the entity (for example, a document can be "underConstruction", "underRevision", "approved", and so on), and then define the possible transitions between each states. A state must be a stable data situation: when no action is executed on it, the data is always in one of the identified states.

The purpose of the data migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced and detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or can go into detail at individual application metadata element level.

Use the previous data model (which should be in a separate information domain), drag and drop previous and new entities, and use the "migrates" dependency to express how previous data is translated into new entities.

Note : Data migration can be expressed at conceptual, logical or physical level. Application communication diagrams can also be used to express data migration. The "migrate" dependency is the key element to formalize migration.

In this example, we see that several attributes from the previous data model have been promoted to "entities" in the new data model.These diagrams can quickly become cluttered by links, when they should be focused on the origin or destination business entities. An alternative is to use tables, as shown below:

We see that the new model is better structured, as it groups previously scattered information. It is normalized.

Data is considered as an asset to the enterprise and data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled. The purpose of the data security diagram is to depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in matrix form between two objects, or can be shown as a mapping. The diagram can also be used to demonstrate compliance with data privacy laws and other applicable regulations (HIPAA, SOX, etc). This diagram should also consider any trust implications where an enterprise’s partners or other parties may have access to the company’s systems, such as an outsourced situation where information may be managed by other people and may even be hosted in a different country.

Alternatively, tables can be created, as in the example below:

However, the links need to be created, since they can be used in any kind of diagram.

Drag and drop the data (business entities, data entities) you want to show, drag and drop roles or actors involved with these entities and express the access mode of each participant to each entity using and evaluating "flow" dependencies.

Note : Large diagrams can become hard to read. We recommend that one data security diagram be created per business entity and/or per participant (typically an actor). In particular, diagrams focused on actors and their missions can provide habilitation links. Diagrams may also focus on external access to the system, that is on which data the external actors can access.

A business footprint diagram describes the links between business goals, organizational units, business functions and services, and maps these functions to the technical components delivering the required capability.

A business footprint diagram provides clear traceability between a technical component and the business goal that it satisfies, whilst also demonstrating ownership of the services identified.

A business footprint diagram demonstrates only the key facts linking organization unit functions to delivery services, and is utilized as a communication platform for senior-level (CxO) stakeholders. It must be focused on the current business interest: depending on the focus, it can concentrate on one or several application components (that need evolution) or on one or more business functions.

Note : In the explorer, select the elements (goals, organization units, business functions, business services, applications components) that are being focused on and that should already be defined. Drag & drop them, and create "trace", "participates in", "supports" and "component realization" dependencies.

Elements used: "support" links between services or processes and functions, participation links between organization units and functions, traces between functions and goals.

The business service/information diagram shows the information needed to support one or more business services. The business service/information diagram shows what data is consumed or produced by a business service and may also show the source of information. The business service/information diagram shows an initial representation of the information present within the architecture and therefore forms a basis for elaboration and refinement within phase C (data architecture).

Drag and drop business services and business entities from the explorer, and draw "flow" dependencies between them to express inputs or outputs. Flow properties provide the means of specifying the input or output orientation.

Note : By using "flow" dependencies between business services and business entities, this diagram represents which kind of entity is used or produced by the services.

The purpose of the event diagram is to depict the relationship between events and process. Certain events, such as the arrival of certain information (for example, a customer submits a sales order) or a certain point in time (for example, the end of a 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.

Event diagrams provide an overview of processes, which helps in their mapping. Event diagrams present a general view of processes, trigger events, sent events, participating roles or organization units, as well as received or sent products. At this macroscopic level, there is no sequence between processes, even if we are able to see that the products sent by a process can be re-used by another process.

Note : Events are connected to processes through "flow" dependencies, roles can initiate or participate in processes, products can be connected to processes through "flow" dependencies.

The purpose of the functional decomposition diagram is to show on a single page the capabilities of an organization that are relevant to the consideration of an architecture. By examining the capabilities of an organization from a functional perspective, it is possible to quickly develop models of what the organization does without being dragged into an extended debate on how the organization does it. Once a basic functional decomposition diagram has been developed, it becomes possible to layer heat-maps on top of this diagram to show scope and decisions. For example, the capabilities to be implemented during the different phases of a change program.

This diagram can be enriched using links to other parts of the model, to indicate, for example, which application supports which function, which role uses which function, and so on.

Note : Dedicated dependencies can be used to enrich the model, for example to indicate which application components support which function, which role uses which function, and so on. Function decomposition can be expressed by "containment" (simply create a function in another function), or by using the "part" dependency.

The elements present in this diagram are essentially functions, which can be embedded or linked by "part" dependencies.

The purpose of a Goal/Objective/Service diagram is to define the ways in which a service contributes to the achievement of a business vision or strategy.

Services are associated with the drivers, goals, objectives, and measures that they support, allowing the enterprise to understand which services contribute

to similar aspects of business performance. The Goal/Objective/Service diagram also provides qualitative input on what constitutes high performance for a particular service.

Note : Drag & drop business services and goals, and define "trace" dependencies between services and goals where appropriate.