1. HEADQUARTERS Introduction to MODEM Building a Semantic Foundation for EA: Reengineering the MODAF™ Meta-Model Based on the IDEAS Foundation Model Lt Col Mikael Hagenbo, Swedish Armed Forces Chairman IDEAS UK MOD Whitehall Main Building, 2012-06-21

2. HEADQUARTERS Introduction MODEM is a component of an enterprise architecture description framework that provides a vocabulary for describing an enterprise, its structure as well as its behaviour in a unified manner. MODEM is an evolution of the metamodel definied by the Ministry of Defence in the UK called M3. The reengineering effort adds value since the semantics of the elements within the framework end up being defined properly, thereby enabling exchange of architecture models. MODEM is based on work performed by the IDEAS group.

3. HEADQUARTERS MODEM is a descendent of work within the IDEAS group (International Defence Enterprise Architecture Specification) 2005-2009: Development of a Model (IDEAS Foundation) for Coalition Architecture Interoperability. IDEAS is based on semantics in order to deal with semantic heterogeneity between the nations national Architecture Frameworks by the use of an approach based on Business Objects Reference Ontology (BORO)™ Methodology. IDEAS Foundation has been exploited by US DoD for DODAF 2. MODEM (MODAF Ontological Data Exchange Model) is the result of a Swedish led effort within IDEAS aiming for an evolution of M3 by exploiting the IDEAS foundation.

4. IDEAS Model 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 national extension national extension 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. This slide UK Crown Copyright 2006

5. HEADQUARTERS The MODEM re-engineering aims to: Harvest the relevant semantic features of UML and the MODAF meta-model and migrate them to MODEM, Winnow out the irrelevant technical implementation features – particularly the constraints that were stove piping the UML meta-model and the MODAF meta-model built upon it, Provide a clearer picture of the enterprise – one which reveals the common underlying business patterns across what previously appeared as very different areas, and Provide a migration path for the existing MODAF models.

6. HEADQUARTERS Rationale on one slide MODEM has been developed to be used by the tool vendors in order to create a means of unification, reusability and exchange of architectural artefacts between different tools. MODEM is an evolution of M3 based on IDEAS work. MODEM will, together with the national architecture frameworks in the IDEAS nations, be a building block for a future common defence standard. NATO is invited to make use of MODEM for NAF. MODEM is not in not in any way defence specific and thus not limited to defence use only.

7. HEADQUARTERS Industry – a crucial partner for defence EA success Interoperable tools and federated repository solutions are required for successful delivery of defence EA. MODEM requires an industry agreed implementation profile that could be used for vendors developing software solutions. Non-UML/SysML tools and UML/SysML tools are equal in importance because of different user categories. There is a definitive requirement to be able to interoperate without loss of data or relations in the diagrams. Please join forces and help us fulfil those requirements. UPDM group is a successful model for industry co- operation.

8. HEADQUARTERS MOD statement and conclusions

9. Chief Information Officer MOD STATEMENT OF INTENT FOR THE IMPLEMENTATION OF MODEM Patrick Gorman Assistant Head Architecture Framework MOD CIO

10. Future MODAF – What We Want To Do On completion of MODEM (c. Sep 2012):  Look to retire M3  Update Policy for use of:  UPDM2 (UML / SysML Tools)  MODEM (Non-UML Tools)  Ensure alignment of MODEM and UPDM  Offer MODEM to NATO to support convergence of frameworks

11. Future MODAF – What We Need To Do To Get There Primarily Stakeholder Engagement:  UK Defence Stakeholders – MOD and Partners.  Software Tool Vendors.  NATO and Nations.

12. Next step Starting with MODEM as a starting point, develop and agree on a Unified Defence Enterprise Architecture Model (UDEAM), along with a data exchange mechanism, that will serve as global standard for creating architectures and exchange architecture data in a semantically assured way.

13. IDEAS Principal Agreement Finalize the development and implementation of the International Defence Enterprise Architecture Specification (IDEAS) foundation v 1.0 in to an Unified Defence Enterprise Architecture Model (UDEAM). Use MODEM and DM2 as starting points. Capture unique Canadian government requirement like “security views” in the model. Align with ISO/IEC 42010:2011 AUSDAF

