Professional Documents
Culture Documents
ArchiMate Cookbook
ArchiMate Cookbook
Document information
Version 1.0
Created 2019-07-20
Modified 2020-09-07
Author Eero Hosiaisluoma (EHo)
ArchiMate Cookbook
Patterns & Examples
Table Of Contents
1. Introduction ................................................................................................................................................................4
1.1 Purpose And Scope ............................................................................................................................................4
1.2 References ..........................................................................................................................................................4
2. ArchiMate Diagram Types .........................................................................................................................................5
2.1 Motivation View (Goals View) .............................................................................................................................5
2.1.1 Motivation View - Example ..........................................................................................................................6
2.1.2 Risk Analysis View.......................................................................................................................................7
2.2 Business Model View ..........................................................................................................................................8
2.2.1 Business Model Canvas (BMC)...................................................................................................................8
2.2.2 SWOT Analysis View ...................................................................................................................................9
2.2.3 Value Stream View ......................................................................................................................................9
2.2.4 Strategy & Capability View ........................................................................................................................11
2.2.5 Implementation Roadmap View.................................................................................................................14
2.3 Layered View ....................................................................................................................................................16
2.3.1 Layered View - Business- and Application Layers Example .....................................................................17
2.3.2 Layered View - Business Layer .................................................................................................................17
2.3.3 Layered View - Customer Service Journey ...............................................................................................18
2.3.4 Layered View - Swimline Process View ....................................................................................................19
2.3.5 Layered View - Service Design View ........................................................................................................20
2.3.6 Layered View - Service Blueprint ..............................................................................................................21
2.4 Interaction View (Co-operation View) ...............................................................................................................21
2.4.1 Actor Interaction (Co-operation) View .......................................................................................................22
2.4.2 Process Interaction (Co-operation) View ...................................................................................................22
2.4.3 Application Interaction (Co-operation) View ..............................................................................................22
2.5 Business Process View .....................................................................................................................................23
2.5.1 Business Process Functional Decomposition View ..................................................................................23
2.6 Conceptual Data Model View............................................................................................................................24
2.7 Data Model View ...............................................................................................................................................25
2.8 Technology Platform View (Infrastructure View) ..............................................................................................25
2.9 Application Structure View (Solution Architecture View) ..................................................................................26
2.9.1 Application Design Pattern (Basic Model) .................................................................................................26
2.9.2 Application Logical Structure View (Application Structure / Internal Structure) ........................................27
2.9.3 Component Model (CM) ............................................................................................................................28
2.9.4 Database....................................................................................................................................................30
2.9.5 Application Integrations .............................................................................................................................32
2.9.6 Sequence Diagrams ..................................................................................................................................32
2.9.7 Application Integration Patterns.................................................................................................................34
2.9.8 Use Case View ..........................................................................................................................................35
3. ArchiMate-Elements (subset) ..................................................................................................................................37
3.1 ArchiMate Motivation -Elements .......................................................................................................................38
3.2 ArchiMate Strategy -Elements ..........................................................................................................................39
Eero Hosiaisluoma ©
2
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
3
ArchiMate Cookbook
Patterns & Examples
1. Introduction
1.1 Purpose And Scope
This document covers ArchiMate -patterns and examples, those of which can be used for modelling concepts and
solutions related to the development work of an organization.
Almost all the business relevant behavioral and structural elements of an organization can be modelled with the
ArchiMate. ArchiMate is a comprehensive and powerful notation, with a wide range of elements and relationships.
However, only a subset of ArchiMate-elements and only a small set of diagram types are enough for most of the
modelling purposes (80% of the cases).
This document introduces the most useful diagram types and related ArchiMate-elements. This subset of
ArchiMate-elements is grouped into the layers of ArchiMate Framework (figure below).
1.2 References
[1] ArchiMate 3.1, Open Group, 2019. https://pubs.opengroup.org/architecture/archimate3-doc/
[2] Enterprise Architecture at Work, 4th Edition, Marc Lankhorst et al., Springer, 2017.
[3] Mastering ArchiMate1, Edition III, Gerben Wierda, 2017.
[4] Lean Enterprise Architecture Method For Value Chain Based Development In Public Sector, Hosiaisluoma et
al, 2018. https://www.hosiaisluoma.fi/blog/lean-enterprise-architecture-method-for-value-chain-based-
development-in-public-sector/
[5] “ArchiMate Examples” blog, Eero Hosiaisluoma. https://www.hosiaisluoma.fi/blog/archimate-examples/
[6] “Holistic Enterprise Development” blog, Eero Hosiaisluoma https://www.hosiaisluoma.fi/blog/
[7] “ArchiMate Cookbook” blog, Eero Hosiaisluoma https://www.hosiaisluoma.fi/blog/archimate-cookbook/
1The most complete book ever written of ArchiMate. The color-scheme is based on aspects (behavior and
structure), whereas the color-scheme of this AM Cookbook is based on the layers – for simplicity.
Eero Hosiaisluoma ©
4
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
5
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
6
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
7
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
8
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
9
ArchiMate Cookbook
Patterns & Examples
capabilities. A value stream focuses us to “start talking business value instead of architecture”. Architecture, in turn,
defines the behavior and structure behind each capability.
This diagram type is modelled with ArchiMate Strategy -elements. (The Value Stream -element is introduced in the
ArchiMate 3.1 [1]).
Eero Hosiaisluoma ©
10
ArchiMate Cookbook
Patterns & Examples
A Capability Map View, the Capability Model, is valuable to identify the following:
1) the strategic core capabilities, which constitute the fundaments of the existence of the organization (incl.
value creation, competitive advantage), and
2) the basic capabilities, which enables the daily operations of the organization.
For capability assessment and identification, the following can be considered:
• a capability defines WHAT the organization does (whereas a resource defines HOW),
• a capability is unambiguous (no overlaps), and relatively stable by its nature,
• a capability can be divided into more detailed, lower-level capabilities,
• a capability can be grouped into a capability group,
• a capability can be:
a. organizational (intangible, related to the existence, strategy or value creation of an organization)
or
b. operational (produced by tangible or intangible resources, related to the operating model).
Eero Hosiaisluoma ©
11
ArchiMate Cookbook
Patterns & Examples
Figure 12: Strategy & Capability Planning View - Example (ref. “Strategy to Capability” Value Stream).
The Strategy View & Capability Planning View is modelled with ArchiMate Motivation- and Strategy-elements
(figure above). This view and these elements can be used for Capability-Based Planning (CBP) purposes.
Eero Hosiaisluoma ©
12
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
13
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
14
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
15
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
16
ArchiMate Cookbook
Patterns & Examples
Figure 19: Layered View, Business Layer - Design Pattern. Note: business interfaces as “channels”.
Note! Business Interfaces 1-3 are nested into higher level business interface “Channels” with relation type
Composition. Accordingly, Business Services 1-3 are nested into higher level business service.
Eero Hosiaisluoma ©
17
ArchiMate Cookbook
Patterns & Examples
The Layered View can be applied to what is appropriate for the purpose. For example, layers can be left out and
depict the development target from the certain viewpoint, e.g. from the business point of view like in the figure
above. However, the layered approach is always based on the top-down order of the elements: customers on the
top, then the business services and so on.
Eero Hosiaisluoma ©
18
ArchiMate Cookbook
Patterns & Examples
The Customer Service Journey is a specialization of the Layered View, which combines business- and application
layer elements.
Eero Hosiaisluoma ©
19
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
20
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
21
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
22
ArchiMate Cookbook
Patterns & Examples
Figure 29: Business Function View – A process may span multiple business functions.
“A business function represents a collection of business behavior based on a chosen set of criteria (typically
required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly
governed by the organization.” [1]
A business function view can be used when it is necessary to model high-level business behavior, which groups
more detailed behavior (such as processes). A business function is a behavioral element, which is performed by a
structural element, typically by an organizational unit (e.g. department or group). A business function is meaningful
behavior for the organization. Business functions can be used for dividing the business into parts, each of which
has certain logical cohesion based on the business services they provide.
Eero Hosiaisluoma ©
23
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
24
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
25
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
26
ArchiMate Cookbook
Patterns & Examples
According to ArchiMate derivation rules (introduced in the ArchiMate specification), the basic application design
pattern can be depicted as shown below.
Figure 36: Application View - Design Pattern (Simplification of the Basic Model).
Note! Application services and application interfaces are the “different sides of the same coin”: a) behavioral
services and b) structural interfaces. Both can be used for modelling the behavior of an application that is exposed
for external use (interactions). Which one to use depends on the case. Application services can be used for
modelling functional dependencies and interactions. Application interfaces instead, can be used for modelling
concrete user interfaces (GUIs) or app2app interfaces (APIs) with operations. As such, application interfaces can
be used for modelling actual dynamics between applications, or between users and applications. Access -
relationship can be bi-directional (in case of read & write accessibility).
If an application interface is to be modelled instead of an application service, then the application interface is
connected with the application component with a Composition -relation type (figure below).
Figure 38: Application Logical Structure (functional decomposition into sub-components /modularization).
This view is useful in designing or understanding the main structure of an application and its sub-components and
the associated data. This diagram can be used e.g. to break down the structure of the application system under
construction, to illustrate modularization /decomposition: what are the sub-systems / sub-components what are the
application services (or application interfaces) they provide. The sub-components are nested into the main
component (Aggregation relationship).
Eero Hosiaisluoma ©
27
ArchiMate Cookbook
Patterns & Examples
Figure 40: Application Logical Structure: Application Functions assigned to modules of an application (A).
Note! The behavior (functions) of an application can be modelled with either ArchiMate Application Function or
Application Process -elements. The latter can also be used for modelling e.g. Robotic Process Automation (RPA)
or (scheduled) batch-processing behavior.
Eero Hosiaisluoma ©
28
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
29
ArchiMate Cookbook
Patterns & Examples
2.9.4 Database
A database is a meaningful unit in the overall enterprise architecture of an organization. E.g. “Client database” or
“Customer database”, “Product database” etc. A logical database is a composition of all the tables of an application
(e.g. “Customer table”, “Orders table”, “Invoices table” etc.), which altogether build up a database.
A logical database can be modelled on the application layer with a) Data Object- or b) Application Component-
element. Which element to use, depends on what kind of database is in question: a) a passive structure or b) an
active structure. Data Object is suitable for modelling the passive data itself: what is the data, how it is structured or
composed (or aggregated) from other data objects, and what are the associations between these data objects.
Application Component is suitable for modelling an active data structure that is capable of data management
behavior such as data processing and/or data storing.
Eero Hosiaisluoma ©
30
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
31
ArchiMate Cookbook
Patterns & Examples
2.9.5.2 ETL-Process
Eero Hosiaisluoma ©
32
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
33
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
34
ArchiMate Cookbook
Patterns & Examples
2 Some tools support many notations such as ArchiMate, BPMN and UML, like Sparx EA for example.
Eero Hosiaisluoma ©
35
ArchiMate Cookbook
Patterns & Examples
The diagrams 1-4 above are just mentioned here for information. Diagrams 1 and 4 can be kept as part of the
documentation of the target application (here: Application Component X).
Eero Hosiaisluoma ©
36
ArchiMate Cookbook
Patterns & Examples
Once again we can see how the layered view can be applied to diverse modelling needs (=“use cases”).
3. ArchiMate-Elements (subset)
Eero Hosiaisluoma ©
37
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
38
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
39
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
40
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
41
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
42
ArchiMate Cookbook
Patterns & Examples
4. ArchiMate Relationships
Eero Hosiaisluoma ©
43
ArchiMate Cookbook
Patterns & Examples
ArchiMate Relationships
Name Description Symbol
Serving Dependency relation between the elements:
[dependency] an element provides its functionality to another element.
Realization Structural relation between the elements:
[structural] an element realizes another, more abstract element.
Assignment Structural relation between the elements:
[structural] an active structural element is allocated as “doer” to another
element.
Access Dependency relation between the elements:
[dependency] the ability of behavior and active structure elements to
observe or act upon passive structure elements.
Composition Structural relation between the elements:
[structural] an element consists of one or more other elements.
Aggregation Structural relation between the elements:
[structural] an element groups a number of other elements.
Flow Dynamic relation between the elements:
[dynamic] represents transfer from one element to another.
Trigger Dynamic relation between the elements:
[dynamic] a temporal or causal relationship between elements.
Association An unspecified relationship, or one that is not represented by
another ArchiMate relationship - always allowed between two
elements.
Eero Hosiaisluoma ©
44
ArchiMate Cookbook
Patterns & Examples
5. Metamodel
5.1 Metamodel - Core
Eero Hosiaisluoma ©
45
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
46
ArchiMate Cookbook
Patterns & Examples
6. Diagram Types
The most essential diagram types that tackle most (80%) of the modelling requirements are as follows:
A. The most useful diagrams:
1. Motivation View (Goals View) [2.1 ]
2. Layered View [2.3 ]
3. Interaction View (Co-operation diagram) [2.4 ]
a. Actor Interaction View (Actor Co-operation diagram) [2.4.1 ]
b. Process Interaction View (Process Co-operation diagram) [2.4.2 ]
c. Application Interaction View (Application Co-operation diagram) [2.4.3 ]
4. Conceptual Data Model View [2.6 ]
B. Also valuable diagrams:
5. Data Model View [2.7 ]
6. Technology Platform View (Infrastructure View) [2.8 ]
C. Additional diagrams:
7. Application Structure View [2.9 ]
8. Process View [2.5 ]
9. Business Model Canvas (BMC) [2.2.1 ]
10. Service Blueprint [2.3.6 ]
11. SIPOC [7.7 ]
These diagram types are introduced in this document.
Eero Hosiaisluoma ©
47
ArchiMate Cookbook
Patterns & Examples
6.4 Maps
Eero Hosiaisluoma ©
48
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
49
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
50
ArchiMate Cookbook
Patterns & Examples
on the organization-specific domain-structure (e.g. business units, business service areas or operational value
streams). For more information see blog posts: https://www.hosiaisluoma.fi/blog/lean-ea-framework/ and
https://www.hosiaisluoma.fi/blog/sparx-ea/ (a Sparx EA reference implementation).
Figure 64: Value Chain based operating model with integrated EA discipline.
Within the LEAD, architecture is done “just enough”. Architecture artifacts (deliverables) are created on demand
basis, “just in time”, not “just in case”. All the architecture diagrams are published continuously on the EA portal for
all the concerned stakeholders of the organization. Architecture is involved in all the development cases right from
the beginning, there is no need for board committee reviews afterwards. Architects provide the Architecture
Landscape, against which all the development targets are evaluated before the development phase (build or buy).
As the “idea to production” process (figure below) performs daily basis (e.g. in two-week sprints), new architectural
content is continuously added into the Architecture Landscape, which is managed within the EA tool’s repository.
Eero Hosiaisluoma ©
51
ArchiMate Cookbook
Patterns & Examples
Figure 65: The LEAD process (implementation of the “Idea To Production” Value Stream).
Note! The development phase consists of several "development paths", some of which are introduced in the
diagram above.
For more information of the LEAD see this blog post: https://www.hosiaisluoma.fi/blog/lean-enterprise-architecture-
method-for-value-chain-based-development-in-public-sector/.
The LEAD and the LEAF are introduced more detailed in the design science research article [4] (Lean Enterprise
Architecture Method for Value Chain Based Development in Public Sector, Hosiaisluoma et al., 2018.), which can
be retrieved from the Research Gate via this link:
https://www.researchgate.net/publication/328560027_Lean_Enterprise_Architecture_Method_for_Value_Chain_Ba
sed_Development_in_Public_Sector .
Figure 66: Goal-Driven Approach - start always with defining the goals (the WHY) first.
Eero Hosiaisluoma ©
52
ArchiMate Cookbook
Patterns & Examples
Figure 67: ArchiMate Core Framework separates the elements of each layer in behavioral and structural
aspects.
A simplified service-driven pattern is illustrated in the diagram below. These are the basic elements of Service-
Driven Approach (SDA).
Eero Hosiaisluoma ©
53
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
54
ArchiMate Cookbook
Patterns & Examples
Figure 71: ArchiMate 1-2-3 metamodel. The WHY and WHAT on the left, the HOW on the right.
The naming “ArchiMate 1-2-3” stands for “one holistic wholeness, two aspects (behavior and structure), three
layers (business, application, technology)”. It is analogous to and compatible with Goal-Driven Approach (GDA)
and Service-Driven Approach (SDA), as they all are based on ArchiMate Framework’s layers and aspects.
The ArchiMate 1-2-3 is an easy as A-B-C, fast track for start using modelling for visualization in all the development
cases in an organization. By starting small and keeping things simple, and then learning by doing, this approach
can be extended smoothly with other ArchiMate elements. Modelling can be used as a supporting method for
overall development. Architecture artifacts can be created with an appropriate modelling tool, and all the
concerning documents can be produced from the tool - according to Model-Based System Engineering, MBSE (as
introduced in the SAFe). It is good practice to start small and simple, and then extend the way of working - as the
architecture- and modelling maturity evolves. ArchiMate 1-2-3 is based on the same diagram types as introduced in
this document.
Eero Hosiaisluoma ©
55
ArchiMate Cookbook
Patterns & Examples
Eero Hosiaisluoma ©
56
ArchiMate Cookbook
Patterns & Examples
This is a “use case oriented” view to manage the EA content. This is a combination of a) typical diagrams grouped
into the Views, and b) collection of maps of fundamental EA structural and behavioral elements. The maps are
positioned according to ArchiMate aspects (active structure, behavior and passive structure).
Note! These frameworks are examples, all the content placeholders (white boxes) can be identified and named to
what is appropriate; content placeholders can be added, modified, removed or replaced to according to what is
essential in the organization. It is important to notice that these maps are collections (catalogs) of relevant
elements in the enterprise architecture of an organization.
When customizing these content frameworks introduced here, the rule of thumb is to keep it simple. Good practice
is to apply the Lean EA principles: use only the relevant content placeholders (“just enough”); create content
placeholders only if needed (“just in time”) – not to create them “just in case”. However, content placeholders can
act like reminders of what should be investigated and modeled. (A specific step-by-step method is to be introduced
here.)
Eero Hosiaisluoma ©
57
ArchiMate Cookbook
Patterns & Examples
8. Appendixes
8.1 Appendix 1: Cloud Service Models
Eero Hosiaisluoma ©
58
ArchiMate Cookbook
Patterns & Examples
8.2.2 Legend
8.2.3 Grouping
The Grouping -element can be used for modelling logical groups of elements that can be handled as an entity. E.g.
application group such as financial applications, external applications, legacy applications etc. In addition, the
grouping can be used for abstracting a group of elements. For example, if we don’t know yet enough details, or we
are not interested in the details of a specific area, we can model such a target area as a group. For example, we
just like to handle external organization’s applications as a group, or certain applications as a group (see figure
below).
Eero Hosiaisluoma ©
59
ArchiMate Cookbook
Patterns & Examples
group of applications e.g. of an organization unit. A class of applications can be modelled as an abstract application
(e.g. named according to following notation: << Application >>), which represents e.g. an application that is not
known, cannot be identified by name etc. These abstractions can be made visible with specialization.
An abstraction represents:
• a "class" of objects / elements
o there can be several instances of this class
o none of the individual instances, but them all as a whole is relevant and meaningful
o all the instances inherit similar behavior (relative to the context in hand)
o Instance naming (according to UML): “Instance name : Class”
• a "role" which certain objects can play
o models an element of a specific kind, that is identified, but not necessary to be known by the name
o only the behavior of an object is known or important to be known
o e.g. a business actor is meaningful to be specified, but its application is not, only the behavior it
plays
• a collection of objects of the same type
o models a set of objects as a whole, group of elements
o e.g. << Financial applications >>, << Front-end applications >> (Note! Naming: plural)
• generalization / specialization
o models the generic element (stereo)type, not any specific element
o there can be specializations of this generalization
o e.g. << Financial application >> and “Purchasing Application” (Note! Naming: singular)
o elements can be typed with the specialization prefix, e.g. “<< IT-service >> Name”
o Module or sub-system e.g. “Module Name [Application Name]”
Notation:
• naming as follows: abstraction << Application(s) >> (with or without “<<” and “>> prefix and suffix)
• italic font can be used in naming, indicating that the concerning element is an “abstraction”
Eero Hosiaisluoma ©
60
ArchiMate Cookbook
Patterns & Examples
Figure 81: ESB pattern (this example uses the Application Function to represent the integration
configuration).
An ESB contains configurations per each integration. These configurations can be modelled e.g. as 1) Application
Components, 2) Application Functions or 3) Application Processes. An Application Component represents a
deployable, independent execution entity, whereas an Application Function and an Application Process represent
the behavior, that can be performed by a) EAI platform itself or b) a sub-component of an EAI platform. Anyhow,
the integration configuration shall be specifically modelled, so that the whole end2end flow of an individual
integration can be handled as a single unit (of work): logically and physically independent and coherent
encapsulation of functionality.
Eero Hosiaisluoma ©
61
ArchiMate Cookbook
Patterns & Examples
Figure 83: API modelled with the Application Interface -element, by using a <<stereotype>>.
Eero Hosiaisluoma ©
62