IT Architecture Modelling using ArchiMate® 2.1 … · • Attend accredited training course • No pre-requisites Study Track • Architects • Those wanting or needing an understanding

IT Architecture Modelling using ArchiMate® 2.1 Delegate Guide

IT Architecture Modelling using ArchiMate® 2.1

Contents Introduction ......................................................................................................................................... 1

Basic Concepts and Definitions ........................................................................................................ 5 Language Principles ........................................................................................................................... 7

Relationships ..................................................................................................................................... 17

Architecture Layers .......................................................................................................................... 27

Language Extensions ....................................................................................................................... 55

Views and Viewpoints ....................................................................................................................... 69

Adapting ArchiMate, Tools, Frameworks and Languages .......................................................... 112

Copyright Notice Includes extracts of text and diagrams from the ArchiMate® 2.1 Specification

Copyright © 2013 The Open Group

Page i


Introduction

Contains material extracted from the ArchiMate® 2.1 Specification

© 2012-2013 The Open Group, All Rights Reserved

Page 1


• Basic Concepts and Definitions• Language Principles• Relationships• Architecture Layers

Day 1

• Architecture Layers (continued)• Language Extensions

Day 2

• Viewpoints• Adapting ArchiMate• Tools, other Frameworks and Languages• Preparation and exam

Day 3



Page 2


• Attend accredited training course

• No pre-requisites

Study Track

• Architects• Those wanting

or needing an understanding of ArchiMate

Target Audience

• 40 multi-choice questions

• 60 minutes• Pass mark: 24• Closed book

Foundation Exam

• 8 complex multi-choice questions

• 90 minutes• Pass mark: 28• Open book

Certified Exam

• Location and exam delivery organised by the Training Provider

Exam Location



Page 3


Resources • Open Group link: http://www.opengroup.org/subjectareas/enterprise/archimate • Books:

• ArchiMate on YouTube • Whitepapers and Publications from Open Group o Pocket Guide o Understanding the Basics (Whitepaper) o Study Guides: Part 1 & Part 2

• Dropbox

https://www.dropbox.com/sh/rk2bvf2ra35hp3t/NaJ6RSOSuf



Page 4

http://www.opengroup.org/subjectareas/enterprise/archimate

https://www.dropbox.com/sh/rk2bvf2ra35hp3t/NaJ6RSOSuf


Basic Concepts and Definitions

Objectives Introduce basic concepts and terminology:

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

Definition of an Enterprise Fundamentally this is a collection of Organisations that share the same goal.

Examples:

• Government Agency • Corporation • Division of a Corporation • Department • Geographically distant organisations linked by common ownership

The definition of Enterprise has been taken from TOGAF® 9, and reflects the common heritage that ArchiMate now has.

The definition of an enterprise is very broad, ranging from mega-corporations and government departments, through to a single department. The point being made that in each of these examples is a range IT-related issues that must be handled by the architect.

However, in reality, these “definitions” can also be recognised as examples of types of enterprise, each having their own characteristics that must be accommodated by Enterprise Architecture.

Purpose of Enterprise Architecture • Optimise fragmented systems • Establish a strategic context • Enable business innovation via efficient IT technology

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

EA aims to:

• Co-ordinate fragmented systems and processes, • Do so on the basis of a strategic understanding of what the organisation needs, • Ensure the right degree of Information Technology efficiency (perhaps measured by its

capabilities) in order to support business innovation

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



Page 5


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

Mission

• To provide a specialised modelling notation for Enterprise Architecture • Addresses the main architectural layers • Philosophy is to remain simple, high-level / conceptual and small

Architecting complex systems is a critical task. The description of systems (its architecture) is needed in order to provide maximum support to the Enterprise.

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

ArchiMate fills this gap. It is designed to address the key areas of architecture (Business, Applications and Technology), with just sufficient capabilities to describe the architecture at a high-level. Other designers / engineers can then take over with the detailed design.

ArchiMate Layers • Business Layer o The Business Layer offers products and services to external customers, which are realized

in the organization by business processes performed by business actors. • Application Layer o The Application Layer supports the business layer with application services which are

realized by (software) applications. • Technology Layer o The Technology Layer offers infrastructure services (e.g., processing, storage, and

communication services) needed to run applications, realized by computer and communication hardware and system software.

These layers are shared by other frameworks, most important of which is TOGAF, although TOGAF call them Business, Information System (Application and Data) and Information Technology.



Page 6


Language Principles

Objectives Understand the principles and core concepts:

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

Underlying Ideas Mission

• To provide a “small” yet comprehensive modelling language • Addresses the needs of Enterprise architecture • Aimed purely at architects • Covers the main Architecture domains

The need to describe the architecture of IS/IT systems is fundamental to the governance of an organisation. But there are several hurdles that must be overcome.

Firstly, decisions need to be made as to the way these systems, which are likely to be very complicated in larger organisations, are described. A general approach is to think of the “entities” which the system consists of, and the way they relate to each other. Inevitable as these entities are considered, the need to look at them in more specialised ways (i.e. business process view; software application view) becomes apparent. Architecture focuses on the highest level of detail.

Secondly, it is important to establish some formality to the way the architecture is described. EA does not need to be as detailed, for instance, as Business Process Modelling, and therefore does not need such a complexity of symbols.

ArchiMate has addressed both these issues by being relatively general, and by focussing on the main areas of importance to architects – Business, Application and Technology.



Page 7


Core Concepts Active structure

Behavior Passive structure

English sentence: “An Order is taken by a CSR”

Service

Interface

ArchiMate is promotes a service-orientated style of EA

Collaboration and interaction

Roles collaborating to execute behaviour

Relationships

