Infrastructure Modelling Language

Infrastructure Modelling Language
The purpose of this paper is to highlight the need of an
infrastructure domain specific extension of Archimate© and
describe the notations and a meta-model for IML.
Authors: Gagan Gandhi, Sab Saini
Infrastructure Modelling Language
Contents
Introduction
3
Architecture Description Process - Maturity Model
3
Infrastructure modelling
5
Infrastructure Modelling Language (IML) and ArchiMate
5
The IML Metamodel
5
IML Concepts
6
IML Views for Infrastructure Design
8
Component View
9
Logical Deployment View
9
Compute View
9
Data Flow View
10
Visio stencil and Sparx EA plug-in
10
Page | 2
Infrastructure Modelling Language
Introduction
The IT architecture community has realised the value of standardisation and uniformity of
representation of information for a long time now. Standardisation offers an integrated architecture
approach that describes the various domains and their interdependencies. It enables model driven
architecture; and helps create different views from the same information based on stakeholder needs.
In addition model driven architecture enables the “service orientation” paradigm – be it Business,
Application or Infrastructure services.
One of the key pain areas of architecture teams today is representation of information – which
results in unruly and huge architecture description documents; and this leads to considerable time
spent in understanding the current state and validating (and re-validating) what the document meant
to say. Architects spend more time trying to unearth the current state in large enterprises; or doing
the Archaeology; than they spend optimizing existing and/or creating new architecture.
Standardisation of architecture description notation and diagrams is the first step to reduce
archaeology efforts. Standardisation of notations, their representation and dependencies gets more
important as the complexity of IT systems increases and as the number of architecture and design
teams involved in describing an IT system, expands.
Architecture Description Process - Maturity Model
The architecture description process maturity model (on the next page) shows a typical journey
that an organisation would take moving from a non-standardised and chaotic state to a state
where teams can seamlessly collaborate with each other and static word documents for
architecture description become history.
Page | 3
Infrastructure Modelling Language
The journey is split in two phases: Standardisation phase and Collaboration phase
The Standardisation phase promotes common language and methods across parts of the
organisation, reduces communication gaps and encourages reuse of assets across engagements.
The main ingredient of standardisation is to agree on a meta-model to represent architecture
concepts. The advent of EA modelling languages have helped drive standardisation of methods
and notations. The predominant industry standard modelling languages used by architects today
are UML and ArchiMate®. These have become the de-facto standards when it comes to
application architecture/ design or solution architecture teams.
Standardisation by itself does not require a change in the modelling tool. MS Visio and
PowerPoint are as powerful and effective as any EA tool to bring in consistency.
The Collaboration phase on the other hand generally has a dependency on the use of an
Enterprise Architecture tool. This is a development phase in which organisations would
implement a shared asset repository; making reuse of assets much easier and eventually
eliminate the need to have static word document to describe architecture. The implementation
specifics of this phase will very much depend on the choice of EA tool, however it is essential to
establish the methods and standards before the tool selection. The standards govern the choice
of tool and not the other way around.
Many organisations deal with architecture description maturity as a one-step process instead of
the highlighted two-phase approach. This paper argues that in order to make the acceptance of
change easier across teams, and to realise the benefit of the initiative half way in the journey –
this exercise should be split in two distinct phases. Doing it all in a single phase is a leap too far
where the value realisation does not happen till at least a few months after the journey has
ended.
This paper focuses on the standardisation aspects of the maturity model.
Page | 4
Infrastructure Modelling Language
Infrastructure Modelling
When it comes to the Infrastructure Architecture domain, the current industry standard
modelling languages offer limited support. The Infrastructure specific concepts in Archimate® and
UML are left to the interpretation on the level of abstraction they are to be used at, and the
attributes that should be captured for each. That is one of the primary reasons why Infrastructure
Architecture more often than not still relies on non-standard Visio diagrams, with heterogeneous
representation of information.
Cognit Solutions has developed an extension of ArchiMate® - Infrastructure Modelling Language
(IML); specifically for the description of Infrastructure Architecture and Design in a standardised
manner. The Infrastructure Modelling Language provides:





