LtCol Mikael Hagenbo, Sweden IDEAS Update to NATO on Program of Work and Recommendations to NATO concerning NAF PWG 10th meeting 17th March 2010 LtCol Mikael Hagenbo, Sweden Chairman IDEAS http://www.ideasgroup.org/

high-level patterns (upper ontology) common objects (agreed taxonomy) IDEAS Model This slide UK Crown Copyright 2006 Layered approach Starting from first principles to ensure common understanding at the most fundamental level Reaching down to country-specific definitions whose meaning may need to be understood by other nations foundation high-level patterns (upper ontology) common objects (agreed taxonomy) national extension fundamental concepts: classes, instances, properties commonly used relationships: whole-part, sequence, participation, etc. internationally accepted terms: person, organization, material, etc. terminology specific to nations that which may be useful to other nations - e.g. Bowman, Bradley FV, etc. International Defence Enterprise Architecture Specification (IDEAS) has on the 24th of April 2009 finalized and delivered the first product in accordance with the Terms of Reference (ToR) signed by the MOD:s/DoD:S in Australia, Canada, United Kingdom, United States and Sweden. The delivery product is named IDEAS Foundation V 1.0 and acts as and foundation for dealing with semantic heterogeneity between the nations national Architecture Frameworks by the use of an approach based on Business objects Reference Ontology (BORO)™ Methodology.

Update from IDEAS An updated version o M3 will be published by MOD at the end of March. Consequently, some minor adjustments to NMM needs to be done (a version 3.1.1). As agreed by UK MOD, Sweden will take on the task to integrate IDEAS foundation version 1.0 in to M3 in close cooperation with the DM2 team. This is a major update. Estimated finalization in September 2010.

Update from IDEAS UK will coordinate the modeling achievements done by US and SE when it comes to Close Air Support (CAS) in order to demonstrate the value of Defence Enterprise Architecture sharing. Estimated time of conclusion late Sept 10. IDEAS will meet the week before the planned PWG meeting in September. Some inputs to PWG can be expected.

Update from IDEAS The development of the Core Unified Defence Enterprise Architecture Model (CUDEAM) will start early 2011. The estimate is that this will be a one year effort. Until then, a lot of effort will be put into UPDM 2, supporting the UPDM Group. Information about the progress will be presented at Integrated EA 2011 in London (February/March timeframe) and at DoD EA Conference in Virginia Beach in spring 2011.

Update from IDEAS Canada will adopt CUDEAM and by doing so, CA will transform from a IDEF 0 notation language to an object oriented notation language. I.e. the same that US DoD did when they replaced CADM with DM2. IDEAS will address also architecture development methodology, training and certification of defence enterprise architects when deemed mature enough. DoD CIO will have a leading role here.

Update from IDEAS The development of the Core Unified Defence Architecture Framework (CUDEAF) will start in autumn 2011. One year of development effort is expected.

UPDATE from IDEAS NATO will be invited to make use of the International Defence Enterprise Architecture Specification (IDEAS) for the NATO Architecture Framework (NAF). Use DoDAF 2.0, MODAF 1.2, DNDAF 1.7, AUSDAF, ISO/IEC 42010:2011 and IDEAS foundation v 1.0 as a starting point. UPDM version 2 will be consistent with IDEAS Foundation.

Operational benefits Enterprise Architecture for defence will provide an ability to handle complexity through abstractions of the real world enabling a stakeholder to select only the information of interest to him/her and suppress the rest that only introduce unnecessary complexity.

Operational benefits Today decisions in defence are made upon poor quality data (e.g. powerpoint™ slides). Everything should be simplified, but you tend to lose the consistency, coherence and traceability if managing defence with powerpoints. Unknown or unsecure

Operational benefits Tomorrow’s decisions in defence are made upon high quality data that can be shared within the organisation or with others Everything can be simplified when presenting, but you can trust the consistency, coherence and traceability since you have high quality data as a sources. User hidden