14. IDEAS Principal Agreement NATO will be invited to make use of the UDEAM for the NATO Architecture Framework (NAF). Statement of future support from Australia is currently unknown.4

15. IDEAS Principal Agreement As a next step for IDEAS the aim is to harvest the knowledge captured in the current national Architecture Frameworks and the NATO Architecture Framework (NAF) and by doing so, expand the scope of the framework. Invite France to join IDEAS.

16. IDEAS Principal Agreement Expansion from only architecture descriptions to a wider scope also comprehending: Life Cycle principles (including methods, methodology, processes and so on), Design principles (including design rules, reference architectures and so on) and finally a “traditional” module for architecture descriptions where the CUDEAM as above as act as a common denominator.

17. HEADQUARTERS Ian Bailey – Model Futures Patrick Gorman – UK MOD Lt Col Mikael Hagenbo – Swedish Armed Forces Lars-Olof Kihlstrom – Generic Systems AB Chris Partridge – BORO Solutions

18. HEADQUARTERS Military Enterprise Architecture Military operations are complex – Large, hierarchical organisations – Small, agile organisations – Thousands of interacting processes – Complex, data-intensive systems Enterprise architecture provides a way to plan and organise information about: – Structures – Behaviour – Capability Image Crown Copyright

19. HEADQUARTERS EA is Just Diagrams, Right ? First generation enterprise architecture really was just about pictures Things have moved on since then – EA is now considered a decision-support tool – Providing the right information, at the right level of abstraction to business and technical stakeholders The frameworks have had to adapt accordingly – Increasing use of meta-models – Some are even looking at ontologies

20. HEADQUARTERS MODAF The UK Ministry of Defence Architecture Framework – Originally based on DoDAF – MODAF extensions now adopted by DoDAF – NATO Architecture Framework *is* MODAF MODAF Meta-Model (M3) – An extension of the UML 2.1 Meta-Model – i.e. a UML profile

21. HEADQUARTERS MODAF Stack Re-useable specifications & strategic governance Logical architecture: Scenarios, requirements, etc. Physical Architecture - Solutions. Block diagram © Model Futures 2008

22. HEADQUARTERS How Does MODA F Work?

23. HEADQUARTERS Then There are Programmes

24. HEADQUARTERS Overview of MODAF Meta-Model Crown Copyright 2010

25. HEADQUARTERS M3 Elements & Viewpoints Crown Copyright 2010

26. HEADQUARTERS M3 Element – View Mapping Crown Copyright 2010

27. HEADQUARTERS Objects (data) Conforming to UML Model OMG’s Meta-Stack FredFido Fido ownedBy Fred UML Model Person Dog ownedBy UML Meta-Model > UML::Class > UML::Class > UML::Associatio n > UML::Associatio n MOF MOF::Class Crown Copyright 2010

28. HEADQUARTERS Profile Meta- Model UML Profiles Profiles are a means for users to make local extensions to the UML Meta-Model – The extensions are called “Stereotypes” Here, the stereotype Resource extends UML::Class – This means that when a user adds a class to their model, they can opt to make it a > UML Model Strike > F-35 > F-35 UML Meta- Model > UML::Class > UML::Class > Resource > Resource > standard user-defined Crown Copyright 2010

29. HEADQUARTERS Re-Engineering M3 If it ain’t broke, don’t fix it – M3 based on the UML 2.1 meta-model – UML is widely used and liked – …by the IT community UML Meta-Model – Designed by committee several committees – Lots of ways to do the same thing – Some really weird and complex ways to do simple things – Betrays its software roots – doesn’t handle physical world very well

30. HEADQUARTERS UML: Whole-Part Several different ways to say one thing is part of another: – ownedElement (anything) – Composite Structure (classes) – Composition/Aggregation Relationships (classes) – Actions in Activities (and CBA) Not ideal if you’re trying to apply some semantic rigour to your projects

31. HEADQUARTERS Flows Flows between elements Flows between activities/actions – While we’re on the topic, what’s the difference between an activity and an action ? – Er…none. Often these flows are the same flow – You end up producing two flows in UML

