COMPARISON BETWEEN

ARCHIMATE, BPMN AND UML

Content
1. INTRODUCTION ................................................................................................................... 4

1.1. Overall about modeling languages ...........................................................................................................4

1.2. Architecture leveling ................................................................................................................................5

1. Business process modeling ...................................................................................................................5
2. Technology modeling ...........................................................................................................................9

1.3. Architecture layer and viewpoints .........................................................................................................10

2. ARCHIMATE ........................................................................................................................ 12

2.1. Overall about Archimate ........................................................................................................................12

2.2. Language structure ................................................................................................................................13

1. Business layer .................................................................................................................................... 15
2. Application layer ................................................................................................................................ 19
3. Technology layer ................................................................................................................................ 21
4. Relationship ....................................................................................................................................... 23
5. Cross-layer dependencies................................................................................................................... 25

2.3. Archimate viewpoint..............................................................................................................................27

1. Viewpoint classification ...................................................................................................................... 27
2. Standard viewpoints in ArchiMate ...................................................................................................... 30

2.4. General analysis on Archimate ...............................................................................................................30

3. BPMN .................................................................................................................................... 32

3.1. Overall about BPMN ..............................................................................................................................32

3.2. Language structure ................................................................................................................................32

1. Process .............................................................................................................................................. 33
2. Choreographies.................................................................................................................................. 34
3. Collaborations.................................................................................................................................... 35
3.3. BPMN viewpoints ..................................................................................................................................35

3.4. General analysis on BPMN .....................................................................................................................36

1. Strengths of BPMN ............................................................................................................................. 36
2. Weaknesses of BPMN ........................................................................................................................ 36

3.5. Comparison between BPMN and Archimate ..........................................................................................37

3.6. Contribution from BPMN to Archimate ..................................................................................................41

4. UML ....................................................................................................................................... 42

4.1. Overall about UML .................................................................................................................................42

4.2. Language structure ................................................................................................................................42

1. The following diagrams model structure:............................................................................................ 42
2. Behavior ............................................................................................................................................ 43
3. Interaction ......................................................................................................................................... 44

4.3. UML viewpoints .....................................................................................................................................45

4.4. General analysis on UML........................................................................................................................46

1. Strengths of UML ............................................................................................................................... 46
2. Weaknesses of UML ........................................................................................................................... 46

4.5. Comparison between UML and Archimate.............................................................................................47

4.6. Contribution from UML to Archimate ....................................................................................................49

5. PROPOSAL ON APPLICATION OF ARCHIMATE, BPMN AND UML .......................... 50

6. CONCLUSIONS AND PERSPECTIVES .............................................................................. 57

6.1. Conclusion .............................................................................................................................................57

6.2. Perspectives ...........................................................................................................................................57

7. REFERENCE ......................................................................................................................... 59
1. Introduction

1.1.Overall about modeling languages

A Modeling Language is "a graphical or textual language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive system". An Enterprise
Architecture Modeling Language is a high level of abstraction language, aiming at representing
enterprise architectural structure, characteristics and properties at early stage of design. In this
document we are compare three modeling language

How do I model an application landscape? How do I relate logical (implementation

independent) and physical business processes (implementation dependent)? How do I match the
application portfolio with the technical infrastructure? How do I visualize what data are required
when delivering which products and services to customers? How do I model a service broker?

These are all examples of modeling questions that an enterprise architect will be confronted
with. There are many variants of modeling solutions that are being practiced in order to answer these
questions. These variants lead to inconsistencies and can limit good communication. Behind every
model there is an original story, but a model can often converge into its own new “truth” where the
original story will get lost over time, especially if the originator of the model is no longer involved in
the maintenance of that model.

Companies that practice „working under architecture‟ are using ArchiMate more and more as
a descriptive language for capturing enterprise architectures consisting of domains like:
products/services, processes, organization, data, applications and technical infrastructure. Using this
language it is possible to model the structure within a domain as well as the relationships between
domains. Another important aspect of ArchiMate is the possibility to visualize models using multiple
viewpoints, specific to different stakeholders. Besides this, the language supports a formal
foundation to enable analysis of models (for example on an aspect such as performance). ArchiMate
is deliberately not intended to replace existing languages like BPMN, UML etc.; it is positioned to
deliver value in addition to these existing languages, the intention is to adapt as much as possible to
existing standards and practices.

The primary goal of BPMN is to provide a notation that is readily understandable by all
business users, from the business analysts that create the initial drafts of the processes, to the
technical developers responsible for implementing the technology that will perform those processes,
and finally, to the business people who will manage and monitor those processes. Thus, BPMN
creates a standardized bridge for the gap between the business process design and process
implementation.

This specification represents the amalgamation of best practices within the business modeling
community to define the notation and semantics of Collaboration diagrams, Process diagrams, and
Choreography diagrams. The intent of BPMN is to standardize a business process model and notation
in the face of many different modeling notations and viewpoints. In doing so, BPMN will provide a
simple means of communicating process information to other business users, process implementers,
customers, and suppliers.

UML is a language with a very broad scope that covers a large and diverse set of application
domains. Not all of its modeling capabilities are necessarily useful in all domains or applications.
This suggests that the language should be structured modularly, with the ability to select only those
parts of the language that are of direct interest. On the other hand, an excess of this type of flexibility
increases the likelihood that two different UML tools will be supporting different subsets of the
language, leading to interchange problems between them. Consequently, the definition of compliance
for UML requires a balance to be drawn between modularity and ease of interchange.

Experience with previous versions of UML has indicated that the ability to exchange models
between tools is of paramount interest to a large community of users. For that reason, this
specification defines a small number of compliance levels thereby increasing the likelihood that two
or more compliant tools will support the same or compatible language subsets. However, in
recognition of the need for flexibility in learning and using the language, UML also provides the
concept of language units.

1.2.Architecture leveling
1. Business process modeling

Defining a business process is usually associated with the creation of a model. A model is
useful for depicting the flow of process activities and the events that trigger the flow. Traditionally a
process model, started with a START event, spanned the breadth of the room and ended with an END
event. And although this level of process model is applicable to the stakeholders with an execution
responsibility, it is mostly information overload to others. One process model therefore is not
appropriate or deemed to be of value to all audiences.

The introduction into the process leveling approach focused on the audience as an influence
on the appropriate process level. The example used showed the strategist and executive examining the
top of the process hierarchy where process steps are gathered into cohesive groups. These process
groups represent the business at an enterprise level. It focuses attention on the strategic "what" and
"why"; providing context and enabling stakeholders with strategic management and scoping
questions. It represents the "business on one page".

Each process group is broken down into the next level, until the required level of detail has
been achieved. Each level modeled has a specific objective and type of stakeholder it is typically
aimed at. As the hierarchy drills down into lower levels, the detail becomes more until we have
eventually detailed a process at an individual task level. Note that not all process modeling exercises
require the lowest level of detail.

Consider these guidelines when adopting a process leveling approach:

• Maintain top-down traceability across the various process levels : A process defined at
any level must be traceable to the highest level. For example, if an activity is defined on Level 4, it
should be linked to a Sub-process on Level 3, which is part of a Level 2 process, that implements part
of a Level 1 value chain that enables a Level 0 enterprise process.

• Only model to the level of detail required : Although the process levels are specified to
a very detailed level, models should only be developed at the more detailed levels if there is a defined
business requirement. As a guideline we recommend that all processes be defined from Level 0 to
Level 2 to provide the bigger picture for future process development, but that more detailed process
models should only be developed if there is guaranteed business benefit.
 Figure 1: Real IRM's Process Levelling