ArchiMate has a rich set of relationships

Architecting is all about describing entities and understanding the relationship between them. The entities tend to fall into three categories. They are an element of the structure of a system, capable of doing things. The things they do can be described as their behaviour. And what they use, in this “information age” is... information! Think of information as “passive” – it doesn’t do anything by itself, but is used the system as a whole. The idea of active, behaviour and passive reflects the way natural language has a subject (active structure), a verb (behaviour) and an object (passive structure).

Service-orientation is an increasingly important style of architecting. So to cater for this both a Service and Interface element is included. The service represents some form of activity (often subject to service levels). The interface exposes the service to the environment. Both services and interface face externally, hiding the internal characteristics of the system.

Concerning behaviour, ArchiMate is interested in the highest level activities only. Anything more detailed can be dealt with by other modelling approaches. But very important to the architect is the way that key elements of the system collaborate with each other, and the detail of that collaboration – refer to as Interaction.

And finally, understanding relationship is vital to clarifying the purpose of each element. ArchiMate has a relatively small set of relationships.

Active Structure Elements Definition An entity capable of performing behaviour

Examples

• Business Interface • Business Actor • Business Role • Application Interface • Application Component • Device • Network



Page 8


Behaviour Elements Definition A unit of activity performed by one or more active structure elements.

Examples

• Business Process • Business Function • Business Interaction • Application Function • Application Interaction • Infrastructure Function

Passive Structure Definition An object on which behaviour is performed.

Examples

• Business Object • Data Object

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

Examples

• Business Service • Application Service • Infrastructure Service

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

Examples

• Business Interface • Application Interface • Infrastructure Interface



Page 9


Core Metamodel

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

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

Example Core Elements



Page 10


Collaboration and Interaction Definitions

• Collaboration: a (temporary) grouping (or aggregation) of two or more structure elements, working together to perform some collective behaviour

• Interaction: a unit of behaviour performed by a collaboration of two or more structure elements

Examples

• Business Collaboration, Interaction • Application Collaboration, Interaction



Page 11


Relationships

Structural (strongest – weakest)

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

Dynamic

• Triggering • Flow

Other • Grouping • Junction • Specialization

ArchiMate Layers • Business

Offers products and services to external customers, which are realised in the organisation by business processes performed by business actors

• Application Supports the business layer with application services which are realised by (software) applications

• Technology Offers infrastructure services (e.g., processing, storage, and communication services) needed to run applications, realised by computer and communication hardware and system software

A common approach to architecture that has been adopted for a long while is to represent systems as layers.

There are natural used by relationships between the two:

• Application Services are used by Business Processes • Technology Services are used by Applications

This is commonly known as the “Layered Pattern”.

However, there is a different relationship between layers, which will be described as “realisation”. For instance, a general business-related document, such as a purchase order (in the Business Layer), is eventually realised by a formal data model (in the Application Layer).



Page 12


The ArchiMate Framework

The framework is a structure into which the elements of the language can be positioned. However, there are other elements related to areas such as:

• Goals, principles, and requirements • Risk and security • Governance • Policies and business rules • Costs • Performance • Timing • Planning and evolution

However, extensions to the language can be permitted, two of which will be explained next.



Page 13


ArchiMate and TOGAF Layers

The idea of layer, as mentioned already, is not new. A well-established implementation of architecture layering is used by TOGAF.

Their “Architecture Development Method” addresses a Business, Information System and Technology layer, all of which are matched with the ArchiMate layers. The Information System, according to TOGAF consists of Applications and Data – these are both covered in the ArchiMate Application layer.

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



Page 14


Motivation Extension Definition An element that provides the context or reason lying behind the architecture of an enterprise.

Examples

• Driver • Goal • Principle • Requirement

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



Page 15


Implementation and Migration Extension Examples

• Work Package • Plateau • Gap • Deliverable

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



Page 16


Relationships

Objectives Explain in detail ArchiMate Relationships:

• Relationship between Layers • Types of Relationship

Relationship Types Overview • Structural

o Composition, Aggregation, Assignment, Realisation, Used By, Access, Association • Dynamic

o Triggering, Flow • Others

o Grouping, Junction, Specialisation • Motivational

o Association, Aggregation, Realisation, Influence • Derived



Page 17


Structural Relationships • Composition • Aggregation • Assignment • Realisation • Used By • Access • Association

Composition

…indicates that an object is composed of one or more other objects.

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

Aggregation

…indicates that a concept groups a number of other concepts.

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



Page 18


Assignment

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

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

• Business role with a business process or function • Application component with an application function • A business collaboration with a business interaction • An application collaboration with an application interaction • A business interface with a business service • An application interface with an application service • A business actor with a business role

Realisation

…links a logical entity with a more concrete entity that realises it.



Page 19


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

Used By

…models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.

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

Access

…models the access of behavioural concepts to business or data objects.

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



Page 20


Association

…models a relationship between objects that is not covered by another, more specific relationship.

The Association is the most general (weak) relationship which can be applied between any elements. It is particularly used in connection with information elements:

• A business object with a representation • A representation with a meaning • A business service with a purpose



Page 21


Dynamic Relationships • Triggering • Flow

Triggering

…describes the temporal or causal relationships between processes, functions, interactions, and events.

In effect a Trigger relationship makes something happen (i.e. it causes something – causal) as a result, and is therefore most important with processes.

Flow

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

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



Page 22


Other Relationships • Grouping • Junction • Specialisation

Grouping

…indicates that objects belong together based on some common characteristic.

A group is a kind of package into which elements can be put. Except there is no concept of a Group “object”; nor is there any composition / aggregation.

Junction

…used to connect dynamic relationships of the same type.

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



