ArchiMate Quick Guide

ArchiMate is an open and independent EA modeling language to support the

description, analysis and visualization of architecture within and across business
domains in an unambiguous way.

Image result for archimate-example-all-layers

What are the Benefits of Archimate?​

Archimate helps to develop an organizations Enterprise Architecture. Here are some of
the key benefits of the framework:​

It ensures consistency across all architecture models. This means an

organizations’ communication of architecture is clear & consistent across all your
business domains.​
It provides stakeholders with guidance. With Archimate, stakeholders will be able
to design, assess & communicate the consequences of any decisions & changes
within these business domains.​
Developing sustaining and changing an enterprise architecture is a very complex
process. Archimate helps by providing material such as a framework, viewpoints
and other reference materials. These can be used by architects & analysts, whether
they are new or experience to the discipline.​
Archimate is always kept up to date. The latest developments and ideas in
Enterprise Architecture are taken into consideration and the Archimate framework
is continually being enhanced.
What is Architecture?
Architecture is both the process and the product of planning, designing, and
constructing buildings or any other structures including enterprise or software
architectures.

Architecture​
Architecture​

“Architecture descriptions are formal descriptions of a system, organized in a way that

supports​ reasoning about the structural and behavioral properties of the system and its
evolution. They define​ the components or building blocks that make up the overall
system, and provide a plan from which​ products can be procured, and subsystems
developed, that will work together to implement the​ overall system. It thus enables you
to manage your overall IT investment in a way that meets the​ needs of your business.”​

Mission​

To provide a specialised modelling notation for Enterprise Architecture​

Addresses the main architectural layers​
Philosophy is to remain simple, high-level / conceptual and small​

Architecting complex systems is a critical task. The description of systems (its

architecture) is needed​ in order to provide maximum support to the Enterprise.​

Before ArchiMate, the tools available either present UML or other modeling options.
They may be​ capable of architecting systems, but they have not been designed with
that specific purpose in mind.​

ArchiMate fills this gap. It is designed to address the key areas of architecture
(Business, Applications​ and Technology), with just sufficient capabilities to describe the
architecture at a high-level. Other​ designers / engineers can then take over with the
detailed design.
ArchiMate Definition
ArchiMate visual modeling notation that would leverage your Enterprise Architecture
practice and will help you describe and understand complex systems.

Basic Concepts and Definitions​

Objectives​

Introduce basic concepts and terminology:​

The Enterprise​
Purpose of Enterprise Architecture​
The ArchiMate Context​
Layers​

Definition of an Enterprise​

Fundamentally this is a collection of Organisations that share the same goal.​

Examples:​

Government Agency​
Corporation​
Division of a Corporation​
Department​
Geographically distant organisations linked by common ownership​
The definition of Enterprise has been taken from TOGAF® 9, and reflects the common
heritage that​

ArchiMate now has.​

The definition of an enterprise is very broad, ranging from mega-corporations and

government​ departments, through to a single department. The point being made that in
each of these examples is​ a range IT-related issues that must be handled by the
architect.​

However, in reality, these “definitions” can also be recognized as examples of types of

enterprise,​ each having their own characteristics that must be accommodated by
Enterprise Architecture.
Purpose of Enterprise Architecture

The need for Enterprise Architecture is well established and strategic in nature. As
organisations grown, this has in the past been done in a haphazard way, leading to a
generally​ unplanned overall system architecture.

Optimise fragmented systems​

Establish a strategic context​
Enable business innovation via efficient IT technology​

The key aim is to ensure EA contributes to the success of the organisation and
establishment of​ competitive advantage.

EA aims to:​

Co-ordinate fragmented systems and processes,​

Do so on the basis of a strategic understanding of what the organisation needs,​
Ensure the right degree of Information Technology efficiency (perhaps measured by
its​ capabilities) in order to support business innovation
What is ArchiMate

ArchiMate is a modelling technique ("language") for describing enterprise architectures.

ArchiMate presents a clear set of concepts within and relationships between

architecture domains, and offers a simple and uniform structure for describing the
contents of these domains.
ArchiMate distinguishes itself from other languages such as Unified Modeling
Language (UML) and Business Process Modeling Notation (BPMN) by its well
defined metamodel, and wider enterprise modelling scope.
ArchiMate offers a common language for describing the construction and
operation of business processes, organizational structures, information flows, IT
systems, and technical infrastructure.

This insight helps the different stakeholders to design, assess, and communicate the
consequences of decisions and changes within and between these business domains.

ArchiMate Framework

An architecture framework is used to structure the concepts and relationships of the

ArchiMate language. It divides the enterprise architecture in to a business, application
and technology layer. In each layer, three aspects are considered: active elements that
exhibit behavior (e.g. Process and Function), an internal structure and elements that
define use or communicate information.
ArchiMate Layers in Core Framework

The aspects of the core, as defined by the three types of element at the bottom of
Figure 1, combined with the layers identified in the previous section, make up a
framework of nine cells, as illustrated in Figure 2. This is known as the ArchiMate Core
Framework.

It is important to understand that the classification of elements based on aspects and

layers is only a global one. It is impossible to define a strict boundary between the
aspects and layers, because elements that link the different aspects and layers play a
central role in a coherent architectural description. For example, running somewhat
ahead of the later conceptual discussions, (business) functions and (business) roles
serve as intermediary elements between “purely behavioral” elements and “purely
structural” elements, and it may depend on the context whether a certain piece of
software is considered to be part of the Application Layer or the Technology Layer.

Image result for archimate layers

The ArchiMate core language defines a structure of generic elements and their
relationships, which can be specialized in different layers. Three layers are defined
within the ArchiMate core language as follows:

Business Layer​
The Business Layer offers products and services to external customers, which
are realized​ in the organization by business processes performed by business
actors.​
Application Layer​
The Application Layer supports the business layer with application services
which are​ realized by (software) applications.​
Technology Layer​
The Technology Layer offers infrastructure services (e.g., processing, storage,
and​ communication services) needed to run applications, realized by computer
and​ communication hardware and system software.​
These layers are shared by other frameworks, most important of which is TOGAF,
although TOGAF​ call them Business, Information System (Application and Data)
and Information Technology.
ArchiMate Language Principles

Objectives​

Understand the principles and core concepts:​

Underlying ideas​
ArchiMate and its relationships​
ArchiMate Framework​
Motivation Extension​
Implementation and Migration Extension​

Underlying Ideas​

The need to describe the architecture of IS/IT systems is fundamental to the

governance of an​ organisation. But there are several hurdles that must be overcome.​

Firstly, decisions need to be made as to the way these systems, which are likely to be
very​ complicated in larger organisations, are described. A general approach is to think
of the “entities”​