In mapping these levels of abstraction to the proposed process levels, the organisation need to
make a decision on exactly what will be represented in the individual levels, based on the modeling
toolset of choice. The levels could be different from what is proposed below, based on practical or
appropriateness considerations.
Process Name Synonym Abstractio Description
n
Level A high level view defining the
L0 Enterprise Operating model level
Contextual scope and boundaries of the
organization

An abstract model that are

constructed to enable
reasoning within an idealized
framework. Idealized here
means that the model may
make explicit assumptions
Macro Value Chain, that are known to be false in
L1 Main Process Conceptual
Process some detail. Such
assumptions may be justified
on the grounds that they
simplify the model while, at
the same time, allowing the
production of acceptably
accurate solutions.

Models representing the

complete business and system
L2 Process Business Process Logical requirements without
reference to a specific
implementation.

Models representing the

complete business and system
Realization ,
L3 Sub-process Logical requirements without
Work cycle
reference to a specific
implementation.

Operational, Models representing a

L4 Activity process Logical specific implementation or
work practice.
Work practice
L5 Task Work Instruction, Implementa Implemented environment
Work flow tion - not
modelled
Table 1: Process levels and levels of abstraction
Physical
Process modeling is an accepted business practice used to improve productivity, retain the
intellectual capital and support organizational change and complexity.
 Process definitions, as intangible assets need to be aligned to their organizational impact.
Process leveling as an approach, ensures that process models are aimed at particular stakeholders -
focusing the value and impact to a given perspective. This is an approach used by a number of
industry organizations and forums.

Real IRM recommends six process levels. These process levels are based on theory and best
practices, and have been proven in practice at several clients. The organization embarking on process
modeling, should define its own process hierarchy using an approach such as the one presented as an
example. Then define the relationship to the modeling tool of choice - specifically the models and
objects that will be used to ensure consistency and quality in establishing this most important
organizational asset.

2. Technology modeling

The stratification of language units is used as the foundation for defining compliance in UML.
Namely, the set of modeling concepts of UML is partitioned into horizontal layers of increasing
capability called compliance levels. Compliance levels cut across the various language units, although
some language units are only present in the upper levels. As their name suggests, each compliance
level is a distinct compliance point. For ease of model interchange, there are just four compliance
levels defined for the whole of UML: “UML Superstructure Specification, v2.0”

• Level 0 (L0). This compliance level is formally defined in the UML Infrastructure. It
contains a single language unit that provides for modeling the kinds of class-based structures
encountered in most popular object-oriented programming languages. As such, it provides an entry-
level modeling capability. More importantly, it represents a low cost common denominator that can
serve as a basis for interoperability between different categories of modeling tools.

• Level 1 (L1). This level adds new language units and extends the capabilities provided by
Level 0. Specifically, it adds language units for use cases, interactions, structures, actions, and
activities.

• Level 2 (L2). This level extends the language units already provided in Level 1and adds
language units for deployment, state machine modeling, and profiles.
 • Level 3 (L3). This level represents the complete UML. It extends the language units provided
by Level 2 and adds new language units for modeling information flows, templates, and model
packaging. The contents of language units are defined by corresponding top-tier packages of the
UML meta-model, while the contents of their various increments are defined by second-tier packages
within language unit packages. Therefore, the contents of a compliance level are defined by the set of
meta-model packages that belong to that level. As noted, compliance levels build on supporting
compliance levels. The principal mechanism used in this specification for achieving this is package
merge (see “Package-Merge (from Kernel)” on page 107). Package merge allows modeling concepts
defined at one level to be extended with new features. Most importantly, this is achieved in the
context of the same namespace, which enables interchange of models at different levels of
compliance as described in “Meaning and Types of Compliance” on page 4.

For this reason, all compliance levels are defined as extensions to a single core “UML”
package that defines the common namespace shared by all the compliance levels. Level 0 is defined
by the top-level meta-model shown in Figure 2.1. In this model, “UML” is originally an empty
package that simply merges in the contents of the Basic package from the UML Infrastructure. This
package, contains elementary concepts such as Class, Package, Data-Type, Operation, etc. (see the
UML 2.0 Infrastructure specification for the complete list of contents).

1.3.Architecture layer and viewpoints

Although, at an abstract level, the concepts that are used throughout EA models in ArchiMate
are similar, ArchiMate defines more concrete concepts that are specific for a certain layer of the
architecture. In this context, we distinguish three main layers:

1. The Business layer offers products and services to external customers, which are realized in
the organization by business processes (performed by business actors or roles).

2. The Application layer supports the business layer with application services which are
realized by (software) application components.

3. The Technology layer offers infrastructural services (e.g., processing, storage and
communication services) needed to run applications, realized by computer and communication
devices and system software.
 From this basic structure, we can deduce a first set of viewpoint types, containing three
viewpoints that are centered around one specific type of concept:

1. Active structure, e.g., the composition of a business actor from sub actors, i.e., an
organization structure;

2. Behavior structure, e.g., the structure of a business process in terms of sub processes;

3. Passive structure, e.g., the information structure in terms of data objects

Although these viewpoints take a specific type of concept and its structure as their focus, they
are not limited to these concepts, and closely related concepts are also included.

This results in the language framework of Archimate shown below. In this framework, we
have projected commonly occurring architectural domains.
2. Archimate

2.1.Overall about Archimate

ArchiMate is an open and independent enterprise architecture modeling language to support
the description, analysis and visualization of architecture within and across business domains[2] in an
unambiguous way.

ArchiMate is a technical standard from The Open Group and is based on the concepts of the
IEEE 1471 standard. It is supported by various tool vendors and consulting firms. ArchiMate is also a
registered trademark of The Open Group. The Open Group has introduced a certification program for
ArchiMate 2.0.

ArchiMate distinguishes itself from other languages such as Unified Modeling Language
(UML) and Business Process Modeling Notation (BPMN) by its architecture leveling.

ArchiMate is a lightweight and scalable language in several respects:

• Its architecture framework is simple but comprehensive enough to provide a good

structuring mechanism for architecture domains, layers, and aspects. • The language
incorporates modern ideas of the “service orientation” paradigm that promotes a new
organizing principle in terms of (business, application, and infrastructure) services
for organizations, with far-reaching consequences for their enterprise architecture.
• Although it intentionally resembles the Unified Modeling Language (UML), the
ArchiMate modeling notation is intuitive and much lighter than currently proposed
by UML 2.0. Nevertheless, the language is expressive enough to allow for the
modeling of all layers (business, application, and technology infrastructure) and all
aspects (structure, behavior, and information) of an organization in an integrated
way.
• The two enterprise architecture standards of The Open Group – TOGAF and
ArchiMate – complement each other and can be used well in combination.
• Finally, tool support for the ArchiMate language is already commercially available
(from BiZZ design, IDS Scheer, Casewise, Telelogic, and others).

The goal of this Technical Standard is to provide the first official and complete specification
of the ArchiMate standard under the flag of The Open Group.
 This specification contains the formal definition of ArchiMate as a visual design language
with adequate concepts for specifying inter-related architectures, and specific viewpoints for selected
stakeholders. This is complemented by some considerations regarding language extension
mechanisms, analysis, and methodological support. Furthermore, this document is accompanied by a
separate document, in which certification and governance procedures surrounding the specification
are specified.

