TOGAF defines an enterprise as being a collection of organizations with a common set of goals. This shows just how important goals are within an enterprise; they are its reason for being. An enterprise has a history, which is translated notably by its organization, the locations where it is present, and its information system. An enterprise operates in one or several business domains, where its skill lies. The transformations required to guide the enterprise architecture are defined by the enterprise’s goals. Goals provide direction, the place we want to get to. As far as possible, all enterprise architecture tasks will refer to goals to define what the desired results or outcome are and hence to decide what must be done. Goals will justify the work to be done, the reorganizations to be carried out, the orientation of the activity toward businesses to be put in place, and the evolution of the IS to support everything by rationalizing choices.

Goals in phase A

Goals are often known before phase A. By deciding on the start of an ADM cycle, the preliminary phase has already identified goals. Goals are reworked in phase A, for example, by using the techniques described below, before being finalized in phase B. The development of business architecture in phase B identifies architecture elements that are recognized as being necessary, which also enables goals forgotten during phase A to be identified later.

Goals and objectives

TOGAF distinguishes between goals and objectives. An objective breaks down a goal in order to set a time-specific milestone which corresponds to the progress made with regard to the goal. Objectives set the targets for goals in order to monitor whether or not they are met. Goals are the “what,” in other words, the desired results, while objectives are the “how,” that is to say, the courses of action that will lead to goals being achieved.

For example,

• “increase the use of our transport capabilities by 30% by the end of next year” is an objective

• “be one of the global top five in our activity sector in 5 years” is a goal.

The definition of goals is particularly based on the estimation of the enterprise’s capacity to progress, as well as on how well business drivers are taken into account. Business drivers or influencers are conditions outside the enterprise and linked to the sector of activity, such as competitive constraints (reduction in costs, competitor growth, etc.) or legal constraints (bank capital, travel agency insurance, etc.). Goals are always center-stage when an ADM cycle is triggered. Prior definition of goals therefore exists, often in an informal form.

One of the first enterprise architecture activities during phase A consists in formalizing, structuring, hierarchically organizing, and rationalizing goals with the help of the techniques presented earlier. Goals are completed and clarified by driver analysis and knowledge of the business and the IS.

Identifying goals

Identifying and selecting goals and giving them a priority level are not easy tasks. The definition of goals is a discipline in itself.

TOGAF reminds us that an objective must be SMART:

• Specific, by determining what must be done in the business

• Measurable, by implementing clear metrics for success

• Attainable, by:

• Clearly breaking down the problem

• Providing the basis for determining elements and plans for the solution

• Realistic, by indicating deadlines and conditions that can be met by the enterprise’s capabilities within stipulated time and cost limitations

• Timely, by explicitly indicating when interest in the solution will disappear

An essential point is that architectural choices must be aligned with the organization’s business goals. By constantly referring to goals, everyone is faced with his or her responsibilities, only asking the IS for the most fundamental things, defining priorities, allocating the necessary budget where the stakes are high, and identifying who is responsible for which goal.

Assigning goals and objectives

Assigning responsibility is a key step in the finalization of goal definition, as it implies negotiation on the feasibility of goals and agreement between stakeholders. By designating who will be responsible for reaching an objective, negotiation must take place with the people responsible, which therefore leads to communication on and validation of the objective in question. Goals and objectives are by no means just a list of pious wishes, but rather strategic choices that will guide the future activity of the enterprise. Responsibility for each objective must therefore be assigned to a person who will be in charge of attaining it.

Most of the time, goals are corporate-level goals, in other words, goals are frequently assigned to the entire enterprise, while objectives are allocated more specifically to people. Where they are assigned to organization units or business processes, the responsible element is always clearly identified (the process owner, the organization unit manager).

Goal graph

Goals are constructed hierarchically. Goals constitute the roots of the goal/objective tree. For every high-level goal, the question, How can we reach this goal? is used to identify lower-level goals, which are generally objectives. Conversely, identifying a low-level objective leads to the question, Which objective or goal will this help us reach? Finally, for every breakdown of a high-level goal, it is useful to think about alternative breakdowns: Do any obstacles exist that will hinder the realization of current goals? What other paths can be envisaged to reach higher-level goals?

This breakdown continues until a set of elementary objectives has been identified, whose allocation is clear and whose feasibility is confirmed.

We will see that the goal diagrams presented here go beyond a simple breakdown hierarchy. Analysis of the goal graph also looks at consistency and conflicts between goals: some goals contradict others (negative influence) or reinforce them (positive influence).

For example, the goal of improving customer service, which requires more staff, is in conflict with the goal of reducing costs. This is not an absolute contradiction, but it does require analysis to determine the exact quantification required and the right balance between the two goals.

Defining priorities for goals