which the system consists of, and the way they relate to each other. Inevitable as these
entities are​ considered, the need to look at them in more specialised ways (i.e. business
process view; software​ application view) becomes apparent. Architecture focuses on
the highest level of detail.​

Secondly, it is important to establish some formality to the way the architecture is

described. EA does​ not need to be as detailed, for instance, as Business Process
Modelling, and therefore does not need​ such a complexity of symbols.​

Mission​

To provide a “small” yet comprehensive modelling language​

Addresses the needs of Enterprise architecture​
Aimed purely at architects​
Covers the main Architecture domains

ArchiMate has addressed both these issues by being relatively general, and by focusing
on the main​ areas of importance to architects – Business, Application and Technology.
ArchiMate - The Core Framework

The idea of layer, is not new. A well-established implementation of architecture​ layering

is used by TOGAF.​

Their “Architecture Development Method” addresses a Business, Information System

and Technology​ layer, all of which are matched with the ArchiMate layers. The
Information System, according to​ TOGAF consists of Applications and Data – these are
both covered in the ArchiMate Application​ layer.​ TOGAF address other are

Image result for archimate core framework

The framework is a structure into which the elements of the language can be
positioned. However,​

there are other elements related to areas such as:​

Goals, principles, and requirements​

Risk and security
Governance​
Policies and business rules​
 Costs​
Performance​
Timing​
Planning and evolution​

In TOGAF, these new elements are put in the extensions that forms the full ArchiMate
framework:

Image result for archimate core framework visual paradigm

ArchiMate - Key Elements

Key Elements

Architecture is all about describing entities and understanding the relationship between
them. The​ entities tend to fall into three categories. They are an element of:

1. the structure of a system - capable of​ doing things.

2. The Behavior - The things they do can be described as their behavior.
3. Passive Structure - what they use, i.e. in this​ “information age” is... information!

Think of information as “passive” – it doesn’t do anything by itself,​ but is used the

system as a whole.

The idea of active, behavior and passive reflects the way natural​ language has a subject
(active structure), a verb (behavior) and an object (passive structure).​

Active structure​
Behavior​
Passive structure​
 ArchiMate- Active - Behavior and Passive Structure

Service vs Interface

For example, “An Order (active Structure) is taken by (Behavior) a CSR (Passive
Structure)”​

Service-orientation is an increasingly important style in architecture. So to cater for this

both a Service​ and Interface element is included. The service represents some form of
activity (often subject to​ service levels). The interface exposes the service to the
environment. Both services and interface​ face externally, hiding the internal
characteristics of the system.​

Service​
Interface​
ArchiMate is promotes a service-orientated style of EA​
Collaboration and interaction​
Roles collaborating to execute behaviour​
Relationships​
ArchiMate has a rich set of relationships​

Concerning behavior, ArchiMate is interested in the highest level activities only.

Anything more​ detailed can be dealt with by other modelling approaches. But very
important to the architect is the​ way that key elements of the system collaborate with
each other, and the detail of that collaboration –​ refer to as Interaction.​

And finally, understanding relationship is vital to clarifying the purpose of each element.
ArchiMate​ has a relatively small set of relationships. The key elements will be explained
in detail in the coming sections.
ArchiMate - Active Structure Elements

Definition​

An entity capable of performing behaviour​

Examples​

Business Interface​
Business Actor​
Business Role​

Application Interface​
Application Component​
Device​
Network
etc
ArchiMate - Active Structure Elements
ArchiMate - Behaviour Elements

Definition​
Definition​

A unit of activity performed by one or more active structure elements.​

Examples​

Business Process​
Business Function
Business Interaction​
Application Function​
Application Interaction​
Infrastructure Function

ArchiMate - Behavior Elements

ArchiMate - Passive Structure Elements

Passive Structure​
Passive Structure​

Definition​

An object on which behaviour is performed.​

Examples​

Business Object​
Data Object

Passive Structure Elements

ArchiMate - Service Elements

Definition​
Definition​

A unit of functionality that a system exposes to its environment, while hiding internal
operations, which​provides a certain value (monetary or otherwise).​

Examples​

Business Service​
Application Service​
Infrastructure Service
ArchiMate - Interface Element

Definition​

A point of access where one or more services are made available to the environment.​

Examples​

Business Interface​
Application Interface​
Infrastructure Interface

The model in the example below includes the two ways to express the assignment
relationship. The Payment function (application) is assigned to the Financial application
(component), and the Payment service (application) is assigned to the Application
interface.
ArchiMate - Core Metamodel

A metamodel is used to describe information “at a higher level”. Often they consist of
elements and​ the relationships between them.

ArchiMate - Core MetaModel

ArchiMate has a complete metamodel described in a series of diagrams. This one – the
Core​ Metamodel – is the first and perhaps most important. It provides the most basic
picture of the main​ elements.​

Example Core Elements

ArchiMate - Collaboration and Interaction

Definitions​

Collaboration: a (temporary) grouping (or aggregation) of two or more structure

elements,​working together to perform some collective behavior​
Interaction: a unit of behavior performed by a collaboration of two or more
structure​ elements​

Examples​

Business Collaboration, Interaction​

Application Collaboration, Interaction

ArchiMate - Collaboration and Interaction

ArchiMate and TOGAF Layers

The idea of layer, as mentioned already, is not new. A well-established implementation

of architecture​ layering is used by TOGAF.​

Their “Architecture Development Method” addresses a Business, Information System

and Technology​ layer, all of which are matched with the ArchiMate layers. The
Information System, according to​ TOGAF consists of Applications and Data – these are
both covered in the ArchiMate Application​ layer.​

TOGAF address other areas such as establishing the context of systems and planning
how revised /​ new architectures are implemented. Both of these are also represented in
ArchiMate, along with the​ idea of “Requirements”.

Image result for togaf archimate layers

ArchiMate - Motivation Extension

Definition​

An element that provides the context or reason lying behind the architecture of an
enterprise.​

Examples​

Driver​
Goal​
Principle​
Requirement
 ArchiMate - Motivation Extension Elements

An important capability of an architecture, for it to be able to trace the reasons for the
inclusion of​ functions, services, processes etc. These reasons are obtained from “the
context”, and they could be​ said to be motivating factors. Matching, or aligning
motivational factors with systems is also crucial to​ governing the architecture.

The ArchiMate Motivation elements enable the modeling of stakeholders, drivers for
change, business goals, principles and requirements:
ArchiMate Motivation Extension
ArchiMate - Implementation and
Migration Extension

This extension covers the all-important planning phase that takes place after
architecting. Architects​ are responsible for visualising a Target architectures, identifying
the gap between the target and​ current architecture. Planning is about how these gaps
will be filled is dealt with by the extension. Like​ the motivation section, there are links
between the core elements and the way they might be​ implemented, as defined by this
extension.​