Page 23


Specialisation

… indicates that an object is a specialization of another

This replicates the UML concept of Generalisation / specialisation (inheritance), but with wider scope. Specialisation can also relate any instances of an element with another.

Motivational Relationships

• Association • Aggregation • Realisation • Influence



Page 24


Derived Relationships …if two structural relationships r:R and s:S are permitted between elements a, b, and c such that r(a,b) and s(b,c), then a structural relationship t:T is also permitted, with t(a,c) and type T being the weakest of R and S.

Derived Relationships make it possible to create, for coherence purposes, links between elements that are not necessarily directly related. Although by association they are linked. Therefore the idea is that the weakest of those associations can be used to directly associate the original elements. Regarding the “strength” of relationships, the strongest is Composition; weakest is Association.



Page 25


Relationships between Layers • Used By • Assignment • Realisation

An important architecting issue is the alignment of system to requirement – otherwise referred to as Business / IT alignment. This can be achieved by highlighting the links between elements in their different layers. Three types are key, and they can relate to Business / Application (B/A) and Application / Technology (A/T) relationships:

1. Used By: which expresses the relationship between behavioural and structural elements, e.g. Application Service used by Business Process (B/A), or Infrastructure Interface used by Application Function (A/T)

2. Realisation: shows how elements in different layers are “made real”, e.g. Data Object realises Business Object (B/A), Artifact realises Application Component (T/A)

3. Assignment: this is relevant only in B/A relationships and can be used to indicate degrees of automation. Assignment suggest full automation, e.g. Application Component assigned to Business Process / Function / Interaction. A way to indicate the relationship is less automated would be to use the used by relationship.



Page 26


Architecture Layers Objectives Explain in detail concepts in the three main Layers:

• Business Layer • Application Layer • Technology Layer



Page 27


Business Layer Metamodel

This metamodel deals solely with the ArchiMate elements in the business layer, and their most basic associations.

It also introduces several more Information Elements (Passive Structure), shown on the left. They can be used to enrich the detail of business views.

Business Layer: Active Structure Concepts • Business Actor • Business Role • Business Collaboration • Business Interface • Location



Page 28


Business Actor

...an organisational entity capable of performing behaviour.

Common Relationships

• Business Actor assigned to Business Role

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

Business Role

...responsible for performing specific behaviour, to which an actor can be assigned.


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



Page 29


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

Business Collaboration

...aggregate of two or more roles that work together to perform collective behaviour.


• Business Collaborations aggregated of roles • Business Collaboration assigned to Business Interactions • Business / Application Interface used by Business Collaboration • Business Collaboration composed of Business Interfaces

A Business Collaboration will occur between two or more business roles. For instance, a salesperson collaborates with a customer (external) or a sales manager may collaborate with a sales person (internal). In a B2B context, organisations collaborate with each other. The name should preferably be a noun.

Collaboration is a way of recognising the existence of some link between roles. The actual behaviour is regarded as a Business Interaction.



Page 30


Business Interface

...a point of access where a business service is made available to the environment.


• Business Role composed of a Business Interface • Business Interface used by a Business Role • Business Interface assigned to Business Services

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

Location

...a conceptual point or extent in space.


• Location assigned to other Structural elements • Location assigned to other Behavioural elements

The Location models the distribution of structural elements.



Page 31


Business Layer: Behavioural Concepts • Business Process • Business Function • Business Interaction • Business Event • Business Service

Business Process

...groups behaviour based on an ordering of activities. It is intended to produce a defined set of Products or Business Services.


• Business Process triggered by or triggers any other business behaviour element • Business Process accesses Business Objects • Business Process realises one or more Business Services • Business Process may use (internal) Business Services or Application Services • Business Role or Application Component assigned to Business Process

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



Page 32


Business Function

...groups behaviour based on a chosen set of criteria (typically business resources and / or competencies).


• Business Function triggered by or triggers any other business behaviour element • Business Function accesses Business Objects • Business Function realises one or more Business Services • Business Function may use (internal) Business Services or Application Services • Business Role or Application Component assigned to Business Function

In effect it is internal behaviour performed by a Business Role. A key point – processes and function apply to a single role. Should be named as a verb ending in “-ing” (the gerund).

Business Interaction

...describes the behaviour of business collaboration.


• Business or Application Collaboration assigned to Business Interaction • Business Interaction triggered by or triggers any other business behavioural element • Business Interactions access Business Objects • Business Interaction realises one or more Business Services or Application Services



Page 33


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

Business Event

...something that happens (internally or externally) and influences behaviour.


• Business Event may trigger or be triggered by a Business Process, Function or Interaction • Business Event may access a Business Object • Business Event may be composed of other Business Events

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



Page 34


Business Service

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


• Business Service associated with a value. • Business Process, Function or Interaction may realise a Business Service • Business or Application Interface assigned to a Business Service

A Business Service exposes functionality of [is performed by] business roles or collaborations to the environment; must be realised by a process or function. Can be associated with a value. Name using a verb with “-ing” at the end (a present participle).



Page 35


Business Layer: Passive Structure Concepts • Business Object • Representation • Meaning • Value • Product • Contract

Business Object

...a passive element that has relevance from a business perspective.


• Business Object accessed by Business Process, Function, Interaction, Event, Service • Business Object association, specialisation, aggregation, composition with other

Business Objects • Business Object realised by a Representation and / or Data Object

Business Objects represent “informational” or (importantly) conceptual elements of relevance to the business. For instance a Sales Catalogue can be regarded conceptually as a means of providing information on items for sale. It could be represented in several ways – as a brochure, or web page. However, its “raw data” will be part of the Applications Layer.



Page 36


Representation

