Phase B is dedicated to defining business architecture (see the definition in Section 2.2.3). TOGAF defines a very rich set of artifacts related to phase B (Table 8.1). In particular, it focuses on the following elements:

• The organization of the enterprise, which will be described through its organization units, actors, and roles. Its geographical distribution (sites, location) will also be presented.

• The enterprise’s capabilities, which are described in greater detail through its functions and business services.

• The enterprise’s activities, represented by its business processes.

• The essential concepts of the business, through a business dictionary and conceptual models of business entities (Table 8.2).

• Business architecture will be optimally defined to satisfy the goals of the enterprise. Phase B participates in the definition and consolidation of goals, already presented in Section 7.3.

8.1.2 Essential concepts used in business architecture models

•  Function: Produces one of the enterprise’s capabilities. For example, “marketing,” “client contract management,” and “telemarketing” are functions.

•  Business service: Represents a service provided by the business. A business service can be realized by one or several IT services, or by other constituents of the enterprise.

•  Role

•  Location: Enterprise site.

•  Headquarters: A specific location, the company headquarters.

•  Organization units: Units that group the functions and capacities of the enterprise. They have resources (personnel, material), missions, and a certain degree of autonomy (for example, the sales department, the administration department).

•  Products, such as the trip or the order.

•  Business events.

•  Business process (for example, “Reserve Trip”).

•  Use case: Represents an interaction between actors and the system in order to meet a functional need.

•  Business entity: Describes the semantics of business entities, independently of any organizational or IS-related considerations (storage, technology, etc.).

•  Business entity (expanded form): Enables an entity’s attributes and operations (specific services operated by this entity) to be presented.

•  Association between classes: An association has a name, and provides each end with a role name and cardinality (number interval indicating the number of possible linked entity occurrences).

•  Information domain: Unit that structures business entities into coherent subdomains.

•  State: Represents one of the stable situations of a business entity or product.

Table 8.2 is a simplified example of a dictionary. According to different enterprise preferences, several attributes can be used to complete terms (lines in the table), such as an attribute indicating the origin of the term. Several types of links can also be used, such as synonym or homonym links. In this example, the dictionary clarifies what a “Trip” is; in this context, it is used as the definition of a trip such as those managed in the product range. However, the trip that a client actually takes is called a “holiday” here, and corresponds to an instance of a trip defined in the product range.

The terms of a dictionary can appear in different diagrams (Figure 8.1) in order to link model elements to the definitions to which they refer. In this figure, we can see class links to terms, as well as association and role links (UML) to terms.

•  Business entity

•  Business entity (developed form)

•  Traceability link

•  Dictionary term

8.2.2 Terminology: The cornerstone of business knowledge

Business knowledge requires clearly defined terminology. There is a normative need for the same meaning to be assigned to a given term by all participants, as well as a need to share knowledge by establishing a dictionary. A dictionary also aims to clarify synonyms, while limiting their number. Homonyms should be avoided in order to assign a single definition to each work, thereby avoiding confusion.

Businesses very often use norms linked to their domain, which provide an extremely useful initial dictionary. This dictionary then has to be completed by terms used within the enterprise itself. The difficulty of this task consists in finding consensus where the terms are not used in the same way by all participants. Terminological ambiguity is omnipresent within enterprises. Enterprise architecture models are then clouded by these ambiguities and unclear terminologies. Communication between participants and the quality of the results produced can be compromised. This confusion must therefore be resolved by defining a dictionary.

The existence of a dictionary is a significant asset when building an enterprise model; in particular, business entity and business process definition will make massive use of the information contained in the dictionary. For example, the dictionary contains concepts that are essential to the business, and which we also find in business entities.

The dictionary will essentially take the form of a catalog (name, definition). It can be structured into several domains, according to the range of the enterprise’s business. It is then up to analysts to decide if and how terms will subsequently be represented as more formal model elements, such as business entities. Terms can be formalized by one or several business entities, attributes, states, events, actors, and so on.

The integration of the dictionary into the model is used to manage traceability to the rest of the model. For example, the definition of a business entity can be linked to a dictionary term, thereby indicating its semantic and terminological reference.

Diagrams supporting enterprise organization modeling are used to establish the mapping of the organization. Roles within the enterprise are determined and positioned with regard to the organization and the different enterprise locations. Organization units, actors, roles, and locations are the key concepts used to represent the organization.

8.3.2 Actors and roles

TOGAF clearly distinguishes the two concepts of actor and role in an enterprise.

An actor is an active enterprise participant (person, system, organization) who takes part in the activities of the enterprise. For example, an “account manager” who carries out sales operations with clients is an enterprise actor. A “board of directors,” which makes decisions regarding the orientation of the enterprise is also an enterprise actor. An actor is never a physical person. It designates a category of function that participants can carry out, as well as a type of skill required. A physical person can represent several actors. This is typically the case in small to medium-sized companies, where the same person can, for example, be the “receptionist” and the “executive secretary,” or where the “sales director” can also assume the role of “marketing director.” An actor can designate a group of people (such as a “decision-making committee”) or any active entity participating in the functioning of the enterprise. In this way, it can also designate external organizations (a “partner”), or information or technical systems that play a particular role within the organization. An actor frequently designates several people who perform similar functions, such as the “account manager,” the “accountant,” and the “client.”

