Presentation is loading. Please wait.

Presentation is loading. Please wait.

NATS Approach to Enterprise Architecture An Introductory Summary

Similar presentations

Presentation on theme: "NATS Approach to Enterprise Architecture An Introductory Summary"— Presentation transcript:

1 NATS Approach to Enterprise Architecture An Introductory Summary
presented by Dr John R F Guy NATS – Chief Architect European ATM EA TRS Dissemination Workshop 8th June 2009

2 Presentation Overview
NATS History & the Problem / Challenge NATS’ reasons for using Enterprise Architecture (EA) What is EA and the value of EA NATS EA approach Roadmap layers EA Frameworks Lessons learned The Future of EA at NATS Summary

3 NATS EA History NATS started using Architectural methods several years ago (circa 2002) and developed an initial Operational & Technical Strategy (“COATS”) In 2006, an urgent need arose to revise how the specification, development & procurement of FDP/Centres’ systems was being done – led to a more-holistic, ATM System-wide approach to be taken In 2006, Formal Enterprise Architecture Framework (based on MODAF) was adopted to create ”The Future Centres Roadmap” The EA approach was “institutionalised” in 2007 with the formation of the Technology Strategy Group (TSG) The Roadmap was extended from Future Centres to NERL-wide technology in 2007 In 2008, the NERL (NATS En-Route Ltd.) Roadmap was implemented In 2009, the NERL Development & Investment Directorate was created to provide a strategic focus for NERL, including Enterprise Architecture

4 The Challenge Develop a coherent strategy to address:
Increasing traffic demands Improving safety & environmental performance Minimising operating costs Contractual commitments Credible evolution strategy Positioning NERL’s systems for SESAR

5 NATS Reasons for EA Approach
Have been using Enterprise Architecture to improve our technology management & alignment with operational & business goals because …..… NERL approach to systems development was not coherent, especially with respect to systems at Centres The value to the business of technical systems was inconsistent Communication of technical solutions to the stakeholder community lacked clarity Investment decisions were being made tactically, not strategically Scenario planning & modelling was very limited

6 Integrated digital communications network
MET Information Navigation Communications Surveillance NATS in 2006/7 Manchester Centre Prestwick Centre Control of Oceanic Traffic Control of Area Traffic Control of Domestic Traffic Air Defence Control of Military Traffic Integrated digital communications network Swanwick Centre West Drayton Centre Control of Area Traffic Control of Terminal Traffic Co-ordination with adjacent Centres European Flight Management Hurn R&D and Training College Corporate & Technical Centre UK Airports Control of Airport Traffic A core integrated communications infrastructure is key – our ‘ring main’ - Effective and wide area communications is central to our business. We have key infrastructure in place for Communications, Navigation and Surveillance technology. The UK Airports are the source or destination of much of the traffic we handle and London still has one of the busiest Airport operations in the world today. Air Traffic is managed in several Centres across the UK. London Area, London Terminal, Scottish Area, Scottish and Manchester Terminal and North Atlantic (Oceanic). We need effective co-ordination with adjacent control centres, airport operators, and other agencies across Europe. Military operations and co-operation with UK Air Defence is essential to maintain our Civil-Military partnership. And not forgetting the contribution from our Training, Research and Development, Simulation, System Design and Development Centres. We have a highly evolved architecture with a mixture of old and new technology, our systems traditionally have a Long In-Service Life. Systems Dependability, Integrity, Flexibility, Extensibility, Availability and a high level of Safety Assurance are a pre-requisite. We are increasingly dependant on our technology to keep up with the pace of change and there are a number of significant challenges ahead of us. 6

7 NATS Future Vision Prestwick Swanwick Technical Centre
Multiple information derived for surveillance purposes Flexible connectivity of voice communications Connections to UK airports Datalink with aircraft Real-time interoperability with international ATM service providers Service Oriented Information Bus Infrastructure Information management and data fusion components in high integrity buildings Enterprise-wide control and monitoring capability Prestwick Swanwick Technical Centre

8 What is “Enterprise Architecture” ?

9 Enterprise Architecture : Some Definitions
Enterprise : an organised entity or group of entities that share a common set of desired outcomes Architecture : a description of the structure, organisation and relationships among the set of components of a system and the principles for their development and evolution Value : a measure or set of measures used to assess the success of an entity Enterprise Architecture : a formal model-based description that aims at optimising the value that information-centric changes bring to an enterprise Enterprise Architecture Framework : A reusable set of models and views that facilitate the creation of an Enterprise Architecture