...a perceptible form of the information carried by a business object.


• Representation realises one or more Business Objects • A Meaning can be associated with a Representation

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



Page 37


Meaning

...the knowledge or expertise present in a business object or its representation, given a particular context.


• A Meaning is associated with a Representation

Meaning expresses the intent of a representation, i.e. an “Invoice” is a document that details exactly what money is owed to the seller by the purchaser. As such meanings are a valuable way of detailing business semantics. Sometimes a single representation can have different meanings to different actors / roles, i.e. an invoice to a customer is informational, and to a sales person is an opportunity for commission. A single meaning can also be applied to multiple representations, such as paper-based or web-based forms. The name should be a noun or a noun phrase.



Page 38


Value

...the relative worth, utility or importance of a business service or product.


• A Value can be associated with Business Services (directly) and Products, Roles and Actors (indirectly) that use them

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

Product

...a coherent collection of services, accompanied by a contract / set of agreements, which is offered as a whole to (internal or external) customers.


• A Product aggregates Business or Application services, as well as a Contract. • A Product may be associated with a Contract, Value



Page 39


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

Contract

...a formal or informal specification of an agreement that specifies the rights and obligations associated with a product.


• A Contract is accessed by Business Process, Function, Interaction, Event, Service • A Contract has an association, specialisation, aggregation, composition with other

Contracts • A Contract is realised by a Representation and / or Data Object

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



Page 40


Application Layer Metamodel



Page 41


Application Layer: Active Structure Concepts • Application Component • Application Collaboration • Application Interface

Application Component

...a modular, deployable, and replaceable part of a software system that encapsulates its behaviour and data and exposes these through a set of interfaces.


• Application Component assigned to Application Functions, Business Processes and Business Functions

• Application Component composed or aggregated of Application Interfaces

Think of the Application Component as eventually the physical software that will perform the necessary functions. It is independently deployable, reusable and replaceable. Its name should use a noun.



Page 42


Application Collaboration

...an aggregate of two or more application components that work together to perform collective behaviour.


• Application Collaboration is a specialisation of a component • Application Collaboration assigned to Application or Business Interactions • Application Collaboration aggregated of Application Components • Application Interface used by Application Collaboration • Application Collaboration composed of Application Interfaces

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

Application Interface

...a point of access where an application service is made available to a user or another application component.


• Application Component composed of Application Interface(s) • Application Interface assigned to Application or Business Services

Specifies how the functionality of a component is accessed by other components. In conceptual terms similar to an Application Programmers Interface listing a set of functions. In addition, details such as parameters, protocols, pre/post conditions and data formats could be included. A quality of interfaces is that they represent an obligation or contract that a component realising the interface must provide. Can be a provided or required interface. Name using a noun.



Page 43


Application Layer: Behavioural Concepts • Application Function • Application Interaction • Application Service

Application Function

...a behaviour element that groups automated behaviour that can be performed by an application component.


• Application Function realises Application Service(s) • Other Application Services or Functions used by Application Functions and Infrastructure

Services • Application Function accesses Data Object • Application Component assigned to Application Function

The Application Function in fact refers to “black box” activity / behaviour done internally by Application Components. Name using a present participle.



Page 44


Application Interaction

...a behaviour element that describes the behaviour of application collaboration.


• Application Collaboration assigned to Application Interaction • Application Interaction realises an Application Service • Application Services and Infrastructure Services used by Application Interaction • Application Interaction accesses Data Object

The Application Interaction provides the general behavioural detail that lies behind a collaboration. A UML Sequence Diagram is useful to model the detail. Name using a verb.



Page 45


Application Service

...a service that exposes automated behaviour.


• Application Service used by Business Processes, Functions, Interactions or Application Functions

• Application Function realises Application Service • Application Interface assigned to Application Service • Application Service accesses Data Object

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



Page 46


Passive Structure Concept • Data Object

Data Object

...a passive element suitable for automated processing.


• Data Object accessed by Application Function, Interaction, Service. • Data Object realises a Business Object • Artifact realises a Data Object • Data Object associated, specialised, aggregated or composed of other Data Objects

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



Page 47


Technology Layer Metamodel

Technology Layer: Active Structure Concepts • Node • Device • System Software • Infrastructure Interface • Communication Path • Network

Node

...a computational resource upon which artifacts may be stored or deployed for execution.


• Nodes aggregated, composed of other Nodes, Devices and System Software • Nodes can be interconnected by Communication Paths • Artifacts can be assigned to Nodes



Page 48


Think of a node as a logical container for Devices and System Software. Indeed at the highest level a node could represent some form of software or hardware resource. Nodes can consist of sub-nodes. Its name should be a noun.

Device

...a hardware resource upon which artifacts may be stored or deployed for execution.


• Devices interconnected by Networks • Artifacts assigned to Devices • System Software assigned to Devices • Device composed, aggregated of other Devices • Node composed, aggregated of Devices

A Device is a physical resource with processing capability, such as Mainframes, PCs and Routers. Often assigned with System Software, and can have sub-devices. Its name should be a noun, possibly including Vendor or product information.

System Software

...a software environment for specific types of components and objects that are deployed on it in the form of artifacts.


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



Page 49


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

Infrastructure Interface

...a point of access where infrastructure services offered by a node can be accessed by other nodes and application components.


• Node composed of Infrastructure Interfaces • Interface used by other Nodes • Infrastructure Interface assigned to Infrastructure Service

How a Technology Service is exposed to the environment. In the technology area interfaces could range from URL / Web Pages; Network Card; URL/Web Service. A quality of interfaces is that they represent an obligation or contract that a component realising the interface must provide. Name should be a noun.

Communications Path

