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” ?8

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