10 What is the Value of Enterprise Architecture?
Quantitative vs. Qualitative Who are the Stakeholders ? How to systematically add more value ? If we don’t understand what the value of EA is and how to articulate this to others, how can we justify what we’re doing? Speaking from our experience at NATS, the most important benefits have been qualitative, not quantitative: we’re now able to talk about our systems, as a whole, instead of as individual silos; we can talk meaningfully about “services” instead of “systems”. However, to be sustainable, the value of EA has to be measurable – at the bottom line of the enterprise, if possible. This requires the use of tools. Secondly, in order to be able to talk about value, you have to understand who are the beneficiaries – the stakeholders. Interestingly enough, we’ve found this changes : in the first place the stakeholders were primarily technical, but increasingly, we’re finding an increased focus on non-technical stakeholders (operational, financial, external). We expect this trend to continue. Thirdly, how do we measure the value of EA. It’s essential to be able to measure value in order to improve the effectiveness of EA. This brings me to EA Maturity Models, of which there are many. Whilst we’re still assessing this area, I would say that it’s less important which model you adopt, than it is to adopt one – it gives you a benchmark against which to measure your progress. In summary, though: you can know the value of EA when you see it, in just the same way that the value of the architecture in The Pantheon in Rome is self-evident. 10

11 The NATS Enterprise Architecture Approach
NERL Business Strategy & Goals Operational Strategy Technical System Architecture & Technology Strategy Solutions delivered through Programmes & Projects Start with the basic set of business goals (safety, service, financial, organisational) and a set of high-level strategies to reach them. A set of brand values used to explain them. Then develop Ops. & Tech. strategies aligned to business goals. These specify operational capabilities, technical services & system functions that support them. Work with programmes and projects to develop a portfolio of programmes and projects that will deliver them. Programmes work with the Ops. customer to deliver the capabilities into use. Throughout the process, Enterprise Architecture & “Service Architects” provide assurance that projects remain aligned with the strategies. 11

12 The NERL Roadmap The Need for a Roadmap
The Roadmap Development Process NERL Roadmap Layers

13 The Need for a Roadmap Operational & Business Drivers
Captures the drivers & lays out the basis for the strategic evolutionary development of NATS systems Aligns the operational needs with the technology solutions (Coherence) Communication of the Strategy Facilitates communication to all Stakeholders Positive tracking of Benefit delivery Assurance provided Explores ‘What-if’ scenarios and options Deliverability of the strategy is assessed 13

14 The Relationship between the Roadmap and the Long Term Investment Plan
Operational Strategy Technical System Architecture & Technology Information Architecture NATS Investment Roadmap Long Term Investment Plan Discretionary Strategic Projects Core Sustainment Sustain Deployed ATM System Assets Asset Base Buildings and Facilities Add & Change Guides Shapes Guide Shape Asset Health Reviews Asset Management © NATS Ltd June 2009

15 The Roadmap as a Management Tool
Project Context Investment Roadmap Investment Planning (NIG) Investment Proposal Intelligence Project Design Envelope Strategic Context Strategic Project Requirements SPRs generated from SFRs Technology Evolution Planning (Strategic Functional Requirements) This illustrates how we use the roadmap to identify, scope and define our projects Left hand thread - This defines how much funding needs to be put in place to achieve the required strategic benefit from a project Horizontal – strategic evolutions – are identified and described in the TEPs (Technology Evolution Plans) and these are used to define the SPRs (Strategic Project Requirements) based on the SFRs (Strategic Functional Requirements) Diagonal – provides extra contextual information to help define the context that the project will be delivering into eg what part does it play in the overall jigsaw - is it an enabler?, is it dependent on other projects?)

16 The Roadmap Development Process
Iterations Cost & Benefit Modelling Spreadsheet based model contains estimates for System developments Testing & Deploying Training (ATC & Engineering) Strategic Requirements Technology Evolution Plans Strategic Evolution Requirements Strategic Project Requirements Roadmap Modelling Identifies systems impacted by evolution Groups changes into “Tranches” & Projects Portfolio Deliverability Assessment Operational and Technology Strategies Functional & Architectural Drivers High Level System Evolution Top box – the top level strategies – these are broken down to provide functional and architectural drivers and the drivers are expressed with a timescale ie when they are required in the evolution process Next box - Road map model Stage 1 – functional drivers identified for each technical service area (eg FDP, HMI, SDP, Voice etc) identify which specific system at each affected ATSU is impacted Stage 2 – for each of these systems – identify the specific change (s) required to make it happen and identify cost impacts (s/w, resource , 1 off costs etc) Stage 3 – group the changes into Tranches (start of Portfolio Management) – groupings that comprise of related changes or are needed for specifice benefits etc Bottom left – output provided for cost model including which will take into account costs for testing, deployment and training Bottom right – this provides the strategic requirements via the TEPs Iteration – normal cycle means that this is undertaken 4 times per year

17 NERL Roadmap Layers Why Business Objectives
Operational & Technical Drivers What Benefits & Impacts Who Other Changes Functionality Changes How System Changes Where Acquisition Tranche / Delivery When How Much 17 17 17 17 17