Examples​

Work Package​
Plateau​
Gap​
Deliverable
 ArchiMate - Implementation and Migration Extension

The ArchiMate Implementation and Migration elements enable the modeling of project
portfolio management, gap analysis and transition and migration planning:
ArchiMate implementation and migration extension
ArchiMate - Relationships

Objectives​

Explain in detail ArchiMate Relationships:​

Relationship between Layers​

Types of Relationship

Structural (strongest – weakest)​

Composition​
Aggregation​
Assignment​
Realisation​
Used By​
Access​
Association

Dynamic​

Triggering​
Flow​

Other​

Grouping​
 Junction​
Specialization

Motivational​

Association, Aggregation, Realisation, Influence​

Derived

ArchiMate - Relationship
ArchiMate Relationship - Composition

Composition Relationship indicates that an object is composed of one or​ more other
objects.

ArchiMate Relationship - Composition

Composition is based on the UML definition, meaning the parts of the whole are created
/ destroyed​ by the whole. Thus they can only be part of a single whole. Note the two
different ways of​ representing this relationship.

The models below show the two ways to express that the application component
Financial application is composed of three other application components:
Image result for archimate composition
ArchiMate Relationship - Aggregation
Aggregation indicates that a concept groups a number of other concepts.​

ArchiMate Relationship - Aggregation

The Aggregation relationship is based on UML, whereby the lifecycle of the parts of the
whole is​ not bound to the whole. Therefore such parts could be part of a different
whole.

Image result for archimate aggregation

ArchiMate Relationship - Assignment

Assignment links active elements (e.g., business roles or​ application components) with
units of behaviour that​ are performed by them, or business actors with​ business roles
that are fulfilled by them.

ArchiMate Assignment Relationship Notation

The Assignment relationship links Active Elements with units of Behaviour (but not the
other way​ round). The most common examples of this relationship are:​

Business role with a business process or function​

Application component with an application function​
A business collaboration with a business interaction​
An application collaboration with an application interaction​
A business interface with a business service​
An application interface with an application service​
A business actor with a business role​

The model in the example below includes the two ways to express the assignment
relationship. The Payment function (application) is assigned to the Financial application
(component), and the Payment service (application) is assigned to the Application
interface.

Note that: the first assignment relationship is implicitly related each other
Image result for archimate assignment
ArchiMate Relationship - Realization

Realization links a logical entity with a more concrete entity​ that realizes it.

ArchiMate Realization Relationship Notation

Realization deals with making abstract or logical things (the “what”) into something real
(the “how”).​ Examples are Process realizes service (operational), and data object
realizes business object or​ Artifact realizes application component (implementation).

This example models 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.

Image result for archimate realization

ArchiMate Relationship - Used By

Used By Relationship models the use of services by processes,​ functions, or

interactions and the access to interfaces​ by roles, components, or collaborations.​

ArchiMate Used By Notation

The Used By relationship should not be confused with the Dependency relationship in
UML, whose​ symbol looks the same. The meaning in ArchiMate is different.

ArchiMate Used By Relationship

ArchiMate relationship - Assess

Assess Relationship models the access of behavioural concepts to business or​ data
objects.

ArchiMate Relationship - Assess Notation

The Access relationship indicates that elements “do something” with information (e.g. a
Business​ Process / Business Object), or Data (e.g. Application Component / Data
Object). The relationship can​ merely indicate that something is accessed, or it can be
enhanced to show whether a Read, Write or​ Read / Write situation exists. Again the
UML Dependency relationship that shares similar symbols is​ not the same.

Image result for archimate assess relationship

ArchiMate Relationship - Association

Association relationship models a relationship between objects that is not covered by

another,​ more specific relationship.

The Association is the most general (weak) relationship which can be applied between
any elements.​

It is particularly used in connection with information elements:​

A business object with a representation​

A representation with a meaning​
A business service with a purpose

Image result for archimate association

ArchiMate Dynamic Relationships
The dynamic relationships describe temporal dependencies between elements within
the architecture. Two types of dynamic relationships are distinguished:

triggering
flow

Triggering Relationship

Triggering relationship describes the temporal or causal relationships between​

processes, functions, interactions, and events.

ArchiMate Triggering Relationship

In effect a Trigger relationship makes something happen (i.e. it causes something –

causal) as a​ result, and is therefore most important with processes.

The model below illustrates that triggering relationships are mostly used to model
causal dependencies between (sub-)processes and/or events.

Image result for archimate triggering

ArchiMate Flow Relationship

Flow relationship describes the exchange or transfer of, for example, information or​
value between processes, function, interactions, and events.

ArchiMate Flow Relationship

The Flow relationship merely indicates the transfer of something from one element to
another.

The model below shows a Claim assessment business function, which forwards
decisions about the claims to the Claim settlement business function. In order to
determine the order in which the claims should be assessed, Claim assessment makes
use of schedule information flow received from the Scheduling business function.

Image result for archimate flow relationship

ArchiMate Relationship - Grouping,
Junction & Specialization

Other Relationships​

Grouping​
Junction​
Specialization​

Grouping

Grouping relationship indicates that objects belong together based​ on some common
characteristic.

In the model below, the grouping relationship is used to group business objects that
belong to the same information domain, in this case Financial administration.

Junction
Junction

Junction Relationship is used to connect dynamic relationships of the​ same type.

ArchiMate Junction Relationship Notation

Junctions provide basic logic capability for use with triggers and flows.

In the model below, a junction is used to denote an or-split (choice).

Image result for Archimate Junction relationship

ArchiMate Specialization Relationship

Specialization relationship indicates that an object is a specialization of​ another

ArchiMate Specialization Relationship

This replicates the UML concept of Generalization / specialization (inheritance), but

with wider scope.​ Specialization can also relate any instances of an element with
another.​

Image result for Archimate specialization relationship

Motivational Relationships​

Association​
Aggregation​
Realization​
Influence
Junction

Junction Relationship is used to connect dynamic relationships of the​ same type.

ArchiMate Junction Relationship Notation

Junctions provide basic logic capability for use with triggers and flows.

In the model below, a junction is used to denote an or-split (choice).

Image result for Archimate Junction relationship

ArchiMate Relationships Between Layers

An important architecting issue is the alignment of system to requirement – otherwise

referred to as​ Business / IT alignment. This can be achieved by highlighting the links
between elements in their​ different layers. Three types are key, and they can relate to
Business / Application (B/A) and​ Application / Technology (A/T) relationships:​