Standard notations for infrastructure elements (spanning architecture and design)
List of attributes that could be captured for each infrastructure element
Standard set of diagrams that should be created for an Infrastructure Architecture
Description
A Visio stencil for infrastructure elements introduced by IML
An extension for IML in Sparx Enterprise Architect and Archi (currently in development)
It is not un-common for the design teams to re-create the artefacts that architecture produces.
IML takes note of this un-warranted effort and unlike some of the other architecture modelling
standards, IML supports design functions as a logical continuation to architecture. The concepts
and attributes can be used by both architecture and design teams to represent a consistent and
standardised view of the system state.
Infrastructure Modelling Language (IML) and ArchiMate®
The concepts and elements in IML are an extension
of the Technology layer of ArchiMate®.
IML
extends
the
infrastructure
and,
implementation & deployment viewpoints of
ArchiMate®. It proposes four standard views for
Infrastructure Design purposes.
The IML Meta-model
The IML meta-model below gives an overview of the concepts in the Infrastructure Modelling
Language, along with their relationship with each other. Most of the concepts are inspired by
ArchiMate®, some of them directly reused:
Page | 5
Infrastructure Modelling Language
Note that the meta-model above does not show all possible concepts and relationships, for
example a Physical or Virtual server may be modelled with 2 or more network interfaces for
admin and service data flows.
IML Concepts
IML concepts take a practical view of the level of detail captured in infrastructure architecture,
which is then augmented in design. IML introduces attributes associated to each concept that
help capture essential details of infrastructure architecture and design. The below table shows
all IML concepts, their definition, notation and associated attributes.
IML Concept & Definition
Notation
Attributes
Component, similar to Archimate®’s application
component, is a modular, replaceable and the
most granular part of a software system that
can be deployed independently into an
execution environment.
None
Infrastructure Service, similar to Archimate®
concept this represents an infrastructureoriented functionality to be consumed by
None
Page | 6
Infrastructure Modelling Language
application components, independent of its
realisation. IML considers an Infrastructure
Service to accept a request and send back a
specific response; and is not customised for
every other project. E.g. enterprise messaging
service or even NTP/DNS
Logical Node: Component or multiple
components that constitute functionality and
need to be deployed on a particular runtime or
execution environment are mapped to Logical
Node. A logical node is realised by compute
infrastructure.
- Runtime Environment
- Operating System
Servers and Hosts: The compute infrastructure
is represented in IML using servers (physical or
virtual) and hosts (that are virtualised).
Physical & Virtual
Servers
- CPU
- Memory
- Hostname
- Network Zone
- Total Storage
- Default Gateway
Physical Server or Host
- Type
- Model
- Hostname
Network Interface, is used to represent
multiple network interface on Servers. Separate
network interface concept helps in mapping
accurate and complete coverage of network
data-flows.
Server Cluster: Multiple servers being
implemented as a cluster to represent a
resilient functionality is depicted using the
cluster concept.
End user Device represents any device used for
end user computing, e.g., Desktop/ Laptop,
Tablet PC, Mobile phone, Handheld scanners
etc.
Network Devices, like Firewall, load-balancer,
IDS/IPS etc. can be represented using network
device concept.
-Name
-Type
-Model
Network Segment depicts the subnets to
capture data flows effectively.
None
Storage Device is used to depict the storage
infrastructure like SAN/NAS storage devices
-Name
-Type
-Model
Page | 7
Infrastructure Modelling Language
Storage Volume, represents the logical blocks
of storage that is presented to servers. These
can be used for OS files, application data or logs
for example.
-Name
-Size
-Storage Tier
-LUN Config
Location is used to depict data-centres or
locations of access e.g. regional office, offshore
development centres.
None
Connectors, as the name says are used to
connect different IML concepts. IML connectors
are inspired from UML/Archimate®
relationships:
- Maps-on, used to map a component to
logical node
- Realization, used to depict relationship of a
logical node with compute infrastructure
- Uses, used to depict how components use
an infrastructure service or how a server
uses storage volume
- Composition, used to depict relationship of
a virtual server with physical host and
storage volume with storage device
- Data-Flow, used to depict data flow
between two network interfaces.
None
IML Views for Infrastructure Description
Standardisation of views or diagrams in architecture description documents is one of the key
considerations for any modelling language. The purpose of multiple views is to enable a separation
of concerns between stakeholders and provide the information they need, nothing more nothing
less.
IML recommends four views to take care of the stakeholder needs from an infrastructure
standpoint. These four views and their journey through architecture and design stages can be
depicted as below:
Page | 8
Infrastructure Modelling Language
Component View
Component View is the solution architecture or context model view that describes the
functionality or a set of functionalities using components.
Logical Deployment View
Logical Deployment View shows the mapping of components onto logical nodes and acting as an
abstraction layer hiding the complexities of computing infrastructure underpinning the
component. The attributes of a logical node capture the execution environment for the
application component.
Compute View
Compute View depicts the realisation of logical nodes by the compute infrastructure – physical
or virtual servers. Virtual servers are shown with a composition relationship to physical hosts.
Each of the compute infrastructures will have multiple attributes to help capture design details.
The attribute list is open to modification but subject to standardisation.
Page | 9
Infrastructure Modelling Language
Data Flow View
IML servers and hosts feature ‘network interfaces’ that are attached to the parent compute
element to represent network interfaces with attributes to capture essential details (as illustrated
in previous figure). Connectors with formatted labels (e.g. destination port, network protocol and
application protocol) are used to capture information flows as illustrated below:
Visio stencil and Sparx EA plug-in
The Infrastructure Modelling Language has been implemented in some of the Tier-1 financial
organisations in various guise and now make a part of their standard architecture development
process. In terms of architecture tools, the modelling language could be used with any tool that
provides the flexibility of creating your own elements and profiles.
Cognit Solutions provides a Microsoft Visio stencil and a Sparx Enterprise Architect Plugin (currently in
development) for IML. Contact Cognit Solutions for the Visio Stencil or Sparx EA MDG.
Page | 10