Your SlideShare is downloading. ×
EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION

                                               EUROCONTROL




   ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


                              ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

                               ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


                              ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

7     LESSONS LEARNT & HIGH LEV...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


1        EXECUTIVE SUMMARY
Thi...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

  4) Undertaking detailed devel...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


2        INTRODUCTION

2.1    ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

The TRS specified the need to p...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


3        DEFINITIONS AND ACRON...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

          NATO                 ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


4        BACKGROUND TO EA AND ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

              manage investment...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

information between all stakeho...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


5        DEVELOPMENT APPROACH ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

        •    expert knowledge o...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

(business) goals, links are nee...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)




                            ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)



The development of the SWIMPO...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

    •    Reporting
    •    Col...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

       -    Application Service...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)


6             ENTERPRISE ARCHI...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

6.2        Development of the E...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

     •   The operational nodes ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

need to identify what are the g...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

      •    Operational View des...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

contain a structured list of ca...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)




                        Fig....
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)




                       Fig. ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

Flight Crew

                  ...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)




                     Fig 10:...
Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9)

 class Concept Model Iteration ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Initial Activities in Enterprise Architecture application to ...
Upcoming SlideShare
Loading in...5
×

Initial Activities in Enterprise Architecture application to ...

1,016

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,016
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Initial Activities in Enterprise Architecture application to ..."

  1. 1. EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION EUROCONTROL Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Document Identifier: OATA-MCS-12-09 Edition: 1.1 Edition Date: 27-05-2009 EUROPEAN AIR TRAFFIC MANAGEMENT
  2. 2. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) DOCUMENT CHARACTERISTICS TITLE Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) EATM Infocentre Reference: Document Identifier: OATA-MCS-12-09 Edition: 1.1 Contractual Ref: TRS 08-11642-C Version Date: 27-05-2009 Contractual ID: D9 Abstract This document provides a summary description of the material produced throughout the study which has ensued from the Eurocontrol TRS entitled “Initial Activities in Enterprise Architecture application to ATM”, plus the analyses performed, the conclusions drawn, the lessons which have been learnt and recommendations made for the subsequent work to be done in the SESAR Development Programme. The document takes the form of an Evaluation Report (D9). Keywords EAEA OATA MCS SESAR Contact Person(s) Tel Unit Prepared by: John R F Guy +44 1489 616526 NATS Issued by: Michael Heap +44 1489 444424 NATS STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via In progress General Public Intranet Internal Draft EATM Stakeholders Extranet Working Draft Restricted Audience Configuration Manager Proposed Issue Printed & electronic copies of the document can be obtained from the Released Issue x EATM Infocentre or from the OATA PSO ELECTRONIC SOURCE Path: File Name: Host System: Software Application Size: Windows XP: Microsoft Word 10.0 Publications OATA Project Support Office (PSO) EUROCONTROL Headquarters EUROCONTROL Headquarters 96 Rue de la Fusée, B-1130 BRUSSELS 96 Rue de la Fusée, B-1130 BRUSSELS Tel: +32 (0)2 729 47 15 Tel: +32 (0)2 729 50 40 Fax: +32 (0)2 729 51 49 E-mail: publication@eurocontrol.int E-mail: oata.pso@eurocontrol.int OATA-MCS-12-09, Edition: 1.1 Page: ii of 58
  3. 3. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) DOCUMENT APPROVAL The following table identifies all management authorities who have successively approved the present issue of this document. AUTHORITY NAME AND SIGNATURE DATE Work Package Manager Project Manager P. Monaco DOCUMENT CONTROL Copyright notice © 2009 European Organisation for the Safety of Air Navigation (EUROCONTROL). All rights reserved. "Member States of the Organisation are entitled to use and reproduce this document for internal and non-commercial purpose under their vested tasks. Any disclosure to third parties shall be subject to prior written permission of EUROCONTROL". DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. Edition Pages Edition Date Reason for change Number affected 0.1 16-03-2009 Working draft document All 0.2 20-03-2009 New table of content & text for Section 7 0.3 27-03-2009 Updated content (Sections 6 and 8) All 0.4 08-04-2009 Updated content (Executive Summary & Section 7) 0.5 24-04-2009 Updated for Eurocontrol comments All 1.0 08-05-2009 Final version Updated after final Eurocontrol comments and 1.1 27-05-2009 discussion (26-05-09) OATA-MCS-12-09, Edition: 1.1 Page: iii of 58
  4. 4. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) TABLE OF CONTENTS DOCUMENT CHARACTERISTICS ........................................................................................................ II DOCUMENT APPROVAL...................................................................................................................... III DOCUMENT CONTROL ........................................................................................................................ III DOCUMENT CHANGE RECORD ......................................................................................................... III TABLE OF CONTENTS......................................................................................................................... IV LIST OF FIGURES.................................................................................................................................. V LIST OF TABLES ................................................................................................................................... V 1 EXECUTIVE SUMMARY................................................................................................................. 6 2 INTRODUCTION ............................................................................................................................. 8 2.1 CONTEXT................................................................................................................................... 8 2.2 SCOPE OF THE STUDY ................................................................................................................ 8 2.3 STRUCTURE OF THIS REPORT ..................................................................................................... 9 3 DEFINITIONS AND ACRONYMS................................................................................................. 10 4 BACKGROUND TO EA AND SOA IN THE ATM DOMAIN ......................................................... 12 4.1 SESAR PROJECT DEFINITION PHASE ....................................................................................... 12 4.2 SOA TASK FORCE ................................................................................................................... 14 5 DEVELOPMENT APPROACH & OVERVIEW OF EAEA DELIVERABLES ............................... 15 5.1 GENERAL OVERVIEW ............................................................................................................... 15 5.2 HIGH LEVEL BREAKDOWN OF ACTIVITY ..................................................................................... 16 5.2.1 Operational Goals.......................................................................................................... 16 5.2.2 Operational Services, Processes & Organisation ......................................................... 17 5.2.3 Information..................................................................................................................... 20 5.2.4 Information and Application Services & Systems.......................................................... 20 6 ENTERPRISE ARCHITECTURE FRAMEWORK CONSIDERATIONS....................................... 22 6.1 INTRODUCTION ........................................................................................................................ 22 6.2 DEVELOPMENT OF THE EAEA FRAMEWORK PROPOSAL ............................................................. 23 6.2.1 Summary of Status ........................................................................................................ 23 6.2.2 Overview of Initial Proposal ........................................................................................... 23 6.2.3 Overview of Updated Proposal...................................................................................... 24 6.3 RATIONALE AND USE OF SOME SELECTED SUB-VIEWS ............................................................... 26 6.3.1 Capability (Strategic) View ............................................................................................ 26 6.3.2 Operational View ........................................................................................................... 27 6.3.3 Service-Oriented View................................................................................................... 32 6.3.4 System View .................................................................................................................. 38 OATA-MCS-12-09, Edition: 1.1 Page: iv of 58
  5. 5. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 7 LESSONS LEARNT & HIGH LEVEL CONCLUSIONS................................................................ 41 7.1 DIRECTION OF STUDY AS SET BY THE TRS ................................................................................ 41 7.2 STRATEGIC BUSINESS ASPECTS ............................................................................................... 41 7.3 THE APPROACH AND METHOD .................................................................................................. 41 7.4 FRAMEWORKS ......................................................................................................................... 42 7.5 INFORMATION AND INFORMATION SERVICES .............................................................................. 42 7.6 OPERATIONAL AND APPLICATION SERVICES .............................................................................. 44 7.7 SYSTEMS................................................................................................................................. 44 7.8 GENERAL CONCLUSIONS .......................................................................................................... 44 8 STUDY RECOMMENDATIONS.................................................................................................... 45 8.1 DIRECTION OF STUDY AS SET BY TRS....................................................................................... 45 8.2 STRATEGIC BUSINESS ASPECTS ............................................................................................... 45 8.3 THE APPROACH AND METHOD .................................................................................................. 45 8.4 FRAMEWORKS ......................................................................................................................... 47 8.5 INFORMATION AND INFORMATION SERVICES .............................................................................. 47 8.6 OPERATIONAL AND APPLICATION SERVICES .............................................................................. 47 8.7 SYSTEMS................................................................................................................................. 48 8.8 GENERAL RECOMMENDATIONS ................................................................................................. 48 9 PROPOSED WAY AHEAD ........................................................................................................... 49 10 REFERENCES .......................................................................................................................... 51 11 ANNEXES ................................................................................................................................. 52 11.1 ANNEX 1 – LIST OF OPERATIONAL (BUSINESS) GOALS ................................................. 52 11.2 ANNEX 2 – CROSS REFERENCES BETWEEN OPERATIONAL (BUSINESS) GOALS AND OPERATIONAL IMPROVEMENTS (OI) IN LINE-OF-CHANGE (LOC) 10 ........................................ 57 LIST OF FIGURES Fig. 1: Overview of Initial EAEA Framework Proposal ............................................................8 Fig. 2: Principal Relationships between Deliverables D1 to D8 ............................................15 Fig. 3: SWIMPOOL Diagram – Airport Centric View .............................................................18 Fig. 4: ATC Hierarchical & C2 Relations ...............................................................................19 Fig. 5: Overview of Updated EAEA Framework Proposal .....................................................25 Fig. 6: NCV-1 – Capability Vision ..........................................................................................27 Fig. 7: NOV-4 – Organisational Relationship Chart...............................................................28 Fig. 8: NOV-5 - Operational Activity Model Example ............................................................29 Fig. 9: NOV-5 – Operational Activity Model...........................................................................30 Fig 10: NOV-6c – Operational Event-Trace Description .......................................................31 Fig. 11: NOV-7 – Information Model (Example) .....................................................................32 Fig. 12: NSOV-1 – Service Taxonomy - Operational Services...............................................33 Fig. 13: NSOV-1 – Service Taxonomy – Application Services...............................................34 Fig. 14: NSOV-1 – Service Taxonomy – Information Services ..............................................35 Fig. 15: NSV-1 – System Interface Description......................................................................39 Fig. 16: NSV-12 – Service Provision ......................................................................................40 LIST OF TABLES Table 1: NSOV-2 – Service Definition - Operational Services ...............................................36 Table 2: NSOV-2 – Service Definition - Application Service ..................................................36 Table 3: NSOV-2 – Service Definition - Information Service..................................................37 Table 4: NSOV-3 – Service to Operational Activities Mapping - Operational Services..........38 OATA-MCS-12-09, Edition: 1.1 Page: v of 58
  6. 6. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 1 EXECUTIVE SUMMARY This evaluation report presents the findings of the Eurocontrol TRS study entitled “Initial activities in Enterprise Architecture application to ATM”. The stimulus for this study came from the output of the SESAR Project Definition (PD) Phase, where it was identified that Enterprise Architecture (EA) and Service Oriented Approach (SOA) techniques should be applied to the development of the future European ATM System (EATMS) which would underpin the creation of an ATM Performance Partnership (ATMPP) between the “Users of the Network” (namely the Airspace Users, Airport Operators and Air Navigation Service Providers (ANSPs)). In order to fit with the envisaged timescale for the start of the SESAR Development Phase, the scope of this study was limited to activities at an Airport, concentrating on the arrival, surface movement, aircraft turnround and departure aspects. The findings cover both the approach taken and the actual output of the study. The TRS had specified a number of deliverables which, when created, were thought to capture and describe a European ATM EA (EAEA), plus a draft EA framework proposal to accompany it. The development of these deliverables was undertaken by a consortium led by NATS and included representatives of the major ATM Stakeholder groups who provided expert knowledge in all the key subject areas. Eurocontrol were also closely involved in the study as a contributor. As this type of activity had not taken place in the context of European ATM previously, there was no definitive process to follow. Consequently, a series of workshops and working sessions were held to develop the material required. To expedite the study in the short time available, a “middle-out” approach was taken. Having identified an initial set of Operational (Business) Goals based primarily upon material developed during the SESAR PD phase, a pictorial view of the operational environment being studied was developed which identified the Actors involved and the Operational Processes that take place. After several iterations, this formed the basis upon which Operational and Information Services were defined and developed. Subsequently, a Conceptual Information Model and thence, a more detailed Information Model were developed. Finally, some Systems aspects and associated Application Services were considered. Using the material described above, consideration was given as to how an EA framework should be chosen, scoped and used to support the definition, development and management of the future EAEA. The principal findings of the study were as follows. 1) The approach taken has demonstrated that taking a service-based approach can readily be used to describe, define and develop the inter-relationships needed to create a future EATMS which would underpin the creation of an ATMPP between the “Users of the Network”. 2) The approach taken to develop operational processes, operational services and information services has shown that this can be successfully applied to analyse both the SESAR future vision and today’s legacy situation. Thus, by adopting such an approach, consideration of activities related to IP1 and IP2 can be made seamless. 3) The trade-off between creating the wide range of specified deliverables within the timescale set for the study, and having to take the “middle-out” approach to do this, meant that creating a full EA solution could not be achieved. Although an initial set of operational (business) goals was developed, further work at the business level and taking a more “top-down” approach to the development of performance capabilities and operational services is required before an “ATM Enterprise” can be defined. However, building upon the work done to date, it is considered that this is readily achievable. OATA-MCS-12-09, Edition: 1.1 Page: 6 of 58
  7. 7. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 4) Undertaking detailed development work of systems solutions before a high degree of maturity of the business relationships and operational processes and services is achieved should not be attempted. 5) The development of a Conceptual Information Model, and thence a more detailed Information Model (or Data Model to be used as a reference for the design of systems solutions), is crucial to this type of activity. Further, it, and the associated information requirements, needs to be developed at a very early stage in the architecture process. Having these aspects in place will allow some parallel working to be undertaken at the business, operational and systems levels provided a strong governance régime is also applied across the levels and it acts from a “top-down” perspective. 6) An EA framework must be considered as a support tool to be used to maintain coherence across the variety of aspects which make up the “ATM Enterprise”. The choice of the framework to be used is not critical, relative to determining the nature of the “ATM Enterprise”. Thus, once it is determined, a suitable framework should be selected which is best suited to support the maintenance and management of the “Enterprise”. One of the “standard” frameworks should be used (as opposed to creating a bespoke EAEA framework) in order to minimise support costs since commercially available software tools are based upon them. To date, and for illustrative purposes only, the work has been aligned with the NATO Architecture Framework (NAF). In conclusion, the study has provided valuable insight into how EA techniques can be used to develop an EAEA and that taking a service-based approach will enable an “ATM Enterprise” to be created which will fulfil the vision developed in the SESAR PD phase. The work undertaken has produced an extremely valuable set of recommendations for the future SESAR Enterprise Architecture work. It is highly recommended that these form the basis of, and starting point for, all future work in this subject area. These recommendations will enable a structured approach to be taken to developing an EAEA in the SESAR development programme. OATA-MCS-12-09, Edition: 1.1 Page: 7 of 58
  8. 8. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 2 INTRODUCTION 2.1 Context The results delivered from the SESAR Project Definition (PD) phase recommended that an Enterprise Architecture (EA) approach, together with taking a Service-Oriented Approach (SOA), be used as the basis to manage the development of the Future European ATM System (EATMS). Consequently, the need for a European ATM Enterprise Architecture (EAEA) was identified. It was recognised by many of the ATM stakeholders participating in the SESAR PD phase that a first set of EA & SOA activities needed to be undertaken urgently in order to facilitate and steer the subsequent programme of work to be undertaken during the SESAR Development Phase. The aim of this study was to go some way to addressing this need. 2.2 Scope of the Study The basis of the study was specified in a Task Requirement Sheet (TRS), the details of which can be found in Ref.1. Its objective was to develop some initial versions of some of the main artefacts and views of an EAEA, but with a scope restricted to an Airport context. The study was also aimed at gaining knowledge and experience on how taking an EA approach can be used in the SESAR Development Phase in order to validate which approach shall be taken in the future. Eurocontrol has proposed an initial description of an EAEA framework [Ref.2], tailored to covering SESAR’s requirements and based upon existing EA frameworks. The initial EAEA framework proposed by Eurocontrol is based on the NATO Architecture Framework (NAF) [Ref.3] and UK Ministry of Defence Architecture Framework (MoDAF) [Ref.4], but is customised to adapt aspects of them to meet the needs of ATM. This initial EAEA framework has been applied to the extent considered relevant to the scope of this study, it being further refined based upon the experience gained in applying it to the practical application of considering activities performed at and around an Airport. The EAEA framework proposed by Eurocontrol comprises the following high-level views: e.g. Gantt Chart Goal Problem Opportunity e.g. Performance Targets Strategic View Business Strategies Organisation / Operational Human Actor Service e.g. Organisational Structure Operational View Process Model Timing Process Information Conceptual Information Model System e.g. Logical Architecture Service-Oriented View Information Service AICM, FOIPS Activities Projects / System Interface System View e.g. Technical Architecture Information AIXM, ICOG ICDs Programme View Software Network e.g. Implementation Standards Technical View / Implemented Systems Physical Architecture Hardware ATM Infrastructure Fig. 1: Overview of Initial EAEA Framework Proposal OATA-MCS-12-09, Edition: 1.1 Page: 8 of 58
  9. 9. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) The TRS specified the need to produce 8 deliverables which contain the detailed output from the study, namely : • Deliverable D1 (Operational (Business) Goals) [Ref.12], • Deliverable D2 (Operational Services) [Ref.13], • Deliverable D3 (Operational Processes) [Ref.14], • Deliverable D4 (Organisation Chart) [Ref.15], • Deliverable D5 (Concept Information Model) [Ref.16], • Deliverable D6 (Services) [Ref.17], • Deliverable D7 (Systems) [Ref.18], • Deliverable D8 (Information Model) [Ref.19]. The material created in order to produce these deliverables has also been used to evaluate the detailed proposals made in the EAEA framework of Ref.2. This material has also been used to evaluate the approach which has been followed as a consequence of having to produce these deliverables as defined by the TRS. 2.3 Structure of this Report This report, defined by the TRS (Ref. 1) as Deliverable D9, has been structured as follows. Section 4 provides a summary of the background information considered relevant to setting the scene and context of the work which has been done, plus the foundations upon which the recommendations made concerning the way ahead have been built. It identifies some key recommendations made in the SESAR PD phase deliverables with respect to the current ATM situation [see Refs 6 to 11] and summarises the proposals made by the so-called SOA Task Force [see Ref. 5]. Section 5 provides an overview of the approach taken to create the core material needed to produce the D1 to D8 deliverables, again this primarily being defined by the activities described in the TRS. Thence, section 6 contains the high level summary of the conclusions drawn from the activities to create this core material and the results of the analytical work performed using the material. A specific section is included which contains the results of the evaluation work performed concerning the usefulness and relevance of the EAEA framework proposal and the views contained within it; this is section 6. Section 7 contains an overview of the lessons learned and high level conclusions. Section 8 contains the Study Recommendations drawn from all aspects of the TRS activity. Finally Section 9 outlines a view of the way ahead and how future activities, namely SESAR Joint Undertaking (SJU) WP-B (see Ref. 20), could benefit from the findings of this Report. OATA-MCS-12-09, Edition: 1.1 Page: 9 of 58
  10. 10. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 3 DEFINITIONS AND ACRONYMS ACRONYMS DEFINITIONS AICM Aeronautical Information Conceptual Model AIXM Aeronautical Information Exchange Model ANSP Air Navigation Service Provider AOC Airline Operations Centre ATC Air Traffic Control ATM Air Traffic Management ATMPP ATM Performance Partnership BAA British Airports Authority CDM Collaborative Decision Making CIM Concept Information Model C2 Command and Control DCB Demand Capacity Balancing DFS Deutsche Flugsicherung DoW Description of Work EA Enterprise Architecture EADS European Aeronautic Defence and Space Company EAEA European ATM Enterprise Architecture EATMS European ATM System ENAV Ente Nazionale Assistenza al Volo ETA Estimated Time of Arrival FOIPS Flight Object Interoperability Proposed Standard IATA International Air Transport Association ICAO International Civil Aviation Organisation ICDs Interface Control Documents ICOG Interoperability Consultation Group IP Implementation Package IT Information Technology KPA Key Performance Area KPI Key Performance Indicator LDM Logical Data Model LFV formerly Luftfartsverket (Sweden) LIM Logical Information Model LOC Line-of-Change MOD Ministry of Defence (United Kingdom) MoDAF MOD Architecture Framework NAF NATO Architecture Framework OATA-MCS-12-09, Edition: 1.1 Page: 10 of 58
  11. 11. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) NATO North Atlantic Treaty Organisation NATS formerly National Air Traffic Services Ltd. (United Kingdom) NOP Network Operations Plan OBG Operational (Business) Goal OI Operational Improvement PD Project Definition R&D Research & Development RBT Reference Business Trajectory SBT Shared Business Trajectory SESAR Single European Sky ATM Research SESAR PD SESAR Project Definition SICTA Sistemi Innovativi per il Controllo del Traffico Aereo SJU SESAR Joint Undertaking SOA Service-Oriented Approach SOV Service-Oriented View SWIM System Wide Information Management TOBT Target Off Block Time TRS Task Requirement Sheet WP Work Package XMI XML Metadata Interchange 4D Four-Dimensional OATA-MCS-12-09, Edition: 1.1 Page: 11 of 58
  12. 12. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 4 BACKGROUND TO EA AND SOA IN THE ATM DOMAIN 4.1 SESAR Project Definition Phase The deliverables from the SESAR PD phase made a number of recommendations, relative to today’s situation [Ref.6], upon which the vision of defining and managing a future EATMS should be based. These covered the 4 main subject areas of the business aspects related to air transport, the role of and approach to performing ATM in the future, the nature of the future institutional aspects and the approach to designing and managing the technical aspects of the future “System”. A selection of the key recommendations was made upon which to base the strategic business considerations and direction needed throughout this study. Those selected are listed below. For Air Transport : • Stakeholders in the Air Transport Industry must grow their businesses to strengthen the links between them. • The business plans of the “Users of the Network” (i.e., the Airspace Users, Airport Operators and Air Navigation Service Providers) must be more closely aligned through a set of service relationships. • Stakeholder’s business planning must share a common set of values, goals, incentives & risk sharing mechanisms. • The ATM Industry must be empowered to manage to the above values & goals by being able to make its own investment decisions & how to finance them. For ATM : • There is a need for a consistent & explicit framework which links the economic, commercial & operational priorities of stakeholders. • A comprehensive ATM performance framework is needed as the basis upon which to make management decisions. • The lack of flexibility to easily change systems must be addressed to enable variable levels of operational ATM System capacity to be provided in real-time. • The concept of a “Network Plan” must be comprehensively developed & implemented • An explicit set of relationships to specify services, requirements & obligations between stakeholders must be created such that they become integrated “partners” in the future ATM System. • A more liberalised approach to service provision & a more proactive approach to investing in new infrastructure based upon applying the principles of asset management must be considered. • Interoperability to be developed & specified at service & functional levels through development of single functional architecture of the future ATM System. For the Institutional aspects : • A simpler, coherent & consistent framework of legislation & regulation matched to the ATM Industry’s future business model is a key goal. • Design the institutional framework & business framework together, such that both work collectively for the benefit of the air transport industry as a whole. • The Future ATM System is likely to closely integrate air & ground systems; this will need simpler decision making mechanism & process(es) to be used to OATA-MCS-12-09, Edition: 1.1 Page: 12 of 58
  13. 13. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) manage investment decisions – these must be designed concurrently with future ATM System. • Realising the expectation of a single functional architecture based upon the exchange of services between stakeholders means there must be a move away from developing prescriptive, technically-oriented standards towards one taking a performance-based approach. For the “System” aspects : • The Design of the Future ATM System must be based upon having a : o functional architecture defining the information flows needed between principal entities within it; o clear distinction between ATM services, the supporting (technical) services and the physical assets which make up the technical infrastructure. • Applied R&D must be focused upon the applications needed to achieve the overall System performance targets, rather than on the technological solutions to deliver them. • The development of future products must be coupled with the in-service support/asset management régimes to achieve a more comprehensive, coherent decision making process. From the recommendations made in Ref.6, the vision of a performance-driven future EATMS based upon a collaborative ATM Performance Partnership (ATMPP) between the “Users of the Network” was proposed [Ref.7]. This forms the foundation of the strategic business and organisational aspects which were considered throughout the study (Note : The ATMPP between the “Users of the Network” will be termed the “ATM Enterprise” for convenience in this document). Based upon the key recommendations outlined above, the system architecture work performed in the SESAR PD phase recommended that EA and SOA techniques be used to develop, define, design and manage the future EATMS. This proposal was based upon the following principal shortcomings of the current situation. • The current EATMS has a fragmented design which is difficult and expensive to change. • The diversity of the technologies in use throughout the systems in operational service today is so large that taking a “bottom-up” approach to making changes to individual systems to try and create a “Single” EATMS for the future will never work in a way which will meet today’s expectations of the stakeholders for a future, performance- driven approach. • The “piecemeal” approach which has been taken up to now to maintaining legacy systems and/or replacing them “one-by-one” in the context of a System-design philosophy which is based upon the “point-to-point” exchange of information is fundamentally mismatched with the way in which modern information technology (IT) systems are designed, how they function and the way in which they need to be procured and maintained. • The way in which the definition, design and evolution of a EATMS has been approached to date has neither led to an effective harmonisation of air navigation service providers’ (ANSP) systems, applications, or interfaces, nor to the creation of a true EATMS which includes the relevant systems all of the Stakeholders which need to be part of it (specifically those of the airspace users and airport operators). None of the above will be capable of enabling the proposals being developed as the Future ATM Target Concept [Ref.8] to be implemented, since it relies on being able to share OATA-MCS-12-09, Edition: 1.1 Page: 13 of 58
  14. 14. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) information between all stakeholders (i.e., through the use of System-wide Information Management (SWIM) techniques) and provide a high degree of connectivity to maximise the benefits of using Collaborative Decision Making (CDM) techniques. 4.2 SOA Task Force From the above points, it was clear that a fundamentally different approach needs to be taken to the design and development of the future EATMS. If stakeholders want to derive the benefits of using modern IT solutions (which are not necessarily bespoke to the ATM industry) to implement the future SESAR concept of operations and meet the future performance needs (but starting from today’s diverse legacy systems baseline), making changes to the design of, and/or replacing, systems must be done in a harmonised way and at a common level throughout the EATMS’s architecture. Taking a service-oriented approach and using an Enterprise Architecture framework will enable this harmonisation to be achieved. As a result of making these recommendations, a small multi-stakeholder task force was set- up to develop them and propose some “next steps”. Their report is included as Ref.5, with a summary of some key findings being as follows. • European ATM has to be seen as a single enterprise, captured in the EAEA. • The EAEA provides a business-driven framework that allows a meaningful way to partition and manage ATM complexity, reconciling different partners’ business visions for ATM and creating a bridge between their business needs and their requirements for IT solutions. • Using a combination of EAEA and SOA will enable improvements in business agility and efficiency to be realised through a streamlining and alignment of the supporting IT infrastructure to the business. • Adopting EAEA and SOA approach is not a silver bullet that will immediately solve all the issues surrounding the evolution of ATM systems. • Moving to using an EAEA and SOA techniques implies a paradigm shift in the way the business is viewed and managed and in the way the supporting IT infrastructure is specified and developed. This will require a big cultural change, especially to management and system engineering processes. • In an EAEA/SOA and SWIM-based environment, partners give access to their systems and information to other partners within the enterprise. This means that security issues, such as authentication and access control, have to be managed at the enterprise level. It was concluded that the adoption of an EAEA and taking a service-based approach represents a long-term strategy for change that will challenge partners to re-engineer their organisation, processes and IT to optimise their ATM related activities as federations of relatively independent services. However, European ATM is not the first to attempt making such a transition and the experience of other industries must be embraced to identify best practice and learn lessons. Consequently, a key recommendation to take an incremental approach, starting with a tightly scoped initial project, to test the findings of the task force laid the basis of the study which is the subject of this report. OATA-MCS-12-09, Edition: 1.1 Page: 14 of 58
  15. 15. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 5 DEVELOPMENT APPROACH & OVERVIEW OF EAEA DELIVERABLES 5.1 General Overview This section describes the process for the development of the content of the 8 deliverables D1 to D8 (Refs 12 to 19 respectively) which contain the working level details of the material produced throughout the study. Fig.2 shows the principal relationships between these 8 deliverables. ANSP Operational (Business) [D1] Business Goals relationships Airspace Airport Users Operator ATM Performance Partnership Operational (Business) Services [D2] Conceptual Information Model Process & [D5] service Operational relationships Processes [D3] Information Services Information Model [D6] Systems Application Services [D8] [D7] Systems & Organisational service (Unit) relationships Structure [D4] Fig. 2: Principal Relationships between Deliverables D1 to D8 The basic material which formed the core of the content for the 8 deliverables was developed through using a series of 3 workshops, each of 4 days in duration, and 4 working sessions, each 3 days long, held at Eurocontrol HQ between the beginning of November 2008 and the end of February 2009. The partners participating in these workshops and working sessions were drawn from the following companies and organisations : • Airline Group • BAA • DFS • ENAV • Indra • LFV (supported by Saab / Combitech) • NATS • SICTA • Eurocontrol • SESAR Joint Undertaking’s (SJU) Industrial Support Function (EADS). The basic material was created using the : OATA-MCS-12-09, Edition: 1.1 Page: 15 of 58
  16. 16. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) • expert knowledge of the participants; • material produced throughout the SESAR project definition phase; • draft material which had already been produced by Eurocontrol prior to the start of the study and which was briefed during the training workshop; • material already available from work which had already been done by some partners on this topic. It was acknowledged from the beginning that developing an Enterprise Architecture is an iterative process and that there are many dependencies between the different artefacts within it. Further, ideally a “top-down” approach should be taken which firstly establishes the vision for the enterprise and its strategic business drivers, so establishing the foundations upon which consideration of the other aspects shown in Fig.1 should be based. However, given the scope constraints and the aggressive timescale imposed upon the study, and since the material available from the training workshop was most mature with respect to developing the operational services and operational processes, working on these was chosen as the starting point for the study in order to expedite progress overall. Consequently, consideration of the various layers (indicated as views in Fig.1) has taken a “middle-out” approach to developing the study’s deliverables. Taking such an approach, when coupled with the pre-defined scope of the deliverables, has inherently directed the way in which the work has been done and imposed limitations upon the methods which could have been used. Taking a more “top-down” approach and allowing more flexibility regarding the set of deliverables (but aligning them with one of the standard EA frameworks) would have led to a more succinct set of deliverables which would have concentrated upon outlining the meta- model [e.g., see Ref.3] for the ATMPP and future EATMS (albeit constrained as being only airport-centric), rather than being pre-occupied with the EA views themselves. 5.2 High Level Breakdown of Activity This section summarises the principal aspects of the content of a set of 8 deliverables [see Refs.12 to 19] produced as part of the study. These 8 deliverables contain details of the material produced from the workshops and working sessions outlined above, plus the ensuing analyses and updates which have been performed. 5.2.1 Operational Goals The D1 document deals with one of the 3 aspects (these being Goal, Problem and Opportunity) which were considered by Eurocontrol to make up a Strategic View. The subject of D1 is Operational (Business) Goals. Without specific guidance being provided at the beginning of the study, these Goals have been derived with respect to the notion of an ATM Performance Partnership (ATMPP) between the “Users of the Network” (i.e., the Airspace Users, Airport Operators and Air Navigation Service Providers) as described in the material produced from the SESAR project definition phase [see Ref.7]. A list of operational (business) goals has been produced and is included as Annex 1. These shall be considered to be an initial set since time, scope and need limitations imposed upon the study did not require an in-depth goal modelling activity to be performed. When undertaking such activities in the future a more comprehensive, rigorous and iterative process of goal development, modelling and analysis must be performed to establish a solid operational/business foundation at the top-level of the Enterprise Architecture (EA) model which will be used to guide the development of the Future EATMS. In order to ensure the development of other aspects of the Enterprise Architecture model and subsequent ATM System are guided and driven in a “top-down” manner by the operational OATA-MCS-12-09, Edition: 1.1 Page: 16 of 58
  17. 17. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) (business) goals, links are needed to these other aspects. In this study, in the operational view, an initial set of Operational Services was specified as being required (this being the subject of the D2 deliverable). In order to link the operational (business) goals to these operational services, the notion of capabilities was introduced. Although not specifically required by the study, an outline of how to address this topic by taking an example is described in Ref.12. This was included because when developing the future EA model referenced above consideration of capabilities (and functions) is essential to ensure the operational services are developed and defined to meet the goals. The D1 document also includes the result of an initial attempt at linking the operational (business) goals to the operational improvements (OIs) in the line-of-change 10 contained in the material produced from the SESAR project definition phase [see Ref.9 and Annex 2]. From the analysis performed, it is concluded that all the OIs can be linked to at least one goal and the majority can be linked to two or more. However, as they are understood and/or specified today, most of the OIs appear to be solutions without any specific connections as to how they will meet the performance targets associated with the goals and/or how they are compatible with taking a service-based approach. It shall be clearly understood that the supplementary information contained in Ref.12 concerning the approach used to link the operational (business) goals to the operational services through the use of capabilities is a result of the “middle-out” approach taken from the beginning of the study to produce the other deliverables as they were specified in the TRS. 5.2.2 Operational Services, Processes & Organisation The activity to identify the Operational Processes, as detailed in D3, and Services, as in D2, for this airport-centric study was addressed by developing a diagram, referred to as a “SWIMPOOL”, of what happens in and around an airport with respect to the conduct of ATM. This diagram, shown as Fig.3, became the reference point for the overall activity. It took into account the Actors / Stakeholders / Organisations that are involved (represented by the “lanes” of the “SWIMPOOL”) in a time period from roughly the top of descent of an aircraft on approach (or leaving the stack as appropriate) to an airport, through the aircraft turnround process, to a point on the climb out from an airport. OATA-MCS-12-09, Edition: 1.1 Page: 17 of 58
  18. 18. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Fig. 3: SWIMPOOL Diagram – Airport Centric View OATA-MCS-12-09, Edition: 1.1 Page: 18 of 58
  19. 19. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) The development of the SWIMPOOL diagram provided a very powerful way of visualising what needs to be done; that is, the operational processes and sub-processes that are required, and how they fit together sequentially for each Actor / Stakeholder. The level of detail that needs to be generated should match the objective of the activity. This representation also lends itself to identification of the relationships between the processes carried out by the different actors, allowing process handoffs to be considered and identified. The handoffs can then be categorised as implicit or explicit and expert judgement can be made whether they are carried out manually, or by making use of automation. In summary, Operational Services are the container used to deliver capabilities through the Process. Once the capabilities have been defined and mapped to the objectives or goals, they provide a linking vehicle to the performance framework that exists throughout the architecture. The SWIMPOOL provides a high level view of the Actors involved in the problem space being analysed. The Organisation Chart (the subject of D4) developed as part of this activity, supports the Actors in the SWIMPOOL and provides greater levels of detail, including other Actors which are part of the Organisations identified for the Airport Centric View, and the roles that each Actor can or will carry out. An example diagram (see Fig.4) extracted from Ref.15 illustrates ANSP ATC roles. Fig. 4: ATC Hierarchical & C2 Relations Organisational relationships are also identified and these have been developed from the roles and tasks which are associated to the individual Actors. The relationships identified and detailed fall into the following categories :- • Command & Control (C2) • Hierarchical • Functional OATA-MCS-12-09, Edition: 1.1 Page: 19 of 58
  20. 20. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) • Reporting • Collaborational 5.2.3 Information The “ATM Enterprise”, which embodies the Operational Processes and Services, requires access to information to deliver its performance and objectives. It is crucial that all Actors / Stakeholders, as well as the various processes and services employed, have the same view and understanding of the information that exists. This view was developed and enhanced by identifying, at the highest level initially, the types of information that are required for the “ATM Enterprise” to function. The types of information are usually referred to as “Concepts”. The view of the information (or Concepts) was captured in a Conceptual Information Model (CIM) which supports all Actors / Stakeholders so that they could develop a common understanding of the terms as they apply across the “ATM Enterprise” and, especially importantly, within their respective business areas. Forming the D5 deliverable, the CIM is a prerequisite for the development of consistent and interoperable processes and services, and ultimately information systems. It focuses on the key concepts needed for the interoperation between Actors / Stakeholders. With the Operational Processes and Services that were identified, expert judgement was applied to identify the information objects that needed to be exchanged at lower levels of the “ATM Enterprise”, thus providing a more detailed (Logical) Information Model (the deliverable D8) containing more concepts and subject areas. Again, the level of detail developed was commensurate with the objectives to be met. The Logical Information Model provides : • A more detailed conceptual view of the information required to support the problem space (in this case the Airport Centric View). • The information areas against which a Logical Data Model (LDM) (which was not specified as a deliverable, but which will be needed to determine system design solutions) will be built to : - split work into manageable areas - control data against information concepts so as to prevent unnecessary fragmentation and achieve the correct level of detail in the LDM. • A link between the CIM and the LDM as an enabler, so as not to have to wait for the LDM to be created. • The opportunity to draw out / identify the Information Services which are confirmed against the LDM later. • Help to support a strong Governance régime by providing understanding of information needs. 5.2.4 Information and Application Services & Systems After the Operational Processes and Operational Services were identified and the relevant Conceptual and Logical Information Models were developed, the capability to process and share the information to meet the objectives of the “ATM Enterprise” (in this case the Airport Centric View) was put in place. This was done initially by identifying the Services that will be required to accomplish this. The Services were categorised (see deliverable D6) as : - Information Services which deliver information to and from the Operational Services used by the Actors within the “ATM Enterprise”; or OATA-MCS-12-09, Edition: 1.1 Page: 20 of 58
  21. 21. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) - Application Services where information will be processed in some way, or is the automated part of an Operational Service. After this level of detail was reached and agreed, expert judgement was made to allocate the range of services to systems (the subject of the D7 deliverable) for the future, or consider where they may be undertaken currently in legacy systems. This was achieved and provided an early view by mapping capabilities to legacy applications and where necessary using a bottom-up approach to validate Services without compromising the overall governance of the top-down perspective of the architecture. OATA-MCS-12-09, Edition: 1.1 Page: 21 of 58
  22. 22. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 6 ENTERPRISE ARCHITECTURE FRAMEWORK CONSIDERATIONS 6.1 Introduction This section provides details of how EA Frameworks have been considered throughout the study. In order to meet the goal of managing the scale, scope and inevitable complexity within and across the various subject areas needed to make up an EAEA, a structured approach is needed. Consisting of a series of views which cover the principal subject areas of importance, an EA framework provides a support environment which helps to achieve the above goal. Several Enterprise Architecture Frameworks are in use today, e.g.: • Department of Defence Architecture Framework (DoDAF) used by all major U.S. Government Department of Defence Organisations. • UK Ministry of Defence Architectural Framework (MoDAF) developed by the UK Ministry of Defence. • NATO Architecture framework (NAF) developed by NATO to support achieving a federation of members’ defence systems. • The Open Group Architecture Framework (TOGAF), a standard generic, industry- neutral, architecture Framework. • The ZACHMAN Framework developed by John A. ZACHMAN, another generic, industry-neutral, framework and one of the first to be developed. There is, however, a strong link between DoDAF, MoDAF and NAF, with the latest updates to each of them generally incorporating the most recent additional features of the others. At the heart of an architecture framework is a reference model, termed a meta-model. This specifies the architectural elements and the permissible relationships between them which can be used to describe the architecture of the subject enterprise. The meta-model is a key enabler to achieving coherence across the important subject areas which make up the architecture. This is done by defining which kinds of elements (to be defined only once) can be used and re-used throughout the views which make up the EA framework. Throughout something as wide-ranging and complex as the EAEA is envisaged to be, the need is to maintain coherence and consistency within and across stakeholder organisations in the relevant subject areas is essential. Whether it be for the : • Management team, who are primarily concerned with defining the business strategy, goals, objectives and performance targets, • Operational experts, who will define the operational activities needed to meet the goals and targets, or • Systems/Technical experts, who will determine the systems solutions needed to underpin the operational activities, meet the goals and the targets, all must have the confidence that the individual aspects for which they are responsible fit together with those of the others at all times. Whilst specific specialist groups will be responsible for the content of the views most applicable to their area of responsibility, all will be reliant upon using the information contained in all of the views (as applicable) to discharge their roles and responsibilities. OATA-MCS-12-09, Edition: 1.1 Page: 22 of 58
  23. 23. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) 6.2 Development of the EAEA Framework Proposal 6.2.1 Summary of Status Prior to undertaking this study, Eurocontrol (after collaboration with the SJU’s Chief Architect and its Industrial Support Function), made an initial EAEA framework proposal [Ref.2] tailored to meet SESAR's requirements. This was based upon a combination of NAF and MoDAF, since these had been explicitly updated to incorporate taking a service-oriented approach1; a key recommendation coming from the SESAR PD phase deliverables. The outline structure of this initial proposal is that shown in Fig.1. This initial EAEA framework proposal, plus the material created throughout this study, provided a basis for refining it, leading to the production of an updated EAEA framework proposal [Ref.21]. Subject to confirmation of the suitability of the proposed approach, Ref.21 will be used in the SESAR development programme. 6.2.2 Overview of Initial Proposal The decision to use predominantly views from NAF as the basis for this first framework proposal was, in principle and to a first order, sound, not only because it takes a service- based approach, but also since one of NATO’s main challenges is to create an overall architecture for its “enterprise”. This "enterprise" brings together, when needed, the defence systems of its member Nations; in particular to achieve the interoperability of their systems. This, in principle at least, is well aligned with the SESAR vision to do the same across today’s ATM Systems which are owned by different organisations throughout Europe. It must be remembered, however, that NAF is not itself an architecture. It provides the rules, guidance and product descriptions for developing, presenting and communicating architectural structures in a military defence environment. It is the common denominator for understanding, comparing and integrating these architectures. Consequently, the terms, phrases and views within it are defined in the context of how they are understood throughout the defence industry with respect to NATO’s role, goals and objectives. Thus, using the same vocabulary does not necessarily mean these terms, etc. will be understood and have the same meaning and relevance throughout the ATM industry. As the study progressed, a first assessment was made of the initial EAEA framework proposal resulting in the following observations and conclusions. • A number of specific views and some of the architectural elements of the underlying meta-model contained in the initial proposal were significantly different from their near equivalent views in either MODAF or NAF. Consequently, the use of the MODAF and/or NAF nomenclature to refer to them was confusing and should not be used. • References to “Activities” and “Processes” in the initial proposal were unclear since in MODAF and NAF they appear to be interchangeable. There is potential for confusion unless clarity and consistency of defining and expressing activities and/or processes is achieved since they are critical to identify the services needed to link them. The activities and/or processes are the basis for what the enterprise does and it is extremely important to get their usage clear, unambiguous and as complete and correct as possible. • By deciding that the Service-Oriented View defines only the System Services, with the Operational Services being defined in the Operational View, and creating views which were more systems-oriented caused concerns regarding their compatibility with taking a service-oriented approach and what shall be understood by a service throughout the meta-model. 1 DoDAF is evolving along the same lines. OATA-MCS-12-09, Edition: 1.1 Page: 23 of 58
  24. 24. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) • The operational nodes are, in MODAF & NAF, logical collections of activities (which could be organisation, systems, human, etc.). Therefore, there should not be preconceived notions of whether a system or a human should perform certain activities. • The initial EAEA framework proposal gave the impression that there would be a need to develop and maintain a bespoke architecture framework. The need to do this should be minimised since, for the EA frameworks which already exist, there is a great deal of supporting resources and infrastructure available at, nominally, very little cost. The aim should be to exploit this support to take best advantage of it. • The Technical View does not contain the physical architecture. It contains standards which are used in the other views. The physical architecture, if wanted, is covered in the system view. • The use of the “All View”, which is in both MODAF & NAF, is missing. This needs to be added as the “All View” is essential when working with the other architectural views since it provides the overall scope and purpose of the enterprise as a whole. In addition to the points made above, a number of other considerations were identified as follows. • Greater emphasis needs to be placed upon firstly creating the scope, definition, aim and mission of the enterprise for the future EAEA, rather than attempting to analyse which framework and thence, which views should be used to define and describe it. • Developing common architectural descriptions which are meaningful both within different companies, organisations, etc. and across them, and which will exist in a distributed enterprise environment will require a common standard for their description. This standard (i.e., the selected architecture description framework) requires a language comprising common language elements, syntax and semantics. The reference model must provide a notation traceable to a formal definition for the modelling elements and the relationships used to describe a specific architecture. • Both MoDAF and NAF provide a service description that is independent of the categorisation or underlying implementation of the service. This is a crucial point in the development of service-oriented architectures and is probably a concept that is most difficult to grasp. Nevertheless it is one of the powerful means to achieve a future EATMS which is composed of the various systems of the different stakeholder organisations. Thus, it is essential to keep the architecture framework indifferent to any kind of implementation specific categorisation of services. The initial EAEA framework proposal did not adhere to this fact. 6.2.3 Overview of Updated Proposal Using the material developed throughout this study and consideration of the observations, conclusions and points identified above with respect to the initial framework proposal, an update of the proposal has been made by Eurocontrol [Ref.21]. The change has been to align the proposal with a standard framework in order to be able to benefit from the “commercial-off-the-shelf” support (e.g., in terms of future tools development, documentation and training) available. Given the limited analysis performed in this study, the experience gained to date and for demonstration purposes at this stage, NAF will be the standard framework used to exemplify the roles of an architecture framework and meta-model in the remainder of this section of the report. However, this does not imply that NAF is the best candidate to use to support the development of the EAEA in the future, nor does it imply that all parts of the framework must be used. Before an appropriate meta-model is defined for the EAEA and a suitable architecture framework chosen for use throughout the SESAR development programme, there is still a OATA-MCS-12-09, Edition: 1.1 Page: 24 of 58
  25. 25. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) need to identify what are the goals of the EAEA, and therefore, which parts of the selected framework will be needed to support achieving these goals. Fig.5 shows an overview of the updated EAEA Framework Proposal. The main difference between it and the initial proposal are : • The “All View” has been introduced. • Greater emphasis has now been placed on capabilities by renaming the Strategic View. • The “Service-Oriented View” previously only addressed services provided by the IT system. Now it addresses all services (including Operational Services previously included in the Operational View) with the kind of service being clearly indicated. • The “System View” now addresses the more general notion of Resources, not just the IT systems, and now includes the notion of "functions”. • The “Technical (Standards) View” now addresses guidelines and standards to support implementation, rather than the implementation itself. Planning of programmes, projects, acquisitions to provide the required capabilities. Capability (Strategic) Problem / View Goal Capability Milestones / Opportunity Timing The high-level requirements for Enterprise change over time. Definitions Operational Organisation / View Information Information View Process Sets the scope and context, provides a summary of findings. Human Actor Exchange Projects / Activities The operational concept – operational roles, processes, scenarios; information flows. Service-Oriented View View Service (Project / Acquisition) View Overview The services to support the operations, their interfaces, behaviour and policy. Systems View Resource / Inter- View Function Data System connection The solution specification – the resources providing the services. Programme Technical (Standards) All View Implementation Technical View Guideline Standard To support implementation – policy, standards, guidance, constraints. Fig. 5: Overview of Updated EAEA Framework Proposal In detail, the refined EAEA framework proposal is decomposed into the following main views. • All View is an overarching view that sets the scope and context of the architecture and contains a common definition of the terms used to describe the architecture. (Note: This view was not addressed by the EA Demonstration Study). • Capability (Strategic) View describes the enterprise vision and in particular the goals or targets that guide the architecture’s development to ensure that all parts of the enterprise collaborate efficiently to reach the same overall goals. OATA-MCS-12-09, Edition: 1.1 Page: 25 of 58
  26. 26. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) • Operational View describes the operational processes and activities, organisations and actors and information exchanges required to accomplish ATM operations. • Service-Oriented View describes the services relevant to the enterprise to manage the information and support the operational processes as defined by the Operational View. • System View describes the systems and the resources supporting the operational needs, plus their interconnections. • Technical View provides the technical implementation guidelines upon which engineering specifications are based and common building blocks are established. It includes a collection of the technical standards, implementation conventions, standards options, rules and criteria organised into profiles that govern systems and system elements for a given architecture. (Note: This view was not addressed by the EA Demonstration Study). • The Programme View describes all relationships between the Capability requirements and the different Programmes and Projects being implemented (Note: This view was not addressed by the EA Demonstration Study). 6.3 Rationale and Use of Some Selected Sub-views The main views of NAF, and hence the updated framework proposal, each consists of a number of sub-views. These are used to address specific aspects concerned with the subject area of each of the main views. NAF [Ref.3] contains 39 sub-views. However, without a clearly defined meta-model of the EAEA against which to assess which of these sub-views are needed to describe and manage it, plus the limited scope of this study, it was only possible to select a limited number to demonstrate their typical content and how they might be used. The material developed during the study and contained in Refs.12 to 19 is the basis of that shown in the example sub-views. Again, it is stressed here that the content of this whole sub-section is included in this report for illustrative purposes only. 6.3.1 Capability (Strategic) View From Ref.3, the sub-view “NCV-1 – Capability Vision” can be used to capture and describe the principal aspects of the enterprise. NCV-1 has three parts, the: • Enterprise Vision; • Enterprise Goals, together with the desired outcomes and measurable benefits associated with them; • Strategy in terms of capabilities. The TRS required that “operational (business) goals” [see Ref.12] be developed. These, plus a capability example contained in Ref.12 and the SESAR performance framework material contained in Ref.7, have been used to develop the sub-view shown in Fig.6. It shows an example of how a hierarchy of goals could start to be developed which links the SESAR key performance areas and targets of Ref.7 with the type of capabilities needed which relate to specific aspects of the EAEA. By linking the ensuing hierarchy of goals to identify and plan the capabilities needed to meet the performance targets, traceability and consistency can be achieved throughout the development and evolution of the EAEA. The scope of the study did not allow for the detailed identification and/or development of capabilities. However, in order to underpin the content within NCV-1, it is considered that the “NCV-2 – Capability Taxonomy” sub-view will be needed to compliment it since it will OATA-MCS-12-09, Edition: 1.1 Page: 26 of 58
  27. 27. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) contain a structured list of capabilities and sub-capabilities that will be required in a certain timeframe. Each capability is, where necessary, sub-divided into sub-capabilities and/or functions, in order to provide clarity and the appropriate level of granularity commensurate with meeting the needs of the capability management process. All terms used in NCV-2 should only be expressed in non-implementation specific based terms. Fig. 6: NCV-1 – Capability Vision (Example related to Partial Set of Goals) 6.3.2 Operational View In NAF, the operational view is a description of the tasks and activities, operational elements and information exchanges required. The detailed material produced throughout the study on operational processes, operational services, information services and organisation/actors was used to create the following illustrative examples of some of the sub-views related to the operational aspects. “NOV-4 – Organisational Relationship Chart” describes the principal actors and/or operational nodes which make up the structure of the EAEA and the organisational relationships between them. These are important because they can, for example, illustrate fundamental human roles as well as the organisational relationships. Fig.7 shows, using the material contained in Ref.15, a typical example derived for the airport- centric scope of this study which relates to an airport operator. OATA-MCS-12-09, Edition: 1.1 Page: 27 of 58
  28. 28. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Fig. 7: NOV-4 – Organisational Relationship Chart (Example for Airport Operator) “NOV-5 – Operational Activity Model” describes the operations that are normally conducted in the course of achieving an operational objective. It describes operational activities, or tasks, and the input/output (I/O) flows between activities; these generally relating to information exchanges. From the operational process and information services produced throughout the study, Fig.8 shows a typical NOV-5-type sub-view of the hierarchical decomposition of the processes (boxers in yellow) and sub-processes (boxes in white) involved. Similarly, Fig.9 shows the processes (boxes in yellow) with the I/O flows of the information elements (boxes in white) between them. These figures have been created using the material contained in Ref.14 and the SWIMPOOL diagram of Fig.3. OATA-MCS-12-09, Edition: 1.1 Page: 28 of 58
  29. 29. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Fig. 8: NOV-5 - Operational Activity Model Example (Example of hierarchical decomposition of processes and sub-processes) OATA-MCS-12-09, Edition: 1.1 Page: 29 of 58
  30. 30. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Flight Crew Aircraft Approach Taxi Aircraft to Aircraft Departure Instructions Flight ATC ATC ATC Business Clearance Instruction Clearance trajectory Airport Air Traffic Control Business Business trajectory trajectory Departure Clearance Provide Landing Provide Surface Clearance Movement Guidance Performance :Efficiency: Sequencing: Airborne Safety: Manage Surface ATC Sequencing Separation Separation and Clearance Plan Sequencing Approach / Departure Controller Manage Aircraft ATC Airborne Clearance Separation and Sequencing Fig. 9: NOV-5 – Operational Activity Model (Example of Input/Output flows between Processes) In order to assess not only the static, but also the dynamic characteristics of the EAEA, “NOV-6 – Operational Activity Sequence & Timing Description” in NAF could be used. In particular, “NOV-6c – Operational Event-Trace Description” can be used to describe the sequence of processes and provide a time-ordered examination of the information exchanges between participating actors in particular scenarios. Fig.10 gives an example of the decomposition of the Aircraft Approach process into sub- processes (boxes in white), activities (boxes in blue) and the sequence between them (black lines with arrow). In green, the event that triggers the starting of the process and in pink the end event of the process. The Actor responsible for the process is the Flight Crew. OATA-MCS-12-09, Edition: 1.1 Page: 30 of 58
  31. 31. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) Fig 10: NOV-6c – Operational Event-Trace Description (Example of “Aircraft Approach” Process) Throughout the study it was apparent that the need to develop and define an Information Model is crucial to ensuring coherence and consistency is achieving throughout all aspects which will make up the EAEA. The purpose of an information model is to analyse the information aspects of the operational domain and to guide the design of information systems. By contrast, a data model (as described in the System View) is used to design the data presentation, handling and storage functionality of an information system. In NAF, “NOV-7 – Information Model” is the sub-view. Fig.10, created using the material contained in Ref.19, shows the main information elements and their relationships developed in the study. OATA-MCS-12-09, Edition: 1.1 Page: 31 of 58
  32. 32. Initial Activities in Enterprise Architecture application to ATM - Evaluation Report (D9) class Concept Model Iteration 1 +air_traffic_time_continuum Time Airspace Surface Business_Traj ectory Clear ance +maybe_affected +wherein_flight_exist_and_move_on_ground +authorizes +describes_the_flight +wherein_flight_exist_and_move_in_air +taking_place_in_space +authorize_to_move +identification +taking_place_on_ground Fli ght +may_afffect +individual_flight_information +affects Condi tion +affects +affects Traffic_flow +creates_demand +holds_demand Dem and +controls_monitor_business_trajectories +affects +is_limited Capacity +is_affected +is_limited Perfor mance +hold_facilities +measure_the_effective_use +is_limited +holds_facilities +may_affect Facility +may_affect +measure_the_effective_use +holds_facilities Ne w s +by_which_business_objectives_may_be_achived +ATM_enterprise_monitors +may_affect «ATM Business Concept» Activ ity +holds_resources +by_which_business_objectives_may_be_achived +an_entity_to_perform_work Resource +initiate_activities +manage_people Per son Organi sation +control_monitor +human_resources «ATM Business Concept» Gov er nance +control_monitor Fig. 11: NOV-7 – Information Model (Example) 6.3.3 Service-Oriented View Taking a service-oriented approach to the development and structuring of the EAEA was a key recommendation in the deliverables produced throughout the SESAR PD phase. Using the understanding of services in its broadest sense, the notion is that the way in which actors throughout the future EATMS interact at all levels is through the provision and receipt of services. The detailed material produced throughout the study on operational, information and application services was used to create the following illustrative examples of some of the sub-views related to taking a service-based approach and which are considered to be useful to support the development of the meta-model of the EAEA. These sub-views have been developed using the material contained in Refs.13, 14, 17 and 19. OATA-MCS-12-09, Edition: 1.1 Page: 32 of 58

×