Operational benefits A decision maker or desk officer will be assured that he/she can do his/hers daily work by using high quality coherent data as information to act on. Making the right decisions “on the drawing board” will help nations and NATO Agencies and Commands to communicate on issues (e.g. interoperability), investments and capability gaps that are made visible by the architecture leading to a vide range of operational benefits.

Nordic Battle Group 2008 Sweden (2300), Finland (200), Norway (150) , Ireland (80) Estonia (50)

NBG 2008 challenges Flexibility and expeditionary mindset Situation awareness and intelligence Deployment and logistics Athena mechanism and operations budget Common political – military understanding (nationally – internationally) Civil-Military cooperation, comprehensive approach Budget constraints Materiel and systems ready for training and operations Late and limited use of architecture related tools

Battle Group 2011 Battle Group 2011 Force Commander is appointed: Brigadier General Stefan Andersson (Army) Experiences from NBG 2008 are being incorporated in the current planning Equipment (ready for use before training year (2010) Challenges addressed Early staffing of key personnel

Battle Group 2011 Battle Group 2011 Nations participation: Finland, Norway, Ireland & Estonia 2000+ soldiers (of which 1600 are Swedish). Readiness level 10 days, Endurance 30 (1290) days One of the areas where we now are using MODAF and architectural work

Snapshot example 17

Snapshot example 18

Operational benefits To improve force planning capability through: Reduced timescale for mission planning Enhanced data Interoperability Reusability Understandability Visibility Shareability Reduced costs Picture source: http://www.aof.mod.uk/aofcontent/i/capability_man_fig3.gif

IDEAS recommendations to NATO PWG Meeting in Rome 2010-03-15--19

Issues Raised by NATO HQC3 Staff: Extensions to NAF Meta Model (NMM) Architecture Data Exchange Mechanism (ADEM) The NAF Itself Cost Implications

Issue #1 – Extensions to NMM When the NMM version 3 was developed it was forecasted a minimum set (2 or 3) of national extensions for national purposes. In the case of NNEC SF there are 94 extensions to NMM made. Only around 30-40 of these extensions to NMM are in use in the model. Not a single element from NMM is used in NNEC SF.

Issue #1 – Extensions to NMM The incorrect use of extensions within the NNEC SF will lead to incoherence with Nations that have adopted the NAF Meta Model. This in turn will limit the exchange of architectural information between NATO and the Nations. To ensure coherence of architectures and to support information sharing, the NAF Meta Model must be strictly adhered to

Issue #1 – Extensions to NMM A further consequence is that the more the NMM is extended the more difficult it will be to coherently share architecture information with architectures developed in other national frameworks such as DoDAF and MODAF.

Issue #1 – Extensions to NMM The cause? NC3A uses a chapter 3 view on architectures that is not aligned with the core of the NAF, the NMM v 3.1. Conclusion: NC3A will not be able to share high quality architecture information with nations using NMM or any of the other major defence frameworks.

Capgemini NL http://www.nl.capgemini.com/resources/case_studies/overarching_architecture_at_nato/?d=8FBFEB54-3D11-1FEC-E26F-2816FA401BCE

Issue #1 – Extensions to NMM Furthermore, NATO won't have any “commercial off-the-shelf” tool support because of all extensions to NMM. UML and SySML tool vendors will make use of UPDM based on M3 and DM2 and NATO will find that all of the extensions made are not supported by the UPDM.

Issue #1 – Extensions to NMM RECOMMENDATION It is the IDEAS nations view that NMM should be perfectly suitable for NATO’s needs without any extensions. IDEAS recommends that NATO uses NMM strictly without any extensions.

Issue #2 – ADEM ADEM only facilitates, currently, exchange of core data which is quite inadequate, by itself, for sharing of meaningful architecture information. This issue is well recognized and is being addressed by IDEAS on the semantic level and by OMG on the syntactic level. IDEAS co-ordinates with OMG on this issue. A definitive connection to issue #1 is obvious.

Issue #2 – ADEM If the NMM is extended then, of course, only the core NMM data will be able to be exchanged – which is why it is important to ensure the architecture conforms as closely as possible to NMM. No core NMM data is found in NNEC SF, only extensions. UPDM2 will provide tools with a consistent NMM profile which makes exchange of data easier, but again, the extensions complicate this because they will not be included in UPDM 2.

Issue #2 – ADEM One of the key issues is XMI, an OMG standard which has been interpreted differently by different UML tool vendors in the past. This issue has been addressed in the Model Interchange Working Group (MIWG) NATO is recommended to get involved in the test-exchanges the MIWG are using to help resolve the problem. Point to point is an option, but probably far more costly than using a off-the-shelf standard. By doing so, NATO is recommended to use NMM strictly without any extensions.

Issue #3 – NAF itself Burning question: Can NATO afford the effort to maintain the NAFv3? We currently have a dichotomy between chapters on the NAF which is unacceptable. At the last PWG Meeting it was agreed that, following the agreement of Chapter 5 ver 3.1 (i.e. the revised NMM), further work on NAF would be put on hold pending the outcome of IDEAS discussions on convergence of frameworks. Maintenance of NAF is dependent on resourcing changes …..

Issue #4 – Cost Implications Affordability of NAF is not, in itself, an issue for the IDEAS Nations as they have their own frameworks. They do have an interest in ensuring coherence of frameworks, which has cost implications. NATO needs to consider whether or not NATO and the NAF using Nations have the resources (financial and human) to maintain NAF in the future. The cost of maintaining NAF will need to be measured against the cost of migrating to another framework.

Issue #4 – Cost Implications The IDEAS Nations will prioritize their resources to focus on the development of IDEAS models and enablers. They will, however, be willing to share their work with NATO to support coherence with NAF. The NMS Leader is happy to host a meeting of the NMS in London in Spring 2010 to take the discussion forward.

Summary NMM is fit for purpose. Failure to use NMM is a blocker to interoperability and the sharing of information PWG agreed chapter 5 (NMM) to a tight schedule in summer of 2009 – still not published.

References to follow

Reference: The Swedish Review of NNEC SF Swedish Armed Forces Architecture team, comments and contributions for discussions at the C3 Management Cabability meeting 23:rd sept 2009 Brussels.

NNEC Services Framework in a far term perspective In 2004 NC3A elaborates AEM, based on industry knowledge in general and Capgemini´s Integrated Architecture Framework in particular, which in its turn is based on TOGAF and ADM. AEM is however more of a framework than a just a method, since there are also defined architecture elements with their relations. 38

NNEC Services Framework in a far term perspective The NAF v3 incorporates AEM in its framework together with the MODAF-inspired NATO Meta Model (NMM). Subsequently we have a NAF containing two meta models from two generations of architecture frameworks. In NAF v3 an attempt has been made to describe how the AEM meta model´s architecture elements are related to NMM and how this is to be used 39

NNEC Services Framework in a far term perspective The AEM meta model has been used by NC3A in parallel with NAF v2 and now NAF v3 for some years and subsequently generated a number of documents and architectures based on it. An important architecture, where the AEM elements (NAF ch3 elements) have been used is OA 3.0. OA 3.0 is further elaborated with the NNEC Services Framework. This NSF like OA 3.0 predominantly uses elements from AEM. 40

NNEC Services Framework in a far term perspective NSF is also based on NNEC Services Strategy (NSS). NSS refers to OASIS SOA RM, but uses a fundamentally different definition of ‘service’. This has induced consequences in NSF, that are incompatible with the NMM. 41

What is the actual situation? We have two competing fundamentally different meta models in NAF v3.1 together with an attempt to overbridge the gap between the two. There is a long history in NC3A to use AEM as a framework. This is not easy to change from as well economical as cultural reasons 42

What is the actual situation? NMM 3.1 is a fairly late appearance and the use of UML has become more advantageous through the new possibilities in UML v2. This has not been realised at all hands. The introduction of SOA in NNEC OA 3.0 has been influenced by the AEM service concept. 43

This is complicated by… The first NAF meta model (AEM meta model) uses a domain specific approach and is not based on a formal language. The second is NMM, which is a profile of UML 2.1 and strictly adherent to the UML standard. Major member nations and partner nations have implemented NMM or close-NMM (as M3) as national standard to facilitate the exchange of model information within and between nations. 44

This is complicated by… NATO architectures are predominantly based on AEM objects, which effectively prevents any model exchange between member nations and NATO. The number of national extensions complicates the use of the NMM OA 3.0 is aimed for Expeditionary Operations 2012. Member nations participating in NRF or in any industrial joint ventures, cannot use their NMM based models to interact with NATO and NC3A. 45

This is complicated by… There is a significant difference in the definitions of important model objects as e.g. service, role, actor etc. There are also object names used in both AEM and NMM but with different definitions. The NNEC Services Strategy v 0.8.4 refers to OASIS SOA Reference model, but provides different definitions on SOA and service, giving a totally different approach to services than intended There is a significant difference in view, how to use UML between major member nations and NC3A. 46

What can we do about it? It is understood that the chapter 3 objects are difficult to change and such a change would affect a vast number of documents. It is however our belief, that it is possible to maintain a majority of the chapter 3 objects as terms well known by humans and transform those objects to the formal language of NMM It is however necessary to obtain a common view on the use of NMM formal description language and the definitions used in this. 47

What can we do about it? A brief attempt made by Sweden shows that this should be possible to a very large extent. It is suggested that a workshop planned in order to discuss the approach and consequences of how to implement the AEM architecture objects in an NMM based model without national extensions and taking this into OA 3.0 and NNEC SF and still conform to OASIS SOA RM and SoaML/UPDM. 48

Reference: Agenda item 4b at NATO Architecture WS in NATO HQ 2009-09-03

Service frameworks within a service oriented federated environment Presentation by Sweden at NATO Architecture Workshop in NATO HQ 2009-09-03

Service frameworks within a service oriented federated environment Services need to be shared, have a taxonomy and be reused. Services is a reusable commodity and the taxonomy of services is a strategic product that needs to be carefully maintained. In order to use services it is however important to establish a set of principles for services that need to be edhered to:

Service frameworks within a service oriented federated environment The services views within NAF and MODAF are implementation independent specifications of services. MODAF 1.2 SOV-1 establishes the taxonomy, SOV-2 establishes the service interface, SOV-3 establishes how a set of services contribute to one or more capabilities, SOV-4 and SOV-5 establishes specified behaviour, NSOV-3 (NAF 3.0)/ proposed NSOV-6 (NAF 3.1) deals with services specification re-use. Services described by the service views should be concrete specifications of loosely coupled entities, i.e. the only external context of a service is its unknown consumer. Let us now consider a service framework in light of these principles.

Service frameworks within a service oriented federated environment SatCom services with the data link and connection services The NNEC services framework Communication services

Service frameworks within a service oriented federated environment In the previous example a couple of things were obvious: The services are not implementation independent, in the example satellite communication is known from the start as the means of implementation.

Service frameworks within a service oriented federated environment In the above example, taken from Community of interest services, the following questions could be asked: Are these services or rather service categories:? Can the interface to a consumer be defined in detail? Can information regarding the service be published such that a potential consumer knows exactly what he/she will achieve by using it?

Service frameworks within a service oriented federated environment A detailed service description might look like this: << Service >> AccessControl bif_srvc_if RealizedBifService RequiredBifService operation , ServiceInterfaceOperation EvaluateAccess in ticket : SAMLTicketType resources ResourcesRequiredType out access_allowed ResourcesAccessType [ .. 1 ] return EvaluateAccessResultType AddRule rule BIFrule rule_id RuleIdType AddRuleResultType ActivateRule ActivateRuleResultType DeactivateRule DeactivateRuleResultType DeleteRule DeleteRuleResultType FetchRules service_id ServiceIdType attribute_list ResourcesListType rules RulesArrayType FetchRulesResultType signal AsynchronousMessage EvaluateAccessRequest EvaluateAccessResponse cnsmr res