Presentation on theme: "NATS Approach to Enterprise Architecture An Introductory Summary"— Presentation transcript:
1NATS Approach to Enterprise Architecture An Introductory Summary presented by Dr John R F Guy NATS – Chief Architect European ATMEA TRS Dissemination Workshop8th June 2009
2Presentation Overview NATS History & the Problem / ChallengeNATS’ reasons for using Enterprise Architecture (EA)What is EA and the value of EANATS EA approachRoadmap layersEA FrameworksLessons learnedThe Future of EA at NATSSummary
3NATS EA HistoryNATS 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 takenIn 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 2007In 2008, the NERL (NATS En-Route Ltd.) Roadmap was implementedIn 2009, the NERL Development & Investment Directorate was created to provide a strategic focus for NERL, including Enterprise Architecture
4The Challenge Develop a coherent strategy to address: Increasing traffic demandsImproving safety & environmental performanceMinimising operating costsContractual commitmentsCredible evolution strategyPositioning NERL’s systems for SESAR
5NATS 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 CentresThe value to the business of technical systems was inconsistentCommunication of technical solutions to the stakeholder community lacked clarityInvestment decisions were being made tactically, not strategicallyScenario planning & modelling was very limited
6Integrated digital communications network MET InformationNavigationCommunicationsSurveillanceNATS in 2006/7Manchester CentrePrestwick CentreControl of Oceanic TrafficControl of Area TrafficControl of Domestic TrafficAir DefenceControl of Military TrafficIntegrated digital communications networkSwanwick CentreWest Drayton CentreControl of Area TrafficControl of Terminal TrafficCo-ordination with adjacent CentresEuropean Flight ManagementHurn R&D and Training CollegeCorporate & Technical CentreUK AirportsControl of Airport TrafficA 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
7NATS Future Vision Prestwick Swanwick Technical Centre Multiple information derived for surveillance purposesFlexible connectivity of voice communicationsConnections to UK airportsDatalink with aircraftReal-time interoperability with international ATM service providersService Oriented Information Bus InfrastructureInformation management and data fusion components in high integrity buildingsEnterprise-wide control and monitoring capabilityPrestwickSwanwickTechnical Centre
9Enterprise Architecture : Some Definitions Enterprise : an organised entity or group of entities that share a common set of desired outcomesArchitecture : a description of the structure, organisation and relationships among the set of components of a system and the principles for their development and evolutionValue : a measure or set of measures used to assess the success of an entityEnterprise Architecture : a formal model-based description that aims at optimising the value that information-centric changes bring to an enterpriseEnterprise Architecture Framework : A reusable set of models and views that facilitate the creation of an Enterprise Architecture
10What is the Value of Enterprise Architecture? Quantitative vs. QualitativeWho 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
11The NATS Enterprise Architecture Approach NERL Business Strategy & GoalsOperational StrategyTechnical System Architecture & Technology StrategySolutions delivered through Programmes & ProjectsStart 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
12The NERL Roadmap The Need for a Roadmap The Roadmap Development ProcessNERL Roadmap Layers
13The Need for a Roadmap Operational & Business Drivers Captures the drivers & lays out the basis for the strategic evolutionary development of NATS systemsAligns the operational needs with the technology solutions (Coherence)Communication of the StrategyFacilitates communication to all StakeholdersPositive tracking of Benefit deliveryAssurance providedExplores ‘What-if’ scenarios and optionsDeliverability of the strategy is assessed13
15The Roadmap as a Management Tool Project ContextInvestmentRoadmapInvestment Planning(NIG)Investment ProposalIntelligenceProject Design EnvelopeStrategicContextStrategic Project RequirementsSPRs generated from SFRsTechnology Evolution Planning(Strategic Functional Requirements)This illustrates how we use the roadmap to identify, scope and define our projectsLeft hand thread - This defines how much funding needs to be put in place to achieve the required strategic benefit from a projectHorizontal – 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?)
16The Roadmap Development Process IterationsCost & Benefit ModellingSpreadsheet based model containsestimates forSystem developmentsTesting & DeployingTraining (ATC & Engineering)Strategic RequirementsTechnology Evolution PlansStrategic Evolution RequirementsStrategic Project RequirementsRoadmap ModellingIdentifies systems impacted by evolutionGroups changes into “Tranches” & ProjectsPortfolio Deliverability AssessmentOperational and Technology StrategiesFunctional & Architectural DriversHigh Level System EvolutionTop 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 processNext box - Road map modelStage 1 – functional drivers identified for each technical service area (eg FDP, HMI, SDP, Voice etc) identify which specific system at each affected ATSU is impactedStage 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 etcBottom left – output provided for cost model including which will take into account costs for testing, deployment and trainingBottom right – this provides the strategic requirements via the TEPsIteration – normal cycle means that this is undertaken 4 times per year
18Enterprise Architecture Frameworks …. there are a lot to choose from .…The Zachman FrameworkDODAF (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 ?
19Why use MODAF for our Roadmap ? This must have been done before ?Do not re-inventLook 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. militaryMODAF contains many of the views we neededMODAFZachman, 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
20MODAFWhat is MODAF ?The UK Ministry of Defence’s Architecture FrameworkA standardised meta-model, set of views & ontology
21How should we use MODAF ? MODAF CAN be : We NEED to: Daunting Too many viewsToo much to understandWe NEED to:Focus on the Roadmap goalsOnly choose views of most valueMODAF 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.
22Roadmap Views - a summary of views and why chosen MODAF uses “views” to express Architectural aspectsMODAF v1.2 has 46 viewsNATS uses 5These define our Architectural Evolution in enough detail to make key decisions & launch projectsThe main point to be made here isTHE SUBSET OF VIEWS IS WHAT IS DEEMED NECESSARY TO SOLVE THE PROBLEM – NOT A PRESCRIPTIVE SETToolkit analogyUse the tool to do the jobNot the whole toolbox
23NATS Application of MODAF (to date) MODAF ViewsOV-1/OV-5SV-5/SV-3StV-3Non-MODAF viewsProduct list/cost estimatesDevelopment/Deployment matricesHigh-level ArchitectureMODAFSo 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 views23
24OV-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 ofHuman 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
25SV-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
26StV-3 : Capability Phasing Phase 1Adding capability to existing infrastructurePhase 2Implementing new infrastructure uponwhich to deploy enhanced capabilityPhase 3Longer-term development ofcommon advanced operationsiFACTS2Mil Eastinto ACNERCSystem &LMARS3ANAS /NodeTC &PrestwickSystemsElectronicFlightData3Mil Eastinto ACNERCSystem &LMARS3ANAS /NodeTC &PrestwickSystemsElectronicFlightData3Mode S/ESTCA/SFLMode S /ARTASnSIS5Swap toiTECFDPSwap toiTECFDPIntegration6SwanwickACTCPrestwickDeployNSNETSSafetyNets7DeployNSNETSARTASandiNCWInitialCommonWorkstationDeployTools8ARTASandiNCWInitialCommonWorkstationPhase 3AdvancedCommonWorkstation9Phase 3build 2Build 2AdvancedTools10Phase 3build 3Build 3AdvancedOperations11Initial TCToolsPhase 11AMANToolsElectronicFlightData4TC &PrestwickSystemsAMANToolsElectronicFlightData4TC &PrestwickSystemsStrategic 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 operationWe can’t drip feed changes since we need time to train and validate controllersEnough time to train all controllers and ensure that there are enough validated controllers to operate the system when it goes liveTraining 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.
27How it all fits together Functional DriverDocument(OV-1)OV-5 Operational Activity ModelHigh LevelArchitecturalEvolutionDiagramDeployment Model(StV-3)SV-5 Ops Activityto SystemFunction Matrix+ SV-3DiagramsCost ModelSV-5 Product toOps FunctionMatrixStrategic RequirementsRelated to Operational and Business DriversQuantify changes in terms of SLOC (S/W) and Capital (H/W)Identifies the system changes required to achieve the functional driversIdentifies the systems impacted by each of the Functional DriversDescribes the required deployment of functions for each Centre OperationGroups the functional change into deliverable groups impacting common areasDescription of the Evolution of the Operations towards a target architectureDescribes System Evolutions related to Functional DriversSo 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
28Lessons Learnt (1/2) Learn through actions Start “small”Identify Key IssuesThere is no ideal organisational solutionCollaboration is essential !Different Stakeholders have different roles at different points of the lifecycleClear responsibilities and accountabilities neededStrong Leadership neededGain Executive Sponsorship !Mine the conflict between stakeholdersDon’t avoid it !Communication is difficult and has to be worked hardWithout good stakeholder communication, you will fail !
29Lessons Learnt (2/2)Use of an Architecture Framework (AF) is essentialIt gives a structure to architecture analysisIt provides a standard form for communicationThe Real Value of an Architecture Framework is in its Meta-model, not the ViewsThe meta-model allows capture of entities & their relationshipsThe meta-model ensures consistency between viewsChoose an AF that has good tools supportZachman may be an interesting thought-map, but you can’t really use it to develop architectureArchitecture is only a meansFocus on the value the architecture modelling providesAdapt/Tailor a standard framework to meet your needsThere is no “one size fits all”
30Future of Enterprise Architecture at NATS We are still on a journey…Roadmap alignment with other ANSPs and SESAR is importantIncreasing emphasis on Strategic Business issuesService OrientationArchitecture Governance & MaturityDevelop EA Maturity ApproachImprove EA governanceRaise profile of EA at Executive and Board levelsEmbed EA across the organisation
31Summary Baseline NERL Roadmap in place Roadmap now being used to support business decision-makingSignificant further opportunities to use EA to manage change in NERL and SESARRecognised Industry EA LeaderWatch this space ...
32NATS Approach to Enterprise Architecture An Introductory Summary presented by Dr John R F Guy NATS – Chief Architect European ATMTHANK YOU FOR YOUR ATTENTIONEA TRS Dissemination Workshop8th June 200932