32. HEADQUARTERS Re-Engineering M3 Need to deal with: – Business models (processes, org structures, etc.) – Systems models (functions, sub-systems, components, states, etc.) – Strategic models – capabilities – Levels of abstraction – conceptual, logical, physical UML wasn’t designed to do this – Hence, the re-engineering often goes back to intent

33. HEADQUARTERS Re-Engineering M3 - Approach We used the BORO Method – Already been used on the IDEAS upper ontology and ISO15926 Every concept has to be grounded – Spatio-temporal individuals, relationships, classes – Analysis is slow and boring…but it works

34. HEADQUARTERS Business Justification Enterprise Architecture is supposed to be about decisions support – …not drawing pictures What if…. – … we could get the architects to populate formal ontologies without them ever realising they’re doing it ? This will all depend on whether the tool vendors get it

35. HEADQUARTERS EA as Business Ontology Enterprise Architecture covers most aspects of the business from strategy, through HR and operations down to IT – That’s if you’re taking EA seriously Combine this with operational data (big data) – …and you’ve got an enterprise-level decision support system

36. HEADQUARTERS Making it Simpler “Cleaner” might be a better word – MODEM will not be any smaller than M3 – …but is more consistent and logically sound Should also be more understandable – Particularly to non-UML users and tool- vendors

37. HEADQUARTERS Building a Real World Semantics for MODAF Why MODAF needs a real world semantics

38. HEADQUARTERS Building in a real world semantics (ontology) The real problem in speech is not precise language. The problem is clear language. Richard Feynmann Formal Semantics Real World UML IDEAS And if the language doesn’t provide a clear picture of the real world, how do people and machines know what is being talked about.

39. HEADQUARTERS Ontology and the real world The question ontology asks can be stated in three words ‘What is there?’ and the answer in one ‘everything’. Not only that, “everyone will accept this answer as true” though “there remains room for disagreement over cases.” (Quine “On What There Is”). So an ontology tells you the things that exist in the real world. If you want a more technical definition An ontology is "the set of things whose existence is acknowledged by a particular … system." (E. J. Lowe, The Oxford Companion to Philosophy)

40. HEADQUARTERS And these One real world: how many (UML compliant) entities? I This seems a reasonable entity But so do these All these are UML compliant.

41. HEADQUARTERS One real world: how many (UML compliant) entities? II But so does this This seems a reasonable entity but they can they exist in the same model, it looks like two different ways to model address What about this? All these are UML compliant.

42. HEADQUARTERS M3 starts to map the real world Problem is that the UML top level is not designed for real world semantics

43. HEADQUARTERS Top level real world semantics UML was not designed to provide a real world semantics –It has a formal semantics MODAF started to establish middle level real world semantics, within UML’s top level formal semantics –Had to fit within the UML constraints MODAF as it currently stands has no top level real world semantics MODEM uses IDEAS (BORO) to bring these semantics in.

44. HEADQUARTERS There is a significant investment in MODAF Build upon what already exists Winnow out the irrelevant technical features Harvest the relevant features

45. HEADQUARTERS M3 UML Profile Building a semantic foundation M3 was designed as a UML profile. implementation structure explicit semantics As a result it has both implementation structure and (explicit) semantics implicit semantics From a semantic perspective, it is like an iceberg, with visible ‘explicit semantic’ and hidden ‘implicit semantics’. The goal is to: Peel off the implementation structure, and Make the implicit semantics explicit semantic foundation

46. HEADQUARTERS Two examples Example 1 – SuperSubType Example 2 – Change over time - states

47. HEADQUARTERS Real world semantics – example 1: super-sub-type

48. HEADQUARTERS MODEM Recovering the supersubtype semantic structure M3 superSubType is not the same as UML Generalisation.

49. HEADQUARTERS Example 2: Change over time - states Figure 15.12 - Protocol state machine” (p. 552 - UML Superstructure Specification, v2.3) A UML State Machine This is one way UML can be used to represent change over time a)there are other ways to do this b)this can be used to represent most algorithms (abstract state machines)

50. HEADQUARTERS What is ‘state’ in the real world? You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing — that's what counts. I learned very early the difference between knowing the name of something and knowing something. Richard Feynmann

51. HEADQUARTERS UML States Have a very constrained structure. For example, cannot: –Have a state inside more than one state machine –Have one state machine inside another –Subtype a state Why not? –Can this happen in the real world (Yes!) –Makes the formal structure easier (?)

