Enterprise Architecture and Systems Engineering Peter Webb BMT Defence Services Limited, United Kingdam, [email protected] Abstract: Factors such as the end of the cold war and increasing globalisation in tenns of competition and social responsibility have significantly increased the complex­ ity of events addressed both by governments and by industry. Furthennore, their responses are increasingly more constrained by economic and environ­ mental issues. It is clear that the large complex "socio-techno-economic" sys­ tems (i.e. enterprises) that may comprise as well as create and deliver these re­ sponses must be both agile and efficient. An approach to the analysis, design and specification of such enterprises is presented which draws on state of the art Enterprise Architecture concepts and Systems Engineering techniques. The resulting EA/SE method enables clear justification of design, definition of in­ terfaces and derivation of validated requirements. Comparisons are drawn to Zachman and ISO 15704 - GERA concepts. 1 INTRODUCTION This paper describes how enterprise architecture concepts and systems engineering techniques have been combined to provide a new approach to the analysis, design and specification of enterprises. It has been named the Enterprise Architecture I Systems Engineering (EA/SE) method. Enterprise architecture provides a rich but generic framework that guides the construction of enterprise models. Furthermore, it enables stakeholder needs and expectations to be identified and traced to technological design while facilitating integration efforts. Systems engineering provides the tools and techniques to create "well engineered" enterprise architectures. In particular, it uses modelling as a means for analysis, improvement and validation of proposed solutions. Sys- The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35621-1_43 K. Kosanke et al. (eds.), Enterprise Inter- and Intra-Organizational Integration © IFIP International Federation for Information Processing 2003 160 Webb, P. terns engineering also supports possible integration between interfacing en­ terprises or systems by identifying and defining interfaces. The systems engineering core process first defmes desired behaviour and determines structural options. Then the defined behaviour is allocated onto each structural option to create a range of potential solutions. Finally a trade­ off is undertaken against pre-defined effectiveness measures in order to iden­ tify a near-optimal solution. In this way an enterprise architecture description is supported by a num­ ber of products comprising diagrams, models and logic statements under­ pinned by a data repository. Where necessary architecture descriptions can be easily translated into requirement sets that are coherent, consistent, com­ plete and validated as correct. 2 ENTERPRISE ARCHITECTURE EA/SE considers an enterprise to be an organisation of people performing processes and supported by technology that cooperate to create and deliver solutions to customers (Fig.l ). These solutions comprise products and/or services that may themselves be whole or part enterprises. Furthermore, an enterprise can interface with others to form a larger integrated enterprise. Figure I: Composition of an Enterprise Examples of enterprises include procurement, support or design project teams and company organisations (people biased) as well as industrial facili­ ties and ships, aircraft or other transport systems (technology biased). The behaviour and structure of an enterprise is defined by its architecture. If an enterprise is to create and deliver quality solutions that, where practical, meet all stakeholders' needs and expectations within cost, schedule and risk Enterprise Architecture and Systems Engineering 161 constraints then it should have an efficient, enabling architecture. Such en­ terprise architectures may be considered "well engineered". The EA/SE approach does not analyse the behaviour and structure of a whole enterprise at once. Instead, it progressively analyses the enterprise from successive degrees of abstraction, building the complete enterprise ar­ chitecture in a structured manner. These degrees of abstraction provide per­ spectives of the architecture and are analogous to supporting layers where each layer defines the context and provides input data for the layer beneath (Fig. 2). The analysis activity starts at the most abstracted layer and works down through the layers. The systems engineering core process outlined in section 1 above is applied once to each layer. Capability I Market Asset I Business Unit System Context System Concept Logical Representation Physical Realisation Figure 2: ENSE Layers of Abstraction Table 1:Comparison of ENSE Abstraction with ZEAF Perspectives and Lifecycle Phases of ISO 15704 (GERA and Pre EN ISO 19439 EA/SE ZEAF ISO 15704 - GERA & Abstraction Perspective EN ISO 19439 Lifecycle Phase Capability I Not Addressed Domain Identification Market Asset I Not Addressed Concept Definition Business Unit System Scope Requirements Definition Context (Contextual)- Planner System Enterprise Model Preliminary I Concept (Conceptual)- Owner Design l Design Logical System Model Detailed I Specification Representation (Logical) - Designer Design Physical Technology Model Implementation Description Realisation (Physical) - Builder The EA/SE layers of abstraction reflect the "perspectives" of the Zach­ man Enterprise Architecture Framework (ZEAF) (Zachman, http://). How­ ever, EA/SE adds two higher layers while missing the lowest ZEAF perspec­ tives dealing with "Detailed Representation" and "Functioning Enterprise". 162 Webb, P. Furthermore, the EA/SE layers are analogous to the life cycle phases of the Generic Enterprise Reference Architecture (GERA), (IS015704, 1999) and (pre EN ISO 19439, 2002). These relationships are shown in Table 1 with typical outputs of EA/SE in Table 2. Ta bl e 2: TlVDlCa . IE NSE Outputs bv Abstraction Layer EA/SE Abstraction Typical EA/SE Outputs - Analysed threats and incidents with desired coun- Capability I Market termeasures and responses. - Allocation to capability I market areas - Outline capability (user) requirements. - Analysed capability behaviour Asset I Business Unit - Detailed user requirements - Allocation to assets I business units - Outline system requirements - Analysed asset I business unit behaviour System Context - Detailed system requirements - Allocation to systems - Outline svstem architecture - Analysed system behaviour System Concept - Detailed system architecture - Allocation to sub-systems - Prel.Uuimu design - Analysed sub-system behaviour Logical Representation - Detail design Allocation to Objects - Outline build - Analysed object behaviour Physical Realisation - Allocation to components - Build description Confusingly, in the ZEAF each "perspective" is divided into "abstrac­ tions" that deal with six fundamental interrogatives. Within EA/SE, each layer of abstraction (i.e. perspective) is similarly divided to address the six interrogatives, but they have been renamed as foci and are defined as fol- lows: a) What entities are being processed? i.e. inputs and outputs; b) How are entities processed? i.e. functions (tasks, activities); c) When do processes occur? i.e. events and times (sequence); d) Where are processes occurring? i.e. locations and environmental con- ditions; e) Who is involved in processes? i.e. organisation, jobs, roles, skills (de- pending on perspective); Enterprise Architecture and Systems Engineering 163 f) Why are processes undertaken in the way they are? i.e. principles, standards. The EA/SE approach aims to answer each of these interrogatives: Analy­ sis of behaviour addresses the interrogatives "what", "how" and "when", while the consideration of structure addresses "where" and "who". Similarly, consideration of motivation and purpose addresses the interrogative "why". The abstraction layers and foci combine to form the EA/SE framework as shown in Table 3. Table 3· The ENSE Framework Behaviour Structure EA/SE Abstraction What? How? When? Where? Who? Why? Capability Asset System Context System Concept Logical Representation Physical Realisation The output from analysis is a description of the Enterprise Architecture model at the respective layer of abstraction. Combining the descriptions for each layer provides a description of the complete Enterprise Architecture model. In fact, the description of each architecture layer can take the form of a requirement specification for the layer beneath. 3 SYSTEMS ENGINEERING The Systems Engineering Core Process adopted by EAISE is adapted from Oliver, et al, (1997). The associated process flow diagram is repro­ duced in Fig. 3. The overall process description given in their book has been adapted in relation to the EA/SE approach and is included in the following paragraphs. Step 1 evaluates and categorises available information for input to the modelling steps. It identifies and eliminates information redundancy, inconsistency and obvious incompleteness. In all but the first abstraction layer this is simply a matter of accepting context information output from 164 Webb, P. is simply a matter of accepting context information output from analysis in the preceding layer. Iterate tofind a feasible solution 2 Define 1-- Effectiveness Measures I 3 5 6 Assess Create .. Perfonn Create __. .... Available Behaviour ... Trade-Off -+ Sequential