Objectives must be measurable. This enables us to check that they really have been attained. Measuring facilitates the quantification of the advantages expected for the business once the objective has been met. These advantages have to be weighed against the effort required to obtain them. Thus, if the objective is “We want to give a full and immediate response to clients placing orders over the telephone,” then we must ask ourselves what advantage this objective brings to the organization. If it is a question of increasing client satisfaction, then it is necessary to measure the increase in satisfaction. For the enterprise, this can have the advantage of generating consistently higher turnover, a better image, increased revenue, and so on.

Goal/objective determination comes up against priority definition, which leads to the postponement of certain goals/objectives and the promotion of others. A common technique consists in evaluating the importance of goals/objectives, as well as their accessibility (how difficult it is for the enterprise to attain them).

Figure 7.1 thus provides a more rational basis for assigning priorities to goals. This exercise can also be useful during phase E when analyzing opportunities and solutions. While it is easy to decide to retain “7,” “6,” and “4” (they are accessible and extremely important) and to defer “3” and “5” (they are not easily accessible and have limited importance), it will be more difficult to decide about goal “1,” which is important but difficult to attain.

Summary of best practices for defining goals

Define the following:

• Subgoals/objectives, by asking how a goal can or should be implemented.

• Supergoals, by asking why a goal is necessary or needed.

• Alternatives, by asking what different ways of satisfying the supergoal exist.

• Conflicting goals, by asking what goals may conflict with each other.

• Allocation/assignment to individual parts of the business.

• Means of measuring their fulfillment.

•  Goal

•  Hierarchical breakdown of goals

•  Indicates that the source goal will make it easier to attain the destination goal.

•  Indicates that the source goal will make it more difficult to attain the destination goal.

The goal diagram is an extension to TOGAF, which only provides the goal catalog. The goal diagram provides useful complementary information, notably through the different types of links represented.

Goal diagrams are used to summarize goals, represent them in the form of a hierarchy, and present the links that exist between goals and other model elements. Goals are situated at the top of the diagram, with the operational objectives that constitute them appearing lower down, via the “Part” link.

Goals are broken down hierarchically using the “part” link. Thus, in Figure 7.2, “Increase turnover and profits” is a strategic goal, which is broken down into operational objectives such as “Increase number of trips reserved per day,” which itself is broken down into “Increase sales presence,” “Optimize client transformation rate,” and “Render products more attractive.” Objectives orient the strategies used to achieve goals. They start to express what must be done. The “why” is expressed by the goals they break down. We can see that the “Reservation via the Internet” goal breaks down the “Increase sales presence” goal, since the capability of selling via the Internet is a new form of sales presence ensuring wide geographical coverage and availability. This goal has a positive influence on the “Optimize client transformation rate,” “Improve business process management,” and “Reduce file processing times” goals.

The existence of drivers imposes the creation of associated goals. This is the case for the “Reservation via the Internet” goal. In a competitive environment where most travel agencies provide access to their services on the Internet, the marketing management team can identify this capability as being a driver: providing this access modernizes the company image and contributes to increasing sales. This capability therefore has the status of a strategic goal, which conditions how the company is organized, notably for the marketing, sales, and accounts departments.

During phase A and then phase B (business architecture), goals are reworked in order to make sure that they meet SMART criteria as closely as possible. Thus, a goal such as “Improve business process management” can be called into question: it is nonspecific, difficult to measure and act upon, and has no time limit. No one within the enterprise will accept responsibility for this goal, and the monitoring of its realization will only be a vague, overall evaluation at the enterprise level. It is preferable to focus on more factual and operational goals, such as specific points on how to improve certain identified processes.

•  Requirement

•  Business process

•  Internal actor

•  Assignment of a goal to an element (actor, organization unit, business process).

•  Indicates that when this requirement is satisfied, the goal will be attained.

Figure 7.3 provides complementary information. Links assigning goals are represented (≪ assigned ≫). In the example in Figure 7.3, the “Optimize client transformation rate” goal is assigned to the “Sales director” internal actor, while the “Render products more attractive” goal is assigned to the “Marketing director” internal actor.

Requirements analysis often takes place by constructing tables such as Tables 7.4 and 7.5. Requirements have a name, a description, and a set of associated properties (which vary according to the enterprise approach). The benefit/cost/risk ratio produced by this example is used to decide on the priority level to be assigned to each requirement: the decision (target version) is therefore indicated in one of the properties of each requirement. The use of tables to support requirements analysis limits the ability to link requirements to goals, work items, test cases, and other artifacts and model elements of the EA and its lifecycle. Requirements should also be managed in the model repository.

Thus, a high risk on a requirement that is not particularly important will certainly lead to the assignment of lower priority to the requirement in question.

It is not easy to place a limit on the number of requirements formulated. The criteria and attributes presented above enable us to rationalize the process of defining priorities and choosing requirements to take into account. Finally, budgetary constraints will intervene to limit them.

Characteristics of a requirement

