Figure 32 gives an overview of the motivation elements and their relationships.
Figure 32: Motivation Elements Metamodel
Note: This figure does not show all permitted relationships: every non-abstract motivation element can have aggregation, composition, and specialization relationships with elements of the same type.
Motivation elements are used to model the motivations, or reasons, that guide the design or change of an Enterprise Architecture.
It is essential to understand the factors, often referred to as drivers, which influence other motivation elements. They can originate from either inside or outside the enterprise. Internal drivers, also called concerns, are associated with stakeholders, which can be some individual human being or some group of human beings, such as a project team, enterprise, or society. Examples of such internal drivers are customer satisfaction, compliance to legislation, or profitability. It is common for enterprises to undertake an assessment of these drivers; e.g., using a SWOT analysis, in order to respond in the best way.
A stakeholder is the role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture.
This definition is based on the definition in the TOGAF framework [4]. A stakeholder has one or more interests in, or concerns about, the organization and its Enterprise Architecture. In order to direct efforts to these interests and concerns, stakeholders change, set, and emphasize goals. Stakeholders may also influence each other. Examples of stakeholders are the CEO, the board of directors, shareholders, customers, business and application architects, but also legislative authorities. The name of a stakeholder should preferably be a noun.
Figure 33: Stakeholder Notation
A driver represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.
Drivers may be internal, in which case they are usually associated with a stakeholder, and are often called “concerns”. Stakeholder concerns are defined in the TOGAF framework [4] as ”the key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Concerns may pertain to any aspect of the function, development, or operation of the system, including considerations such as performance, reliability, security, distribution, and evolvability.” Examples of internal drivers are Customer satisfaction and Profitability. Drivers of change may also be external; e.g., economic changes or changing legislation. The name of a driver should preferably be a noun.
Figure 34: Driver Notation
An assessment represents the result of an analysis of the state of affairs of the enterprise with respect to some driver.
An assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These need to be addressed by adjusting existing goals or setting new ones, which may trigger changes to the Enterprise Architecture.
Strengths and weaknesses are internal to the organization. Opportunities and threats are external to the organization. Weaknesses and threats can be considered as problems that need to be addressed by goals that “negate” the weaknesses and threats. Strengths and opportunities may be translated directly into goals. For example, the weakness “Customers complain about the helpdesk” can be addressed by defining the goal “Improve helpdesk”. Or, the opportunity “Customers favor insurances that can be managed online” can be addressed by the goal “Introduce online portfolio management”. The name of an assessment should preferably be a noun or a (very) short sentence.
Figure 35: Assessment Notation
The stakeholder Chief Marketing Officer (CMO) is concerned with the driver Market Share, the stakeholder Chief Executive Officer (CEO) is concerned with the drivers Market Share and Profitability, and the stakeholder Chief Financial Officer (CFO) is concerned with the driver Profitability. The driver Profitability is composed of two other drivers: Revenue and Costs. Several assessments are associated with these drivers (e.g., the assessment Market Share Is Declining is associated with driver Market Share), and assessments may influence each other in a positive or negative way (e.g., Market Share Is Declining results in Revenue Is Declining, which in turn results in Profitability Is Declining).
Example 18: Stakeholder, Driver, and Assessment
The motivation of an organization or individual to achieve certain results is represented by goals, principles, requirements, and constraints. Goals represent that a stakeholder wants to realize a certain outcome; e.g., “Increase customer satisfaction by 10%”. The end results realized by capabilities that realize these goals are outcomes. Principles and requirements represent desired properties of solutions – or means – to realize the goals. Principles are normative guidelines that guide the design of all possible solutions in a given context. For example, the principle “Data should be stored only once” represents a means to achieve the goal of “Data consistency” and applies to all possible designs of the organization’s architecture. Requirements represent formal statements of need, expressed by stakeholders, which must be met by the architecture or solutions. For example, the requirement “Use a single CRM system” conforms to the aforementioned principle by applying it to the current organization’s architecture in the context of the management of customer data.
A goal represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.
In principle, a goal can represent anything a stakeholder may desire, such as a state of affairs, or a produced value. Examples of goals are: to increase profit, to reduce waiting times at the helpdesk, or to introduce online portfolio management. Goals are typically used to measure success of an organization.
Goals are generally expressed using qualitative words; e.g., “increase”, “improve”, or “easier”. Goals can also be decomposed; e.g., Increase profit can be decomposed into the goals Reduce cost and Increase sales. However, it is also very common to associate concrete outcomes with goals, which can be used to describe both the quantitative and time-related results that are essential to describe the desired state, and when it should be achieved.
Figure 36: Goal Notation
An outcome represents an end result that has been achieved.
Outcomes are high-level, business-oriented results produced by capabilities of an organization, and by inference by the core elements of its architecture that realize these capabilities. Outcomes are tangible, possibly quantitative, and time-related, and can be associated with assessments. An outcome may have a different value for different stakeholders.
The notion of outcome is important in business outcome-driven approaches to Enterprise Architecture and in capability-based planning. Outcomes are closely related to requirements, goals, and other intentions. Outcomes are the end results, and goals or requirements are often formulated in terms of outcomes that should be realized. Capabilities are designed to achieve such outcomes.
Outcome names should unambiguously identify end results that have been achieved in order to avoid confusion with actions or goals. At a minimum, outcome names should consist of a noun identifying the end result followed by a past-tense verb or adjective indicating that the result has been achieved. Examples include “First-place ranking achieved” and “Key supplier partnerships in place”. Outcome names can also be more specific; e.g., “2015 quarterly profits rose 10% year over year beginning in Q3”.
Figure 37: Outcome Notation
A principle represents a qualitative statement of intent that should be met by the architecture.
Principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context. A requirement defines a property that applies to a specific system as described by an architecture.
A principle needs to be made specific for a given system by means of one or more requirements, in order to enforce that the system conforms to the principle. For example, the principle “Information management processes comply with all relevant laws, policies, and regulations” is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.
A principle is motivated by some goal or driver. For example, the aforementioned principle may be motivated by the goal to maintain a good reputation and/or the goal to avoid penalties. The principle provides a means to realize its motivating goal, which is generally formulated as a guideline. This guideline constrains the design of all systems in a given context by stating the general properties that are required from any system in this context to realize the goal. Principles are intended to be more stable than requirements in the sense that they do not change as quickly as requirements may do. Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.
Figure 38: Principle Notation
A requirement represents a statement of need that must be met by the architecture.
In the end, a business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system.
The term “system” is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again. Therefore, a system may refer to any active structural element, behavior element, or passive structural element of some organization, such as a business actor, application component, business process, application service, business object, or data object.
Requirements model the properties of these elements that are needed to achieve the “ends” that are modeled by the goals. In this respect, requirements represent the “means” to realize goals.
During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties that can be exhibited by systems. At this point, goals can be realized by requirements that demand these properties from the systems.
For example, one may identify two alternative requirements to realize the goal to improve portfolio management:
• By assigning a personal assistant to each customer, or
• By introducing online portfolio management
The former requirement can be realized by a human actor and the latter by a software application. These requirements can be decomposed further to define the requirements on the human actor and the software application in more detail.
Figure 39: Requirement Notation
A constraint represents a factor that prevents or obstructs the realization of goals.
In contrast to a requirement, a constraint does not prescribe some intended functionality of the system to be realized, but imposes a restriction on the way it operates or may be realized. This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), a restriction on the implementation process (e.g., time or budget constraints), or a restriction on the functioning of the system (e.g., legal constraints).
Figure 40: Constraint Notation
The goal Improve Profitability of Service Offering is realized by the outcome Increased Profit. This outcome is influenced positively by the outcomes Increased Revenue and Reduced Cost of Customer Acquisition. The outcome Increased Revenue is influenced positively by an outcome Increased Market Share. Both of these outcomes are realized by a combination of two principles: Serve Customers Wherever They Are and Serve Customers Whenever They Need Our Help. Both of these principles are realized by a combination of two requirements: Mobile Applications Shall Run On All Popular Mobile Platforms and Services Shall Be Accessible Through Mobile Browsers. The goal Reduced Cost Of Customer Acquisition is realized by a principle Respond To Changing Customer Needs, Preferences, And Expectations Quickly And Efficiently, which in turn is realized by a constraint Mobile Applications Shall Be Built With Cross-Platform Frameworks.
Example 19: Goal, Outcome, Principle, Requirement, and Constraint
Different stakeholders may attach a different value to outcomes, since they may have different interests. Similarly, they may give their own meaning or interpretation to core elements of the architecture.
Meaning represents the knowledge or expertise present in, or the interpretation given to, a core element in a particular context.
A meaning represents the interpretation of an element of the architecture. In particular, this is used to describe the meaning of passive structure elements (for example, a document, message). It is a description that expresses the intent of that element; i.e., how it informs the external user.
It is possible that different users view the informative functionality of an element differently. For example, what may be a “registration confirmation” for a client could be a “client mutation” for a CRM department (assuming for the sake of argument that it is modeled as an external user). Also, various different representations may carry essentially the same meaning. For example, various different documents (a web document, a filled-in paper form, a “client contact” report from the call center) may essentially carry the same meaning.
A meaning can be associated with any core element. To denote that a meaning is specific to a particular stakeholder, this stakeholder can also be associated to the meaning. The name of a meaning should preferably be a noun or noun phrase.
Figure 41: Meaning Notation
Value represents the relative worth, utility, or importance of a core element or an outcome.
Value may apply to what a party gets by selling or making available some product or service, or it may apply to what a party gets by buying or obtaining access to it. Value is often expressed in terms of money, but it has long since been recognized that non-monetary value is also essential to business; for example, practical/functional value (including the right to use a service), and the value of information or knowledge. Though value can hold internally for some system or organizational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship.
A value can be associated with all core elements of an architecture as well as with outcomes. To model the stakeholder for whom this value applies, this stakeholder can also be associated with that value. Although the name of a value can be expressed in many different ways (including amounts, objects), where the “functional” value of an architecture element is concerned it is recommended to try and express it as an action or state that can be performed or reached as a result of the corresponding element being available.
Figure 42: Value Notation
Sending push notifications has a value of Cost Efficiency for the stakeholder Insurer, and a value of Being Informed and Peace of Mind (which is partly due to a value of Certainty) for the stakeholder Customer. Different meanings can be assigned to the different specific types of notification messages. A Confirmation Of Receipt Message has the meaning Claim Has Been Received, a Review Complete Message has the meaning Claim Review Complete, and a Payment Complete Message has the meaning Claim Has Been Paid.
Example 20: Meaning and Value
Table 4 gives an overview of the motivation elements, with their definitions.
|
Definition |
Notation |
|
|
Stakeholder |
The role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture. |
|
|
Driver |
An external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them. |
|
|
Assessment |
The result of an analysis of the state of affairs of the enterprise with respect to some driver. |
|
|
Goal |
A high-level statement of intent, direction, or desired end state for an organization and its stakeholders. |
|
|
Outcome |
An end result that has been achieved. |
|
|
Principle |
A qualitative statement of intent that should be met by the architecture. |
|
|
Requirement |
A statement of need that must be met by the architecture. |
|
|
Constraint |
A factor that prevents or obstructs the realization of goals. |
|
|
Meaning |
The knowledge or expertise present in, or the interpretation given to, a core element in a particular context. |
|
|
Value |
The relative worth, utility, or importance of a core element or an outcome. |
|
The purpose of the motivation elements is to model the motivation behind the core elements in an Enterprise Architecture. Therefore, it should be possible to relate motivation elements to core elements.
As shown in Figure 43, a requirement (and, indirectly, also a principle, outcome, and goal) can be related directly to a structure or behavior element by means of a realization relationship. Also, the weaker influence relationship is allowed between these elements. Meaning and value can be associated with any structure or behavior element.
Figure 43: Relationships between Motivation Elements and Core Elements
Also, a business actor may be assigned to a stakeholder, which can be seen as a motivation role (as opposed to an operational business role) that an actor may fulfill.
Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Bookstore as document C179.