2.2.Language structure
In the enterprise modeling language that we propose, the service concept plays a central role.
A service is defined as a unit of functionality that some entity (e.g., a system, organization or
department) makes available to its environment, and which has some value for certain entities in the
environment. Service orientation supports current trends such as the service-based network economy
and ICT integration with Web services. These examples already show that services of a very different
nature and granularity can be discerned: they can be provided by organizations to their customers, by
applications to business processes, or by technological facilities (e.g., communication networks) to
applications.

A layered view provides a natural way to look at service-oriented models. The higher layers
make use of services that are provided by the lower layers. Although, at an abstract level, the
concepts that are used within each layer are similar, we define more concrete concepts that are
specific for a certain layer. In this context, we distinguish three main layers:

• The Business layer offers products and services to external

customers, which are realized in the organization by business
processes performed by business actors.
• The Application layer supports the business layer with application
services which are realized by (software) applications.
• The Technology layer offers infrastructural services (e.g., processing,
storage and communication services) needed to run applications,
realized by computer and communication hardware and system
software.
 Each of these main layers can be further divided in sub-layers. For example, in the Business
layer, the primary business processes realizing the products of a company may make use of a layer of
secondary (supporting) business processes; in the Application layer, the end-user applications may
make use of generic services offered by supporting applications. On top of the Business layer, a
separate Environment layer may be added, modeling the external customers that make use of the
services of the organization (although these may also be considered part of the Business layer).

In line with service orientation, the most important relation between layers is formed by use
relations, which show how the higher layers make use of the services of lower layers. However, a
second type of link is formed by realization relations: elements in lower layers may realize
comparable elements in higher layers; e.g., a 'data object' (Application layer) may realize a 'business
object' (Business layer); or an 'artifact' (Technology layer) may realize either a 'data object' or an
'application component' (Application layer).

The general structure of models within the different layers is similar. The same types of
concepts and relations are used, although their exact nature and granularity differ. Figure 3 shows the
central structure that is found in each layer.
 First, we distinguish the structural or static aspect (right side of Figure 3) and the behavioral
or dynamic aspect (left side of Figure 3). Behavioral concepts are assigned to structural concepts, to
show who or what displays the behavior. In the example, role, interface and collaboration are
assigned to business process, organizational service and business interaction, respectively.

Second, we make a distinction between an external view and an internal view on systems.
When looking at the behavioral aspect, these views reflect the principles of service orientation as
introduced in the previous section. The service concept represents a unit of essential functionality that
a system exposes to its environment. For the external users, only this external functionality, together
with non-functional aspects such as the quality of service, costs etc., are relevant. If required, these
can be specified in a contract or service level agreement. Services are accessible through interfaces,
which constitute the external view on the structural aspect.

Although for the external users only the external view is relevant, the design of organizations
or systems and their internal operations and management also requires knowledge about the internal
realization of the services and interfaces. For this realization, we make a distinction between
behavior that is performed by an individual structural element (e.g., actor, role component, etc.), or
collective behavior (interaction) that is performed by a collaboration of multiple structural elements.

In addition to active structural elements (the business actors, application components and
devices that display actual behavior, i.e., the 'subjects' of activity), we also recognize passive
structural elements, i.e., the objects on which behavior is performed. In the domain of information-
intensive organizations, which is the main focus of our language, these are usually information
objects in the business layer and data objects in the application layer, but they may also be used to
represent physical objects.

1. Business layer

Figure 2 shows the meta-model of business layer concepts. The meta-model follows the structure of
the generic meta-model introduced in the previous chapter. However, this layer also includes a
number of additional informational concepts which are relevant in the business domain: a product and
 associated contract, the meaning of business objects, and the value of products of business services.

Figure 3: Business Layer Meta-model

Note: This figure does not show all permitted relationships: every element in the language can
have composition and aggregation relations with elements of the same type; furthermore, there are
indirect relationships that can be derived, as explained in Archimate 2.0 document.

The structure aspect at the business layer refers to the static structure of an organization, in
terms of the entities that make up the organization and their relationships.

Two types of entities are distinguished:

• The active entities that are the subjects (e.g., business actors or business roles) that
perform behavior such as business processes or functions (capabilities). Business
actors may be individual persons (e.g., customers or employees), but also groups of
people (organization units) and resources that have a permanent (or at least long-
term) status within the organizations. Typical examples of the latter are a department
and a business unit.
 • The passive entities (business objects) that are manipulated by behavior such as
business processes or functions. The passive entities represent the important
concepts in which the business thinks about a domain.

Architectural descriptions focus on structure, which means that the inter-relationships of

entities within an organization play an important role. To make this explicit, the concept of business
collaboration has been introduced. Business collaborations have been inspired by collaborations as
defined in the UML 2.0 standard [8], [12], although the UML collaborations apply to components in
the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to
the “community” concept as defined in the RM-ODP Enterprise Language [6], as well as to the
“interaction point” concept, defined in Amber [13] as the place where interactions occur.

The concept of business interfaces is introduced to explicitly model the (logical or physical)
locations or channels where the services that a role offers to the environment can be accessed. The
same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or
through the Internet. In contrast to application modeling, it is uncommon in current business layer
modeling approaches to recognize the business interface concept.

Table 2: Summary Business Layer Concepts

 2. Application layer

Figure 4 gives an overview of the application layer concepts and their relationships. Many of
the concepts have been inspired by the UML 2.0 standard [7], [10], as this is the dominant language
and the de facto standard for describing software applications. Whenever applicable, we draw
inspiration from the analogy with the business and application layer.