The definition of requirements in the ADM cycle was presented in Section 2.2.6. A requirement specifies a capability or a condition that must (or should) be provided by a system. A requirement can concern the enterprise in general, one of its processes, one of its functions or organization units (for example, “the sales department must manage order cancellations”), or the information system more specifically (for example, the nonfunctional requirements in Table 7.5). Requirements must be satisfied by the business architecture (meaning that business processes, business services, actors, and organization units must be defined or adapted to handle order cancellations), or by application and technology architectures (for example, we will see that the application architecture includes a “CreditCard” component to implement the “purchase automation” requirement). Requirements concerning the IS will then be sent to projects and will constitute their specifications.

Functional requirements present a complete description of the way in which the system will operate. They should enable actors (users or technical actors) to have a realistic image of the system and to see all aspects of its functioning, before its construction.

Using Table 7.5, nonfunctional requirements will primarily interest technical architects, who will use them to deduce the needs of the infrastructure. Security experts, operations managers, and system and network engineers are also concerned.

Properties that must be verified by a requirement

The “business book of knowledge” (BABoK)^a defines the properties that must be respected by the requirements in Table 7.6.

In practice, requirement analysis is an extremely difficult task. The following are some of the issues involved:

• Customers often don’t know the requirements.

• Analysts and designers need to have a thorough understanding of the essence of the requirements, and what it means to match them.

• Requirements are not stable between the time they were analyzed and the time the solution is delivered.

Good requirements management has to address these realities. This is why TOGAF puts them in the center of the ADM circle, and why requirements analysis is a continuous activity throughout the ADM.

Goals and requirements

Goals constitute one of the starting points for the development of requirements, and help make requirements clearer for stakeholders. Goals focus on the “why” (strategic questions) and the “what” (the results we want to achieve), whereas objectives clarify the “how” (operational questions), before using requirements to broach the question of the detailed functional and nonfunctional characteristics of the solutions that realize the strategies used to achieve the goals. Requirements introduce the “what” at the solution level (which developments to carry out, which system to put in place, etc.).

The breakdown of goals often helps identify initial requirements. Respecting these requirements will then help guarantee (using the “guarantee” link) that goals are reached (see Figure 7.4). Thus, when the “Trip reservation process automation” requirement on the IS is satisfied, this will facilitate the guarantee that the “Reduce file processing times” goal be reached.

It is not always easy to distinguish between goals and requirements. In the example mentioned in this section, we can see that the goal has a general scope, whereas the requirement appears as a solution to the goal.

Operational objectives are assigned (using the “assigned” link) to an actor, an organization unit, a business process, a business function, or a business service. They are never assigned to an IS component; this level of detail corresponds to requirements that can be satisfied (using the “satisfy” link) by an IS component.

Requirements are written like behavioral specifications rather than goals to be reached (the system will carry out…, access will be limited to…).

The requirement diagram presented here is based on the SysML^b standard.

•  Requirement

•  Goal

•  Interaction component

•  Use case

•  Breaks a requirement down into more elementary requirements.

•  Describes the manner in which a model element or a set of model elements can be used to refine a requirement.

•  Determines that a model element is used to satisfy a requirement by supporting the requested function or by responding to the formulated constraint. Very often an application component satisfies a requirement.

•  Defines the manner in which a test case (which can be a use case) verifies a requirement. For example, a use case can express test sequences, which check whether or not a requirement is satisfied.

Requirements can be presented in graphical form. Here, requirement modeling enables requirements to be positioned and several types of links to be defined between requirements and the rest of the model. Requirements often appear in architecture models, to remind us which requirements refer to which represented model elements. Matrices can be used instead of diagrams.

These links between requirements and the architecture model are used to measure:

• Whether or not each requirement is satisfied by at least a part of the system

• Whether or not at least one test case is planned for each requirement

• Which model elements satisfy no requirements

Thus, requirements are justified through their links to goals, and the model itself is justified through its links to requirements. Moreover, requirements enable us to closely monitor how well the model respects the specifications.

In Figure 7.5, the “IS access via website” requirement guarantees the “Reservation via the Internet” goal. It is satisfied by the “TripReservationSite” component, and will be verified by the “Reserve trip” and “Cancel trip” use cases.

Event diagrams present business events, but also and above all provide a macroscopic view of processes. They cover what is traditionally referred to as a “process map,” and can be implemented with several levels of detail. Three different views are presented here. The most macroscopic level is used to carry out general mapping of business processes (Figure 7.6); an intermediate level presents events, participants, and data linked to a group of processes (Figure 7.7); the most detailed level focuses on one given process and provides details on the process’ external environment.

•  Organization domain

•  Business process

Figure 7.6 presents organization domains (for example, “Marketing”) which structure processes (for example, “Define portfolio”). It provides a macroscopic view of processes that is useful when mapping them; in other words, when producing an inventory of processes that can then be organized.

