ArchiMate realisation relations

Find this and related slide shows on ArchiMate and TOGAF on this page
http://grahamberrisford.com/AM%201%20Methods/6PRODUCTSandTECHNIQUES/AM%20products%20and%20techniques.htm
Avancier
EA models the enterprise as a
system that is stateful and
event-driven.
System elements are
interrelated.
Events trigger changes to
system state and/or the
provision of services to
external entities.
ArchiMate and TOGAF
Core concepts
Symbols (boxes & lines)
Concept framework
Relations
1. order and derivation
2. grouping
3. realisation
Diagram types
Relations between system elements
3 Analysis of realisation relations
Including diagrams and definitions edited from the ArchiMate 2.1 standard.
Copyright © The Open Group, All Rights Reserved.
ArchiMate is a registered trademark of The Open Group.
Training at http://avancier.website
What does realisation mean in ArchiMate?
► “realization links a logical entity with a more concrete entity
that realizes it".
► Realisation means one thing realises another thing?
► You can can’t define a word using the word.
► There are several possible interpretations of realisation in general,
and realisation in ArchiMate.
Training at http://avancier.website
Avancier
PART ONE: Realisation in general
► PART ONE: Realisation in general
► PART TWO: Realisation in ArchiMate
Training at http://avancier.website
Avancier
Abstraction scales
Avancier
► Every system description is an abstraction that steps away from a relatively
complex reality to a simpler model of it.
► ArchiMate has notations for three of the four abstraction scales below
Omission
Elaboration
Composition
Generalisation
Idealisation
Composite
Generalised
thing
Logical
Part
Specialised
thing
More concrete
Decomposition
Specialisation
Realisation
Training at http://avancier.website
“Logical” can be interpreted several ways
► Purely conceptual description
■ unrelated to computing (computation-independent)
■ E.g. business/conceptual data model
► Technology-independent description
■ independent of specific technology (platform-independent)
■ E.g. logical data model of a specific database
► Simple, elegant description
■ De-duplicated, regardless of optimisation to meet NFRs
■ E.g. normalised logical data model
► External description
■ An interface or service contract that encapsulates internal
content or workings
Training at http://avancier.website
Avancier
“Realisation” can be interpreted several ways
► Concept to
► Reality
► External to
► Internal
Avancier
Logical
aspect
or thing
Role
Business
Function
Logical
Application
Component
Physical
aspect
or thing
Actor
Organisation
Unit
Physical
Application
Component
External
aspect
or thing
Service
Interface
Internal
aspect
or thing
Process
Component
Training at http://avancier.website
Realisation as extension of description
Avancier
► Generalisation and specialisation boxes specify different
properties of one object. The specialisation extends the properties
of the generalisation
Generalisation
Mammal
Network
Node
Specialisation
Human
Firewall
► Realisation can be seen as a kind of specialisation, in which an
abstract logical description is extended with physical details
Logical
Description
Interface
Business
Object
Physical
Description
Component
Data
Object
Training at http://avancier.website
Realisation as implementation of description
Avancier
► Realisation can be seen as a kind of implementation,
► whereby a system description is implemented as a concrete reality
in an oprational system
Description
Type
Role
Class
Data
Object
Real thing
Instance
Actor
Object
Row in
Table
Training at http://avancier.website
From extension to implementation
► Extension of description
Avancier
Logical
Description
Interface
Service
Data Object
Physical
Description
Class
Process
Type
Database
Table
Description
Class
Process
Type
Database
Table
Real thing
Object
Process
Performance
Row in
Table
► Implementation of description
Training at http://avancier.website
Realisation by degrees
Avancier
► Traditionally, IS/IT methods refer to
■ a scale in description from conceptual to
logical to physical, and then
■ an implementation step from abstract
description to concrete reality.
Idealisation
Conceptual Model
Logical Model
Physical Model
Real or Concrete Material
Realisation
Training at http://avancier.website
“links a logical entity with a more concrete entity".
► So more concrete can mean
■ More elaborate, technology-specific (perhaps
executable) description
■ Operational reality, working instances, rather than
description
Avancier
Idealisation
Conceptual Model
Logical Model
Physical Model
Real or Concrete Material
► In the latter sense, an entity is either abstract or
concrete; there are no degrees of concreteness.
Training at http://avancier.website
Realisation
Realisation in the Zachman Framework?
Avancier
► A curious alignment of architecture domain with level of idealisation
Levels in Zachman framework
Realisation
Human
Ideal
Business
Conceptual
System
Logical
Technology
Physical
Technology
Real
Realisation
► Surely we can take conceptual, logical and physical views of each
layer – business, system and technology?
Training at http://avancier.website
Realisation in TOGAF?
Avancier
► The pattern in the TOGAF meta model is that
■ logical components realise (meaning, are encapsulated by) services
■ physical components realise (meaning implement) logical components
Business Service
Business
Function, Role
Organisation, Actor
Information System Service
Information Systems
Logical Application Component
Physical Application Component
Platform Service
Technology
Logical Technology Component
Physical Technology Component
Training at http://avancier.website
PART TWO: Realisation in ArchiMate
► PART ONE: Realisation in general
► PART TWO: Realisation in ArchiMate
Training at http://avancier.website
Avancier
ArchiMate uses realisation relations
Avancier
Service
► Within one view and layer
Process
Business
► And between layers
Business
Object
Application
Data Object
► This last looks odd wrong
(tbd).
Infrastructure
Training at http://avancier.website
Application
Component
System
Software
Service <realised by> Process
► The service contract should define the pre and post
conditions of the process
Training at http://avancier.website
Avancier
Service
Interface
Process
Role
Interface <composes> Role
► Interface <is realised by> Role?
Training at http://avancier.website
Avancier
Service
Interface
Process
Role
Interface <composes> Role
► Interface <realised by> Role?
Training at http://avancier.website
Avancier
Service
Interface
Process
Role
Service <realised by> Function
Training at http://avancier.website
Avancier
Service
Interface
Function
Component
Interface <composes> Components (composed into?)
Avancier
Service
Interface
Function
Component
► Surely better
► Interface <realised by> Component?
Training at http://avancier.website
Interface <provided by> Component
► And also: Interface <realised by> Component?
Training at http://avancier.website
Avancier
Service
Interface
Function
Component
Infrastructure Usage Viewpoint
► Are these Services really Interfaces?
► Clunky to show Software Systems 1-to-1 with Services
Training at http://avancier.website
Avancier
Service
Interface
Function
Node
Questionable use of “Realisation” relation
Avancier
► A Software System “realises” an Application Component?
► A hardware Device Node “realises” an Application Component?
Is this system
software?
Should be
used by
► Why is only one Communication path shown?
Training at http://avancier.website
An example
Avancier
A driver uses an interface to a motor car
component
The interface provides access to several services
(accelerate, brake, steer, change gear).
The motor car realises the interface.
The car’s internal components (pedals, engine,
brakes, steering wheel, gear lever, gears) cooperate
in internal processes (invisible to the driver) to
realise the car’s services.
Training at http://avancier.website
Driver
Motor Car
Interface
Motor Car
Car
Component
Remove the interface and the weaker relation applies
A car does not realise the driver; it is used by the driver
Avancier
Driver
Motor Car
Car
Component
Training at http://avancier.website
Remove the interface and the weaker relation applies
A car does not realise the driver; it is used by the driver
Avancier
Driver
Motoring
Holiday
Motor Car
Car
Process
Car
Component
What realises a motoring holiday?
The car realises a sequence of car process service requests made by
the driver to car components (via interfaces) during the process of a
motoring holiday.
Training at http://avancier.website
Remove the interface and the weaker relation applies
An application does not realise the user,
it is used by the user
Avancier
User
Use Case
Application
Automated
Service
Application
Component
What realises a use case?
The app realises a sequence of automated service requests made by
the user to app components and system software (via interfaces)
during the process of a motoring holiday.
Training at http://avancier.website
Surely this diagram is wrong?
Avancier
System software does not realise the application, it is used by the application
Is this system
software?
Training at http://avancier.website
Should be
used by
Again, this must surely be wrong?
Avancier
► Can an entity in a lower layer realise an entity in a higher layer?
Should be
used by
Should be
used by
► It is one thing to say a component realises services requested of it
► It is another to say a server component realises a client component
► If I ask you the time, you can realise the service request I make, but
you do not realise me (the service requester)
Training at http://avancier.website