1. Used By: which expresses the relationship between behavioural and structural
elements, e.g.​Application Service used by Business Process (B/A), or Infrastructure
Interface used by​Application Function (A/T)​
2. Realisation: shows how elements in different layers are “made real”, e.g. Data
Object realises​ Business Object (B/A), Artifact realises Application Component
(T/A)​
3. Assignment: this is relevant only in B/A relationships and can be used to indicate
degrees of automation. Assignment suggest full automation, e.g. Application
Component assigned to​ Business Process / Function / Interaction. A way to
indicate the relationship is less automated​
would be to use the used by relationship.​

In the example ArchiMate model below, you can see the integration of the various
ArchiMate layers with relationships
Image result for archimate-example-all-layers
ArchiMate Core Layers

Objectives​

The ArchiMate core language defines a structure of generic elements and their
relationships, which can be specialized in different layers. Three layers are defined
within the ArchiMate core language as follows:

Business Layer​
Application Layer​
Technology Layer​

Image result for archimate core layers

The general structure of models within the different layers is similar. The same types of
elements and relationships are used, although their exact nature and granularity differ.
ArchiMate - Business Layer

This metamodel deals solely with the ArchiMate elements in the business layer, and
their most basic​ associations.​ It also introduces several more Information Elements
(Passive Structure), shown on the left. They can​ be used to enrich the detail of business
views.

ArchiMate - Business Layer

Business Layer - Structure Concepts

Business Layer: Active Structure Concepts​

Business Actor​
Business Role​
Business Collaboration​
Business Interface​
Location

Business Actor

Business Actor is an organisational entity capable of performing behavior. The

Business Actor is someone who performs behaviour assigned to a business role. The
Actor may​ be a person, group, department, business unit. The business actor exists
both outside the​ organisation (i.e. customer) and inside the organisation (i.e. sales
person). The Name of a Business​ Actor should be a noun.

ArchiMate = Business Actor Notation

Example
 ArchiMate - Business Actor Example

Business Role​

The Business Role establishes responsibilities for behavior. These responsibilities can
be​ associated with the Actor responsible, and with functions and processes that do the
actual behaving.​ Also used to show the division of labor and responsibility within
organisations. The name of a​ business role should be a noun.

Business role is responsible for performing specific behavior, to which an​ actor can
be assigned.

Related Business Role with Other Elements

Business Actor assigned to Business Role​

Business Role assigned to Business Process or Business Function​
Business / Application Interface used by Business Role​
Business Role composed of Business Interfaces

Example
In the model below, the business role Insurance Seller is fulfilled by the Insurance
Department actor and has telephone as a provided interface. The business role
Insurance Buyer is fulfilled by the Customer actor, and has telephone as a required
interface.

Image result for archiMate business role visual paradigm

Business Collaboration

Business collaboration is aggregate of two or more roles that work together to​ perform
collective behavior. A Business Collaboration will occur between two or more business
roles. For instance, a salesperson​ collaborates with a customer (external) or a sales
manager may collaborate with a sales person​ (internal). In a B2B context, organisations
collaborate with each other. The name should preferably be​ a noun.​ Collaboration is a
way of recognizing the existence of some link between roles. The actual behavior​ is
regarded as a Business Interaction.

Example
 Image result for archimate business collaboration visual paradigm

Business Collaborations aggregated of roles​

Business Collaboration assigned to Business Interactions​
Business / Application Interface used by Business Collaboration​
Business Collaboration composed of Business Interfaces

Business Interface​

Business Interface​ is a point of access where a business service is made​ available to

the environment. It is a point of actual contact. It could be physical, like talking to a
salesperson in​ a shop. Or perhaps nowadays it is by means of phone or web (both
examples of “channels”). Can be​ a provided or required interface. Should be named as a
noun.

Example

This example puts an organization into its environment, consisting of external parties
such as customers, suppliers, and other business partners. It is very useful in
determining external dependencies and business interface and shows the value chain
or network in which the actor operates.

Business Role composed of a Business Interface​

Business Interface used by a Business Role​
 Image result for archimate business interface visual paradigm

Example

Business Interface can also be assigned to Business Services

 ArchiMate - Business Process 2

Location​

The Location models the distribution of structural elements. Location​ is a conceptual

point or extent in space.

Example

Location assigned to other Structural elements​

Location assigned to other Behavioral elements
 Image result for archimate location visual paradigm

Example

This example describes the relationships between applications components in terms of

the information flows between them, or in terms of the services they offer and use. This
example creates an overview of the application landscape of an organization and
expresses the (internal) co-operation or orchestration of services that together support
the execution of a business process.
ArchiMate diagram example: Cooperation
Business Layer: Behavioral Concepts

Business Process​
Business Function​
Business Interaction​
Business Event​
Business Service

Business Process

Business Process groups behavior based on an ordering of activities. It is intended to​

produce a defined set of Products or Business Services.​ The key point about a Business
Process is that it represents the “internal” aspects of activities. A​ sales person may
[externally] collaborate with a customer to sell something, but eventually sales​
“Process” may ensue who actually performs a load of internal things, such as preparing
sales​ documents, calculating delivery and so on. A key point – processes and function
apply to a single​ role. Its name should be a verb.​

Example

Business Process triggered by or triggers any other business behavior element​

Business Process accesses Business Objects​
Business Process realizes one or more Business Services​
Business Process may use (internal) Business Services or Application Services​
Business Role or Application Component assigned to Business Process
 Image result for archimate location visual paradigm

Business Function

Business Function groups behavior based on a chosen set of criteria (typically​ business
resources and / or competencies). In effect it is internal behavior performed by a
Business Role. A key point – processes and function​ apply to a single role. Should be
named as a verb ending in “-ing” (the gerund).

Example

Business Function triggered by or triggers any other business behavior element​

Business Function accesses Business Objects​
Business Function realizes one or more Business Services​
Business Function may use (internal) Business Services or Application Services​
Business Role or Application Component assigned to Business Function​
 Image result for archimate business function visual paradigm

Business Interaction​ describes the behavior of business​ collaboration. Business

Interaction is the actual behaviour that takes place between business roles. For
instance, if​ a Point of Sale system needs to collaborate with a Credit Card Payment
system, the detail of their​ interaction must be known. Should be named as a verb in the
present tense.

Example

In the model below, a business interaction is triggered by a request. The business

interaction Take out combined insurance is performed as collaboration between the
travel and luggage insurance seller. The business interaction needs the Policy info
business object, and realizes the (external) business service Combined insurance
selling. As part of the business interaction, the Prepare travel policy and Prepare
luggage policy are triggered. The Travel insurance seller and Luggage insurance seller
perform these processes separately.
 Business or Application Collaboration assigned to Business Interaction​
Business Interaction triggered by or triggers any other business behavioural
element​
Business Interactions access Business Objects​
Business Interaction realizes one or more Business Services or Application
Services

ArchiMate - Business Interaction

Business Event​