18 Enterprise Architecture Frameworks
…. there are a lot to choose from .… The Zachman Framework DODAF (US Department of Defense Architecture Framework) MODAF (UK Ministry of Defence Architecture Framework) TOGAF (The Open Group Architecture Framework) NAF (NATO Architecture Framework) TEAF (US Treasury Enterprise Architecture Framework) …. how to select one ?

19 Why use MODAF for our Roadmap ?
This must have been done before ? Do not re-invent Look to industry best-practice … An Architecture Framework ? Examples include Zachman, TOGAF, DODAF, MODAF, etc. ATM no different to any other large complex “system of systems”, e.g. military MODAF contains many of the views we needed MODAF Zachman, TOGAF, DODAF, RUP, etc.. How do we decide which approach will work? What characterizes our needs? We need something that will capture business and operational requirements and technology well – and that has a “mission” focus. In fact, our domain is quite like a classic battlefield command and control mission. We don’t really want something that will dictate our process. It would be useful if we could develop an approach that offers long term benefits. Zachman: it can help, but it’s very generic, good for business requirements, but not specific enough for technology planning. TOGAF: Thorough, but very complex; has a strong IT as opposed to mission focus. DODAF: Hmm...good for technology and detailed operations; has a mission focus.. Doesn’t cover business aspects, though. But, on the other hand ….. MODAF: Has all the good detailed capabilities, but also embraces strategic (business) aspects. 19

20 MODAF What is MODAF ? The UK Ministry of Defence’s Architecture Framework A standardised meta-model, set of views & ontology

21 How should we use MODAF ? MODAF CAN be : We NEED to: Daunting
Too many views Too much to understand We NEED to: Focus on the Roadmap goals Only choose views of most value MODAF can be daunting, seem to have too many views and can be too much to understand (especially with its arcane terminology). In order to use it successfully, we need to first take a step back and remember what we want the Roadmap to do: - CAPTURE the business objectives - MAP the business objectives to systems - SHOW the evolution of the systems - COMMUNICATE the strategy to our stakeholders. So, by focusing on the Roadmap goals and being selective in the MODAF views we use, we can find an effective path forward.

22 Roadmap Views - a summary of views and why chosen
MODAF uses “views” to express Architectural aspects MODAF v1.2 has 46 views NATS uses 5 These define our Architectural Evolution in enough detail to make key decisions & launch projects The main point to be made here is THE SUBSET OF VIEWS IS WHAT IS DEEMED NECESSARY TO SOLVE THE PROBLEM – NOT A PRESCRIPTIVE SET Toolkit analogy Use the tool to do the job Not the whole toolbox

23 NATS Application of MODAF (to date)
MODAF Views OV-1/OV-5 SV-5/SV-3 StV-3 Non-MODAF views Product list/cost estimates Development/Deployment matrices High-level Architecture MODAF So what this led us to was a basic set of 5 MODAF views, of which the OV-5 and the SV-5 were most important. We also developed a set of non-MODAF views to support other goals of the Roadmap that didn’t map well onto MODAF. I’m going to illustrate our use of some of the MODAF views in the following slides. We’re not going to discuss the non-MODAF views 23

24 OV-5 : Operational Activity Model
Let’s take a look at the OV-5 Operational Activity Model. This view is key to understanding the operational needs of the business. As it happened, we did a couple of different things with the OV-5. Firstly, we didn’t use it to represent ALL the Operational Activities of the business, we only captured the new or modified activities that need to be addressed by future technology. Secondly, we organized the Operational Activities around the Operational Nodes of the business (our Centres). Thirdly, we prioritised the activities in terms of near-, mid- and long-term importance. Lastly, we associated various benefits with each of the activities in the areas of Human Performance (i.e., Safety), Value (that is Cost Reductions), Capacity (how many flights we can handle), Obligation (what we are required by regulation to provide – e.g., Single European Sky mandates) and Environment. These benefits could then be traced forward directly using the next MODAF view, the SV-5. 24

25 SV-5 : Ops Activity to System Function Matrix
SV-5 is a very important MODAF view. It allows us to translate between the Operational and Technical Systems worlds, to connect our systems evolution to the operational benefits and requirements. We chose to simply use an Excel Spreadsheet to capture the SV-5 information. We added a couple of “additional features” to the SV-5 template: We ordered the Operational Activities (the rows) by their priority, so we could start to see an evolutionary sequence. We also grouped the activities by our Operational Nodes. Instead of merely putting “Xs” in the matrix, we put the actual systems that we plan will support the operational activity. We used comments and colouring to capture issues and other detailed information in the matrix. 25