Identifying actors outside the enterprise helps clarify how these actors are positioned with regard to the organization: who interacts with them. They enable the enterprise to be represented as it is seen from the outside. The “client” or the “partner” are examples of typical external actors.

The role represents one of an actor’s usual or expected functions. Roles are often described as responsibilities. They establish accountability and are the foundation for enterprise governance. The role is the function that an actor performs in a particular situation. It corresponds to a certain skill domain of the actor and to the contribution the actor makes within the enterprise through the implementation of his or her skills, knowledge, experience, and capabilities. For example, a sales director performs the function of managing sales, as well as managing commercial resources. Several different actors can play identical roles. For example, the sales director, marketing director, and administrative director all play the role of managing the human resources for which they are responsible.

8.3.4 The “organization decomposition diagram—flows” artifact

•  External actor

•  Organization unit

•  Link showing the circulation of data between active enterprise entities (actors, organization units, etc.).

The tasks and responsibilities of actors and organization units can also be represented in terms of the information flows that circulate between them. This type of representation describes the information received, processed, or sent by each participant in the organization. Presenting the information handled by participants illustrates what they need to know to perform their responsibilities within the enterprise.

In Figure 8.4, the marketing department receives information on availability from agency partners. It sends the description of the trip portfolio to both clients and account managers. This diagram therefore presents the essential information flows that are in transition within the enterprise. These are received by or sent to actors or organization units. This example focuses on the flows sent or received by external actors and processed by the enterprise’s essential organization units. This type of diagram provides a very useful first glimpse of how the enterprise functions. Its generality means that it can be understood by everyone, while providing elements that facilitate the identification of business processes and managed business entities.

This model does not show how, when, or in what order flows are exchanged and gives no indication of the nature of the flows. Other models will have to provide this information.

The flows exchanged provide interesting information on the responsibilities of the entities involved in the exchanges. For example, the marketing department must provide the portfolio of available trips, while taking into account availability and partner product ranges. Figure 8.5 shows a diagram focused on an actor (Sales Director) that is a useful summary of the responsibilities, goals and connections of the actor. Skills can be added to get a complete actor definition.

8.3.5 The “organization decomposition diagram—role allocation” artifact

•  External role

•  Internal role

•  External actor

•  Internal actor

•  “Assumes” links indicating which role an actor plays.

Figure 8.3 shows which roles are played by which actors. As we can see, the account manager clarifies client expectations, sells products, and makes sales reports.

An actor plays a role in order to carry out a task in a business process. This is one of the usual or expected functions of an actor, or the part that someone or something plays in a particular situation.

Here, the “assumes” link shows which roles are played by which actors.

For example, a smaller enterprise can have the same roles as a larger enterprise in the same business, but these roles will be distributed across a smaller number of actors.

Information on which roles an actor can assume can be produced in detailed diagrams on actors (Figure 8.3) by adding “assumes” links. It can also be summarized in matrices.

8.3.6 The “location organization diagram” artifact

•  Locations: enterprise sites

•  Internal actor

•  Locations: enterprise headquarters

•  Deployed instance of an organization unit

•  Links determining the location of actors and roles, where this is not implicit.

TOGAF defines the location organization diagram as being the description of the links that exist between actors, roles, and locations within an organizational structure. Organizational mapping procures the executive manager and decision-maker chain of command within the organization. Although this type of diagram does not focus on goal modeling, it can also link goals to associated participants.

The example in Figure 8.6 represents locations and actors. The headquarters are in Paris, and there are three branches in Nantes, Toulouse, and Lyon. In this image, organization units are shown in specific locations to illustrate their deployment; the IT department is thus situated in Toulouse. These are not organization units themselves, but rather instances that appear in deployment locations. In this way, several occurrences of the same kind of organization unit can appear in different locations. Thus, the sales department is present in Toulouse, Paris, Nantes, and Lyon. We can see therefore that the majority of services are concentrated in Paris. The sales department is divided between each of the branches.

The same technique can be used to localize roles. As in Figure 8.6, we can also use the “location” dependency to represent this. However, the geographical location of roles is often implicit through their responsibility links (role to role or role to organization unit).

8.3.7 The “location diagram” artifact

•  Location: enterprise headquarters

•  Location: enterprise site

The location diagram can be used as an alternative to the TOGAF location catalog. Once established, location diagrams then enable us to represent the location of organization units and roles (phase B), and then in phase D to represent the geographical deployment of hardware and applications. Locations are used to take into account geographical constraints during the definition of enterprise architecture. Figure 8.7 shows that the headquarters of the company are in Paris, with three associated branches situated in Nantes, Toulouse, and Lyon.

