enterprise architecture and aesthetics

© 2005 VEGA Group PLC 1

Enterprise Architecture and Aesthetics

Dr. Paul King, VEGA Group PLC

Abstract

Enterprise architecture is the discipline of describing and analysing the relationship

between an enterprise's objectives and purpose, and the system of systems, which

the enterprise uses to help achieve those objectives. This paper makes the case for

the importance of aesthetics in enterprise architecture. It proposes an enterprise

architectural modelling language, which addresses enterprise form, purpose and

aesthetics. This language is a meta-model extension of SysML which uses the power

of SysML to address the engineering aesthetic of enterprise architecture.

The paper is based on work carried out for the UK Ministry of Defence's Integration

Authority to develop an "Integration Services Support Environment" (ISSE). ISSE uses

the enterprise architecture modelling language to enable the consistent description,

and hence analysis, of a large and heterogeneous system of systems. ISSE itself has

been developed as a enterprise architecture modelling tool and as a repository of

interconnected models of MoD's enterprise.

Introduction and Purpose

Enterprise architecture. Enterprise architecture is the discipline of describing and

analysing the relationship between an enterprise's objectives and purpose, and the

system of systems which the enterprise uses to help achieve those objectives.

Traditional architecture is concerned with describing the form, purpose and aesthetics

(described by Vitruvius as "firmitas utilitas venustasque") of structures which societies

construct to modify their physical environment. Most architectural frameworks for

enterprise architecture address form and purpose, but not aesthetics. This paper

makes the case for the importance of aesthetics in enterprise architecture. It proposes

an architectural framework which addresses the form, purpose and aesthetics of an

enterprise architecture. At the core of this framework is an enterprise architectural

modelling language. This language is a meta-model extension of SysML which uses

the power of SysML to reason about abstractions, patterns and classification in order

to be able to address the engineering aesthetic of enterprise architecture.

White Paper


ISSE. The paper is based on work carried out for the UK Ministry of Defence's

Integration Authority. In April 2001, following a competitive selection process, the

Integration Authority placed a contract with Logica (now LogicaCMG) and VEGA

Group PLC to develop an "Integration Services Support Environment" (ISSE). A key

element of the LogicaCMG/VEGA proposal was for a "reference model" to enable the

consistent description, and hence analysis, of a large and heterogeneous system of

systems.

During the course of development of ISSE it has been recognised that modelling an

enterprise such as the MoD requires a modelling language of considerable power, and

the reference model has become the basis for an enterprise architecture modelling

language. ISSE itself has been developed as a SysML-based enterprise architecture

modelling tool and as a repository of interconnected models of the elements of MoD's

enterprise architecture. Key objectives in the development of ISSE have been the

ability to construct queries based on the meta-model which enable analysts to

investigate the complex relationships with the enterprise architecture, and the ability to

manage a repository of a large number of consistent models of the systems of which

the enterprise consists.

Why Enterprise Architecture

Enterprise complexity. Many organisations have complex business processes which

they support using complex IT systems. These systems may be legacy, even

inherited, and consequently poorly documented. The process for acquiring new

capability is likely itself to be complex. This complexity often results in the costly

procurement of IT systems which fail to meet their expectations, if they deliver at all.

There are many well-documented cases of such procurement in both private and

public organisations.

The solution to managing this complexity is the development of an “enterprise

architecture”, which encompasses the ability to consistently model a complex,

heterogeneous, information-based enterprise, creating a repository of manageable

information, from which consistent views of the enterprise can be created. An

enterprise architecture should facilitate the exploitation of models and views to

manage enterprise and interoperability issues.

In 2003 the FBI asked the US National Research Council to assist in reviewing its

Trilogy IT modernisation programme. In its report to the FBI the review committee


made the following statement:

"The committee believes that the absence of an enterprise architecture has been

a major contributor to the problems faced by the implementers of the [FBI's] Trilogy

program. That is, the lack of an architecture to guide the planning of an information

and communication infrastructure has resulted in improvisation that has virtually no

chance of resulting in a well-ordered infrastructure for the enterprise to build upon. In

fact, merely providing parts (e.g., computers and accessories, piece-part applications,

and so on) is like buying brick, mortar, and lumber and expecting a builder to produce

a functional building without benefit of building codes, blueprints, or an understanding

of how people will use the building." (See (NRC).)

This is as succinct and robust a statement of the need for an enterprise architecture

as one could have. The report goes on to stress the importance of the involvement

and leadership of senior management in developing and maintaining an enterprise

architecture. It details the adverse consequences for the FBI of its failure to adopt an

enterprise architecture. Of course, the FBI has not been alone in this respect, and the

lessons they have had to painfully learn have also been learnt by many other

organisations. As a result the use of enterprise architecture is being adopted widely in

both government and private organisations.

Enterprise Architecture. The uses and benefits of enterprise architectures are

documented elsewhere (see for example (OIO) for a thorough discussion on

enterprise architecture). An architecture can be used, inter alia, in the following ways:

As an investment tool;

To provide a vision for the future;

To enable the communication of ideas;

To provide the organising principles of an enterprise;

As a means of managing the knowledge about an enterprise;

To enable effective re-use of the processes of the enterprise and its applications and

infrastructure;

To catalogue the enterprise's purpose and how it achieves that purpose;

To have a road-map of how the enterprise will evolve

Firmitas utilitas venustasque

Architecture. Since the classical period, architecture, in the general sense, has been

recognised as encompassing descriptions of the form, purpose and aesthetics of a

construction, usually a building, or set buildings, or a town or city. In the 1st century BC


Vitruvius expressed this as "firmitas utilitas venustasque" and this has been a theme

of writings on architecture since. We will consider the role of form, purpose and

aesthetics in enterprise architecture in the following sections.

Enterprise Purpose. An enterprise architecture should describe an enterprise's

purpose in terms of its missions and operational activities within the context of the

environment the enterprise operates in. In other words, what the enterprise’s

objectives are, and how it goes about achieving these objectives. Within an

organisation, objectives or missions are assigned to roles, which undertake the

activities which achieve the enterprise's purpose. An enterprise's activities may

depend on each other, and the architecture needs to express this. The enterprise

architecture identifies the actors (human, technological and natural) external to the

enterprise, in its environment, which will have an impact on it and on which it wishes to

have an impact. This is the "operational architecture".

The enterprise architecture also describes the how the enterprise uses technology that

it has, or plans to have, at its disposal, and relates these to the enterprise's missions

and operational activities. This part of the enterprise architecture is a “specification

architecture”, which specifies what the enterprise's technology does, and how it

supports the enterprise in undertaking the enterprise's activities. An enterprise’s

technology base can be viewed as comprising a set of systems. This corresponds to

the systems engineering view of an enterprise’s technological base forming a “system

of systems”. In a large enterprise the system concept reflects how technology is often

acquired through a set of procurement projects, each delivering a system. “System”

provides enterprise architecture with a concept that can be used to address the

specification of what an enterprise's technological base does for it, grouping

functionality into clusters.

Each system provides a set of related functions. The enterprise architecture must

specify the enterprise’s legacy and planned systems, with their functions and the types

of people that will operator them. It must show how functions in different systems

interact. This description must identify the characteristics of a system which effect how

it can be used and the qualities of service that functions are required to meet when

they are invoked.

The enterprise will evolve. Therefore the enterprise architecture must be capable of

representing changes, both to show the enterprise’s purpose at different times and by

being able to relate the elements at different time periods.


Enterprise Form. Form in enterprise architecture records the organisation of the

enterprise and its system of systems. There are organisational relationships between

operational roles and between resources: the enterprise architecture should record

these relationships. The enterprise architecture also needs to record the typical

business entities which are key to the execution of operational activities and the rules

that regulate the operation of the activities and the life cycles of the business entities.

As well as describing the how the enterprise organises itself, it is also important to

describe how the enterprise organises the technology it uses. The specification of

what the technology does is part of the purpose of the enterprise: its structural

composition is part of the form of the enterprise. Structural form can be described

using the concept of “component” and the enterprise's system of systems as being

assembled from a set of components. A component has a set of well-defines

interfaces and is created using available, usually "off-the-shelf", technology and

meeting de jure, de facto or enterprise standards.

An enterprise architecture must detail the current and planned structure of its

technological implementation in terms of the components that implement the

behaviours the enterprise wishes to automate. The architecture must describe how

components interact with each other. It should show the dependence of architecture

on products and standards. This forms the technical architecture within the overall

enterprise architecture.

Enterprise Aesthetics. The importance of aesthetics, in the form of guiding

principles, for enterprise architectures has been recognised. For instance the

canonical definition of architecture in IEEE 1471 (IEEE1471) is: "the fundamental

organisation of a system embodied in its components, their relationships to each other

and to the environment and the principles guiding its design and evolution [emphasis

added]". However architectural frameworks, from Zachman (ibn) onwards, have

concentrated on purpose and form, and neglected aesthetics.

The focus on form and purpose tends to result in the construction of architectures that

describe concrete realisations of enterprises. These descriptions are catalogues of

current or future configurations, and do not enable reasoning about the architecture

nor the construction of taxonomies of re-usable concepts. Such descriptions do not

support the ability to make abstractions, which can capture architectural rules,

patterns, and the commonalties between concrete architectures.


© Paul King, 2004

Figure 1 - The front elevation of Lansdown Crescent, Bath

Aesthetics

In the everyday sense of the word, architecture often refers to the common style used

to construct a number of related edifices; or put another way, it describes the common

features of these edifices, whether they are features of form or the method of

construction. These common features are patterns which are reused, because they

embody either some quality that is found attractive, or some structural form that has

proved economically efficient, or both.

Figure 1 is a picture of the front of Lansdown Crescent in Bath. Lansdown Crescent

exhibits features that make it easily recognisable as an example of Bath’s Georgian

architecture. It is, for example, constructed, as almost all buildings in Bath are, from

local ashlar stone; it has neo-classical ornamentation; it is a crescent. Figure 2 (pg. 7)

shows the back of Lansdown Crescent. Unlike the front, the rear of the building does

not appear to conform to a strong pattern. Indeed, it is not a single building, but a

collection. They are constructed from ashlar, yes, but using rough-hewn blocks. The

rear of Lansdown Crescent does however illustrate another pattern used in

constructing Georgian Bath – the use of the façade. The front of the building was built

under the direction to the architect, to meet his aesthetic specification; each individual

home behind the façade was constructed to the specification of its first owner.

Enterprise architectures need to be able to similarly address these ideas of patterns,

in analysing both the enterprise's purpose and its form. For instance, an enterprise

architecture should be capable of being used to identify where similar operational

activities are being used which can be rationalised, or where the same operational

activity is being performed in different ways. This should entail more than an architect

eyeballing diagrams: there needs to be an architectural language which enables the


© Paul King, 2004

Figure 2 - Part of the rear elevation of Lansdown Crescent, Bath

explicit recording of such facts, so that they can be reasoned about, rationalised and

concepts re-used

In a similar way the architect's job is to uncover patterns in the way the enterprise

uses or could use technology, and to be able to explore how it will impact on

operational processes, and to rationalise its delivery.

The idea of looking for common features and patterns suggests a need to classify, to

be able to group together elements of the enterprise, which have the same or similar

features. This in turn suggests the use of abstraction, the conceptualisation of a

problem to understand the essential features. The creation of an enterprise

architecture is the creation of a model, or blueprint, of the enterprise, its systems and

their implementation. An important characteristic of this model is its ability to support

classification, and the discovery, use and re-use of effective patterns.

We think of the aesthetics in the architecture of buildings and towns as those features,

which attempt to please us visually, but aesthetics can arise from considerations of

utility and form. If a building is to be a productive place to work it has to have an

aesthetic which enables and encourages people to effectively undertake particular

activities. Its form has to conform to engineering principles, patterns and practices that

enable its efficient and sturdy construction in its environment. In other words, it should

measure up to an engineering aesthetic, which determines the form's fitness for

purpose and worthiness as a construction.


A building architecture that is not aesthetically pleasing from an engineering point of

view is likely to be difficult (and costly) to construct and prone to structural weakness.

Since form and purpose are closely bound together, a poorly engineered building is

also likely to be unloved by its users, and therefore to have ineffective utility. An

architectural pattern is most likely to be re-used if architects find it appealing and fit for

the purpose they wish to apply it. The judgement to re-use a pattern, even if objective

evidence is available, is likely to be influenced by consideration of engineering

aesthetics.

It is not only building architecture that has adopted patterns. Patterns are widely and

productively used in software architectures. For example, the J2EE BluePrints

(J2EE1) provide a collection of interrelated patterns which create an architecture for

constructing enterprise software solutions using J2EE (as well as other software

technologies). The software community has developed standards for documenting

patterns that themselves encourage the use of patterns.

These considerations apply to enterprise architectures. At the heart of cost effective

and robust solutions to an enterprise's technological requirements must be sound

business and engineering practices which understand the enterprise's purpose and in

form its systems architecture. An enterprise architecture must be able to articulate

patterns and principles and enable architects to reason about them.

A Meta-Model for Enterprise Architecture

Architecture as Model. An architecture is a model in that is a description or

abstraction of something to be realised in the world of concrete, stone, wood, metal,

semi-conductors and people. There are several purposes of this model: to enable the

architect to communicate his ideas to his customer; to enable the architect to

communicate his ideas to the engineering team who will implement them; to enable

the architect to analyse the problem at hand and devise a solution. It may in fact be

several models: it might be a catalogue of architectural elements which provides the

context for further development; or a cookbook of patterns from which solutions can

be fashioned. Like all models, the underlying use of an architecture is to provide a tool

for investigation and reasoning about a problem.

Enterprise architecture requires an enterprise approach to modelling, and thus

understanding based on a repository of linked and coherent enterprise models. It

needs the ability to define and generate architectural views, and provide an

organisation with a common framework and language for discussing enterprise and


integration problems.

Language Objectives. The purpose of an enterprise architecture is to describe and

analyse the relationship between an enterprise's objectives and purpose, and the

system of systems which the enterprise uses to achieve those objectives. An

enterprise architecture modelling language will identify the concepts needed to

describe the enterprise's structure and behaviour; the structure and behaviour of the

systems which the enterprise uses to enable its purpose; and the relationship of the

enterprise to the systems it uses. Furthermore, such a language must provide the

infrastructure necessary to construct a taxonomy of the operational and system

structures an enterprise is constructed from, and to describe the style and patterns of

the enterprise activities, and the principles and patterns underlying the construction

and features of its systems. The concepts from which an enterprise architecture

modelling language is built from form a meta-model for enterprise architecture: that is

a model of the concepts used in models which are enterprise architectures.

Language Characteristics. Figure 3 (pg. 9)shows the plan of the ground floor of a

house. In the analogy of enterprise architecture to building architecture, architectural

views are often conceived as the equivalent of these types of plan. Or else enterprise

architecture is compared with town planning: the provision of utility services (water,

power, sewage, etc) are seen as the equivalent of IT infrastructure services (data

networks, naming and addressing services, etc), while town planning rules and

regulations are seen as the equivalent of interconnection rules and buildings as

applications.

Everyone is, at some level at least, able to understand a building plan, although it is

unlikely they could use it to build a house, and a builder requires considerably more

information (describing building materials, construction methods, engineering

drawings, etc) if the house is to be built in accordance with the architect's vision. The

building plan, especially of something like a house that we are familiar with, can be

interpreted by our implicit knowledge of houses. The obvious assumption to make is

that the implicit knowledge of a house would be contained in a meta-model of houses.

However a building architectural modelling language that worked at that level would

need to know about the myriad different forms of structure architects design, and the

purposes they can be put to, as well as building regulations, planning rules, utility

services, and so forth. To be generally useful it would collect together a set of

sufficiently general concepts - such as structure, purpose, regulation, construction

method, utility service for instance - which could be used to model types of entities like


��

��

��

��

��

� ��

� ��

��

Figure 3 - A plan of a house

house, which can then be re-used to create plans like the one in Figure 3.

Similarly, an enterprise architecture modelling language needs to have the sufficient

generality to be useful across enterprises in general. A particularly large or complex

enterprise might have a specialised meta-model, however in such a case the diversity

of the enterprise would encourage the use of a meta-model which had sufficient

generality to be able to address all aspects of the enterprise.

This means that the enterprise architecture modelling language must be able to create

models of classes of entities (the equivalent of the class of things we identify as a

house in building architecture) which are significant to the enterprise. Each class

needs to model all the behaviour, features and internal structure which are of

important-t to the architect when using that type of entity in an architecture. These

classes will be described using the language of the enterprise architecture meta-

model.

Modelling an architecture requires a modelling language which can express the

constructs that the architect wishes to describe. The modelling language should

provide a framework for constructing an integrated set of models of different parts of

the enterprise that address the operational, specification, implementation, technology

and programmatic aspects. It should:

• Have the power to represent classification, abstraction and patterns;

• Be able to model structure;

• To have powerful mechanisms for modelling behaviour;


• Have mechanisms for representing the operational, specification and

technical architectures in an enterprise architecture;

• Provide a means for integrating programmatic information with the other

aspects of the architecture.

Using a modelling language that is tailored to address specific constructs of an

enterprise architecture enables the construction of consistent models across a wide

range of systems which may support the enterprise, and makes it possible to construct

a range of queries to interrogate and explore a system-of-systems repository.

SysML. As noted already enterprise architecture is systems engineering applied to

enterprises, and therefore an appropriate starting point for an enterprise architecture

modelling language is a system engineering modelling language that has extension

mechanisms would be a good candidate for an enterprise architecture modelling

language. SysML (SysML) is a proposal by SysML-Partners to The Object

Management Group for a UML-based systems engineering modelling language. It is

designed to meet the requirements of the OMG’s UML for Systems Engineering

request for proposal. The key requirements that SysML meets are the ability to model:

• Structure - system hierarchy, environment, system interconnection,

deployment;

• Behaviour – input & output, function-based behaviour, function activation &

deactivation, state-based behaviour, allocation of behaviour to systems;

• Properties - parametric models, continuous time variable attributes;

• Requirements – specification, requirements hierarchy, traceability;

• Verification - test cases, verification results;

• General relationships – association, collections, decomposition, dependency,

generalisation, instantiation;

• Model views.

SysML is an extension to UML 2.0 (UML2) and uses the profiling and meta-modelling

extension mechanisms provided by UML 2.0. As such it is itself capable of further

extension using these mechanisms.

SysML provides a first class modelling language which addresses the basic

requirements of enterprise architecture. In particular it has mechanisms for modelling

structure and behaviour in the context of being able to model the general relationships

between elements of an architecture. This supports the important aesthetics

component of enterprise architecture. SysML’s extension mechanisms enable the

construction of a meta-model which explicitly address the concepts required to model


Operational Context

Specification

Technology

Prog

ram

me

Figure 4 - Enterprise Architecture Viewpoints

the enterprise purpose and form.

Enterprise Architecture Meta-model. The enterprise architecture meta-model should

be compact and flexible: it should only incorporate concepts which are required to

extend SysML to provide an enterprise architecture modelling language, which is easy

to use and focuses on essential principles. It should re-use SysML wherever possible.

An enterprise is complex: an enterprise architecture is likely to consist of many models

and contain large quantities of information about the enterprise. Therefore, the

enterprise architecture meta-model needs to be capable of being used to construct

queries about the enterprise, particularly queries that relate different elements of the

enterprise to one-another.

It is helpful to create a number of viewpoints from which to model an enterprise. The

enterprise architecture meta-model provides a framework for constructing an

integrated set of models of the enterprise which address the operational context,

specification, technology and programme viewpoints of the enterprise. These

viewpoints are shown in Figure 4. The enterprise architecture meta-model elements

are shown in Figure 5 (pg.15). The elements of the meta-model are organised

according to the viewpoints. Some elements of the meta-model occur in more than

one viewpoint.

Operational Viewpoint. The operational viewpoint contains elements, which describe

the purpose and structure of the enterprise. The elements of the viewpoint are:

• Operational Objective - a high-level categorisation of the types of activities an

enterprise engages in;

• Operational Activity - the activities that need to be undertaken in order to

accomplish objectives of the enterprise;

• Operational Role - the actors within the operational context who have to

achieve objectives;


• Operational Resource - the means by which roles can undertake activities in

order to achieve objectives.

Specification Viewpoint. The specification viewpoint contains the elements of the

meta-model used to specify the technology used by an enterprise. The specification

view reflects the service-oriented flavour of the architecture: interactions between

systems (that is groupings of functionality) are modelled by the imposition of services

between system functions. The services reflect the need to establish a clear

specification of the capability of one system to provide functionality to other systems,

and also its dependency on other systems. The elements of the specification

viewpoint are:

• System - a system is a container for functionality organised to accomplish a

specific set of objectives. A system can be realised as a collection of

hardware and software, or just software (when it might be referred to it as an

“application”). A system may or may not be able to function on its own;

• System Function - the specification a coherent grouping of behaviours which

can be used to support the successful undertaking of an operational activity

and which are to be implemented using technology;

• System Service - a contractual definition of a set of behaviours that other the

functions of other systems can rely on;

• System Operator - A class of individuals who contribute to the execution of a

system function in support of an operational activity;

• QoS - the definition of the quality of service which a system function or

system service will provide when it is invoked;

• Characteristic - the definition of a particular characteristic of a system.

Technology Viewpoint. The technology viewpoint contains the concepts of the meta-

model which are used to describe the construction of technology employed by an

enterprise. The elements of the technology viewpoint are:

• Component - a component is a replaceable unit of deployment, subject to

third party composition, that provides the realisation of a set of well-defined

behaviours through implementation in hardware and/or software.

Components are used to record the implementation decisions that have been

made in realising a system. Components identify the products and

technology used to implement part of a systems and system functions. They

also identify the standards that the system uses.


• Component Interface - components interact with each other through

component interfaces. A component interface realises one or more system

services and identifies the standards used to implement the system services.

• Enabling technology - technology which is available to implement a system,

but not in the form of an off-the-shelf product.

• Off-the-shelf Product - Technology which can be acquired in a product form.

• Standard - a de jure, de facto or enterprise endorsed standard.

Programme Viewpoint. The programme viewpoint contains concepts for defining the

programmes used by an enterprise to acquire technology. The significant features of

this model of acquisition programmes are the linking of programme activities by

programme artefacts, and its integration with the other meta-model viewpoints. Most

models of plans link activities directly: since the meta-model is not attempting to

provide a general model of planning, but to understand how programmes are

interrelated by the delivery of artefacts between them, the meta-model makes this

explicit. The integration with the other viewpoints allows views to be created which can

show the state of an enterprise in different epochs. The elements of the programme

viewpoint are:

• Programme - A programme consists of a planned set of activities needed to

realise a set of programme deliverables and bring them into service. A

programme can co-ordinate the activities of a number of sub-programmes,

undertake activities and is responsible for a number of artefacts.

• Programme Deliverable - an element of an enterprise that is delivered by a-

programme: programme deliverables are defined by concepts (such as a

system or component) in other viewpoints of the meta-model. A programme

deliverable goes through a series of life-cycle states (concept, specified,

designed, tested, trialed, in-service, out-of-service, etc) during a programme.

• Programme Artefact - something produced by a programme including state

changes in programme deliverables.

• Programme Activity - A discreet (at the required level of granularity being

modelled) stage in a programme which delivers one or programme artefacts.

A programme activity defines time required to deliver the artefacts.


Prog

ram

me

Vie

wpo

int

Tec

hnol

ogy

Vie

wpo

int

Spec

ific

atio

n V

iew

poin

tO

pera

tiona

l Con

text

Vie

wpo

int

Syst

emSe

rvic

e

prov

ides

Syst

emFu

nctio

nha

s su

b-fu

nctio

n is e

xpos

ed b

yus

ed b

y

Syst

emha

s sub

-sys

tem

Syst

emO

pera

tor

is o

pera

ted

by

cont

ribu

tes t

o

Ope

ratio

nal

Res

ourc

eho

sts

QoS

Cha

ract

eris

tic

char

acte

rise

s

char

acte

rise

s

char

acte

rise

s

Ope

ratio

nal

Act

ivity

supp

orts

Prog

ram

me

Art

efac

tPr

ogra

mm

eA

ctiv

ity

Prog

ram

me

Prog

ram

me

Del

iver

able

unde

rtak

es

is re

quir

ed b

y th

e en

d of

is a

life

-cyc

le s

tate

of

is s

ub-p

rogr

amm

e of

is re

spon

sibl

e fo

r

deliv

ers

is re

quir

ed b

y th

e st

art o

f

deliv

ers

host

s

Ope

ratio

nal

Act

ivity

supp

orts

has

sub-

func

tion

Ope

ratio

nal

Obj

ectiv

e

Ope

ratio

nal

Rol

e

Ope

ratio

nal

Res

ourc

e

unde

rtak

es

is u

sed

by

cons

ists

of

part

icip

ates

in

Prog

ram

me

Del

iver

able

Com

pone

nt

Syst

emha

s sub

-sys

tem

is im

plem

ente

d by

has

Stan

dard

Ena

blin

gT

echn

olog

y

OT

S Pa

ckag

e

Com

pone

ntIn

terf

ace

used

by

offe

rs

is im

plem

ente

d by

is u

sed

by

depe

nds

on

is im

plem

ente

d by

is im

plem

ente

d by

has

sub-

com

pone

nt

Figure 5 - Enterprise Architecture Meta-Model


Extending to SysML. The meta-model is integrated with SysML to create an

enterprise modelling language by identifying the meta-model elements as extensions

of language elements in SysML. For instance the meta-model elements "operational

role", "operational resources", "system" and "component" are extensions (stereotypes)

of the SysML language element "assembly", while "operational activity" and "system

function" extend SysML "activity".

A model created using the enterprise architecture modelling language contains a

taxonomy of architectural components. Each architectural component has structure

and behaviour, and relationships to other architectural components, which accord with

the relationships defined in the meta-model. The architect assembles an architecture

using instances of the architectural components. The architecture itself is a SysML

assembly whose parts are typed by architectural components and whose connections

should conform to the relationships established in the taxonomy. The behaviours of

the architecture choreograph the behaviours of the architectural components from

which the architecture is assembled to create the behaviour of the enterprise.

The Integration Service Support Environment

The enterprise architecture modelling language described in the preceding sections

has be developed to underpin the implementation of an "integration services support

environment" (ISSE) on behalf of the UK Ministry of Defence's Integration Authority.

The UK MoD Integration Authority. The Integration Authority is part of the Defence

Procurement Agency of the UK Ministry of Defence. It is charged with delivering

integration services across Defence and does through by undertaking enabling work

on architecture, providing interoperability assurance for acquisition programmes as

part of the department's scrutiny process, managing the UK test and reference

programme, involvement the NITEworks experimentation programme, and delivery of

integration support to acquisition projects. Included in the architecture enablers are

technical leadership of the MoD Architectural Framework and the provision of a

repository of architectural models of MoD's systems of systems.

The ISSE Programme. In April 2001, following a competitive selection process, the

Integration Authority placed a contract with Logica (now LogicaCMG) and VEGA

Group PLC to develop an "Integration Services Support Environment" (ISSE). A key

element of the LogicaCMG/VEGA proposal was for the adoption of a "reference


model" to enable the consistent description, and hence analysis, of a large and

heterogeneous system of systems.

Key objectives in the development of ISSE have been the provision of a capability to

capture descriptions of the systems used by the MoD together with the ability to

construct queries based on the meta-model which enable analysts to investigate the

complex relationships within the enterprise architecture, and the ability to manage a

repository of a large number of consistent models of MoD's systems. During the

course of development of ISSE it has been recognised that modelling an enterprise

such as the MoD requires a modelling language of considerable power, and that the

reference model is best considered as an enterprise architecture modelling language.

Therefore, ISSE itself has come to be developed as a SysML-based enterprise

architecture modelling tool and a repository of interconnected models of the elements

of MoD's enterprise architecture.

The Integration Authority's endorsed mission for ISSE is that it "provides an

architecture based, visual decision support environment to enable the acquisition

community to understand, analyse and resolve system of systems and integration

issues".

ISSE provides an enterprise approach to modelling, and thus understanding based on

a repository of linked and coherent enterprise models. It supports the ability to define

and generate architectural views, and provides an organisation with a common

framework and language for discussing enterprise and integration problems. It

supports:

• Capability planning;

• Development of enterprise architecture;

• Management of a system of systems;

• Technology planning;

• Equipment acquisition planning;

• Systems engineering;

• Management of standards.

Part of the original motivation for the ISSE meta-model was to provide a framework to

enable the construction of queries across large numbers of interdependent models.

ISSE's query capability allows the user to define and store of queries based on paths

consisting of elements and relationships. The queries find paths which link

architectural parts, traversing elements and relationships which are either defined by


the meta-model or other more general relationships. The results from a query can be

filtered by imposing constraints on the properties of the elements returned.

The query capability is integrated with the taxonomy so that queries can navigate

classification hierarchies and return results based on relationships an architectural

element inherits from its generalisations. Queries can be used to create derived

relationships.

These queries enable the investigation of the topology of an architecture: in other

words the discovery of the existence and form of connections between parts of an

architecture. The query capability can be used proactively to find permissible

connections between architectural elements, or as a validation tool to check that

connections conform to predefined rules and to find architectural defects caused by

invalid connections. Since the query capability knows about the classification

hierarchy we create patterns which model architectural styles, and then investigate the

conformance of an architecture to a set of patterns.

Examples. ISSE has been used extensively to model many of MoD’s systems. This

has informed ISSE's development and led to a growing awareness of the importance

of architectural modelling within MoD. ISSE has been used to catalogue existing

systems as a baseline for identifying future capability and to create specifications for

new equipments. The use of this approach to architecture enables important

improvements in clarity, understanding and precision over previous approaches to

capability and system specification.

Conclusion

Aesthetics is concerned with beauty and taste, which are personal matters, even if by

and large we usually have common perceptions beautiful or tasteful people, buildings,

landscapes and paintings. Have our investigations into enterprise architectures,

supported by the use of ISSE, helped us to understand aesthetics in enterprise

architecture? Well, we have been able to devise an approach to architecture based on

patterns which has been successfully exploited to categorise complex and previously

unmanageable descriptions of particular areas of the UK's military capability. We are

applying the same approach to specifying new capabilities. We believe this will result

in more robust specifications, which are closely aligned to business processes,

ultimately leading to more controlled and predictable implementation projects resulting

in better systems.

Importantly our work has helped us recognise that it is important to have a definition of

what an architecture is (as opposed to just a framework with which to describe


architectures) and that this definition must support the formulation of architectural

patterns which promote re-use. We have been able to influence the MOD Architectural

Framework (MODAF) towards adopting a model, as opposed to view, based approach

underpinned by a meta-model derived from our original.

My personal inclination is to search for patterns, and I am particularly pleased when I

can use a pattern to describe or explain a range of things or phenomena. So, in that

sense what we have achieved starts to appeal to my aesthetic, and presumably to

others to whom patterns and their application are pleasing. It does of course raise the

questions of whether some patterns have more utility or a better aesthetic than other,

and how one could measure or determine such differences. And there is the question

what other types of aesthetic might be discernible in enterprise architectures.

At the technical level, we are developing a methodology which will facilitate a

reproducible process of enterprise architecting. In parallel with this, we will strengthen

our concept of architecture, and support this by corresponding developments in ISSE

to enhance its support for enterprise architecture descriptions.

References

National Research Council, “A Review of the FBI’s Trilogy Information Technology

Modernization Program”, Computer Science and Telecommunications Board,

National Academies Press, Washington, D.C., 2004.

Ministry of Science, Technology and Innovation, "White Paper on Enterprise

Architecture", Government Enterprise Architecture in Denmark, Denmark, June

2003 http://www.oio.dk/arkitektur

Sowa, J.F. and J.A. Zachman, ‘Extending and formalizing the framework for

information systems architectures’, IBM Systems Journal, 31(3), 1992, pp. 590-

616.

IEEE Computer Society. IEEE Std 1471-2000: IEEE Recommended Practice for

Architectural Description of Software-Intensive Systems, Oct. 9, 2000.

DODAF - The Department of Defense Architectural Framework, 2004.

Core J2EE Patterns at http://java.sun.com/blueprints/corej2eepatterns

/Patterns/index.html

System Modelling Language: SysML Specification, version 0.8r1, SysML Partners,

2004

UML 2.0 Superstructure Specification (Final Adopted Specification; OMG document

number ptc/04-10-02)


About the Author

Dr. Paul King is a Managing Consultant with VEGA Group PLC. He has considerable

experience in systems engineering and information systems design. Paul provides IT

consulting to managers and engineers in MOD and other government departments in

the areas of enterprise architectures, interoperability, security engineering and system

specification. Before becoming a consultant, Paul worked for eleven years as a

systems engineer for a large IT systems implementation company, and before that as

a Research Scientist (modelling the dynamic behaviour of gun barrels) at the Royal

Military College of Science at Shrivenham. He gained his PhD in Mathematics at the

University of Rochester, NY.

About VEGA

VEGA is an international consulting and technology company. Established in 1978, we

work closely together with clients in Space, Defence and Government throughout

Europe and in the US.

Recognised for our specialist expertise and in-depth domain knowledge, we provide

independent advice and support services directly to end-user organisations, such as

space agencies, armed forces and government bodies. As a consortium partner or

subcontractor of choice, we also support prime contractors and systems integrators.

Our services and solutions are targeted at delivering sustainable performance

improvements for our clients. They are based on the practical application of in-depth

domain knowledge and technical excellence, born out of over 25 years' hands-on

experience.

Our people combine a pragmatic engineering ethos with unparalleled enthusiasm for

the domains in which they work. Their skills and dedication ensure VEGA is highly

valued as an expert adviser and partner of choice - a trusted pair of hands for both

consulting and implementing technology.

VEGA delivers services to clients worldwide. We have offices and operations in

Europe and the US.

To find out more: www.vega-group.com

enterprise architecture and aesthetics

Documents

firmitas utilitas venustasque

national research council

competitive selection process

enterprise architecturemodelling language

enterprise architecture modellinglanguage

vega group plc

coherent enterprise models

enterprise architecture meta