52. HEADQUARTERS Removing Implementation Structure Combining state machines State machine inside a state machine

53. HEADQUARTERS Removing Implementation Structure Sub-typing state machines State machine subtypes another state machine State subtypes another state

54. HEADQUARTERS Building in a ‘clear’ real world semantics Formal Semantics Real World UML IDEAS

55. HEADQUARTERS More details concerning MODEM can be found at: http://www.amazon.co.uk/Business-Objects-Re-engineering-Chris-Partridge/dp/0955060303/ http://www.borosolutions.co.uk/research/content/files/SwAF-MODEM-Behaviour Analysis Report - March 2011.pdf http://dl.dropbox.com/u/823291/MODAF_M3_and_IDEAS_integration_phase%201%20and%202%20version_1.00.pdf http://dl.dropbox.com/u/823291/MODAF_M3_and_IDEAS_integration_examplification_version_1.00.pdf

56. HEADQUARTERS MODEM: Reason for being and examples Lt Col Mikael Hagenbo, Swedish Armed Forces Lars-Olof Kihlström, Generic Systems Sweden AB, Ian Bailey, Model Futures Limited, Chris Partridge, BORO Solutions Limited Patrick Gorman, UK MOD

57. HEADQUARTERS Enterprise architecture goals Goal: An EA model should be capable of supporting decisions on many levels: –Strategic –Operational (Logical) –Services handling –Standards use –Programme and project handling –Solution choices

58. HEADQUARTERS What is an EA good for? Why bother? EA Model based on an architecture framework Dealing with traceability (examples) How do we deliver a given capability configuration?? Why should we have B that costs C? What happens if we delete solution D? How does a change impact on the overall capability of the enterprise? Pertaining to systems development (examples) What do the interfaces to the systems look like? What systems does system A interface with? What does the interaction between systems look like? What are the parts of the system? Are there alternative solutions? Dealing with transition/ change (examples) Can we deliver a capability configuration in time? What does the costs look like? How are requirements met? What to own and what to outsource? Questions posed by a customer (examples) What are we capable of at a certain point in time? What happens if the tasks or partners are modified or exchanged? What happens if we reallocate resources? When do we achieve a specified capability? What capabilities do we get for the money we are spending? Too often, this has not been achieved due both to the way users deal with EA and due to how tools support EA development. Their use should aid decision making concerning the enterprise and enable questions such as the one below to be answered.

59. HEADQUARTERS Enetrprise architecture issues Issues: Projects that end up with an enterprise architecture model able to support decision making at different levels are few and far betwee n Why: –Lack of proper guidance –Inability to get at the data needed –Lack of management support –No staying power –Inability to compare and utilise results from different EA projects.

60. HEADQUARTERS So why is MODEM needed? Current tool and architecture framework use situation Different tools are used in different domains. GenEA: General EA tools (ARIS, MEGA, SA, MooD etc.) UML tools with EA plugins (Magic Draw, Sparx, Rhapsody, Artisan etc.) They are islands on their own with no direct communication in between tools. They can not be used to enhance each other. Implementation Specification Strategy and planning Operational processes GenEA a UML EA a UML EA b UML EA c UML EA d UML EA e GenEA b GenEA c GenEA d GenEA e

61. HEADQUARTERS Possible tool situation based on MODEM A seamless transfer between tools without importing other tool conventions can be achieved if they are based on MODEM as an underlying basis. This will expand the usage as well as market for all tools. The interconnection ability will dramatically increase the use of each tool. The strengths of the different tools can be used to enhance the overall use of all tools. This will provide an benefits to all areas of use and to all tools. MODEM basis Implementation Specification Strategy and planning Operational processes GenEA a UML EA a UML EA b UML EA c UML EA d UML EA e GenEA b GenEA c GenEA d GenEA e e.g. RDF

62. HEADQUARTERS What does a meta-model for an architecture framework provide? It could be said that the MODAF/ NAF/ UPDM meta-model provides a grammar for speaking architecture in accordance with a framework. It defines the type of words that may be used and how they can be combined (related) to form architectural “sentences”.