26 StV-3 : Capability Phasing
Phase 1 Adding capability to existing infrastructure Phase 2 Implementing new infrastructure upon which to deploy enhanced capability Phase 3 Longer-term development of common advanced operations iFACTS 2 Mil East into AC NERC System & LMARS 3A NAS / Node TC & Prestwick Systems Electronic Flight Data 3 Mil East into AC NERC System & LMARS 3A NAS / Node TC & Prestwick Systems Electronic Flight Data 3 Mode S/ ESTCA /SFL Mode S / ARTAS nSIS 5 Swap to iTEC FDP Swap to iTEC FDP Integration 6 Swanwick AC TC Prestwick Deploy NSNETS Safety Nets 7 Deploy NSNETS ARTAS and iNCW Initial Common Workstation Deploy Tools 8 ARTAS and iNCW Initial Common Workstation Phase 3 Advanced Common Workstation 9 Phase 3 build 2 Build 2 Advanced Tools 10 Phase 3 build 3 Build 3 Advanced Operations 11 Initial TC Tools Phase 1 1 AMAN Tools Electronic Flight Data 4 TC & Prestwick Systems AMAN Tools Electronic Flight Data 4 TC & Prestwick Systems Strategic view as to how capture changes into sensible packages of change that can then be deployed into operational environment. The operational environment gives us restriction for the following reasons: We have a 24/7 operation We can’t drip feed changes since we need time to train and validate controllers Enough time to train all controllers and ensure that there are enough validated controllers to operate the system when it goes live Training on system that is close enough to the one going live to ensure training valid and realistic. Again we have the three phases and the three major operations. The first phase shows changes to individual systems to support one centre. As we move through the architectural evolution we can see that we are developing a change once and deploying it into several centres. Tranches – a view of how we can deploy capabilities into operational service. A portfolio of candidate project can then be developed to support each tranche and passed into the normal PM process.

27 How it all fits together
Functional Driver Document (OV-1) OV-5 Operational Activity Model High Level Architectural Evolution Diagram Deployment Model (StV-3) SV-5 Ops Activity to System Function Matrix + SV-3 Diagrams Cost Model SV-5 Product to Ops Function Matrix Strategic Requirements Related to Operational and Business Drivers Quantify changes in terms of SLOC (S/W) and Capital (H/W) Identifies the system changes required to achieve the functional drivers Identifies the systems impacted by each of the Functional Drivers Describes the required deployment of functions for each Centre Operation Groups the functional change into deliverable groups impacting common areas Description of the Evolution of the Operations towards a target architecture Describes System Evolutions related to Functional Drivers So how does it all fit together? How has MODAF helped us address the Roadmap questions we set out to answer? Why? – This information was already captured. The process helped us to achieve an improved understanding of our Business Objectives. What? – OV-5 Helped us to understand the operational needs. Who? – OV-1 helped us understand who are the stakeholders. How? – The OV-5 has identified which operational activities are required. Where? - The SV-5 and SV-3 have helped us address which systems are impacted. When? – The StV-3 has helped us address deployment. How Much? – The Cost Model has addressed this. 27

28 Lessons Learnt (1/2) Learn through actions
Start “small” Identify Key Issues There is no ideal organisational solution Collaboration is essential ! Different Stakeholders have different roles at different points of the lifecycle Clear responsibilities and accountabilities needed Strong Leadership needed Gain Executive Sponsorship ! Mine the conflict between stakeholders Don’t avoid it ! Communication is difficult and has to be worked hard Without good stakeholder communication, you will fail !

29 Lessons Learnt (2/2) Use of an Architecture Framework (AF) is essential It gives a structure to architecture analysis It provides a standard form for communication The Real Value of an Architecture Framework is in its Meta-model, not the Views The meta-model allows capture of entities & their relationships The meta-model ensures consistency between views Choose an AF that has good tools support Zachman may be an interesting thought-map, but you can’t really use it to develop architecture Architecture is only a means Focus on the value the architecture modelling provides Adapt/Tailor a standard framework to meet your needs There is no “one size fits all”

30 Future of Enterprise Architecture at NATS
We are still on a journey… Roadmap alignment with other ANSPs and SESAR is important Increasing emphasis on Strategic Business issues Service Orientation Architecture Governance & Maturity Develop EA Maturity Approach Improve EA governance Raise profile of EA at Executive and Board levels Embed EA across the organisation

31 Summary Baseline NERL Roadmap in place
Roadmap now being used to support business decision-making Significant further opportunities to use EA to manage change in NERL and SESAR Recognised Industry EA Leader Watch this space ...

32 NATS Approach to Enterprise Architecture An Introductory Summary
presented by Dr John R F Guy NATS – Chief Architect European ATM THANK YOU FOR YOUR ATTENTION EA TRS Dissemination Workshop 8th June 2009 32

Download ppt "NATS Approach to Enterprise Architecture An Introductory Summary"

Similar presentations

Ads by Google