Motivation Elements

Motivation elements are used to model the motivations, or reasons, that guide the design or change of an Enterprise Architecture.

Motivation Elements Metamodel

Motivation Elements Metamodel gives an overview of the motivation elements and their relationships.

fig Motivation Elements Metamodel
Figure 1. Motivation Elements Metamodel
This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Derivation of Relationships. The full specification of permitted relationships can be found in Relationships (Normative).

Stakeholder, Driver, and Assessment

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. A stakeholder can be an individual or a group of people, such as a project team, enterprise, or society. Drivers that are associated with a stakeholder are often called “concerns” of that stakeholder. Examples of such 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 Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, in order to respond in the best way.

Stakeholder

A stakeholder represents the role of an individual, team, or organization (or classes thereof) that represents their interests in the effects 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 Chief Executive Officer (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.

fig Stakeholder Notation
Figure 2. Stakeholder Notation

Driver

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 that are associated with a stakeholder are often called “concerns” of that stakeholder. Stakeholder concerns are defined in the TOGAF framework [4] as “an interest in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.” Examples of internal drivers are customer satisfaction and profitability. Drivers of change may also be external to the enterprise (e.g., economic changes or changing legislation) and need not have a stakeholder associated with them. The name of a driver should preferably be a noun.

fig Driver Notation
Figure 3. Driver Notation

Assessment

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.

fig Assessment Notation
Figure 4. Assessment Notation

Example

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

ex Stakeholder Driver and Assessment
Example 18: Stakeholder, Driver, and Assessment

Goal, Outcome, Principle, Requirement, and Constraint

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.

Goal

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.

fig Goal Notation
Figure 5. Goal Notation

Outcome

An outcome represents an end result, effect, or consequence of a certain state of affairs.

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. The distinction between goals and outcomes is important. Simply put, a goal is what you want, and an outcome is what you get. Outcomes are the end results, and goals or requirements are often related to outcomes that should be realized. Capabilities can be designed to achieve such outcomes.

However, not all outcomes relate to goals. When modeling a future state, an outcome models some result or effect that is expected to have been achieved or occur at that future point in time. Unlike goals, outcomes can also be used to model potentially unwanted effects; for example, in order to design appropriate mitigating measures.

Outcome names should unambiguously identify end results that have been achieved or are expected to be achieved at a definite point in the future. Examples include “First-place customer satisfaction ranking achieved” and “Key supplier partnerships in place”. Outcome names can also be more specific; e.g., “10% year-over-year quarterly profits increase in 2018”.

fig Outcome Notation
Figure 6. Outcome Notation

Principle

A principle represents a statement of intent defining a general property that applies to any system in a certain context in the architecture.

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.

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, whereas a requirement defines a property that applies to a specific system as described by an architecture. 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.

fig Principle Notation
Figure 7. Principle Notation

Requirement

A requirement represents a statement of need defining a property that applies to a specific system as described 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.

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, two alternative requirements may be identified to realize the goal “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.

fig Requirement Notation
Figure 8. Requirement Notation

Constraint

A constraint represents a limitation on aspects of the architecture, its implementation process, or its realization.

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

fig Constraint Notation
Figure 9. Constraint Notation

Example

The goal “Improve Profitability of Service Offering” is realized by the outcome “Increased Profit by 10% in Next Fiscal Year”. This outcome is influenced positively by the outcomes “Increased Revenue by 20% in Next Fiscal Year” and “Reduced Cost of Customer Acquisition by 25%”. The outcome “Increased Revenue by 20% in Next Fiscal Year” is influenced positively by an outcome “Increased Market Share by 10% in Next Fiscal Year”. There is also a negative outcome: “Increased Technology Expenditure by 10%”. 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 outcome “Reduced Cost Of Customer Acquisition by 25%” 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”.

ex Goal Outcome Principle Requirement and Constraint
Example 19: Goal, Outcome, Principle, Requirement, and Constraint

Meaning and Value

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

Meaning represents the knowledge or expertise present in, or the interpretation given to, a concept in a particular context.

A meaning represents the interpretation of a concept 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 concept. 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.

fig Meaning Notation
Figure 10. Meaning Notation

Value

Value represents the relative worth, utility, or importance of a concept.

Value represents the usefulness, advantage, benefit, desirability, or gain for a customer, stakeholder, or end user by, for example, selling a product, using a service, or completing some activity. 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 any concept. 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.

fig Value Notation
Figure 11. Value Notation

Example

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

ex Meaning and Value
Example 20: Meaning and Value

Summary of Motivation Elements

Motivation Elements gives an overview of the motivation elements, with their definitions.

Table 1. Motivation Elements
Element Definition Notation

Stakeholder

Represents the role of an individual, team, or organization (or classes thereof) that represents their interests in the effects of the architecture.

image
image

Driver

Represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them.

image
image

Assessment

Represents the result of an analysis of the state of affairs of the enterprise with respect to some driver.

image
image

Goal

Represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.

image
image

Outcome

Represents an end result, effect, or consequence of a certain state of affairs.

image
image

Principle

Represents a statement of intent defining a general property that applies to any system in a certain context in the architecture.

image
image

Requirement

Represents a statement of need defining a property that applies to a specific system as described by the architecture.

image
image

Constraint

Represents a limitation on aspects of the architecture, its implementation process, or its realization.

image
image

Meaning

Represents the knowledge or expertise present in, or the interpretation given to, a concept in a particular context.

image
image

Value

Represents the relative worth, utility, or importance of a concept.

image
image

Relationships with Core Elements

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 Relationships Between Motivation Elements and Core Elements, 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.

fig Relationships Between Motivation Elements and Core Elements
Figure 12. Relationships Between Motivation Elements and Core Elements

Additionally, a business internal active structure element (i.e., business actor, role, or collaboration) may be assigned to a stakeholder to express that someone with an operational position within the enterprise is also a stakeholder of that enterprise.