Business architecture endeavors to identify the key business processes linked to the ADM cycle. It goes back to the process mapping initiated in phase A in order to complete it, notably by qualifying processes (see Section 12.2.2).

Based on business process maps, business managers and analysts can define priorities related to the processes that are to be revamped or optimized. They identify critical zones, consider processes impacted by new enterprise goals, and launch more detailed studies of certain processes, which involve additional business process analysis and modeling tasks.

Phase B updates and produces event diagrams (presented in Chapter 7 in phase A), which present an overview of processes by mapping them and by identifying contextual information (trigger events, participants, incoming and outgoing products) that will be used in process flow diagrams.

8.5.4 The “service/information diagram” artifact

The Service/Information diagram presents the information used to support one or several business services. This type of diagram defines which type of data is consumed or produced by a business service. It can also present the source of the information. It provides an initial representation of the information used within an architecture. In this way, it will provide a basis for detailing data architecture during phase C.

“Data flow” type links (flows) between business services and business entities represent which type of entity is used as input or produced as output by services.

•  Business entity

•  Business service

•  Data flow between data (business entity, event, product) and active elements of the system (business process, service).

8.5.5 The “business footprint diagram” artifact

•  Business service

•  Goal

•  Process component

•  Entity component

•  Function

•  Organization unit

•  Business process

•  Determines that a function, service, or process is supported by finer-grain business elements.

•  Determines that a participant participates in an enterprise activity or part of an enterprise activity.

•  General traceability link: The origin of the traceability link has its foundation in the destination of the link.

•  Realization by a component: Realizes an element identified at business level.

A business footprint diagram describes the links between business goals, organization units, business functions, and business services. These functions and services are also traced with technical components producing the required capabilities. By following these links, the business footprint diagram enables us to obtain traceability between a technical component and the business goals that it satisfies, while also revealing the owners and managers of the identified services.

A business footprint diagram is only interested in essential elements that show the connection between organization units and functions to produce services. It is used to communicate with the management of the enterprise.

Business footprint diagrams focus on the current concerns of the business. Depending on these concerns, they can concentrate on one or several application components requiring further development, as well as on one or several business functions. Thus, we select the goals that we judge to be the most important to the subject, and create or reuse application components, business functions, and business services that we trace to these goals. The diagram then defines what has to be worked on, enabling all participants to understand that a more detailed analysis for each architectural domain will develop these previously identified elements.

This type of diagram positions identified elements with regard to goals and traces them to each other using specialized dependencies.

TOGAF considers data architecture to be a subphase of phase C. However, data architecture also contributes to phase B, notably where business entities are handled (Figure 8.13).

Three different views are presented here, showing specific levels of detail. At the highest level, we find the information domain diagram (Figure 8.14), which presents the structuring of entities into different domains. Next, Figure 8.15 presents the main business entities that appear in “undeveloped” form, in other words, without showing details on their attributes and properties. Finally, Figure 8.16 presents the most detailed view of entities, where these are developed and their attributes defined.

Using conceptual data diagrams

A pertinent conceptual data model is a legacy of knowledge upon which many enterprise architecture models can be based:

• Data models obviously derive from the conceptual data diagram.

• Service data diagrams will be based on this model.

• “Entity” application components² will be derived from the most important key business entities of this model, as well as their access interfaces.

• Business processes can share the definition of their information flows or products exchanged with the business entities defined in conceptual data diagrams.

The use of a modeling tool based on a central repository provides great consistency to all diagrams, some of whose model elements are shared and others derived (Figure 8.17).

8.6.2 The “product lifecycle diagram” artifact

The product lifecycle diagram defines the main states of a given entity, and the possible transitions between these states. In this way, it presents the possible changes in state for an entity. This entity is considered as being an autonomous element that reacts to the operations and processing that can be applied to it, independently of the definition of the business processes and applications that can use it.

Each change in state is represented in the diagram. These can include events, conditions, or rules that provoke transitions between states. Product lifecycle diagrams then constrain the business process involving these entities, forcing them to respect defined transitions.

Several processes can act on identical entities: the definition of rules at entity level enables them to be shared at a higher level.

To identify states, we must imagine the different “stable” situations in which an entity can find itself, in other words, the situations where the entity does not undergo any transformation or processing. For example, a document can be in the following states: “created,” “under review,” “approved,” and so on. Next, the possible transitions between these states must be defined. For example, it is not possible to pass directly from the “created” state to the “approved” state, and the logical transition goes from “created” to “under review.” When an entity is not undergoing any processing, it is in a defined state.

Defining the business entity lifecycle ensures better formalization of entities and provides an indication of the stages that are essential to their management. This state model can be linked to the process model. Thus, the BPMN diagram can show that an entity is in a specific state at certain stages of the process.

•  State

•  Transition: Describes the change in state from an original state to a destination state, following an operation being carried out on the entity, a particular condition being met, or an event occurring.