63. HEADQUARTERS What does give us that MODAF M3 does not ? Consider the following text: 'Twas brillig, and the slithy toves Did gyre and gimble in the wabe; All mimsy were the borogoves, And the mome raths outgrabe. A portion of Jabberwocky: A poem by Lewis Carroll published as part of: Through the looking-glass, and what Alice found there (1872)

64. HEADQUARTERS An analogy..... While the grammar of the poem is sound, i.e. adjectives, nouns and verbs can be identified and they seem to relate to one another as they should, the meaning is less than clear. The difference between MODAF M3 and MODEM could be visualised by saying that in MODAF M3 the Jabberwocky poem would be accepted as correct as it only checks the grammar, whereas MODEM would also provide the semantic meaning.

65. HEADQUARTERS MODEM: A simple example

66. HEADQUARTERS A simple example In order to see the basic differences between frameworks such as MODAF and NAF and MODEM it may be useful to look at a simple example. Let us assume that an architect wishes to describe how much a given kind of laptop weighs. The next slides shows how this is done based on the use of MODAF, based on UPDM and finally based on MODEM.

67. HEADQUARTERS Describing laptop weight using MODAF

68. HEADQUARTERS Describing laptop weight using UPDM 2

69. HEADQUARTERS An example of modelling the weight of a particular kind of laptop

70. HEADQUARTERS MODEM: Pattern usage

71. HEADQUARTERS Patterns As part of the integration efforts patterns of repeatable relationships between different types of elements have been identified and included as part of MODEM These patterns are quite powerful and have been reused again and again as part of the reengineering effort. The basic set of patterns include examples such as: –Overlap and intersection –Exchange –Behaviour –Agent –Process

72. HEADQUARTERS Patterns It should be remembered that an architect interested in developing an architecture model is not expected to work directly with these patterns but at a much higher level where the detailed structure, while existing within the tool supporting the architecture model development, will be invisible. MODEM representation is required in order to be able to achieve semantic interoperability when exchanging architecture data and in order to facilitate detailed queries towards the stored data.

73. HEADQUARTERS Architect: I have a need to show roads that overlap as part of my architecture model

74. HEADQUARTERS Architect: The actual intersection is of special interest

75. HEADQUARTERS An overlapping types example

76. HEADQUARTERS Intersection between overlapping types

77. HEADQUARTERS Another reappearing pattern in MODEM The set of Individuals that are all parts of the set of individuals in X. The set of all Xpart individuals that are temporal parts of the set of individuals in X The set of all X individuals The set of all wholePart relationships where the part is an Xpart individual and the whole is an X individual. The set of all wholePart relationships where the part is an Xstate individual and the whole is an X individual. The set of all wholePart relationships where the part is an X individual and the whole is an X individual.

78. HEADQUARTERS A real example of the pattern An Individual that is part of a Process. A ProcessPart that is a temporal part of a Process A ProcessPart that is an Individual whose extent is defined by its involvements. A wholePart that asserts an Individual is part of a Process A processWholeState where the part is a ProcessState - i.e. all of the spatial extent of the process for a period of time. A processWholeP art that asserts a Process is part of a Process.

79. HEADQUARTERS I want to show distribution (exchange) of music scores within a symphony orchestra Viola notes Trumpet notes Cello notes Violin notes Viola notes Trumpet notes Cello notes Violin notes Trumpet notes

80. HEADQUARTERS A generic node representation LogArchSet1 is composed of ProbDomSet1 and NodeSet10 ProbDomSet1 is composed of SecDomSet1 and NodeSet1 SecDomSet1 is composed of NodeSet4 and NodeSet5 NodeSet1 is composed of NodeSet2 and NodeSet3

81. HEADQUARTERS MODEM representation

82. HEADQUARTERS A Search and rescue representation in UPDM

83. HEADQUARTERS The same representation within MODEM with proper semantics

84. HEADQUARTERS Conclusions The representations shown here may seem complex but thay are in actual fact just repetitions of defined patterns. Once the patters have been implemented as a representation within the tool their use should be relatively straight forward. Tools that implement these will be able to seamlessly interact with other tools based on the same semantic approach. This will then achieve the goals of true interoperability and pave the way for use of EA to achieve significant decision support within different organisations as well as interoperability between organisations.