Tips & Tricks
Your SlideShare is downloading.
Enterprise Architecture and Aesthetics
Like this document? Why not share!
slide mỹ học cầu
by COMM 2213
Sukrut Repose : 3BHK Luxury Homes f...
Architecture lesson #3 the pantheon
4 hình thức Kiếm tiền online hiệu q...
by ProSeoer Slide Share
Email sent successfully!
Show related SlideShares at end
Enterprise Architecture and Aesthetics
Jun 08, 2010
Comment goes here.
12 hours ago
Are you sure you want to
Your message goes here
Be the first to comment
Be the first to like this
Number of Embeds
Flagged as inappropriate
Flag as inappropriate
No notes for slide
Transcript of "Enterprise Architecture and Aesthetics"
1. White Paper 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. © 2005 VEGA Group PLC 1
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 2
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 st construction, usually a building, or set buildings, or a town or city. In the 1 century BC © 2005 VEGA Group PLC 3
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 4
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 5
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. © Paul King, 2004 Figure 1 - The front elevation of Lansdown Crescent, Bath 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 6
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. © Paul King, 2004 Figure 2 - Part of the rear elevation of Lansdown Crescent, Bath 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 7
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 8
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 9
house, which can then be re-used to create plans like the one in Figure 3. Figure 3 - A plan of a house 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 10
• 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 11
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 Context Programme Specification Technology Figure 4 - Enterprise Architecture Viewpoints 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 12
• 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 13
• 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 14
Characteristic hosts Operational characterises Resource Operational System has sub-system is used by Resource hosts is operated by Operational System Role provides Operator contributes to undertakes participates in has sub-function System characterises Function Operational Operational supports Activity consists of Objective is exposed by used by QoS Operational Activity has sub-function System © 2005 VEGA Group PLC Service characterises supports Operational Context Viewpoint Specification Viewpoint System has sub-system Programme Deliverable Figure 5 - Enterprise Architecture Meta-Model has delivers has sub-component Enabling is used by Component is required by the end of Technology Programme Programme Activity Artefact is required by the start of is implemented by used by offers undertakes is implemented by is a life-cycle state of Component Standard is implemented by Interface is responsible for Programme Programme Deliverable is implemented by depends on delivers OTS Package is sub-programme of Technology Viewpoint Programme Viewpoint 15
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 16
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 17
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 18
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 19
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 © 2005 VEGA Group PLC 20