Business Event​ is something that happens (internally or externally) and influences​

behavior. It is a trigger or stimulus for behaviour. It could be triggered by actors,
functions and​ other interactions. It could be internal or external in origin. Also it is
“instantaneous” in nature. The​ name should be a verb used in the perfect tense, i.e.
“claim received”.

Example

In the model below, the Request insurance event triggers the Take out insurance
process. A business object containing the Customer info accompanies the request. In
order to persuade the customer to purchase more insurance products, a triggering
event is raised in the Receive request process. This triggers the Send product portfolio
to customer process.

Business Event may trigger or be triggered by a Business Process, Function or

Interaction​
Business Event may access a Business Object​
Business Event may be composed of other Business Events

Image result for archimate business event visual paradigm

Business Service

Business Service​ is a service that fulfils a business need for a customer (internal or​
external to the organisation).

Example

A Business Service exposes functionality of [is performed by] business roles or

collaborations to the​ environment; must be realised by a process or function. Can be
associated with a value. Name using​ a verb with “-ing” at the end (a present participle).

Business Service associated with a value.​

Business Layer: Passive Structure
Concepts

Business Object​
Representation​
Meaning​
Value​
Product​
Contract

Business Objects

Business Object​ is a passive element that has relevance from a business perspective.​ It
represents “informational” or (importantly) conceptual elements of relevance to the​
business. For instance a Sales Catalog can be regarded conceptually as a means of
providing​ information on items for sale. It could be represented in several ways – as a
brochure, or web page.​ However, its “raw data” will be part of the Applications Layer.

Example

The model below shows a business object Invoice, which aggregates (multiple)
business objects Invoice line. Two possible realizations of this business object exist: an
Electronic invoice (data object) and a Paper invoice (representation). The business
process Create invoice creates the invoice and the invoice lines, while the business
process Send invoice accesses the business object Invoice.

Business Object accessed by Business Process, Function, Interaction, Event,

Service​
Business Object association, specialisation, aggregation, composition with other​
 Business Objects​
Business Object realized by a Representation and / or Data Object

Image result for archimate business business object visual paradigm

Representation

Representation​ is a perceptible form of the information carried by a business object.

Think of a Representation as a realisation of some form of business object. ArchiMate
suggests that if​ relevant, representations can be associated with medium (paper, audio,
etc.) or format (HTML, PDF,​ etc.). Name it using a noun.

Example

The model below shows the business object Request for insurance, which is realized
(represented) by a (physical) request form. The Invoice business object is realized
(represented) by a paper bill.

Representation realizes one or more Business Objects​

A Meaning can be associated with a Representation
 Image result for archimate business representation visual paradigm

Meaning

Meaning​ is the knowledge or expertise present in a business object or its

representation, given​ a particular context. Meaning expresses the intent of a
representation, i.e. an “Invoice” is a document that details exactly​ what money is owed
to the seller by the purchaser. As such meanings are a valuable way of detailing​
business semantics. Sometimes a single representation can have different meanings to
different​ actors / roles,

For Example, an invoice to a customer is informational, and to a sales person is an

opportunity for​ commission. A single meaning can also be applied to multiple
representations, such as paper-based​ or web-based forms. The name should be a noun
or a noun phrase.

Example

The model below shows an Insurance policy document that is the representation of an
Insurance policy, which is a business object. The meaning related to this document is
the Insurance policy notification, which consists of a Policy explanation, an Insurance
registration, and a Coverage description.

A Meaning is associated with a Representation​

 Image result for archimate meaning example visual paradigm

Value

Value​ is the relative worth, utility or importance of a business service or product. Often
a value is expressed in monetary terms, is most significant to external roles (customer),
and is​ associated with services. The value could be non-monetary terms (perhaps
related to services​ provided without a fee), and there is also the idea of “functional
value” or a service.

Example

In the ArchiMate Diagram below shows:

The value Be Insured is the highest-level expression of what the service Provide
Insurance enables the client to do
 three “sub-values” are distinguished that are part of what Be Insured amounts to.
A Value can be associated with Business Services (directly) and Products, Roles
and Actors​ (indirectly) that use them.

ArchiMate value example

Product

Product​ is a coherent collection of services, accompanied by a contract / set of​

agreements, which is offered as a whole to (internal or external) customers. Think of a
Product more as financial, service-based or informational, that has emanated from a​
software-intensive organisation, rather than manufactured goods. Products can be
thought of also as​ “product types”, and buying is an obvious service associated with it.
Its name will have organisational​ significance (i.e. related to brand) or will be a more
general noun (i.e. “travel insurance”).

Example

This Example depicts the value that these products offer to the customers or other
external parties involved and shows the composition of one or more products in terms
of the constituting (business or application) services, and the associated contract(s) or
other agreements.

It may also be used to show the interfaces (channels) through which this product is
offered, and the events associated with the product.

A Product viewpoint is typically used in product development to design a product by

composing existing services or by identifying which new services have to be created for
this product, given the value a customer expects from it.

It may then serve as input for business process architects and others that need to
design the processes and ICT realizing these products.

A Product aggregates Business or Application services, as well as a Contract.​

A Product may be associated with a Contract, Value

Image result for archimate product visual paradigm

Contract

Contract​ is a formal or informal specification of an agreement that specifies the rights

and​ obligations associated with a product.​ A contract is a specialisation of a Business
Object and is very much associated with products.​ Although it can also be linked to
services – SLA is a common part of contractual documents. Its name​ should be a noun.​

Example​
Example​

A Telebanking contract associated with the product Telebanking account. The contract
consists of two parts (subcontracts): the Service Conditions and a Service Level
Agreement.

Note That:

A Contract is accessed by Business Process, Function, Interaction, Event, Service​

A Contract has an association, specialisation, aggregation, composition with other​
Contracts​
A Contract is realized by a Representation and / or Data Object​
Business Process, Function or Interaction may realize a Business Service​
Business or Application Interface assigned to a Business Service​

ArchiMate - Business Process 2

ArchiMate - Application Layer

Metamodel

The metamodel gives an overview of the application layer concepts and their
relationships. Many of the concepts have been inspired by the UML 2.0 standard, as this
is the dominant language and the de facto standard for describing software
applications.

Image result for archimate metamodel application layer visual paradigm

ArchiMate Application Layer - Active
Layer Concepts

The main active structure concept for the application layer is the application
component. This concept is used to model any structural entity in the application layer:
not just (re-usable) software components that can be part of one or more applications,
but also complete software applications, sub-applications, or information systems.

Application Component​
Application Collaboration​
Application Interface

Although very similar to the UML 2.0 component, our component concept strictly
models the structural aspect of an application: its behavior is modeled by an explicit
relationship to the behavioral concepts.

Application Component

