As mentioned in Part I, the metamodel of motivational is an extension in ArchiMate as shown in the Figure below that includes two kind of motivational concepts: 1) Source of Intentions 2) Motivation
There are four motivation elements: 1) Goal, 2) Principle, 3) Requirement, and 4) Constraint
Goal
A goal is defined as an end state that a stakeholder intends to achieve. Goals are generally expressed using qualitative words:
- Increase
- Improve
- Easier
In principle, a goal can represent anything a stakeholder may desire, such as:
- a state of affairs
- a produced value.
Examples of goals are:
- Increase profit
- Reduce waiting times at the helpdesk
- Introduce on-line portfolio management
Note That:
- 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
- Essentially, goals should able to be described their desired state, and when they should be achieved.
Example – Goal Concept
The ArchiMate diagram below illustrates the goals for modeling 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.
2. Principle
A principle is defined as a normative property of all systems in a given context, or the way in which they are realized.
Principle vs Requirement
Similar to requirements, principles define intended properties of systems, but they are different in scope:
- A principle is 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.
In other words, 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. Principles are intended to be more stable than requirements in the sense that they do not change as quickly as requirements may do.
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.
Principle vs Goal
Principles are strongly related to goals and requirements. A principle is motivated by some goal. Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.
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.
For example:
the principle “information management processes comply with all relevant laws, policies, and regulations” may be motivated by the goal to maintain a good reputation.
Motivation Concept Diagram Example:
The ArchiMate 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 Online Portfolio Service and Provide Online Information Service to apply the principle to the actual systems (architecture) under design.
3. Requirement
Requirements model the properties that are needed to achieve specified by the goals. In other words, requirements represent the “means” to realize goals. A requirement is typically defined as a statement of need that must be realized by a system.
Goal and Sub-goal
As mentioned before, goals can be realized by requirements that assign these properties to the systems.
During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties (requirements) exhibited by systems.
ArchiMate Example – Requirement Concept
- The ArchiMate diagram below illustrates the decomposition of goals towards requirements.
Interpreting The Diagram
- 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 Online Portfolio Service and Provide Online Information Service.
- Both requirements are realized by some software applications. In addition, the requirement Provide Online Portfolio Service may realize the goal Improve Portfolio Management.
- Alternatively, this goal can be realized by assigning a personal assistant to each customer.
4. Constraint
A constraint is defined as a restriction on the way in which a system is realized.
Requirement vs Constraint
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
For example:
- Specific technology that is to be used
- Restriction on the implementation process (e.g., time or budget constraints).
Example ArchiMate Diaram – Constraint
For the realization of a new portfolio management application, two constraints are imposed, as shown in the model below:
- In consideration of the cross-platform requirement – the realization of the application Java should be used
- The budget of the implementation project is limited to 500k Euro
Other ArchiMate Resources: