© 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
© 2005 VEGA Group PLC 2
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
© 2005 VEGA Group PLC 3
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
© 2005 VEGA Group PLC 4
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.
© 2005 VEGA Group PLC 5
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.
© 2005 VEGA Group PLC 6
© 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
© 2005 VEGA Group PLC 7
© 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.
© 2005 VEGA Group PLC 8
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
© 2005 VEGA Group PLC 9
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
© 2005 VEGA Group PLC 10
���������
���� ���
����
�������
������ �
� ������
� ��� �
������
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;
© 2005 VEGA Group PLC 11
• 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
© 2005 VEGA Group PLC 12
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;
© 2005 VEGA Group PLC 13
• 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.
© 2005 VEGA Group PLC 14
• 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.
© 2005 VEGA Group PLC 15
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
© 2005 VEGA Group PLC 16
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
© 2005 VEGA Group PLC 17
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
© 2005 VEGA Group PLC 18
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
© 2005 VEGA Group PLC 19
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)
© 2005 VEGA Group PLC 20
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
Top Related