Figure 4: Application Layer Meta[model

Note: This figure does not show all permitted relationships: every element in the language can
have composition and aggregation relations with elements of the same type; furthermore, there are
indirect relationships that can be derived, as explained in Archimate 2.0 document.
 The main structural 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. 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.

Also in application architecture, the inter-relationships of components are an essential

ingredient. Therefore, we also introduce the concept of application collaboration here, defined as a
collective of application components which perform application interactions. The concept is very
similar to the collaboration as defined in the UML 2.0 standard [7], [10].

In the purely structural sense, an application interface is the (logical) channel through which
the services of a component can be accessed. In a broader sense (as used in, among others, the UML
2.0 definition), an application interface defines some elementary behavioral characteristics: it defines
the set of operations and events that are provided by the component, or those that are required from
the environment. Thus, it is used to describe the functionality of a component. A distinction may be
made between a provided interface and a required interface. The application interface concept can be
used to model both application-to-application interfaces, which offer internal application services,
and application-to business interfaces (and/or user interfaces), which offer external application
services.

Also at the application layer, we distinguish the passive counterpart of the component, which
we call a data object. This concept is used in the same way as data objects (or object types) in well-
known data modeling approaches, most notably the “class” concept in UML class diagrams. A data
object can be seen as a representation of a business object, as a counterpart of the representation
concept in the business layer.

Table 3: Summary of Technology Layer Concepts

 3. Technology layer

Figure 5 gives an overview of the technology layer concepts and their relationships. Many of
the concepts have been inspired by the UML 2.0 standard [7], [10], as this is the dominant language
and the de facto standard for describing software applications and infrastructure. Whenever
applicable, we draw inspiration from the analogy with the business and application layers.
 Figure 5:Technology Layer Meta model
Note: This figure does not show all permitted relationships: every element in the language can
have composition and aggregation relations with elements of the same type; furthermore, there are
indirect relationships that can be derived, as explained in Archimate 2.0 document.

The main structural concept for the technology layer is the node. This concept is used to
model structural entities in this layer. It is identical to the node concept of UML 2.0. It strictly models
the structural aspect of a system: its behavior is modeled by an explicit relationship to the behavioral
concepts.

An infrastructure interface is the (logical) location where the infrastructure services offered by
a node can be accessed by other nodes or by application components from the application layer.

Nodes come in two flavors: device and system software, both taken from UML 2.0. A device
models a physical computational resource, upon which artifacts may be deployed for execution.
System software is an infrastructural software component running on a device. Typically, a node
consists of a number of sub-nodes; for example, a device such as a server and system software to
model the operating system.

The inter-relationships of components in the technology layer are mainly formed by the
communication infrastructure. The communication path models the relation between two or more
nodes, through which these nodes can exchange information. The physical realization of a
communication path is a modeled with a network; i.e., a physical communication medium between
two or more devices (or other networks).

Table 4: Summary of Technology Layer Concepts

4. Relationship
 The meta-models and examples from the previous chapters show the different types of
relationships that the ArchiMate language offers. In this chapter, we provide a more precise
description of these relationships.

The relationships can be classified as either:

• Structural, which model the structural coherence of concepts of the same or different
types
• Dynamic, which are used to model (temporal) dependencies between behavioral
concepts
• Other, which do not fall in one of the two above categories

Table 5: Summary of Relationships

 5. Cross-layer dependencie

In the previous chapters we have presented the concepts to model the business, application,
and technology layers of an enterprise. However, a central issue in enterprise architecture is business-
IT alignment: how can these layers be matched? In this chapter, we describe the relationships that the
ArchiMate language offers to model the link between business, applications, and technology.

 Business-Application Alignment:

Figure 6 shows the relationships between the business layer, the application layer, and the
technology layer concepts. There are three main types of relationships between these layers:

1. Used by relationships, between application service and the different types of

business behavior elements, and between application interface and business role. These
relationships represent the behavioral and structural aspects of the support of the business by
applications.

2. A realization relationship from a data object to a business object, to indicate that the
data object is a digital representation of the corresponding business object.

3. Assignment relationships, between application component and business process,

function, or interaction, and between application interface and business service, to indicate
that, for example, business processes or business services are completely automated. The case
that a business process, function, or interaction is not completely automated but only
 supported by an application component is expressed with a “used by” relationship (see, e.g.,
the example of an Application Usage Viewpoint in Section 8.4.11).

In addition, there may be an aggregation relationship between a product and an application or

infrastructure service, to indicate that the application or infrastructure service can be offered directly
to a customer as part of the product. Also, a location may be assigned to all active and passive
structural elements (and, indirectly, behavior elements) in the application and technology layers.

Figure 6: Relationships between Business Layer and Lower Layer Concepts

 Application-Technology Alignment

Figure 45 shows the relationships between application layer and technology layer concepts.
There are two types of relationships between these layers:

1. Used by relationships, between infrastructure service and the different types of application
behavior elements, and between infrastructure interface and application component. These
relationships represent the behavioral and structural aspects of the use of technical infrastructure by
applications.

2. A realization relationship from artifact to data object, to indicate that the data object is
realized by, for example, a physical data file, and from artifact to application component, to indicate
that a physical data file is an executable that realizes an application or part of an application. (Note: In
this case, an artifact represents a “physical” component that is deployed on a node; this is modeled
with an assignment relationship. A (logical) application component is realized by an artifact and,
indirectly, by the node on which the artifact is deployed.)

Figure 7: Relationships between Business Layer and Lower Layer Concepts

2.3.Archimate viewpoint
1. Viewpoint classification

An architect is confronted with many different types of stakeholders and concerns. To help
him in selecting the right viewpoints for the task at hand, we introduce a framework for the definition
and classification of viewpoints and views. The framework is based on two dimensions: purpose and
content. The following three types of architecture support the purpose dimension of architecture
views:

• Designing: Design viewpoints support architects and designers in the design process from
initial sketch to detailed design. Typically, design viewpoints consist of diagrams, like those used in,
for example, UML.

• Deciding: Decision support viewpoints assist managers in the process of decision-making by

offering insight into cross-domain architecture relationships, typically through projections and
intersections of underlying models, but also by means of analytical techniques. Typical examples are
cross-reference tables, landscape maps, lists, and reports.
 • Informing: Informing viewpoints help to inform any stakeholder about the enterprise
architecture, in order to achieve understanding, obtain commitment, and convince adversaries.
Typical examples are illustrations, animations, cartoons, flyers, etc.

The goal of this classification is to assist architects and others find suitable viewpoints given
their task at hand; i.e., the purpose that a view must serve and the content it should display. With the
help of this framework, it is easier to find typical viewpoints that might be useful in a given situation.
This implies that we do not provide an orthogonal categorization of each viewpoint into one of three
classes; these categories are not exclusive in the sense that a viewpoint in one category cannot be
applied to achieve another type of support. For instance, some decision support viewpoints may be
used to communicate to any other stakeholders as well.

For characterizing the content of a view we define the following abstraction levels:

• Details: Views on the detailed level typically consider one layer and one aspect from the
ArchiMate framework. Typical stakeholders are a software engineer responsible for design and
implementation of a software component or a process owner responsible for effective and efficient
process execution. Examples of views are a BPMN process diagram and a UML class diagram.

• Coherence: At the coherence abstraction level, multiple layers or multiple aspects are
spanned. Extending the view to more than one layer or aspect enables the stakeholder to focus on
architecture relationships like process-uses-system (multiple layer) or application-uses-object
(multiple aspect). Typical stakeholders are operational managers responsible for a collection of IT
services or business processes.

• Overview: The overview abstraction level addresses both multiple layers and multiple
aspects. Typically, such overviews are addressed to enterprise architects and decision-makers, such as
CEOs and CIOs.

In Figure 59, the dimensions of purpose and abstraction level are visualized in a single
picture, together with examples of typical stakeholders that are addressed by these viewpoints. The
top half of this figure shows the purpose dimension, while the bottom half shows the level of
abstraction (or detail). Table 5 and Table 6 summarize the different purposes and abstraction levels.
 Figure 8: Classification of Enterprise Architecture Viewpoints

Table 6: Viewpoint Purpose

Typical Stakeholders Purpose Examples
Designing Architect, software developer, Navigate, design, support UML diagram, BPMN
business process designer design decisions, compare diagram, flowchart, ER
Deciding Manager, CIO, CEO decision-making
alternatives Cross-reference
diagram table,
landscape map, list, report
Informing Employee, customer, others Explain, convince, obtain Animation, cartoon,
commitment process illustration, chart

Table 7: Viewpoint Abstraction Levels

Typical Stakeholders Purpose Examples

Details Software engineer, process Design, manage UML class diagram, BPMN
owner process diagram
Views expressing
Coherence Operational managers Analyze dependencies, relationships like “use”,
impact of-change “realize”, and “assign”
Overview Enterprise architect, CIO, Change management Landscape map
CEO
 2. Standard viewpoints in ArchiMate

A viewpoint in ArchiMate is a selection of a relevant subset of the ArchiMate concepts (and

their relationships) and the representation of that part of an architecture that is expressed in different
diagrams. A set of such viewpoints was developed based on practical experience. Some of these
viewpoints have a scope that is limited to a single layer or aspect. Thus, the Business Function and
Business Process viewpoints show the two main perspectives on the business behavior; the
Organization viewpoint depicts the structure of the enterprise in terms of its departments, roles, etc.;
the Information Structure viewpoint describes the information and data used; the Application
Structure, Behavior, and Co-operation viewpoints contain the applications and components and their
mutual relationships; and the Infrastructure viewpoint shows the infrastructure and platforms
underlying the enterprise‟s information systems in terms of networks, devices, and system software.
Other viewpoints link multiple layers and/or aspects: the Actor Co-operation and Product viewpoints
relate the enterprise to its environment; the Application Usage viewpoint relates applications to their
use in, for example, business processes; and the Deployment viewpoint shows how applications are
mapped onto the underlying infrastructure.

In the following sections, the ArchiMate viewpoints are described in detail. For each
viewpoint the comprised concepts and relationships, the guidelines for the viewpoint use, and the
goal and target group and of the viewpoint are indicated. Furthermore, each viewpoint description
contains example models. For more details on the goal and use of viewpoints, refer to [2], Chapter 6.
The diagrams illustrating the permitted concepts and relationships for each viewpoint do not show all
permitted relationships: every element in a given viewpoint can have composition, aggregation, and
specialization relationships with elements of the same type.

2.4.General analysis on Archimate

In the development of the ArchiMate language, standards such as UML have always been
guiding beacons. Also, practical cases performed with the partners have played a significant role in
steering and validating the development of the ArchiMate language. At present, the ArchiMate
language has matured and has become more stable. Therefore, a more precise comparison with
relevant standards and approaches has become possible and relevant. This is the topic of the current
document.

Two important principles underlie the ArchiMate language:

 1. The concepts are primarily aimed at models at a relatively high level of abstraction,
although, in principle, the ArchiMate language can be used at various levels of detail, (see D2.2.1 -
Concepts for Architectural Description). It should be possible to express concepts in standards and
partner-specific modeling approaches as specializations and/or compositions of ArchiMate concepts.

2. It should be possible to use the ArchiMate language as an “umbrella” language (D2.2.1):

i.e., it should be possible to use ArchiMate concepts to link more detailed models of specific domains
(which are currently not yet related to each other), that are expressed in other (design) languages.

Obviously, both principles require a sound comparison and mapping to standards. In our view,
the required level of detail for these mappings differs with respect these two goals. Using ArchiMate
as an umbrella language to link models in other languages requires an unambiguous and very detailed
mapping of concepts, linking models or parts of models. Given the scope and timeline of ArchiMate
this can be achieved only for a very limited set of standards.

The focus of this deliverable is on a less detailed comparison between ArchiMate and other
languages and standards, which shows the main strengths and weaknesses of the different languages.
First, this provides a broad view on the positioning of ArchiMate with respect to other languages.
Also, it may enhance the understanding of the ArchiMate language for people familiar with the other
languages, and it provides additional validation for ArchiMate (e.g., it may show gaps in the coverage
of the language). Because of the more global nature of this comparison, more standards and
languages can be taken into account. In the next stage of the project, a more detailed mapping will be
made for a limited number of standards and partner specific languages, to illustrate the use of
ArchiMate as an umbrella language.
3. BPMN

3.1.Overall about BPMN

Business Process Model and Notation (BPMN) is a standard for business process modeling
that provides a graphical notation for specifying business processes in a Business Process Diagram
(BPD), based on a flowcharting technique very similar to activity diagrams from Unified Modeling
Language (UML). The objective of BPMN is to support business process management, for both
technical users and business users, by providing a notation that is intuitive to business users, yet able
to represent complex process semantics. The BPMN specification also provides a mapping between
the graphics of the notation and the underlying constructs of execution languages, particularly
Business Process Execution Language (BPEL).

The primary goal of BPMN is to provide a standard notation readily understandable by all
business stakeholders. These include the business analysts who create and refine the processes, the
technical developers responsible for implementing them, and the business managers who monitor and
manage them. Consequently, BPMN serves as a common language, bridging the communication gap
that frequently occurs between business process design and implementation.

Currently there are several competing standards for business process modeling languages used
by modeling tools and processes Widespread adoption of the BPMN will help unify the expression of
basic business process concepts (e.g., public and private processes, choreographies), as well as
advanced process concepts (e.g., exception handling, transaction compensation).

3.2.Language structure
A Business Process can be defined as a collection of related tasks that produce a specific
service or product for a particular customer. Business Process Model and Notation (BPMN) is a
leading visual notation for modeling Business Processes. It uses a set of predefined graphical
elements to depict a process and how it is performed. The current version of BPMN defines three
models to cover various aspects of processes:

 Processes (which can be internal executable or non-executable as well a public processes);

 Choreographies
 Collaborations
 Internal processes are those processes internal to an organization also referred to as workflow.
Some internal processes can be modeled to show how they could be executed by automating the
steps using a system, while others are modeled to document their process flow, whether it is a
manual or system supported process.

Public processes model the interaction between processes and participants. Only the activities
that show the communication between processes are modeled in the Public Process, all the other
activities are modeled in the Internal Process.

Choreographies look similar to Internal Processes but here the activities are “interactions that
represent a set (one or more) of message exchanges” between participants (Object Management
Group, 2010).

Collaborations are used to model the interactions between business entities. It includes Pools
which represents the participants of the process and the flow of messages between these participants.
The public process can be modeled in a Pool or it can be left empty. Collaborations can consist of any
combination of Pools, processes, and choreographies.

These main diagram types mentioned above are similar to the viewpoint concept specified in
ArchiMate 2.0 in the sense that these are the types of diagrams (or views) that can be created using
this notation, although they are not nearly as detailed and specific as in ArchiMate 2.0. While these
diagram types are explained in terms of what the diagram entails, no examples are given, whereas the
ArchiMate viewpoints are categorized according to their purpose and context and are explained with
an example of how the different elements are connected to each other.

1. Process

A Process describes a sequence or flow of Activities in an organization with the objective of

carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of
Activities, Events, Gateways, and Sequence Flows that define finite execution. Processes can be
defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-
level Processes can be grouped together to achieve a common business goal.
 Figure 9: Example Process
2. Choreographies

A Choreography is a type of process, but differs in purpose and behavior from a standard
BPMN Process. A standard Process, or an Orchestration Process (see page 145), is more familiar to
most process modelers and defines the flow of Activities of a specific Partner Entity or organization.
In contrast, Choreography formalizes the way business Participants coordinate their interactions. The
focus is not on orchestrations of the work performed within these Participants, but rather on the
exchange of information (Messages) between these Participants.

Figure 10: Example choreographies

 3. Collaborations

The Collaboration package contains classes that are used for modeling Collaborations, which
is a collection of Participants shown as Pools, their interactions as shown by Message Flows, and
MAY include Processes within the Pools and/or Choreographies between the Pools . A Choreography
is an extended type of Collaboration. When a Collaboration is defined it is contained in Definitions.

Figure 11: Example collaborations

3.3.BPMN viewpoints
As the name already indicates, BPMN is restricted to the business layer, with a strong
emphasis on the behavior aspect. The main purpose of the language is to provide a uniform notation
for modeling business processes in terms of activities and their relationships. The „pool‟, „lane‟ and
„artifact‟ concepts offer limited possibilities for including some structural and informational aspects
associated with the business processes.
 BPMN

3.4.General analysis on BPMN

1. Strengths of BPMN

BPMN is a standard, with very well defined syntax and a (sufficiently) defined semantics;
using BPMN you can reuse skills, training and tools (to some extent) between your analysts, and be
have reasonable expectations that your processes will execute the way you draw them .

Many vendors implement (almost all of) the standard, so you can expect a degree of
portability between different engines.

You can communicate outside the development group with expectations that, with a little
basic training, your diagrams will still be readable for someone who has not been involved in the
project .

You can reasonably expect (or lobby for) auditing bodies to understand BPMN as a published
standard and acknowledge the fact that your diagrams describe precisely how your processes is
implemented and run.

2. Weaknesses of BPMN

The weaknesses of BPMN could relate to:

  Ambiguity and confusion in sharing BPMN models.
 Support for routine work.
 Support for knowledge work, and.
 Converting BPMN models to executable environments.

3.5.Comparison between BPMN and Archimate

Currently, BPMN only defines a concrete syntax, i.e., a uniform (graphical) notation for
business process modeling concepts. However, there is a formal mapping to the XML based business
process execution language BPEL4WS. A formal meta model for BPMN does not (yet) exist.
However, to give an overview of the language, we show our interpretation of a meta model of the
main BPMN concepts in

Figure 12: BPMN metamodel

An event in BPMN is defined as something that “happens” during the course of a business
process. These events affect the flow of the process and usually have a cause (trigger) or an impact
(result). This closely matches the business event concept in ArchiMate. However, BPMN defines a
large number of specializations of the concept. The main specializations are start event, stop event
and intermediary events, but several subtypes of all of these exist. This is in agreement with the focus
of BPMN on detailed process modeling, which differs from ArchiMate‟s goal, i.e., to model the
overall structure of an enterprise.

An activity is a generic term for work that a company performs. An activity can be atomic or
non-atomic (compound). In this sense, it most closely matches the generic business behavior concept
in ArchiMate. Specializations of the activity concept are process (ArchiMate: business process), sub-
process (ArchiMate: business process/function) and task, defined as an atomic activity that is
included within a process (ArchiMate: business activity).

A gateway is used to control the divergence and convergence of sequence flow. Thus, it will
determine branching, forking, merging, and joining of paths. The gateway concept is useful mainly
for detailed process modeling, for which BPMN has been developed. BPMN defines a large number
of specializations of the gateway concept. The junction relation in ArchiMate, which is used to
model, e.g., split or joins of triggering relations, can be seen as an abstraction of the gateway concept.
However, the gateway concept often also implies behavior. If this behavior is relevant, a mapping to a
business activity (with multiple outgoing triggering relations, or followed by a junction) might be
more suitable.

A pool is a “swim lane” and a graphical container for partitioning a set of activities from other
pools, usually in the context of B2B situations. A lane is a sub-partition within a pool and will extend
the entire length of the pool, either vertically or horizontally. Lanes are used to organize and
categorize activities. Pools and lanes can be used to group activities based on arbitrary criteria. As
such, they can be mapped to the grouping relation in ArchiMate. However, they are most commonly
used to represent the actors or roles that perform to activities. In that case, they can be interpreted as
the business actor or business role concept in ArchiMate. The only relation that can be specified
between pools is a message flow. Placing activities within a pool or lane can be seen as a way to
specify the assignment between behavior and roles/actors in ArchiMate.

BPMN defines three types of artifacts, which are not formally defined as concepts. An
annotation is a textual annotation that can be associated with any concept. There is no separate
concept for this in ArchiMate. A data object represents data that can be accessed by activities, very
similar to the business object in ArchiMate. Finally, a group artifact can be used to group arbitrary
concepts, in the same way as the grouping relation in ArchiMate.
 A sequence flow is used to show the order that activities will be performed in a process. The
ArchiMate triggering relation can express this control flow in a quite similar way. A message flow is
used to show the flow of messages between two entities that are prepared to send and receive them. In
BPMN, two separate pools in the diagram will represent the two entities (participants). In ArchiMate,
the flow relation can be used to express this.

An association is used to associate information with flow objects. Text and graphical no flow
objects can be associated with the flow objects. Depending on the exact use, this is represented by the
access relation or the association relation in ArchiMate.

Summarizes the BPMN concept compare with Archimate concept:

3.6.Contribution from BPMN to Archimate
The coverage of BPMN is restricted to the business layer. Moreover, there is a strong
emphasis on the behavior aspect; actors/roles that perform the behavior can be modeled in a
limited way by means of pools and lanes.

All the main BPMN concepts (except Annotation) have an equivalent in ArchiMate,
while on the other hand not all of the ArchiMate concepts have a counterpart in BPMN.
However, BPMN has a large number of more specific concepts, which are defined as
specializations of the main concepts. This is in agreement with the objectives of the two
languages: while ArchiMate is designed to describe the high-level architecture of the whole
enterprise, BPMN focuses on the detailed description of business processes.

Currently, BPMN does not have a formal meta-model and the concepts and relations
have not been defined in a strict way. The emphasis is on the graphical notation of the
language.
4. UML

4.1.Overall about UML

UML is a general purpose modeling language. It was initially started to capture the behavior
of complex software and non-software system and now it has become an OMG standard.

UML provides elements and components to support the requirement of complex systems.
UML follows the object oriented concepts and methodology. So object oriented systems are generally
modeled using the pictorial language.

UML diagrams are drawn from different perspectives like design, implementation,
deployment etc.

At the conclusion UML can be defined as a modeling language to capture the architectural,
behavioral and structural aspects of a system.

Objects are the key to this object oriented world. The basic requirement of object oriented
analysis and design is to identify the object efficiently. After that the responsibilities are assigned to
the objects. Once this task is complete the design is done using the input from analysis.

The UML has an important role in this OO analysis and design, The UML diagrams are used
to model the design. So the UML has an important role to play.

4.2.Language structure
In this document we consider the latest version of UML, UML 2.0 (Object Management
Group, 2003a and 2003b). UML describes 13 sublanguages, each having own diagram to model a
specific aspect of a (software) system. These diagrams can be considered the viewpoints of UML.
The diagrams can be grouped in three categories of UML diagrams; structure, behavior and
interaction.

1. The following diagrams model structure:

A Class diagram shows the structure of the system on the type level, using classes and
relationships between the classes. A class is a particular kind of thing logically important enough to
see instances of it frequently occurring in the various instantiated models. A relationship expresses
how classes correspond with each other, could depend on each other, could influence each other, and
could be connected to each other.

An Object diagram shows the structure of the system on the instance level at a certain point in
time, using objects and links between the objects. An object diagram is quite similar to a class
diagram. An object is a concrete thing of the type described by the class of which the object is an
instance of; a link between objects is the concrete relation of the type described by the relationship of
which the link is an instance. In this sense an object diagram describes the concrete or instantiated
logical structure of a system at a certain point in time, exactly conforming to the type description of
the corresponding class diagram.

A Package diagram shows how model elements are grouped into packages as well as the
dependencies between packages. A package can import individual elements or other packages.

A Composite structure diagram depicts physical connections between (logical) elements (like
classes/objects, packages, use cases). With the diagram, a class can be hierarchically decomposed into
an internal structure that represents the runtime decomposition of the class. There are two
appearances: via ports and connectors or as collaboration (of roles: views on elements).

A Component diagram describes the global physical organization of the system into so-called
components: components reflect an application, system or enterprise. In the context of software, a
component often is a (large) subsystem of a software system, or even the whole software system.

A Deployment diagram describes the actual assignment of the components to various,

concrete physical resources held responsible for containing or performing what is modeled in such a
component. In the case of a software system, usual physical resources are pieces of hardware, such as
storage memory, a network, a computer or processor. It shows the storage or execution architecture of
the system.

2. Behavior

A Use Case diagram models the behavior of a system using actors and use cases, as seen from
the outside. The model is declarative with respect to the functionality expressed: each use case
represents one (large) functionality. The functionality should be provided by the system to actors
representing the various stakeholders. Moreover, for each use case the various (main) scenarios
describing how to use that particular functionality are given, thus modeling the possible interactions
taking place between the actors and the system when that functionality is being used. The way these
scenarios are specified is not fixed; they may be formulated in more or less structured English, which
is not uncommon.

A State Machine diagram describes local behavior through state changes of a concrete object
while in execution, by performing internal steps or driven by messages received from outside or by
sending messages out. At each point in time the current state represents the situation reached by the
execution so far. Thus a State Machine diagram models the local flow of control from state to state
within an object, i.e. within a conceptually small part of the system.

An Activity diagram describes more global behavior through the flow of control within some
larger part of the system, from object or actor to object or actor, again in terms of states. In this case a
current state represents a situation as far as it is relevant for this more global form of control flow.
Quite commonly, state changes, for instance on the basis of having finished an activity, correspond to
the effect of having performed a local operation, often triggering an activity in another object or actor.

3. Interaction

Communication diagram: Shows instances of classes, their interrelationships, and the message
flow between them, restricted to one (type of) scenario. Communication diagrams typically focus on
the structural organization of objects that send and receive messages. The ordering within the
scenario is described through enumeration. In UML 1.x these diagrams were called Collaboration
diagrams. In UML 2.0 the Collaboration diagram still present, but has no “official” status. This
diagram is mainly used to group classes, thus creating so-called collaborating classes.

A Sequence diagram shows instances of classes and the message flow between them. In
contrast to a communication diagram a message flow is not restricted to one (type of) scenario, but to
as many scenarios as wanted. The ordering within the scenarios is not through enumeration but along
a scale-less time axis, so-called lifelines. Along a vertical time axis - the lower the later - the order of
sending and receiving messages (events, triggers, data, and signals) between objects (and actors) is
indicated.

An Interaction Overview diagram combines the flow structure of activity diagrams with
sequence diagrams. It does so by replacing activities by sequence diagrams; their lifelines, so to
speak, correspond to the swim lanes. So all "activities" are formulated in terms of interaction
scenarios. By reusing the flow structure of activity diagrams, interaction overview diagrams are
"complex" sequence diagrams with many smaller sequence diagram-like fragments.

A Timing diagram combines a sequence diagram and explicit time; instead of lifelines,
sequences of (local) state changes specify the scenarios where time annotations make time explicit. It
is typically used to show the subsequent state changes of one or more objects over time in response to
events, internal as well as external.

4.3.UML viewpoints
UML offers a set of 13 diagrams for modeling different aspects of software systems. But these
diagrams may be used for modeling more general dynamic systems as well. So, we are put all it in the
same framework of Viewpoint to compare with Archimate and BPMN

There is no grouping of UML diagrams into business, application and technical/infrastructure

present, since UML was only intended for software systems. Therefore it is difficult to make a
distinction between business, application and technical. Therefore, the lines that create this division
are dashed, to note that this is not a strict division.
 Although it is not a priori clear how to apply the UML concepts to modeling business
architecture, we have projected the different diagram types into the ArchiMate framework.

4.4.General analysis on UML

1. Strengths of UML

UML has several strengths which lift it above any of the methods and notations which
preceded it:

Breadth of coverage: UML covers the entire software lifecycle from requirements
capture through to physical design and deployment. It encompasses both dynamic and
static elements and provides focus for both timing critical and data critical systems.

Standardization: UML has brought together the 3 main strands of OO notation. It

has also been accepted by Coad who was a minority player. Only Schlaer-Mellor stand
apart from UML. Standardization of notation is vital for the software industry if it is to
move on to more important topics and start to share ideas in a consistent way as other
engineering disciplines do.

Industry backing: Most tool manufacturers, recognizing both the weight of support
and the advantages of standardization, are providing UML support in their CASE tools.
More will surely follow.

Extensibility: UML provides a mechanism for extending the notation by means of

'stereotypes'. This is undoubtedly a good thing but does lead to some unfortunate side
effects.

The BPMN notation is very intuitive, which facilitates the illustration and read
large and complex processes.

2. Weaknesses of UML

UML has in my opinion three serious deficiencies:

 Lack of Graphical Separation: UML uses a relatively small number of shapes to
represent a large number of concepts. This homogeny results in diagrams where it is
difficult to determine content easily. It is even at times difficult to determine what the
diagram represents at first glance(classes or objects, static or dynamic relationships)

Overuse of Stereotypes: This is a related point to the above but taker‟s it a stage
further. Many of the design elements which had a distinct appearance in the individual
notations have been merged and separated only by the stereotype notation. Examples
include: meta-classes, class categories, interface classes etc. The result is that diagrams
cannot be easily understood visually but rather individual labels must be read to
distinguish the nature of the items. As mentioned above stereotypes are a great way of
adding new features to the notation but they should not be used for fundamental features.

Reduced emphasis on Physical Design: Despite Booch( Grady Booch, James

Rumbaugh and Ivar Jacobsen of Rational Cor who has been developed as a notation for
software engineering ) providing a rich and useful set of icons for physical design, and the
fact that none of the other notations offered anything similar UML has removed many of
these leaving only the package (sometimes stereotyped as a subsystem, and possibly with
COM interface lollipops) and the Node(whether active or passive) Tasks, processes,
interfaces, implementation, module have all gone the way of the dodo. Physical design is
often neglected by software engineers and this de-emphasis in UML can only encourage
that trend.

4.5.Comparison between UML and Archimate

We start with analyzing the structural concepts, followed by the behavioral concepts and
ending with the informative concepts. The structural concepts are the concepts that are easiest to
understand since they are similar to well-known structural notions in other formalisms. So they are
relatively easy to translate. The behavioral concepts are a bit less common. Finally, the informative
concepts are even more difficult to understand and therefore to translate, as they are rather
uncommon.
 For the translation we have used the generic Archimate Meta-model. We translate from
ArchiMate to UML. The ArchiMate concept is highlighted in bold; the UML concept is on the right
side of the arrow. Our approach in translating ArchiMate meta-model concepts to UML is to match
properties based on the characterizations of ArchiMate concepts. In some cases a match can be found
for properties corresponding to different UML concepts.

The translation shows the ArchiMate concept, followed by the chosen UML concept(s). In our
approach the arguments for our choices of UML concepts are given after the translation. More detail
please read in referent (Mapping between Archimate and standard and file excel )

Table 8: Summarize compare Archimate and UML

Archimate concept UML equivalent concept

Structural Element Class
Object Class
Actor Class
Role Class
Collaboration Collaboration
Interface Interface
Behavioral Element Sequence or Activity
Sequence or Interaction
Interaction
Overview
Process/function Activity or Sequence
Event Interaction in Sequence
Service Operation of an Interface
Informative Element Use Case(s) or Note(s)
Purpose Use Case(s)
Meaning Note(s)
Representation Note(s) or Class

The relations from the ArchiMate meta-model are very important too, as they express how in
any concrete ArchiMate model the concrete instances of the different meta-model concepts can be
related.

So, by translating the ArchiMate meta-model relations in a straightforward manner to UML

relationships (associations, specializations, and aggregations) one can infer the required ArchiMate
consistencies into the corresponding UML model. This is really relevant for a possible UML profile
for the ArchiMate approach. Consistency checking and management between different kinds of UML
diagrams can be based on the consistency of the ArchiMate meta-mode.
4.6.Contribution from UML to Archimate
When using UML directly, there is a very strong inclination to express technical details.
Although such details certainly make sense, from the perspective of a software developer, these
details are not present in the original ArchiMate example model. This results in leaving out
(unwanted) details, making it difficult to use and explain UML. In particular since, when using
the declarative style, sometimes the resulting UML diagrams are strictly speaking incomplete.
As a result this makes it difficult to verify the correctness of a diagram.

The ArchiMate approach hides technical details. ArchiMate models tend to leave out
technical details concerning communication and other behavioral aspects. In this way it is left
open which participant (role) in an interaction exactly does what for whom and when.

Perhaps it is UML's property of nearly forcing a UML modeler to add such technical,
constructive details, why some authors argue that UML is not sufficiently suited for the
modeling needs of business architects, and the like.

ArchiMate and UML can be combined. Alignment and integration between different
UML diagrams can be verified through ArchiMate. On the other hand ArchiMate models may
be studied, via its UML translation, in the context of UML models.
5. Proposal on application of Archimate, BPMN and UML
The harmonization approach assumes a repository-based modeling tool that can accommodate
all three notations, and people with the relevant skills in the various notations.

In addition, the Zachman principle of maintaining primitives before creating composite

models is a prerequisite. A primitive model or list describes a singular aspect (element) of the
organization (without relating it to anything) for example: role, organization unit, risk, control,
application, data entity. A composite model on the other hand is specifically focused on showing how
things interrelate and will therefore always consist of a combination of primitives that relate to each
other.

When you create composite models (relating these different elements together) you can reuse
objects created and maintained in the primitive models/lists. This will enable easier re-use and
maintenance of objects.

Use ArchiMate for all the high-level modeling as defined in the business architecture layer,
creating your organization chart, strategy models, functional decomposition, etc. using the ArchiMate
notation. ArchiMate is useful here since it contains the constructs to create these views and BPMN
doesn‟t (see BPMN 2.0 Specification Concepts).
 Figure 13: Example ArchiMate Models

When it comes to defining process models, it is recommended that a process leveling approach is used
which ensures that process models are created for a specific audience, keeping in mind what the focus of that
specific stakeholder is (Viljoen, 2012). This is the first suggested integration point between ArchiMate and
BPMN. Use ArchiMate for the high-level processes (level 0 through 3 in the example) and BPMN for the more
detailed operational processes (level 4 in the example below).
 Figure 14: Example Showing Integration between ArchiMate and BPMN
To model the Application Architecture, ArchiMate can also be used to model the contextual and
conceptual definition of applications, and then link the more specialized UML notation below the conceptual
layer to create the models describing the structure or behavior of specific applications.

Figure 15: Example Showing Integration between ArchiMate and UML

When important relationships between layers or components need to be modeled, any of the
ArchiMate viewpoints can be used.
 The Application Usage Viewpoint can be used to describe how applications are used to
support processes and how they are used by other applications (The Open Group, 2012).

Figure 16: ArchiMate Application Usage Viewpoint

Use the Infrastructure Usage Viewpoint to show how applications are supported by hardware
and software infrastructure, the infrastructure services delivered by infrastructure and system and
networks provided to the applications (The Open Group, 2012).
 Figure 17: ArchiMate Infrastructure Usage Viewpoint Example
Although a UML Deployment diagram can be created, the ArchiMate Implementation and Deployment
Viewpoint is suggested for defining context and scope. The advantage of the ArchiMate viewpoint being that it
stays at the concept level (rather than drill into detail) to inform the organization at the same time as promoting
the re-use of application and infrastructure components.

Figure 18: ArchiMate Implementation and Deployment Viewpoint Example

Considering the meta-models in context to each other, the ArchiMate Business Layer and BPMN
meta-models can be harmonized or linked in the following way:
 Value Business Business Business
Service Interface Actor

Product
Business
Process/ Business
Meaning Function Role
interaction

Business
Business Object
Collaboration
Contract

Business Location
Representation
Event

Heading

Contain Lane

Is sub-devided by

Sub-devides

Flows between
Pool Message

Contained in

Contain Contain

triggers Control Control by

Event Caused Activity Gateway
by Sequence of
Used by/produced
Is associated with
by

Is associated with Is associated with Is associated with

Text
Data Object Group
Annotation

Figure 19: Combined ArchiMate Business Layer and BPMN Meta-Models

 Application Application
Service Interface

Data
Object
Application
Component
Application
/Function
interaction Application
Collaboration

Is grouped in
Message Package
Is associated
with User case
Send/receives grouped

Contains
Is sent/received by

deployed Is contained in
Lifeline Component Is deployed Node
on
System
Relised Boundary Box
by

Relised
Links Is linked by
Is associated Collaboratio
Actor with Interface Object
n links

Figure 20: Combined ArchiMate Application Layer and UML Meta-Models

6. Conclusions and Perspectives

6.1.Conclusion
BPMN and UML notations will most likely be used in organizations that go to the trouble of
defining their process architecture and application designs. From an EA perspective, these types of
exercises produce outputs that are not useful for our stakeholders expecting to be informed on
concepts and scope rather than on the detail of implementation or design.

For that reason an approach to harmonize the ArchiMate, BPMN and UML modeling
notations are proposed. The harmonization involves using the specific modeling notation for its
intended use and playing to its strengths. ArchiMate models the concepts (the architecture) well,
whereas BPMN models the implementation processes and UML the software designs.

What remains is to detail how these languages and their meta-models will co-exist and in
harmonizing, add value to the organization.

Understanding each of the notations discussed above and their defined concepts will enable
Enterprise Architects to select the relevant aspects of each notation that will work for their specific
Enterprise Architecture initiatives. This will ensure that the Enterprise Architectures are built using
fit-for-purpose notations: when processes are defined, a standard notation is used which was
originally designed to define processes; when describing application behavior, a standard notation is
used which was designed for describing applications; and when describing the Enterprise
Architecture on a high level and how the different elements impact each other, a standard notation is
used which was designed for that.

Designing and building an Enterprise Architecture in this way will ensure that it is appropriate
and relevant to the audience it was intended for.

6.2.Perspectives
In this document, we used Archimate in high level of business process modeling and
technology modeling( descries in 1.2 Architecture leveling), when we descries more detail about
business process and technology( software and infrastructure ), we use BPMN and UML.
 We will research about BPEL and BPM to apply for more detail of business process, and
compare it. After that we will find how to apply it into architecture .
7. Reference
http://ipapi.org/wiki/index.php/BPMN
The Open Group standard Archimate 1.0 Specification
The Open Group standard Archimate 2.0 Specification
The Open Group Business Process Model and Notation 2.0
Unified Modeling Language: Superstructure
ArchiMate Language Primer, TI reference : TI/RS/2004/024, Author(s) : Marc Lankhorst and
the ArchiMate team
ArchiMate, BPMN and UML: An approach to harmonizing the notations, Michelle van den
Berg Business Architecture Consultant Real IRM Solutions
Reflections on Business Process Levelling, Sarina Viljoen Specialist Consultant
Towards a UML profile for theArchiMate language ArchiMate Deliverable 2.2.3c, Maria-
Eugenia Iacob (TI) Henk Jonkers (TI)Martijn Wiering (LIACS)
UML Process, Sharam Hekmat PragSoft Corporation