Figure 61 shows the metamodel of motivational concepts. It includes the actual motivations or intentions – i.e., goals, principles, requirements, and constraints – and the sources of these intentions; i.e., stakeholders, drivers, and assessments.
Motivational elements are related to the core elements via the requirement or constraint concept.
Figure 61: Motivation Extension Metamodel
Note: This figure does not show all permitted relationships: every non-abstract element in the Motivation extension can have aggregation and specialization relationships with elements of the same type.
Motivational concepts are used to model the motivations, or reasons, that underlie the design or change of some enterprise architecture. These motivations influence, guide, and constrain the design.
It is essential to understand the factors, often referred to as drivers, which influence the motivational 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.
The actual motivations are represented by goals, principles, requirements, and constraints. Goals represent some desired result – or end – that a stakeholder wants to achieve; e.g., increasing customer satisfaction by 10%. 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 stakeholder is defined as the role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.
This definition is based on the definition in TOGAF [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. 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 62: Stakeholder Notation
Example
The model below illustrates the modeling of stakeholders. Two main stakeholders are modeled: the Board of ArchiSurance and Customer. The Board is composed of three other stakeholders: the CIO, the CEO, and the CFO.
Example 47: Stakeholder
A driver is defined as something that creates, motivates, and fuels the change in an organization.
Drivers may be internal, in which case they are usually associated with a stakeholder. Examples of internal drivers (or “concerns”) are “Customer satisfaction”, “Compliance to legislation”, 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 63: Driver Notation
Example
The model below illustrates the modeling of internal and external drivers of change. Stakeholders CEO and Customer share a common concern Customer satisfaction, which is an internal driver of change. The stakeholder CEO also has the satisfaction of the company’s shareholders as a concern. This driver can be decomposed into two sub-drivers: Profit and Stock value. In addition to these internal drivers, there is an external driver Economic changes, which influences the stock value.
Example 48: Driver
An assessment is defined as the outcome of some analysis of some driver.
An assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These outcomes 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 on-line” can be addressed by the goal “introduce on-line portfolio management”. The name of an assessment should preferably be a noun or a (very) short sentence.
Figure 64: Assessment Notation
Example
The model below describes the assessments of driver Customer satisfaction and the sub-concern Helpdesk support. In this case, all assessments represent weaknesses. Concerning Customer satisfaction in general, customers complain and even leave ArchiSurance. The assessment Complaining customers is further detailed and divided into four complaints: the lack of insight into the status of a claim, the inconvenient way of submitting claims, the lack of insight into the customer’s portfolio, and the inconsistency and incompleteness of customer information. Concerning Helpdesk support in particular, customers experience long waiting queues and high service times.
Example 49: Assessment
A goal is defined as an end state that a stakeholder intends to achieve.
In principle, an end 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 on-line portfolio management.
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 objectives with goals, which can be used to describe both the quantitative and time-related measures which are essential to describe the desired state, and when it should be achieved.
Figure 65: Goal Notation
Example
The model below illustrates the modeling of goals to address the assessments of the driver Costs: the applications costs and the costs of employees are too high. The former assessment is addressed by the goals Reduce maintenance costs and Reduce direct application costs (of usage). The latter assessment is addressed by the goal Reduce workload employees, which is decomposed into Reduce manual work and Reduce interaction with customer.
Example 50: Goal
A requirement is defined as a statement of need that must be realized by a system.
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, behavioral 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 assign these properties to the systems.
For example, one may identify two alternative requirements to realize the goal to improve portfolio management: (i) by assigning a personal assistant to each customer, or (ii) by introducing on-line 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 66: Requirement Notation
Example
The model below illustrates the decomposition of goals towards requirements. The goals Facilitate self-service and Make customer interaction more effective result from the successive decomposition of the goals Reduce workload employees and Reduce interaction with customer. The goal Facilitate self-service can be realized by the alternative requirements Provide on-line portfolio service and Provide on-line information service. Both requirements are realized by some software application. In addition, the requirement Provide on-line portfolio service may realize the goal Improve portfolio management. Alternatively, this goal can be realized by assigning a personal assistant to each customer.
Example 51: Requirement
A constraint is defined as a restriction on the way in which a system is realized.
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 in which the system may be realized. This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), or a restriction on the implementation process (e.g., time or budget constraints).
Figure 67: Constraint Notation
Example
For the realization of a new portfolio management application, two constraints are imposed, as shown in the model below: for the realization of the application, Java should be used, and the budget of the implementation project is limited to 500k Euro.
Example 52: Constraint
A principle is defined as a normative property of all systems in a given context, or the way in which they are realized.
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.
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. 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 68: Principle Notation
Example
The model below illustrates the use of principles. Principle Systems should be customer facing is modeled as a means to realize the goals Reduce interaction with customer and Reduce manual work. The principle is further specialized into the requirements Provide on-line portfolio service and Provide on-line information service to apply the principle to the actual systems (architecture) under design.
Example 53: Principle
Table 26 gives an overview of the motivational concepts, with their definitions.
Table 26: Motivational Concepts
|
Concept |
Definition |
Notation |
|
Stakeholder |
The role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture. |
|
|
Driver |
Something that creates, motivates, and fuels the change in an organization. |
|
|
Assessment |
The outcome of some analysis of some driver. |
|
|
Goal |
An end state that a stakeholder intends to achieve. |
|
|
Requirement |
A statement of need that must be realized by a system. |
|
|
Constraint |
A restriction on the way in which a system is realized. |
|
|
Principle |
A normative property of all systems in a given context, or the way in which they are realized. |
|
The metamodels and examples from the previous sections show the different types of relationships that can be used between two motivational elements and between one motivational element and one core element. This section provides a more precise description of these relationships.
The association relationship models that some intention is related to a source of that intention.
The association relationship is used, for example, to model that a stakeholder has certain drivers, that an assessment is related to a driver, or that a goal is based on an assessment.
Figure 69: Association Notation
Example
The model below shows that Costs are a concern of the CFO, that Application costs are too high, and that the organization wants to Reduce maintenance costs and Reduce direct application costs.
Example 54: Association Example for the Motivation Extension
The aggregation relationship models that some intention is divided into multiple intentions.
The aggregation relationship is generally used to describe an intention in more detail by decomposing the intention into multiple, more concrete intentions.
Figure 70: Aggregation Notation
Alternatively, an aggregation can be expressed by nesting the model elements.
Example
The models below show the two ways to express the decomposition of goal Reduce workload employees into the sub goals Reduce interaction with customer and Reduce manual work.
Example 55: Aggregation (Decomposition)
The realization relationship models that some end is realized by some means.
The realization relationship is used to represent the following means-end relationships:
1. A goal (the end) is realized by a principle, constraint, or requirement (the means).
2. A principle (the end) is realized by a constraint or requirement (the means).
3. A requirement (the end) is realized by a system (the means), which can be represented by an active structure element, a behavior element, or a passive structure element.
Figure 71: Realization Notation
Example
The model below illustrates several ways to use the realization relationship. Principle Systems should be customer facing is a means to realize the goal Reduce interaction with customer. Requirement Provide on-line portfolio service is a means to realize sub-goal Facilitate self-service, and to realize the principle Systems should be customer facing. And this requirement can be realized by the business service On-line portfolio service.
Example 56: Realization (Means-End)
The influence relationship models that some motivational element has a positive or negative influence on another motivational element.
The influence relationship is used to describe that some motivational element may influence (the realization of) another motivational element. In general, a motivational element is realized to a certain degree. An influence by some other motivational element may affect this degree positively or negatively, depending on the degree in which this other motivational element is satisfied itself. For example, the degree in which the goal to increase customer satisfaction is realized may be represented by the percentage of satisfied customers that participate in a market interview. This percentage may be influenced positively by, for example, the goal to improve the company’s reputation; i.e., a higher degree of improvement results in a higher increase in customer satisfaction. On the other hand, the goal to lay off employees may influence the company’s reputation negatively; i.e., more lay-offs could result in a lower increase (or even decrease) in the company’s reputation. And thus (indirectly), the goal to increase customer satisfaction may also be influenced negatively.
A positive influence relationship does not imply that the realization of the influenced motivational element depends on the contributing intention. The necessary means to realize some motivational element are modeled using the realization relationship.
A negative influence relationship does not imply that the realization of the influenced motivational element is completely excluded by the contributing motivational element.
The influence relationship re-uses the notation of the flow relationship, signifying a “flow of influence”. An attribute can be used to indicate the direction and strength of the influence. The choice of possible attribute values is left to the modeler; e.g., {++, +, 0, -, --} or [0..10].[4]
Figure 72: Influence Notation
Example
The model below illustrates the use of the influence relationship for making a trade-off between the two requirements that realize the goal Improve portfolio management. The goal Increase customer satisfaction and the principle Systems should be customer facing are used as trade-off criteria. Both requirements positively influence the intended increase of customer satisfaction. The requirement of using a personal assistant scores a little better for this criterion. However, the requirement scores a lot worse for the customer-facing criterion.
The positive score of the requirement Provide on-line portfolio service for the customer-facing principle is consistent with the description of the requirement realizing the principle in an earlier example.
Example 57: Influence
Table 27 gives an overview of the relationships, with their definition, that involve one or more intentional concepts.
Table 27: Relationships
|
Intentional Relationships |
Notation |
|
|
Association |
Association models that some intention is related to a source of that intention. |
|
|
Aggregation |
Aggregation models that some intentional element is divided into multiple intentional elements. |
|
|
Realization |
Realization models that some end is realized by some means. |
|
|
Influence |
Influence models that some motivational element has a positive or negative influence on the realization of another motivational element. |
|
The purpose of the motivation extension is to model the motivation behind the core elements in some enterprise architecture. Therefore, it should be possible to relate motivational elements to core elements.
As shown in Figure 73, a requirement or constraint can be related directly to a core element by means of a realization relationship. Other motivational elements cannot be related directly to core elements, but only indirectly by means of derived relationships via requirements or constraints.
Figure 73: Relationships between Motivation Extension and the ArchiMate Core Concepts
Also, a business actor may be assigned to a stakeholder, which can be seen as a motivational role (as opposed to an operational business role) that an actor may fulfill.
A number of standard viewpoints for modeling motivational aspects have been defined. Each of these viewpoints presents a different perspective on modeling the motivation that underlies some enterprise architecture and allows a modeler to focus on certain aspects. Therefore, each viewpoint considers only a selection of the concepts and relationships that have been described in the preceding sections.
The following viewpoints are distinguished:
• The stakeholder viewpoint, which focuses on modeling the stakeholders, drivers, the assessments of these drivers, and the initial goals to address these drivers and assessments
• The goal realization viewpoint, which focuses on refining the initial, high-level goals into more concrete (sub-)goals using the aggregation relationship, and finally into requirements and constraints using the realization relationship
• The goal contribution viewpoint, which focuses on modeling and analyzing the influence relationships between goals (and requirements)
• The principles viewpoint, which focuses on modeling the relevant principles and the goals that motivate these principles
• The requirements realization viewpoint, which focuses on modeling the realization of requirements and constraints by means of core elements, such as actors, services, processes, application components, etc.
• The motivation viewpoint, which covers the entire motivational aspect and allows one to use all motivational elements
All viewpoints are separately described below. For each viewpoint the comprised concepts and relationships, the guidelines for the viewpoint use, and the goal and target group and of the viewpoint are indicated. Furthermore, each viewpoint description contains example models. For more details on the goal and use of viewpoints, refer to [2], Chapter 8.
The stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.
Table 28: Stakeholder Viewpoint Description
|
Stakeholder Viewpoint |
||
|
Stakeholders |
Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture mission and strategy, motivation |
|
|
Purpose |
Designing, deciding, informing |
|
|
Abstraction Level |
Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more concrete goals, and the refinement of concrete goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.
In addition, the principles may be modeled that guide the refinement of goals into requirements.
Table 29: Goal Realization Viewpoint Description
|
Goal Realization Viewpoint |
||
|
Stakeholders |
Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture mission, strategy and tactics, motivation |
|
|
Purpose |
Designing, deciding |
|
|
Abstraction Level |
Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
The goal contribution viewpoint allows a designer or analyst to model the influence relationships between goals and requirements. The resulting views can be used to analyze the impact that goals have on each other or to detect conflicts between stakeholder goals.
Typically, this viewpoint may be used after goals have, to some extent, been refined into sub-goals and, possibly, into requirements. Therefore, aggregation and realization relationships may also be shown in this viewpoint.
Table 30: Goal Contribution Description
|
Goal Contribution Viewpoint |
||
|
Stakeholders |
Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture mission, strategy and tactics, motivation |
|
|
Purpose |
Designing, deciding |
|
|
Abstraction Level |
Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
The principles viewpoint allows the analyst or designer to model the principles that are relevant to the design problem at hand, including the goals that motivate these principles. In addition, relationships between principles, and their goals, can be modeled. For example, principles may influence each other positively or negatively.
Table 31: Principles Viewpoint Description
|
Principles Viewpoint |
||
|
Stakeholders |
Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture mission and strategy, motivation |
|
|
Purpose |
Designing, deciding, informing |
|
|
Abstraction Level |
Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
The requirements realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.
In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.
Table 32: Requirements Realization Viewpoint Description
|
Requirements Realization Viewpoint |
||
|
Stakeholders |
Enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture strategy and tactics, motivation |
|
|
Purpose |
Designing, deciding, informing |
|
|
Abstraction Level |
Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
The motivation viewpoint allows the designer or analyst to model the motivation aspect, without focusing on certain elements within this aspect. For example, this viewpoint can be used to present a complete or partial overview of the motivation aspect by relating stakeholders, their primary goals, the principles that are applied, and the main requirements on services, processes, applications, and objects.
Table 33: Motivation Viewpoint Description
|
Motivation Viewpoint |
||
|
Stakeholders |
Enterprise and ICT architects, business analysts, requirements managers |
|
|
Concerns |
Architecture strategy and tactics, motivation |
|
|
Purpose |
Designing, deciding, informing |
|
|
Abstraction Level |
Overview, Coherence, Details |
|
|
Layer |
Business, Application, and Technology layers |
|
|
Aspects |
Motivation |
|
Concepts and Relationships
Example
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C13L.