Application Component​ is a modular, deployable, and replaceable part of a software

system​ that encapsulates its behaviour and data and exposes these​ through a set of
interfaces. Think of the Application Component as eventually the physical software that
will perform the​ necessary functions. It is independently deployable, reusable and
replaceable. Its name should use a​ noun.

ArchiMate Application Component Notation

Example
Example

The models below show the two ways to express that the application component
Financial application is composed of three other application components.

Image result for archimate application components visual paradigm

Example

In the model below, a financial application is depicted as an application component

consisting of two sub-components for accounting and billing, each of which offers an
application service to the environment. These services are accessible through a shared
accounting & billing application interface, which is part of the financial application.

Image result for archimate application components visual paradigm

Note That:

Application Component assigned to Application Functions, Business Processes

and​ Business Functions​
Application Component composed or aggregated of Application Interfaces

Application Collaboration

Application Collaboration​ is an aggregate of two or more application components that

work​ together to perform collective behavior. An Application Collaboration represents
the need for application components to “talk” to each other.​ How this is done is
modeled in detail by an interaction. Patterns of collaboration could be used, i.e.​Model /
View / Controller, Client / Server. Name should be a noun.

Example

In the model below, two components collaborate in transaction administration: an

Accounting component and a Billing component. This collaboration performs the
application interaction Administrate transactions.
 Image result for archimate application collaboration visual paradigm

Note That

Application Collaboration is a specialization of a component​

Application Collaboration assigned to Application or Business Interactions​
Application Collaboration aggregated of Application Components​
Application Interface used by Application Collaboration​
Application Collaboration composed of Application Interfaces

Application Interface

Application Interface​ is a point of access where an application service is made

available​ to a user or another application component. It specifies how the functionality
of a component is accessed by other components. In conceptual terms​ similar to an
Application Programmers Interface listing a set of functions. In addition, details such as​
parameters, protocols, pre/post conditions and data formats could be included. A
quality of interfaces​ is that they represent an obligation or contract that a component
realizing the interface must provide.​ It can be a provided or required interface. A noun is
using as its name.

Example

In the model below, a financial application is depicted as an application component

consisting of two sub-components for accounting and billing, each of which offers an
application service to the environment. These services are accessible through a shared
accounting & billing application interface, which is part of the financial application.

Image result for archimate application interface visual paradigm

Note That

Application Component composed of Application Interface(s)​

Application Interface assigned to Application or Business Services
Application Layer: Behavioral Concepts

Behavior in the Application Layer is described in a way that is very similar to Business
Layer behavior. Also here, a distinction is made between the external behavior of
application components in terms of application services, and the internal behavior of
these components; i.e., application functions that realize these services.

Application Function​
Application Interaction​
Application Service​

Application Function

Application Function​ is a behavior element that groups automated behavior that can be​
performed by an application component.​

Example

In the model below, the internal behavior of the Financial application component is
modeled as an application function consisting of two sub-functions. These application
functions realize the application services that are made available to the users of the
application.
 Image result for archimate application function visual paradigm

Note That

Application Function realises Application Service(s)​

Other Application Services or Functions used by Application Functions and
Infrastructure​ Services
Application Function accesses Data Object​
Application Component assigned to Application Function

Application Interaction​

Application Interaction​ is a behavior element that describes the behavior of​ application
collaboration.​ The Application Interaction provides the general behavioral detail that lies
behind a collaboration. A​ UML Sequence Diagram is useful to model the detail. Name
using a verb.

Example

In the model below, an Accounting component and a Billing component of a financial

system cooperate to compose an administrate transactions interaction. This is
modeled as an application interaction assigned to the collaboration between the two
components.

Import into your Project

 Image result for archimate application interaction visual paradigm

Note That

Application Collaboration assigned to Application Interaction​

Application Interaction realizes an Application Service​
Application Services and Infrastructure Services used by Application Interaction​
Application Interaction accesses Data Object

Application Service​

Application Service is a service that exposes automated behavior.​ The Application

Service in effect is providing some informational service needed by the business. It is​
these Services, for instance, that could be “orchestrated” to underpin a business
process. It​ represents what you actually get from the Application Component.

Example

In the model below, an application event Request for a Quotation triggers an application
process "Obtain Travel Insurance", which is served by the two aforementioned
application services.
Note That

Application Service used by Business Processes, Functions, Interactions or

Application​ Functions​
Application Function realises Application Service​
Application Interface assigned to Application Service​
Application Service accesses Data Object
ArchiMate Application Layer - Passive
Structure Concept

Passive Structure Concept

Data Object

Data Object​ is a passive element suitable for automated processing.​ It represents

the “Data Entities” of a formal data model that can be eventually used by​
databases. Must be meaningful to both the Business and Application layers. Name
should be a noun.

Example

The model below illustrates two ways to use the realization relationship. An application
(component) Financial application realizes the Billing service (application); the Billing
data object realizes the business object Invoice.
 Image result for archimate application data object visual paradigm

Note That

Data Object accessed by Application Function, Interaction, Service.​

Data Object realises a Business Object​
Artifact realises a Data Object​
Data Object associated, specialised, aggregated or composed of other Data
Objects​

A Data Object represents the “Data Entities” of a formal data model that can be
eventually used by​ databases. Must be meaningful to both the Business and
Application layers. Name should be a noun.
ArchiMate - Technology Layer

Technology Layer - Metamodel

The Technology Layer is typically used to model the technology architecture of the
enterprise, defined by the TOGAF framework as: “the structure and interaction of the
platform services, and logical and physical technology components”.

The Figure shown below gives an overview of the Technology Layer elements and their
relationships. Whenever applicable, inspiration is drawn from the analogy with the
Business and Application Layers.

ArchiMate - Technology Layer - Metamodel

Technology Layer: Active Structure
Concepts

Technology Layer: Active Structure Concepts​

Node​
Device​
System Software​
Infrastructure Interface​
Communication Path​
Network​

Node​

Node​ is a computational resource upon which artifacts may be stored or​ deployed for
execution.​ Think of a node as a logical container for Devices and System Software.
Indeed at the highest level a​ node could represent some form of software or hardware
resource. Nodes can consist of sub-nodes.​ Its name should be a noun.

ArchiMate - Node Notation

Example

In the model below, we see an Application Server node, which consists of a Blade
device and Java EE-based application server system software.
 ArchiMate - Technology Layer Node Notation

Note That

Nodes aggregated, composed of other Nodes, Devices and System Software​

Nodes can be interconnected by Communication Paths​
Artifacts can be assigned to Nodes​

Device​

Device​ is a hardware resource upon which artifacts may be stored or deployed​ for
execution.​ A Device is a physical resource with processing capability, such as
Mainframes, PCs and Routers.​ Often assigned with System Software, and can have sub-
devices. Its name should be a noun,​ possibly including Vendor or product information.

