Class diagrams

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 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 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.

Main business entities of the DiscountTravel domain, and their relationships

business-entityBusiness Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc.).

business-entity-dev-formBusiness Entity (developed form): It also presents here one attribute, that is one property that the entity may have.

associationAssociation between two classes. An association has a name, and provide at each end the role name, and the cardinalities (possible number of occurrences) of related elements.

Data dissemination diagrams

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; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

In this model, data is localized either in a repository or in an entity application component

entity-componentEntity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

interaction-application-componentInteraction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

process-componentProcess application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

utility-componentUtility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

DataBaseApplicationComponent32Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

system-federationSystem federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

ApplicationApplication: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

business-entityBusiness Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

flow-linkData flow: Expresses that data (for example business entity) is input or output from a dynamic entity.

Data lifecyle diagrams

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.

Identify the possible states of the entity (for example, a document can be "underCreation", "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.

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.

Lifecycle of the "Order" business entity

stateState: represent one of the main stable situations of a business entity or a product.

transitionTransition: move from one state to another state due to an action on the owner entity.

Data migration diagrams

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 as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.

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

Migrate dependencies can be between business entities, or be more accurately defined at the "attribute" level

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 rapidly be cluttered by links, they should be focused on the origin or destination business entities. Tables can alternatively be used such in the table below:

Origin Migrates in
Element Nature Element Nature
transportation Class Travel Class
Hotel Class
Flight Class
Travel Class Travel Class
Travel.destination Attribute Destination Class
Travel.hotel Attribute Hotel Class
Reservation Class Roomreservation Class
Hotem Class


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

business-entityBusiness Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

business-entity-dev-formBusiness Entity (developed form): This also presents here one attribute, in other words, one property that the entity may have.

migrate-linkMigrates link: Migration of elements between two versions of the IS. Generally used between business entities or application components.

Data security diagrams

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.

Large diagrams can become hard to read. It is recommended that you create one data security diagram per business entity, and/or per participant (typically a role). In particular, diagrams focused on actors and their missions can provide habilitation links. Diagrams may also be focused on the external access to the system, that is on which data the external actors can access.

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

Client Individual trip Order Travel Bill
Marketing Agent CRUD
Billing person CRUD


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

This diagram expresses who has the right to access which data and with which rights

external-actor-32External Actor: Actor that is external to the enterprise.

internal-actor-32Internal actor: Actor which belongs to the enterprise

data-flow-crudFlow of data: There is one active element on one side (e.g. actor, process) and an element carrying data at the other side (entity, event, product). Habilitation can be expressed on these flows, expressing which access and rights on data the active element has.


Sign in to use the forum and be informed of the latest news.

Latest comments