...a link between two or more nodes, through which these nodes can exchange data.


• A Communications Path connects one or more Nodes • Network realises one or more Communication Paths



Page 50


The Communication Path is a logical communications link between nodes. Can logically represent qualities of the physical network.

Network

...a communication medium between two or more devices.


• Network connects one or more Devices • Network realises one or more Communication Paths

The Network relates to the physical communications infrastructure, which could be wired or wireless. Will have certainly physical properties, such as Bandwidth or Latency.



Page 51


Technology Layer: Behavioural Concepts • Infrastructure Function • Infrastructure Service

Infrastructure Function

...a behaviour element that groups infrastructural behaviour that can be performed by a node.


• Infrastructure Function realises Infrastructure Service • Other Infrastructure Services used by Infrastructure Function • Infrastructure Function accesses Artifact • Node assigned to Infrastructure Function

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



Page 52


Infrastructure Service

...an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.


• Infrastructure Service used by Nodes or Application Components • Infrastructure Interface assigned to Infrastructure Service • Infrastructure Services access Artifacts

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



Page 53


Technology Layer: Passive Structure Concept • Artifact

Artifact

...a physical piece of data that is used or produced in a software development process, or by deployment and operation of a system.


• Artifact realise Application Component, Software System, Data Object • Node assigned to Artifact



Page 54


Language Extensions

Objectives Explain in detail concepts in the Extensions:

• Motivation Extension • Implementation and Migration Extension

ArchiMate 2 and the TOGAF® ADM • ArchiMate Core

• Enables modelling of the architecture domains defined by TOGAF

• Motivation Extension • Enables modelling of stakeholders,

drivers for change, business goals, principles and requirements

• Implementation and Migration Extension • Enables modelling of project

portfolio management, gap analysis and transition and migration planning



Page 55


Motivation Extension Metamodel



Page 56


Motivational Concepts • Stakeholder • Driver • Assessment • Goal • Requirement • Constraint • Principle

Stakeholder