The enterprise’s key business processes

Phase A and then business architecture must identify the key business processes linked to the enterprise transformation targeted by the ADM cycle. These key business processes must therefore be listed, classified, and their respective positions specified, while providing information on the context. These business processes will constitute determining reference elements for application architecture, which will have to provide services to support some of them. Their definition will be used for business governance, which will make sure that they run correctly, that results are efficiently produced, and that enterprise functioning rules are respected.

The event diagram provides an overview of processes and their connections to other processes and to other business architecture elements. The most general event diagram view, presented in Figure 7.6, is used to establish the business process map by classifying them (in business domains as shown in Figure 7.6) and by providing information on their context. This map will be completed by process files similar to those presented in Section 12.2.2.

Based on this business process map, business managers and analysts can define priorities with regard to processes that must be overhauled or optimized. They identify critical zones, think about processes impacted by new enterprise goals, and may begin more detailed studies of certain processes, which involve additional business process modeling and analysis work.

Business events and processes

Business events represent any event that can arise during the functioning of the enterprise and which necessitates management work on the part of the enterprise. A “request for information” from a client or a “cancellation” are examples of business events. Events can be of different types, for example:

• External events, initiated by an entity outside the enterprise (for example, “order from a client”).

• Temporal events, initiated by a time-linked condition (for example, “month end” or “fiscal year end”).

• Internal events, initiated within the enterprise (for example, “current stock level lower than stock renewal level”).

Most events require action to be taken within the enterprise, and this action will be described in business processes. When a business event occurs, this can also trigger a process that will produce a business result or response.

The “Event diagram” artifact (intermediate view)

•  Business event

•  Product

•  Business process

•  Internal actor

•  External actor

•  Link indicating a flow of data (input or output) on an active element (here, processes).

•  The origin actor is the initiator of the process.

•  The origin actor or organization unit participates in the running of the process.

•  The origin actor is the owner of the process.

Event diagrams provide an overview of processes, trigger events or sent events, participating actors, roles or organization units, and products received or sent. At this intermediate macroscopic level, there is no sequence between processes, even if we can see that products sent by a process can be reused by another process. This intermediate level of detail cannot be presented for all company processes in a single diagram. For reasons of size, several diagrams of this type must be created and then classified, for example, by process domain (identified in the map).

The event diagram, shown in Figure 7.7, presents support processes (see Section 12.2.4) linked to marketing and financial services and production processes linked to trip reservation. It associates trigger events or sent events to these processes, as well as input or output products.

It associates actors to these processes, actors who initiate or participate in processes, events that trigger or that are generated by processes and input or output products on processes.

The “Event diagram” artifact (view focused on a process)

•  Product

•  Goal

•  External actor

•  Internal actor

•  Business event

•  Organization unit

•  Business process

•  Function

•  Link expressing incoming and outgoing information between an event and a process, or between a product and a process. This kind of link exists between the “Order” product and the “Reserve trip” process, or between the “Order cancellation” event and the “Cancel order” process.

•  A “participates in” link from a role or organization unit to a process. Thus, the sales department and the administration department participate in the realization of the “Reserve trip” process.

•  An “initiator of” link from a role or organization unit to a process. Thus, the client is the initiator of the “Reserve trip” process.

•  An “owner of” link between an actor and a process. Every process must have an owner whose role is to guarantee the correct functioning of processes by supervising them and by applying corrective measures when they are run. Here, the sales director is the owner of the “Reserve trip” process.

Event diagrams can focus on a particular process in order to determine its context in greater detail. For a given process (here, “Reserve trip”), the actors and organization units that initiate or participate in the process will be expressed, as well as the owner of the process, the trigger events or events sent by the process, and the incoming/outgoing information flows. Goals assigned to the process also appear in this diagram. They are used to identify priority processes that must be modeled, as well as to orient modeling and planned improvements in performance, automation, better synchronization with information systems, and so on. Key performance indicators (KPIs) can be partially deduced from goals assigned to processes.

For reference purposes, TOGAF indicates the characteristic operational objectives that can be assigned to a process:

• Increase process production rate (for example, “Optimize trip reservation times”)

• Ensure consistent process production quality (for example, “Reduce reservation failure or error rates”)

• Obtain a foreseeable process execution cost

• Increase existing process reuse

• Reduce interprocess information provision times

Figure 7.8 focuses on a process and is a graphical view of the process file (see below).

Business process catalog

TOGAF defines the process/event/control/product catalog. This kind of catalog will be produced as a result of process mapping. Macroscopic diagrams (Figure 7.6) and intermediate diagrams (Figure 7.7) can be referenced in this catalog. In Table 7.7, we show the information resulting from identification. Qualification generally happens during phase B and provides other defined properties (frequency, complexity, etc.), as shown in Table 7.8.