ArchiMate - Device Notation

Example

The model below shows an example of a number of servers, modeled as devices,

interconnected through a local area network (LAN).
 Image result for archimate device

Note That

Devices interconnected by Networks​

Artifacts assigned to Devices
System Software assigned to Devices​
Device composed, aggregated of other Devices​
Node composed, aggregated of Devices​

System Software​

System Software​ is a software environment for specific types of components and​

objects that are deployed on it in the form of artifacts.​ System Software represents
things like the Operating System, J2EE Application Server, a database​ system, workflow
engine, communications middleware. Artifacts, such as a Java class can be​ deployed
(assigned) to System Software. Often name with the appendage “...server” depending
on​ the environment involved. Often combined with a device to form a general node.

Example
In the model below, we see a mainframe device that deploys two system software
environments: a customer transaction server and a database management system
(DBMS).

Image result for archimate system software visual paradigm

Note That

System software assigned to Device​

Artifacts assigned to System Software​
Node composed, aggregated of System Software​
System Software realises Application Component, Collaboration, Interface, Service​

Infrastructure Interface​

Infrastructure Interface​ a point of access where infrastructure services offered by a

node​ can be accessed by other nodes and application components.​ How a Technology
Service is exposed to the environment. In the technology area interfaces could​ range
from URL / Web Pages; Network Card; URL/Web Service. A quality of interfaces is that
they​ represent an obligation or contract that a component realizing the interface must
provide. Name​ should be a noun.

Example

This example contains the software and hardware infrastructure elements supporting
the application layer, such as physical devices, networks, or system software (e.g.,
operating systems, databases, and middleware).

Image result for archimate infrastructure interface visual paradigm

Note That

Node composed of Infrastructure Interfaces​

Interface used by other Nodes​
Infrastructure Interface assigned to Infrastructure Service​

Communications Path​

Communications Path​ is a link between two or more nodes, through which these nodes
can​ exchange data.​ The Communication Path is a logical communications link between
nodes. Can logically represent​ qualities of the physical network.

Example

In the model below, we see a communication path “message queuing” between an

Application Server and a Client.
Note That

A Communications Path connects one or more Nodes​

Network realizes one or more Communication Paths​
Technology Layer: Behavioral Concepts

Infrastructure Function​
Infrastructure Service

Technology Function​

Technology (or Infrastructure Function)​ a behavior element that groups infrastructural

behavior that can be​ performed by a node.​ The Infrastructure Function refers to the
internal behavior of a node. A Database node performs​ database-like functions (i.e.
transaction management), which are exposed through the Infrastructure​ service.

ArchiMate - Technology Function Notation

Example
 Image result for archimate infrastructure function visual paradigm

Note That

Technology Function realizes technology (or Infrastructure) Service​

Other Infrastructure Services used by technology Function​
Technology Function accesses Artifact​
Node assigned to Technology Function​

The Technology Function refers to the internal behavior of a node. A Database node
performs​ database-like functions (i.e. transaction management), which are exposed
through the Technology​ service.​

Technology Service​

Technology Service​ is an externally visible unit of functionality, provided by one or more

nodes,​ exposed through well-defined interfaces, and meaningful to the environment.​
Technology Services represent the functionality of a node to its environment, which is
exposed by its​ interface. Examples are messaging, storing, naming and directory
services. Should be named as a​ verb, possibly with the word “service” included in it.

ArchiMate - Technology Service Notation

Example
 ArchiMate - Technology Servvice

Note That

Technology (or Infrastructure Service) used by Nodes or Application Components​

Infrastructure Interface assigned to Technology Service​
Technology Services access Artifacts​
Technology Layer: Passive Structure
Concept
Artifact​

Artifact​ is a physical piece of data that is used or produced in a software​ development

process, or by deployment and operation of a system.​

Example

A Web Archive artifact (which may realize an application component) is composed of

two other artifacts: Database Access Java Archive and Business Logic Java Archive.
Two specializations of the Web Archive artifact are a Purchase Application Web Archive
and a Quotation Application Web Archive. A Travel Insurance Database artifact (which
may realize a data object) is associated with the Web Archive artifact.

Image result for archimate artifact visual paradigm

Note That

Artifact realise Application Component, Software System, Data Object​

Node assigned to Artifact
ArchiMate Language Extension

Objectives​

Explain in detail concepts in the Extensions:​

Motivation Extension​
Implementation and Migration Extension

Image result for archimate framework visual paradigm

ArchiMate Core​
 Enables modelling of the​ architecture domains defined by​ TOGAF​

Motivation Extension​

Enables modelling of stakeholders,​ drivers for change, business goals,​ principles

and requirements​

Implementation and Migration​ Extension​

Enables modelling of project​ portfolio management, gap​ analysis and transition

and​ migration planning
Motivation Extension

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.

Motivation Metamodel

Figure shows below 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.
ArchiMate Motivation Extension Metamodel
ArchiMate - Motivation Concepts

Stakeholder​
Driver​
Assessment​
Goal​
Requirement​
Constraint​
Principle

Stakeholder​

Stakeholder is the role of an individual, team, or organisation (or classes thereof) that​
represents their interests in, or concerns relative to, the outcome of the architecture.
Based on definition from TOGAF. Examples are CEO, Board, Shareholders, Customers,
businesses.​ In other words an Actor can also be a Stakeholder. Name should be a noun.

Motivation Extension - Stakeholder Notation

Example

This example models 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.

Image result for stakeholder archimate visual paradigm

Note That

Stakeholder composed, aggregated of other Stakeholders​

Stakeholder associated with all other elements

Driver​

Driver​ is something that creates, motivates, and fuels the change in an organisation.​
Drivers can be internal (Customer satisfaction, Compliance to Legislation), or External
(economic​ climate, legislation). Name should be a noun.

ArchiMate - Driver Notation

Example
The example 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.

Image result for driver archimate visual paradigm

Note That

Driver composed, aggregated of other Drivers​

Driver associated with or influences other Motivation elements​ Contains material
extracted from the ArchiMate​

Assessment​

Assessment​ is the outcome of some analysis of some driver.​ An Assessment is made

by analysing drivers, then doing a SWOT analysis. Strengths and​ Weaknesses need to
be exploited or minimised. Opportunities need to be capitalised on and threats​
mitigated. Together these will result in Goals being set. Name could be a noun, or short
statement /​ sentence.​

ArchiMate - Assessment Notation

Example

This example models 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.

Note That

Assessment composed, aggregated of other Assessments​

Assessment associated with or influences other Motivational elements​

Goal​
Goal​

