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.
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.
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.
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?)
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
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.
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.
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
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
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.
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.
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.
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.
NATS Approach to Enterprise Architecture An Introductory Summary EA TRS Dissemination Workshop 8 th June 2009 presented by Dr John R F Guy NATS – Chief Architect European ATM
Presentation Overview <ul><li>NATS History & the Problem / Challenge </li></ul><ul><li>NATS’ reasons for using Enterprise Architecture (EA) </li></ul><ul><li>What is EA and the value of EA </li></ul><ul><li>NATS EA approach </li></ul><ul><li>Roadmap layers </li></ul><ul><li>EA Frameworks </li></ul><ul><li>Lessons learned </li></ul><ul><li>The Future of EA at NATS </li></ul><ul><li>Summary </li></ul>
NATS EA History <ul><li>NATS started using Architectural methods several years ago (circa 2002) and developed an initial Operational & Technical Strategy (“COATS”) </li></ul><ul><li>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 </li></ul><ul><li>In 2006, Formal Enterprise Architecture Framework (based on MODAF) was adopted to create ”The Future Centres Roadmap” </li></ul><ul><li>The EA approach was “institutionalised” in 2007 with the formation of the Technology Strategy Group (TSG) </li></ul><ul><li>The Roadmap was extended from Future Centres to NERL-wide technology in 2007 </li></ul><ul><li>In 2008, the NERL (NATS En-Route Ltd.) Roadmap was implemented </li></ul><ul><li>In 2009, the NERL Development & Investment Directorate was created to provide a strategic focus for NERL, including Enterprise Architecture </li></ul>
The Challenge <ul><li>Develop a coherent strategy to address: </li></ul><ul><li>Increasing traffic demands </li></ul><ul><li>Improving safety & environmental performance </li></ul><ul><li>Minimising operating costs </li></ul><ul><li>Contractual commitments </li></ul><ul><li>Credible evolution strategy </li></ul><ul><li>Positioning NERL’s systems for SESAR </li></ul>
NATS Reasons for EA Approach <ul><li>Have been using Enterprise Architecture to improve our technology management & alignment with operational & business goals ........ because …..… </li></ul><ul><ul><li>NERL approach to systems development was not coherent, especially with respect to systems at Centres </li></ul></ul><ul><ul><li>The value to the business of technical systems was inconsistent </li></ul></ul><ul><ul><li>Communication of technical solutions to the stakeholder community lacked clarity </li></ul></ul><ul><ul><li>Investment decisions were being made tactically, not strategically </li></ul></ul><ul><ul><li>Scenario planning & modelling was very limited </li></ul></ul>
NATS in 2006/7 Hurn R&D and Training College Corporate & Technical Centre UK Airports Control of Airport Traffic Integrated digital communications network Manchester Centre Prestwick Centre Control of Oceanic Traffic Control of Area Traffic Control of Domestic Traffic Co-ordination with adjacent Centres European Flight Management Swanwick Centre West Drayton Centre Control of Area Traffic Control of Terminal Traffic Air Defence Control of Military Traffic MET Information Navigation Communications Surveillance
NATS Future Vision Service Oriented Information Bus Infrastructure Datalink with aircraft Prestwick Swanwick Technical Centre Flexible connectivity of voice communications Multiple information derived for surveillance purposes Connections to UK airports Enterprise-wide control and monitoring capability Real-time interoperability with international ATM service providers Information management and data fusion components in high integrity buildings
Enterprise Architecture : Some Definitions <ul><li>Enterprise : an organised entity or group of entities that share a common set of desired outcomes </li></ul><ul><li>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 </li></ul><ul><li>Value : a measure or set of measures used to assess the success of an entity </li></ul><ul><li>Enterprise Architecture : a formal model-based description that aims at optimising the value that information-centric changes bring to an enterprise </li></ul><ul><li>Enterprise Architecture Framework : A reusable set of models and views that facilitate the creation of an Enterprise Architecture </li></ul>
What is the Value of Enterprise Architecture? <ul><li>Quantitative vs. Qualitative </li></ul><ul><li>Who are the Stakeholders ? </li></ul><ul><li>How to systematically add more value ? </li></ul>
The NATS Enterprise Architecture Approach NERL Business Strategy & Goals Solutions delivered through Programmes & Projects Technical System Architecture & Technology Strategy Operational Strategy
The NERL Roadmap <ul><li>The Need for a Roadmap </li></ul><ul><li>The Roadmap Development Process </li></ul><ul><li>NERL Roadmap Layers </li></ul>
The Need for a Roadmap <ul><li>Operational & Business Drivers </li></ul><ul><ul><li>Captures the drivers & lays out the basis for the strategic evolutionary development of NATS systems </li></ul></ul><ul><ul><li>Aligns the operational needs with the technology solutions (Coherence) </li></ul></ul><ul><li>Communication of the Strategy </li></ul><ul><ul><li>Facilitates communication to all Stakeholders </li></ul></ul><ul><ul><li>Positive tracking of Benefit delivery </li></ul></ul><ul><li>Assurance provided </li></ul><ul><ul><li>Explores ‘What-if’ scenarios and options </li></ul></ul><ul><ul><li>Deliverability of the strategy is assessed </li></ul></ul>
The Roadmap as a Management Tool Project Context Investment Roadmap Investment Planning (NIG) Investment Proposal Investment Intelligence Project Design Envelope Strategic Context Strategic Project Requirements SPRs generated from SFRs Technology Evolution Planning (Strategic Functional Requirements)
The Roadmap Development Process Iterations <ul><li>Cost & Benefit Modelling </li></ul><ul><ul><li>Spreadsheet based model contains </li></ul></ul><ul><ul><li>estimates for </li></ul></ul><ul><ul><ul><li>System developments </li></ul></ul></ul><ul><ul><ul><li>Testing & Deploying </li></ul></ul></ul><ul><ul><ul><li>Training (ATC & Engineering) </li></ul></ul></ul><ul><li>Strategic Requirements </li></ul><ul><ul><li>Technology Evolution Plans </li></ul></ul><ul><ul><li>Strategic Evolution Requirements </li></ul></ul><ul><ul><li>Strategic Project Requirements </li></ul></ul><ul><li>Roadmap Modelling </li></ul><ul><ul><li>Identifies systems impacted by evolution </li></ul></ul><ul><ul><li>Groups changes into “Tranches” & Projects </li></ul></ul><ul><ul><li>Portfolio Deliverability Assessment </li></ul></ul><ul><li>Operational and Technology Strategies </li></ul><ul><ul><li>Functional & Architectural Drivers </li></ul></ul><ul><ul><li>High Level System Evolution </li></ul></ul>
How Much NERL Roadmap Layers Business Objectives Why Operational & Technical Drivers What Benefits & Impacts Who Other Changes Functionality Changes How System Changes Where Acquisition Tranche / Delivery When
Enterprise Architecture Frameworks <ul><li>… . there are a lot to choose from .… </li></ul><ul><li>The Zachman Framework </li></ul><ul><li>DODAF (US Department of Defense Architecture Framework) </li></ul><ul><li>MODAF (UK Ministry of Defence Architecture Framework) </li></ul><ul><li>TOGAF (The Open Group Architecture Framework) </li></ul><ul><li>NAF (NATO Architecture Framework) </li></ul><ul><li>TEAF (US Treasury Enterprise Architecture Framework) </li></ul><ul><li>… . how to select one ? </li></ul>
Why use MODAF for our Roadmap ? <ul><li>This must have been done before ? </li></ul><ul><ul><li>Do not re-invent </li></ul></ul><ul><ul><li>Look to industry best-practice … </li></ul></ul><ul><li>An Architecture Framework ? </li></ul><ul><ul><li>Examples include Zachman, TOGAF, DODAF, MODAF, etc. </li></ul></ul><ul><ul><li>ATM no different to any other large complex “system of systems”, e.g. military </li></ul></ul><ul><ul><li>MODAF contains many of the views we needed </li></ul></ul>MODAF
MODAF <ul><li>What is MODAF ? </li></ul><ul><ul><li>The UK Ministry of Defence’s Architecture Framework </li></ul></ul><ul><ul><li>A standardised meta-model, set of views & ontology </li></ul></ul>
How should we use MODAF ? <ul><li>MODAF CAN be : </li></ul><ul><ul><li>Daunting </li></ul></ul><ul><ul><li>Too many views </li></ul></ul><ul><ul><li>Too much to understand </li></ul></ul><ul><li>We NEED to: </li></ul><ul><ul><li>Focus on the Roadmap goals </li></ul></ul><ul><ul><li>Only choose views of most value </li></ul></ul>
Roadmap Views - a summary of views and why chosen <ul><li>MODAF uses “views” to express Architectural aspects </li></ul><ul><li>MODAF v1.2 has 46 views </li></ul><ul><li>NATS uses 5 </li></ul><ul><ul><li>These define our Architectural Evolution in enough detail to make key decisions & launch projects </li></ul></ul>
StV-3 : Capability Phasing Swanwick AC Swanwick TC Prestwick iFACTS iFACTS 2 Mode S/ ESTCA /SFL Mode S / ARTAS nSIS ARTAS 5 Initial TC Tools Tools Phase 1 1 Mil East into AC NERC System & LMARS 3A NAS / Node TC & Prestwick Systems Electronic Flight Data 3 Deploy NSNETS Deploy NSNETS Deploy NSNETS ARTAS and iNCW Initial Common Workstation Phase 3 Phase 3 Phase 3 Advanced Common Workstation 9 Phase 3 build 2 Phase 3 build 2 Phase 3 Build 2 Advanced Tools 10 Phase 3 build 3 Phase 3 build 3 Phase 3 Build 3 Advanced Operations 11 Phase 2 Implementing new infrastructure upon which to deploy enhanced capability Phase 1 Adding capability to existing infrastructure Phase 3 Longer-term development of common advanced operations AMAN Tools Electronic Flight Data 4 TC & Prestwick Systems AMAN Tools Electronic Flight Data 4 TC & Prestwick Systems Swap to iTEC FDP Swap to iTEC FDP Swap to iTEC FDP Swap to iTEC FDP Swap to iTEC FDP Swap to iTEC FDP iTEC Integration 6 Deploy NSNETS Deploy NSNETS Deploy NSNETS Safety Nets 7 ARTAS and iNCW Initial Common Workstation Deploy Tools 8 ARTAS and iNCW Mil East into AC NERC System & LMARS 3A NAS / Node TC & Prestwick Systems Electronic Flight Data 3
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 Architectural Evolution 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
Lessons Learnt (1/2) <ul><li>Learn through actions </li></ul><ul><ul><li>Start “small” </li></ul></ul><ul><ul><li>Identify Key Issues </li></ul></ul><ul><li>There is no ideal organisational solution </li></ul><ul><ul><li>Collaboration is essential ! </li></ul></ul><ul><li>Different Stakeholders have different roles at different points of the lifecycle </li></ul><ul><li>Clear responsibilities and accountabilities needed </li></ul><ul><li>Strong Leadership needed </li></ul><ul><ul><li>Gain Executive Sponsorship ! </li></ul></ul><ul><li>Mine the conflict between stakeholders </li></ul><ul><ul><li>Don’t avoid it ! </li></ul></ul><ul><li>Communication is difficult and has to be worked hard </li></ul><ul><ul><li>Without good stakeholder communication, you will fail ! </li></ul></ul>
<ul><li>Use of an Architecture Framework (AF) is essential </li></ul><ul><ul><li>It gives a structure to architecture analysis </li></ul></ul><ul><ul><li>It provides a standard form for communication </li></ul></ul><ul><li>The Real Value of an Architecture Framework is in its Meta-model, not the Views </li></ul><ul><ul><li>The meta-model allows capture of entities & their relationships </li></ul></ul><ul><ul><li>The meta-model ensures consistency between views </li></ul></ul><ul><li>Choose an AF that has good tools support </li></ul><ul><ul><li>Zachman may be an interesting thought-map, but you can’t really use it to develop architecture </li></ul></ul><ul><li>Architecture is only a means </li></ul><ul><ul><li>Focus on the value the architecture modelling provides </li></ul></ul><ul><li>Adapt/Tailor a standard framework to meet your needs </li></ul><ul><ul><li>There is no “one size fits all” </li></ul></ul>Lessons Learnt (2/2)
Future of Enterprise Architecture at NATS <ul><li>We are still on a journey… </li></ul><ul><li>Roadmap alignment with other ANSPs and SESAR is important </li></ul><ul><li>Increasing emphasis on Strategic Business issues </li></ul><ul><li>Service Orientation </li></ul><ul><li>Architecture Governance & Maturity </li></ul><ul><ul><li>Develop EA Maturity Approach </li></ul></ul><ul><ul><li>Improve EA governance </li></ul></ul><ul><ul><li>Raise profile of EA at Executive and Board levels </li></ul></ul><ul><ul><li>Embed EA across the organisation </li></ul></ul>
Summary <ul><li>Baseline NERL Roadmap in place </li></ul><ul><li>Roadmap now being used to support business decision-making </li></ul><ul><li>Significant further opportunities to use EA to manage change in NERL and SESAR </li></ul><ul><li>Recognised Industry EA Leader </li></ul><ul><li>Watch this space ... </li></ul>
NATS Approach to Enterprise Architecture An Introductory Summary EA TRS Dissemination Workshop 8 th June 2009 presented by Dr John R F Guy NATS – Chief Architect European ATM THANK YOU FOR YOUR ATTENTION
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.