1. 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

2. 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.

3. 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.

4. 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.

5. Update from IDEAS
The development of the Core Unified Defence Enterprise Architecture Model (CUDEAM) will start early 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. 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

12. 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.

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

14. 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

15. 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

16. 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

17. Snapshot example 17

18. Snapshot example 18

19. Operational benefits To improve force planning capability through:
Reduced timescale for mission planning
Enhanced data
Interoperability
Reusability
Understandability
Visibility
Shareability
Reduced costs
Picture source:

20. IDEAS recommendations to NATO
PWG Meeting in Rome

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

22. 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 of these extensions to NMM are in use in the model.
Not a single element from NMM is used in NNEC SF.

23. 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

24. 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.

25. 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.

26. Capgemini NL

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.

32. 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 …..

33. 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.

34. 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.

35. 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.

36. References to follow

37. 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.

38. NNEC Services Framework in a far term perspective
In 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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 Member nations participating in NRF or in any industrial joint ventures, cannot use their NMM based models to interact with NATO and NC3A. 45

46. 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 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

47. 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

48. 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

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

50. Service frameworks within a service oriented federated environment
Presentation by Sweden at NATO Architecture Workshop in NATO HQ

51. 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:

52. 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.

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

54. 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.

55. 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?

56. 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