… The role of an individual, team, or organisation (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.


• Stakeholder composed, aggregated of other Stakeholders • Stakeholder associated with all other elements

Based on definition from TOGAF. Examples are CEO, Board, Shareholders, Customers, businesses. In other words an Actor can also be a Stakeholder. Name should be a noun.

Driver

...something that creates, motivates, and fuels the change in an organisation.


• Driver composed, aggregated of other Drivers • Driver associated with or influences other Motivation elements



Page 57


Drivers can be internal (Customer satisfaction, Compliance to Legislation), or External (economic climate, legislation). Name should be a noun.

Assessment

...the outcome of some analysis of some driver.


• Assessment composed, aggregated of other Assessments • Assessment associated with or influences other Motivational elements

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



Page 58


Goal

...an end state that a stakeholder intends to achieve.


• Goal composed, aggregated of other Goals • Goals associated with or influences other Motivational elements

A Goal is a target to aim for. Often recognised by the use of qualitative words, such as “increase sales”. Goals can be decomposed into several levels.



Page 59


Requirement

...a statement of need that must be realised by a system.


• Requirement composed, aggregated of other Requirements or Constraints • Requirement realises Goal or Principle • Requirement associated or influences remaining Motivational elements

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



Page 60


Constraint

...a restriction on the way in which a system is realised.


• Constraint composed, aggregated of other Constraints or Requirements • Constraint realises Goal or Principle • Constraint associated or influences remaining Motivational elements

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

Principle

...a normative property of all systems in a given context, or the way in which they are realised.


• Principle composed, aggregated of other Principles • Principle realises a Goal

Principles are a more general form of requirement, and are thus applicable over all systems. They are therefore much more stable and enduring in their nature. However, they are refined into more specific



Page 61


requirements when applied to individual systems. A principle is motivated by a Goal, e.g. Goal = “no instances of being sued”, Principle = “abide by the law”.

Link between Main and Motivational Elements

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



Page 62


Motivational Relationships

Association

…models that some intention is related to the source of that intention.

Aggregation

…models that some intention is divided into multiple intentions.

In the context of motivation, Aggregation is a way of decomposing intentions (Goals) into more concrete intentions (Goals with more specific timescales, measures).



Page 63


Realisation

…models that some end is realised by some means.

The realisation relationship is used to represent the following means-end relationships:

1. A goal (the end) is realised by a principle, constraint, or requirement (the means). 2. A principle (the end) is realised by a constraint or requirement (the means). 3. A requirement (the end) is realised by a system (the means), which can be represented by an

active structure element, a behaviour element, or a passive structure element.



Page 64


Influence

…models that some end is realised by some means.

An Influence exists between motivational elements – one element influencing the other(s). Additionally, the relationship can be assigned as either positive (using the “+” sign) or negative (using the “-” sign).



Page 65


Implementation and Migration Extensions Metamodel

Implementation and Migration Concepts • Work Package • Deliverable • Plateau • Gap

Work Package

… A series of actions designed to accomplish a unique goal within a specified time.


• Work Package composed, aggregated of other Work Packages • Work Package realises Goal, Requirement, Constraint, Deliverable, Plateau • Work Package flows to other Work Package

A Work Package represents actions taken over time, implying a clearly defined start and end date. There should also be goals to meet. Used to model projects. Can be grouped together as part of a programme or portfolio.



Page 66


Deliverable

… A precisely-defined outcome of a work package.


• Deliverable composed, aggregated of other Deliverables • Deliverable realises Goal, Requirement, Principle, Constraint

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

Plateau

… A relatively stable state of the architecture that exists during a limited period of time.


• Plateau composed, aggregated of and triggers other Plateau • Plateau aggregation and realisation of Goal, Requirement, Constraint



Page 67


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

Gap

… An outcome of a gap analysis between two plateaus.


• Gap composed, aggregated of other Gaps • Gap associated with all other elements

Gaps are evident between baseline and target architectures (otherwise there would be no need for anything to be done!). They are identified by comparing elements, e.g. comparing an application interface in the baseline with that of the target, whereby new functionality is added.



Page 68


Views and Viewpoints

Objectives Explain in detail ArchiMate Views and Viewpoints:

• Concepts of View, Viewpoint and Stakeholder • ArchiMate Viewpoint classification • Viewpoint List • ArchiSurance • Standard Viewpoints • Motivation Viewpoints • Implementation and Migration Viewpoints



Page 69


ISO 42010 Model

ISO 42010 is a standard for describing architecture. It establishes several key concepts:

• Stakeholders are involved either directly or indirectly with systems • Each stakeholder will have their own perspective or view of the system, i.e. Financial View,

Processes View, Security View, Data view. In the end, the view is what you see. • Each stakeholder will have concerns associated with the view, i.e. the Data-related view must

show data in some structured way. • In order to cover those concerns a viewpoint will establish a set of rules which will govern the

view. In the case of Data, we may want to view data as entity models at a conceptual, logical and physical level.

• Therefore we will need Conceptual, Logical and Physical Entity-relationship models.

The view is what you see.

When you talk about a view, you are talking about what you see. The viewpoint is what you want to see.

When you talk about the viewpoint, you are talking about the rules associated with what you see.

The Model is how you see it.



Page 70


Classification

ArchiMate has a neat way of classifying viewpoints, considering two dimensions – what purpose does the view serve, and what level of detail does the content portray.

Example purposes and suggested model-types are:

• Designing: used by architects and designers – diagrams and models. • Deciding: emphasis on cross-domain relationships – matrices, lists, maps and reports • Informing: to provide higher-level information – illustrations, animations

The model-types are generalisations; they are not exclusively related to these purposes.

Example [abstraction] levels are:

• Details: this are more for use by designers / engineers • Coherence: deal most with important associations across or within domains • Overview: abstractions and multi-layered, most useful for EAs and Decision-makers



Page 71


Viewpoint List Concerns Standard

Introductory Make design choices visible, convince stakeholders

Organisation Identification of competencies, authority, and responsibilities

Actor Co-operation Relationships of actors with their environment

Business Function Identification of competencies, identification of main activities, reduction of complexity

Business Process Structure of business processes, consistency and completeness, responsibilities

Business Process Co-operation

Dependencies between business processes, consistency and completeness, responsibilities

Product Product development, value offered by the products of the enterprise

Application Behaviour Structure, relationships and dependencies between applications, consistency and completeness, reduction of complexity

Application Co-operation Relationships and dependencies between applications, Orchestration / choreography of services, consistency and completeness, reduction of complexity

Application Structure Application structure, consistency and completeness, reduction of complexity

Application Usage Consistency and completeness, reduction of complexity of Applications

Infrastructure Stability, security, dependencies, costs of the infrastructure

Infrastructure Usage Dependencies, performance, scalability

Implementation and Deployment

Dependencies, security, risks

Information Structure Structure and dependencies of the used data and information, consistency and completeness

Service Realisation Added-value of business processes, consistency and completeness, responsibilities

Layered Consistency, reduction of complexity, impact of change, flexibility

Landscape Map Readability, management and reduction of complexity, comparison of alternatives

Motivation

Stakeholder Stakeholders, drivers, assessment and resultant goals

Goal Realisation Linking high-level goals into sub-goals and requirements

Goal Contribution Highlighting the influences between goals and requirements

Principles Principles and their motivating goals



Page 72


Concerns Requirements Realisation

Showing how requirements are realised by core elements

Motivation A complete overview of motivational elements

Implementation and Migration

Project Architecture vision and policies, motivation

Migration History of models

Implementation and Migration

Architecture vision and policies, motivation



Page 73


ArchiSurance A critical part of this section is to have a look at examples of views that are contained within the ArchiSurance Case Study (see hand-outs). It is mandated that delegates become familiar with ArchiSurance, and there could be some exam questions on it.

The case study makes use of the TOGAF Architecture Development Method, which also adopts a layered approach to architecture.

Context

Organisational Context Stakeholders View

Principles View



Page 74


Business Goals / Drivers

Business Architecture Organisation Structure View



Page 75


Organisation View

Business Function View



Page 76


Business Process View



Page 77


Applications Application Landscape View

Application Cooperation View



Page 78


Application Usage View



Page 79


Data Information Structure View

Data Dissemination View



Page 80


Technology Infrastructure Landscape View

Infrastructure View



Page 81


Change Scenario – Context (Phase A) Application Portfolio Rationalisation

Business Goals and Principles

Goal Refinement View



Page 82


Target Architecture Vision (Phase A) Introductory View

Target Business Architecture (Phase B) Requirements Realisation View



Page 83


Target Application Architecture (Phase C) Target Application Co-operation View

Application Architecture Gap View



Page 84


Target Infrastructure Architecture (Phase D) Target Technology Architecture

Technology Architecture Gap



Page 85


Transition Architecture (Phase E) Migration View

Migration Plan (Phase F) Project Context View



Page 86


Selection of Detailed Viewpoints

Standard Motivation Implementation

Introductory Stakeholder Project

Organisation Goal Realisation Migration

Business Function Principles Implementation

Business Process Requirements Realisation

Application Structure Motivation

Infrastructure

Implementation and Deployment

Information Structure

Service realisation

Layered

Landscape



Page 87


Standard Viewpoints

Introductory Viewpoint Stakeholders Enterprise architects, managers

Concerns Make design choices visible, convince stakeholders

Purpose Designing, deciding, informing

Abstraction Level Coherence, overview, detail

Layer Business, Application, and Technology

Aspects Active structure, behaviour, passive structure

Concepts and Relationships



Page 88


Introductory Viewpoint Example



Page 89


Organisation Viewpoint Stakeholders Enterprise, process and domain architects, managers, employees,

Shareholders

Concerns Identification of competencies, authority, and responsibilities


Abstraction Level Coherence

Layer Business

Aspects Active Structure


Organisation Viewpoint Example



Page 90


Business Function Viewpoint Stakeholders Enterprise, process and domain architects

Concerns Identification of competencies, identification of main activities, reduction of complexity

Purpose Designing


Layer Business

Aspects Behaviour, active structure


Business Function Viewpoint Example



Page 91


Business Process Viewpoint Stakeholders Process and domain architects, operational managers

Concerns Structure of business processes, consistency and completeness, responsibilities

Purpose Designing

Abstraction Level Detail

Layer Business

Aspects Behaviour


Business Process Viewpoint Example



Page 92


Application Structure Viewpoint Stakeholders Enterprise, process application and domain architects

Concerns Application structure, consistency and completeness, reduction of complexity

Purpose Designing

Abstraction Level Detail

Layer Application

Aspects Active structure, passive structure


Application Structure Viewpoint Example



Page 93


Application Usage Viewpoint Stakeholders Enterprise, process, and application architects, operational managers Concerns

Consistency and completeness, reduction of complexity Purpose

Designing, deciding


Layer Business and application





Page 94


Application Usage Viewpoint Example

Infrastructure Viewpoint Stakeholders Infrastructure architects, operational managers Concerns

Stability, security, dependencies, costs of the infrastructure Purpose

Designing Abstraction Level Details

Layer Technology





Page 95


Infrastructure Viewpoint Example

Implementation and Deployment Viewpoint Stakeholders Application and infrastructure architects, operational managers

Concerns Dependencies, security, risks

Purpose Designing


Layer Application, technology

Aspects Passive structure, behaviour, active structure



Page 96



Implementation and Deployment Viewpoint Example



Page 97


Information Structure Viewpoint Stakeholders Domain and information architects

Concerns Structure and dependencies of the used data and information, consistency and completeness

Purpose Designing

Abstraction Level Details

Layer Business, application, technology

Aspects Passive Structure




Page 98


Information Structure Viewpoint Example

Service Realisation Viewpoint Stakeholders Process and domain architects, product and operational managers

Concerns Added-value of business processes, consistency and completeness, responsibilities

Purpose Designing, deciding


Layer Business

Aspects Behaviour, active structure, passive structure



Page 99



Service Realisation Viewpoint Example

Layered Viewpoint Stakeholders Enterprise, process, application, infrastructure, and domain architects

Concerns Consistency, reduction of complexity, impact of change, flexibility


Abstraction Level Overview



Page 100




Concepts and Relationships All architecture concepts

Layered Viewpoint Example



Page 101


Landscape Map Viewpoint Stakeholders Enterprise architects, top managers: CEO, CIO Concerns

Readability, management and reduction of complexity, comparison of alternatives

Purpose Deciding




Concepts and Relationships All ArchiMate Concepts

Landscape Map Viewpoint Example



Page 102


Motivation Viewpoints

Stakeholder Viewpoint Stakeholders Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers

Concerns Architecture mission and strategy, motivation

Purpose Designing, deciding, informing Abstraction Level Coherence, Details


Aspects

Motivation


Stakeholder Viewpoint Example



Page 103


Goal Realisation Viewpoint Stakeholders Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers


Purpose Designing, deciding

Abstraction Level Coherence, Details


Aspects Motivation


Goal Realisation Viewpoint Example



Page 104


Principles Viewpoint Stakeholders Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers





Aspects Motivation


Principles Viewpoint Example



Page 105


Requirements Realisation Viewpoint Stakeholders Enterprise and ICT architects, business analysts, requirements managers

Concerns Architecture strategy and tactics, motivation




Aspects Motivation


Requirements Realisation Viewpoint Example



Page 106


Motivation Viewpoint Stakeholders Enterprise and ICT architects, business analysts, requirements managers

Concerns Architecture strategy and tactics, motivation


Abstraction Level Overview, Coherence, Details


Aspects Motivation


Motivation Viewpoint Example



Page 107


Implementation and Migration Viewpoints

Project Viewpoint Stakeholders (Operational) managers, enterprise and ICT architects, employees, shareholders

Concerns Architecture vision and policies, motivation

Purpose Deciding, informing


Layer Implementation and Migration



Project Viewpoint Example



Page 108


Migration Viewpoint Stakeholders Enterprise architects, process architects, application architects, infrastructure architects and domain architects, employees, shareholders

Concerns History of models



Layer Implementation and Migration

Aspects Not applicable


Migration Viewpoint Example



Page 109


Implementation and Migration Viewpoint Stakeholders (Operational) managers, enterprise and ICT architects, employees, shareholders

Concerns Architecture vision and policies, motivation

Purpose Deciding, informing


Layer Business layer, application layer, technology layer, implementation and migration extension





Page 110


Implementation Viewpoint Example



Page 111


Adapting ArchiMate, Tools, Frameworks and Languages

Objectives In this final main section we will deal with:

• Adapting ArchiMate • Using ArchiMate-related tools • Using ArchiMate with other Frameworks and Languages

Adapting ArchiMate – Adding Attributes Profiles

• Pre-defined • User-defined

The concept of profiling (also a UML concept) is to define a kind of data structure capable of capturing additional information you may wish to store alongside elements. Such data could be pre-defined in ArchiMate tools, e.g. capturing descriptive data, or user-defined whereby specific additional information is captures (see example).

Adapting ArchiMate – Specialisations

Specialisation (a form of inheritance) is a powerful way of creating user-defined elements based on the properties and qualities of an existing one.



Page 112


Using ArchiMate-related tools Capabilities:

• Specification-related o Follow the specification o Help with relationships o Support for profiles

• Implementation-specific o Sharing and collaboration o Publishing o Repository management o Help facilities

Using ArchiMate with other Frameworks and Languages TOGAF As the ArchiSurance case study shows, ArchiMate fits comfortably within the ADM, and [almost] replicates the TOGAF Architecture Types. There are large similarities between the TOGAF and ArchiMate metamodel, with much attention being devoted to harmonising these.

UML ArchiMate has deliberately mimicked many UML concepts, in order for it to be familiar to UML practitioners. However it’s also distinct, because of its focus on higher levels of viewpoint detail. It should also make it easier for designers and software engineers to understand and elaborate designs into Activity, Sequence and Class Diagrams

BPMN In the business process area, BPMN is a natural environment to take high-level ArchiMate diagrams and model them for use in Business Process Management environments.



Page 113


Access, 20 Active Structure Elements, 8 Adapting ArchiMate

Adding Attributes, 112 Specialisations, 112

Aggregation, 18, 63 Application Collaboration, 43 Application Component, 42 Application Function, 44 Application Interaction, 45 Application Interface, 43 Application Layer, 41 Application Service, 46 ArchiMate and TOGAF Layers, 14 ArchiMate Framework, 13 ArchiSurance

Applications, 78 ArchiSurance, 74 Business Architecture, 75 Change Scenario, 82 Context, 74 Data, 80 Migration Plan, 86 Organisational Context, 74 Target Application Architecture, 84 Target Architecture Vision, 83 Target Business Architecture, 83 Target Infrastructure Architecture, 85 Technology, 81 Transition Architecture, 86

Artifact, 54 Assessment, 58 Assignment, 19 Association, 21 Behaviour Elements, 9 Business Actor, 29 Business Collaboration, 30 Business Event, 34 Business Function, 33 Business Interaction, 33 Business Interface, 31 Business Layer, 28 Business Object, 36 Business Process, 32 Business Role, 29 Business Service, 35 Collaboration and Interaction, 11 Communications Path, 50 Composition, 18 Constraint, 61 Contract, 40 Core Concepts, 8 Core Metamodel, 10 Data Object, 47

Deliverable, 67 Derived Relationships, 25 Device, 49 Driver, 57 Enterprise, 5 Enterprise Architecture, 5 Flow, 22 Gap, 68 Goal, 59 Grouping, 23 Implementation and Migration Extension, 16 Implementation and Migration Extensions, 66 Influence, 65 Infrastructure Function, 52 Infrastructure Interface, 50 Infrastructure Service, 53 Interfaces Element, 9 ISO 42010 Model, 70 Junction, 23 Language Principles, 7 Layers, 6, 12 Link between Main and Motivational Elements,

62 Location, 31 Meaning, 38 Motivation Extension, 15, 56 Network, 51 Node, 48 Passive Structure, 9 Plateau, 67 Principle, 61 Product, 39 Realisation, 19, 64 Relationships, 12, 17 Relationships between Layers, 26 Representation, 37 Requirement, 60 Service Elements, 9 Specialisation, 24 Stakeholder, 57 System Software, 49 Technology Layer, 48 Triggering, 22 Used By, 20 Using ArchiMate with other Frameworks and

Languages, 113 Using ArchiMate-related tools, 113 Value, 39 Viewpoint Classification, 71 Viewpoint List, 72 Viewpoints, Implementation and Migration

Implementation, 110 Implementation Example, 111 Migration, 109



Page 114


Migration Example, 109 Project, 108 Project Example, 108

Viewpoints, Motivation Goal Realisation, 104 Goal Realisation Example, 104 Motivation, 107 Motivation Example, 107 Principles, 105 Principles Example, 105 Requirements Realisation, 106 Requirements Realisation Example, 106 Stakeholder, 103 Stakeholder Example, 103

Viewpoints, Standard Application Structure, 93 Application Structure Example, 93 Application Usage, 94 Application Usage Example, 95 Business Function, 91 Business Function Example, 91

Business Process, 92 Business Process Example, 92 Implementation and Deployment, 96 Implementation and Deployment Example,

97 Information Structure, 98 Information Structure Example, 99 Infrastructure, 95 Infrastructure Example, 96 Introductory, 88 Introductory Example, 89 Landscape Map, 102 Landscape Map Example, 102 Layered, 100 Layered Example, 101 Organisation, 90 Organisation Example, 90 Service Realisation, 99 Service Realisation Example, 100

Work Package, 66



Page 115

What next? Find out about our extensive portfolio of courses by visiting our website at www.qa.com

Who shall I contact? Call us on 0845 757 3888 Email [email protected] Visit our website www.qa.com

Learning should be as natural as breathing. We learn when we find ourselves in an unfamiliar situation, when we try something new, when we interact with other people. All of these are triggers that kick off the learning cycle.

We learn most of all when we take time to reflect on how our attitude and behaviour has a positive or negative influence on our collective ability to meet our goals.

QA is currently deploying learning solutions that incorporate blends of the above engagement strategies in both our public and bespoke programmes.

Find out more....

C ll 0845 757 3888

IT Architecture Modelling using ArchiMate® 2.1 … · • Attend accredited training course • No pre-requisites Study Track • Architects • Those wanting or needing an understanding

Documents