IT Architecture Modelling using ArchiMate® 2.1 … · • Attend accredited training course • No...
Transcript of IT Architecture Modelling using ArchiMate® 2.1 … · • Attend accredited training course • No...
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
IT Architecture Modelling using ArchiMate® 2.1
Introduction
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 1
IT Architecture Modelling using ArchiMate® 2.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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 2
IT Architecture Modelling using ArchiMate® 2.1
• 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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 3
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 4
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 5
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 6
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 7
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 8
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 9
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 10
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 11
IT Architecture Modelling using ArchiMate® 2.1
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).
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 12
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 13
IT Architecture Modelling using ArchiMate® 2.1
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”.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 14
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 15
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 16
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 17
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 18
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 19
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 20
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 21
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 22
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 23
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 24
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 25
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 26
IT Architecture Modelling using ArchiMate® 2.1
Architecture Layers Objectives Explain in detail concepts in the three main Layers:
• Business Layer • Application Layer • Technology Layer
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 27
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 28
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 29
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 30
IT Architecture Modelling using ArchiMate® 2.1
Business Interface
...a point of access where a business service is made available to the environment.
Common Relationships
• 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.
Common Relationships
• Location assigned to other Structural elements • Location assigned to other Behavioural elements
The Location models the distribution of structural elements.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 31
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 32
IT Architecture Modelling using ArchiMate® 2.1
Business Function
...groups behaviour based on a chosen set of criteria (typically business resources and / or competencies).
Common Relationships
• 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.
Common Relationships
• 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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 33
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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”.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 34
IT Architecture Modelling using ArchiMate® 2.1
Business Service
...a service that fulfils a business need for a customer (internal or external to the organisation).
Common Relationships
• 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).
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 35
IT Architecture Modelling using ArchiMate® 2.1
Business Layer: Passive Structure Concepts • Business Object • Representation • Meaning • Value • Product • Contract
Business Object
...a passive element that has relevance from a business perspective.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 36
IT Architecture Modelling using ArchiMate® 2.1
Representation
...a perceptible form of the information carried by a business object.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 37
IT Architecture Modelling using ArchiMate® 2.1
Meaning
...the knowledge or expertise present in a business object or its representation, given a particular context.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 38
IT Architecture Modelling using ArchiMate® 2.1
Value
...the relative worth, utility or importance of a business service or product.
Common Relationships
• 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.
Common Relationships
• A Product aggregates Business or Application services, as well as a Contract. • A Product may be associated with a Contract, Value
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 39
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 40
IT Architecture Modelling using ArchiMate® 2.1
Application Layer Metamodel
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 41
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 42
IT Architecture Modelling using ArchiMate® 2.1
Application Collaboration
...an aggregate of two or more application components that work together to perform collective behaviour.
Common Relationships
• 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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 43
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 44
IT Architecture Modelling using ArchiMate® 2.1
Application Interaction
...a behaviour element that describes the behaviour of application collaboration.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 45
IT Architecture Modelling using ArchiMate® 2.1
Application Service
...a service that exposes automated behaviour.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 46
IT Architecture Modelling using ArchiMate® 2.1
Passive Structure Concept • Data Object
Data Object
...a passive element suitable for automated processing.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 47
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• Nodes aggregated, composed of other Nodes, Devices and System Software • Nodes can be interconnected by Communication Paths • Artifacts can be assigned to Nodes
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 48
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Common Relationships
• System software assigned to Device • Artifacts assigned to System Software • Node composed, aggregated of System Software • System Software realises Application Component, Collaboration, Interface, Service
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 49
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Common Relationships
• A Communications Path connects one or more Nodes • Network realises one or more Communication Paths
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 50
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 51
IT Architecture Modelling using ArchiMate® 2.1
Technology Layer: Behavioural Concepts • Infrastructure Function • Infrastructure Service
Infrastructure Function
...a behaviour element that groups infrastructural behaviour that can be performed by a node.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 52
IT Architecture Modelling using ArchiMate® 2.1
Infrastructure Service
...an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 53
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• Artifact realise Application Component, Software System, Data Object • Node assigned to Artifact
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 54
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 55
IT Architecture Modelling using ArchiMate® 2.1
Motivation Extension Metamodel
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 56
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Common Relationships
• Driver composed, aggregated of other Drivers • Driver associated with or influences other Motivation elements
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 57
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 58
IT Architecture Modelling using ArchiMate® 2.1
Goal
...an end state that a stakeholder intends to achieve.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 59
IT Architecture Modelling using ArchiMate® 2.1
Requirement
...a statement of need that must be realised by a system.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 60
IT Architecture Modelling using ArchiMate® 2.1
Constraint
...a restriction on the way in which a system is realised.
Common Relationships
• 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.
Common Relationships
• 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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 61
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 62
IT Architecture Modelling using ArchiMate® 2.1
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).
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 63
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 64
IT Architecture Modelling using ArchiMate® 2.1
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).
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 65
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 66
IT Architecture Modelling using ArchiMate® 2.1
Deliverable
… A precisely-defined outcome of a work package.
Common Relationships
• 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.
Common Relationships
• Plateau composed, aggregated of and triggers other Plateau • Plateau aggregation and realisation of Goal, Requirement, Constraint
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 67
IT Architecture Modelling using ArchiMate® 2.1
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.
Common Relationships
• 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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 68
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 69
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 70
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 71
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 72
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 73
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 74
IT Architecture Modelling using ArchiMate® 2.1
Business Goals / Drivers
Business Architecture Organisation Structure View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 75
IT Architecture Modelling using ArchiMate® 2.1
Organisation View
Business Function View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 76
IT Architecture Modelling using ArchiMate® 2.1
Business Process View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 77
IT Architecture Modelling using ArchiMate® 2.1
Applications Application Landscape View
Application Cooperation View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 78
IT Architecture Modelling using ArchiMate® 2.1
Application Usage View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 79
IT Architecture Modelling using ArchiMate® 2.1
Data Information Structure View
Data Dissemination View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 80
IT Architecture Modelling using ArchiMate® 2.1
Technology Infrastructure Landscape View
Infrastructure View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 81
IT Architecture Modelling using ArchiMate® 2.1
Change Scenario – Context (Phase A) Application Portfolio Rationalisation
Business Goals and Principles
Goal Refinement View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 82
IT Architecture Modelling using ArchiMate® 2.1
Target Architecture Vision (Phase A) Introductory View
Target Business Architecture (Phase B) Requirements Realisation View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 83
IT Architecture Modelling using ArchiMate® 2.1
Target Application Architecture (Phase C) Target Application Co-operation View
Application Architecture Gap View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 84
IT Architecture Modelling using ArchiMate® 2.1
Target Infrastructure Architecture (Phase D) Target Technology Architecture
Technology Architecture Gap
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 85
IT Architecture Modelling using ArchiMate® 2.1
Transition Architecture (Phase E) Migration View
Migration Plan (Phase F) Project Context View
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 86
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 87
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 88
IT Architecture Modelling using ArchiMate® 2.1
Introductory Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 89
IT Architecture Modelling using ArchiMate® 2.1
Organisation Viewpoint Stakeholders Enterprise, process and domain architects, managers, employees,
Shareholders
Concerns Identification of competencies, authority, and responsibilities
Purpose Designing, deciding, informing
Abstraction Level Coherence
Layer Business
Aspects Active Structure
Concepts and Relationships
Organisation Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 90
IT Architecture Modelling using ArchiMate® 2.1
Business Function Viewpoint Stakeholders Enterprise, process and domain architects
Concerns Identification of competencies, identification of main activities, reduction of complexity
Purpose Designing
Abstraction Level Coherence
Layer Business
Aspects Behaviour, active structure
Concepts and Relationships
Business Function Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 91
IT Architecture Modelling using ArchiMate® 2.1
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
Concepts and Relationships
Business Process Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 92
IT Architecture Modelling using ArchiMate® 2.1
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
Concepts and Relationships
Application Structure Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 93
IT Architecture Modelling using ArchiMate® 2.1
Application Usage Viewpoint Stakeholders Enterprise, process, and application architects, operational managers Concerns
Consistency and completeness, reduction of complexity Purpose
Designing, deciding
Abstraction Level Coherence
Layer Business and application
Aspects Behaviour, active structure
Concepts and Relationships
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 94
IT Architecture Modelling using ArchiMate® 2.1
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
Aspects Behaviour, active structure
Concepts and Relationships
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 95
IT Architecture Modelling using ArchiMate® 2.1
Infrastructure Viewpoint Example
Implementation and Deployment Viewpoint Stakeholders Application and infrastructure architects, operational managers
Concerns Dependencies, security, risks
Purpose Designing
Abstraction Level Coherence
Layer Application, technology
Aspects Passive structure, behaviour, active structure
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 96
IT Architecture Modelling using ArchiMate® 2.1
Concepts and Relationships
Implementation and Deployment Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 97
IT Architecture Modelling using ArchiMate® 2.1
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
Concepts and Relationships
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 98
IT Architecture Modelling using ArchiMate® 2.1
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
Abstraction Level Coherence
Layer Business
Aspects Behaviour, active structure, passive structure
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 99
IT Architecture Modelling using ArchiMate® 2.1
Concepts and Relationships
Service Realisation Viewpoint Example
Layered Viewpoint Stakeholders Enterprise, process, application, infrastructure, and domain architects
Concerns Consistency, reduction of complexity, impact of change, flexibility
Purpose Designing, deciding, informing
Abstraction Level Overview
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 100
IT Architecture Modelling using ArchiMate® 2.1
Layer Business, application, technology
Aspects Passive structure, behaviour, active structure
Concepts and Relationships All architecture concepts
Layered Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 101
IT Architecture Modelling using ArchiMate® 2.1
Landscape Map Viewpoint Stakeholders Enterprise architects, top managers: CEO, CIO Concerns
Readability, management and reduction of complexity, comparison of alternatives
Purpose Deciding
Abstraction Level Overview
Layer Business, application, technology
Aspects Passive structure, behaviour, active structure
Concepts and Relationships All ArchiMate Concepts
Landscape Map Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 102
IT Architecture Modelling using ArchiMate® 2.1
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
Layer Business, application, technology
Aspects
Motivation
Concepts and Relationships
Stakeholder Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 103
IT Architecture Modelling using ArchiMate® 2.1
Goal Realisation Viewpoint Stakeholders Stakeholders, business managers, enterprise and ICT architects, business analysts, requirements managers
Concerns Architecture mission and strategy, motivation
Purpose Designing, deciding
Abstraction Level Coherence, Details
Layer Business, application, technology
Aspects Motivation
Concepts and Relationships
Goal Realisation Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 104
IT Architecture Modelling using ArchiMate® 2.1
Principles 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
Layer Business, application, technology
Aspects Motivation
Concepts and Relationships
Principles Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 105
IT Architecture Modelling using ArchiMate® 2.1
Requirements Realisation Viewpoint Stakeholders Enterprise and ICT architects, business analysts, requirements managers
Concerns Architecture strategy and tactics, motivation
Purpose Designing, deciding, informing
Abstraction Level Coherence, Details
Layer Business, application, technology
Aspects Motivation
Concepts and Relationships
Requirements Realisation Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 106
IT Architecture Modelling using ArchiMate® 2.1
Motivation Viewpoint Stakeholders Enterprise and ICT architects, business analysts, requirements managers
Concerns Architecture strategy and tactics, motivation
Purpose Designing, deciding, informing
Abstraction Level Overview, Coherence, Details
Layer Business, application, technology
Aspects Motivation
Concepts and Relationships
Motivation Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 107
IT Architecture Modelling using ArchiMate® 2.1
Implementation and Migration Viewpoints
Project Viewpoint Stakeholders (Operational) managers, enterprise and ICT architects, employees, shareholders
Concerns Architecture vision and policies, motivation
Purpose Deciding, informing
Abstraction Level Overview
Layer Implementation and Migration
Aspects Passive structure, behaviour, active structure
Concepts and Relationships
Project Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 108
IT Architecture Modelling using ArchiMate® 2.1
Migration Viewpoint Stakeholders Enterprise architects, process architects, application architects, infrastructure architects and domain architects, employees, shareholders
Concerns History of models
Purpose Designing, deciding, informing
Abstraction Level Overview
Layer Implementation and Migration
Aspects Not applicable
Concepts and Relationships
Migration Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 109
IT Architecture Modelling using ArchiMate® 2.1
Implementation and Migration Viewpoint Stakeholders (Operational) managers, enterprise and ICT architects, employees, shareholders
Concerns Architecture vision and policies, motivation
Purpose Deciding, informing
Abstraction Level Overview
Layer Business layer, application layer, technology layer, implementation and migration extension
Aspects Passive structure, behaviour, active structure
Concepts and Relationships
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 110
IT Architecture Modelling using ArchiMate® 2.1
Implementation Viewpoint Example
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 111
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 112
IT Architecture Modelling using ArchiMate® 2.1
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.
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 113
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
Page 114
IT Architecture Modelling using ArchiMate® 2.1
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
Contains material extracted from the ArchiMate® 2.1 Specification
© 2012-2013 The Open Group, All Rights Reserved
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