Goal​ is an end state that a stakeholder intends to achieve.​ A Goal is a target to aim for.
Often recognize by the use of qualitative words, such as “increase​ sales”. Goals can be
decomposed into several levels.

ArchiMate Goal Notation

Example

This example models 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 subgoals 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.
 Image result for goal archimate visual paradigm

Note That

Goal composed, aggregated of other Goals​

Goals associated with or influences other Motivational elements​

Requirement​

Requirement​ is a statement of need that must be realised by a system.​ Requirements

represent the means to achieve the ends (Goals). Higher-level requirements address​
goals, but eventually they can reach a more detailed level where requirements are
associated with the​ system itself. Requirements can be decomposed into potentially
many levels of detail.

ArchiMate - Requirement Notation

Example
Example

Image result for requirement archimate visual paradigm

Note That

Requirement composed, aggregated of other Requirements or Constraints​

Requirement realizes Goal or Principle​
Requirement associated or influences remaining Motivational elements​

Constraint​

Constraint​ is a restriction on the way in which a system is realized.​ Constraints impose

restrictions at a system level, and often relate to time, cost, resources, platform,​ and
skills.

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

Image result for constraint archimate visual paradigm

Note That

Constraint composed, aggregated of other Constraints or Requirements​

Constraint realises Goal or Principle​
Constraint associated or influences remaining Motivational elements

Principle​

Principle​ is a normative property of all systems in a given context, or the way in​ which
they are realized.​ Principles are a more general form of requirement, and are thus
applicable over all systems. They are​ therefore much more stable and enduring in their
nature. However, they are refined into more specific requirements when applied to
individual systems. A principle is motivated by a Goal, e.g. Goal = “no​ instances of being
sued”, Principle = “abide by the law”.

ArchiMate - Principle Notation

Example
Example

This example 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.

ArchiMate - Principle Example

Note That

Principle composed, aggregated of other Principles​

Principle realizes a Goal​
Link between Main and Motivational
Elements

Motivational elements can be reflected in any core element via a Value. Stakeholders
can also be​ assigned to actors. Requirements too are realized by core elements.
Motivational Relationships

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.

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.

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.

Association​

Association​ models some intention that is related to​ the source of that intention.

ArchiMate - Association
 ArchiMate Association (Relationship) Example

Aggregation​

Aggregation models some intention that is divided into​ multiple intentions.​ In the
context of motivation, Aggregation is a way of decomposing intentions (Goals) into
more​ concrete intentions (Goals with more specific timescales, measures).

ArchiMate Aggregation (Relationship) Example

Realization​

Realization​ models that some end that is realized by some​ means.​ The realization
relationship is used to represent the following means-end relationships:​

Principle Systems should be Customer Facing is a means to realize the goal

 Reduce Interaction with Customer.
Requirement Provide Online Portfolio Service is a means to realize sub-goal
Facilitate Self-Service, and to realize the principle Systems should be Customer
Facing.
This requirement can be realized by the business service Online Portfolio Service.

ArchiMate Realization (Relationship) Example

Note That

1. A goal (the end) is realized by a principle, constraint, or requirement (the means).​

2. A principle (the end) is realised 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.

Influence​
Influence ​models that some end is realized by some​ means.​ An Influence exists
between motivational elements – one element influencing the other(s).​ Additionally, the
relationship can be assigned as either positive (using the “+” sign) or negative (using​
the “-” sign).​

Example

The Diagram below illustrates the use of the influence relationship for making a trade-
off between the two requirements (assign personal assistant and provide on-line
portfolio service) that realize the goal Improve portfolio management.

1. The goal Increase Customer Satisfaction and the principle Systems should be
Customer Facing are used as trade-off criteria.
2. Both requirements positively influence the intended increase of customer
satisfaction.
3. The requirement of Provide Online Portfolio Service also positively influence the
intent of Systems should be Customer Facing.
4. The requirement of using a personal assistant greatly increases customer
satisfaction.
5. However, the Assign Personal Assistant requirement scores a lot worse for the
customer-facing criterion and Reduce Workload for Employees.
ArchiMate - Implementation and
Migration Extensions

Metamodel​

The Figure below gives an overview of the implementation and migration elements and
their relationships.

ArchiMate - Implementation and Migration Extension Metamodel

Implementation and Migration Concepts​

Work Package​
Deliverable​
Plateau​
Gap

Work Package​
Work Package​ is a series of actions designed to accomplish a unique goal within a​
specified time.​ A Work Package represents actions taken over time, implying a clearly
defined start and end date.​ There should also be goals to meet. Used to model projects.
Can be grouped together as part of a​ program or portfolio.​

ArchiMate - Work Package Notation

Example 1

Image result for Work package archimate visual paradigm

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 (Work Package) is limited
to 500k Euro.
Note That

Work Package composed, aggregated of other Work Packages​

Work Package realises Goal, Requirement, Constraint, Deliverable, Plateau​
Work Package flows to other Work Package​

Deliverable​

Deliverable​ is a precisely-defined outcome of a work package.​ A Deliverable is the result

of something – ideally a work package. This could include reports, papers,​ software, or
even more intangible, such as the new organisational structure resulting from change.​
However, perhaps more understandably, a deliverable might be the implementation of (a
part of) an​ architecture.

ArchiMate - Deliverable Notation

Example

The proposed project is modeled by a set of work packages and the corresponding
deliverables.
 Image result for deliverable archimate visual paradigm

Note That

Deliverable composed, aggregated of other Deliverables​

Deliverable realizes Goal, Requirement, Principle, Constraint​

Plateau​

Plateau​ is a relatively stable state of the architecture that exists during a limited​ period
of time. A plateau is a place in time at which point the state of architecture can be
described. Best used to​ show the progression of transition states that architecture can
go through as it is fully delivered.

ArchiMate - Plateau Notation

Example

The model below illustrates the use of the plateau concept to model the migration from
Baseline to transition architecture, and subsequently to Target Architecture, defining a
number of intermediate (possibly alternative) Transition Architectures.

Image result for plateau archimate visual paradigm

Note That

Plateau composed, aggregated of and triggers other Plateau​

Plateau aggregation and realization of Goal, Requirement, Constraint​

Gap​

Gap​ is an outcome of a gap analysis between two plateaus.​ Gaps are evident between
baseline and target architectures (otherwise there would be no need for​ anything to be
done!). They are identified by comparing elements, e.g. comparing an application​

Example 1

This example models and concepts that can be used for specifying the transition from
an existing architecture to a desired architecture.
 Image result for gap archimate visual paradigm

Example 2

This example illustrates the gap between the Baseline and Target infrastructure,
showing which of the elements of the infrastructure are added to or removed from the
Baseline.

Image result for gap archimate visual paradigm

Note That

Gap composed, aggregated of other Gaps​

Gap associated with all other elements​