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 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. style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility 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 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. style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility MOD statement and conclusions MOD STATEMENT OF INTENT FOR THE IMPLEMENTATION OF MODEM Patrick Gorman Assistant Head Architecture Framework MOD CIO 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility 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. 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 style.visibility style.visibility style.visibility style.visibility 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 style.visibility style.visibility style.visibility ppt_x ppt_y style.visibility ppt_x ppt_y 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. style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility 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 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 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 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 MODAF Stack Systems (SV) Operational (OV) Service (SOV) Strategic ( StV ) Acquisition ( AcV ) Standards (TV) Re-useable specifications & strategic governance Logical architecture: Scenarios, requirements, etc. Physical Architecture - Solutions. Block diagram © Model Futures 2008 How Does MODAF Work? Then There are Programmes Overview of MODAF Meta-Model Crown Copyright 2010 M3 Elements & Viewpoints Crown Copyright 2010 M3 Element – View Mapping Crown Copyright 2010 Objects (data) Conforming to UML Model OMG’s Meta-Stack Fred Fido Fido ownedBy Fred UML Model Person Dog ownedBy UML Meta-Model << Metaclass >> UML::Class << Metaclass >> UML::Association MOF MOF::Class Crown Copyright 2010 style.visibility style.visibility style.visibility 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 <<Resource>> UML Model Strike <<Resource>> F-35 UML Meta-Model << Metaclass >> UML::Class <<Stereotype>> Resource <<extends>> standard user-defined user-defined Crown Copyright 2010 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 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 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 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 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 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 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 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 Building a Real World Semantics for MODAF Why MODAF needs a real world semantics 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. style.visibility style.visibility style.visibility style.visibility style.visibility 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) style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility style.visibility M3 starts to map the real world Problem is that the UML top level is not designed for real world semantics style.visibility style.visibility style.visibility 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. There is a significant investment in MODAF Build upon what already exists Winnow out the irrelevant technical features Harvest the relevant features style.visibility style.visibility style.visibility 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 style.visibility style.visibility style.visibility style.visibility Two examples Example 1 – SuperSubType Example 2 – Change over time - states Real world semantics – example 1: super-sub-type style.visibility style.visibility style.visibility style.visibility MODEM Recovering the supersubtype semantic structure M3 superSubType is not the same as UML Generalisation. style.visibility style.visibility style.visibility 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 there are other ways to do this this can be used to represent most algorithms (abstract state machines) 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 style.visibility style.visibility style.visibility 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 (?) Removing Implementation Structure Combining state machines State machine inside a state machine style.visibility style.visibility style.visibility style.visibility style.visibility Removing Implementation Structure Sub-typing state machines State machine subtypes another state machine State subtypes another state style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility Building in a ‘ clear ’ real world semantics Formal Semantics Real World UML IDEAS 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 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 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility What is an EA good for? Why bother? EA Model based on an architecture framework D ealing with traceability (ex a mples) 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? P ertaining to systems development (ex a mples) 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 (ex a mples) 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. style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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”. style.visibility style.visibility 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) style.visibility style.visibility style.visibility 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. style.visibility style.visibility MODEM: A simple example 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. style.visibility style.visibility style.visibility Describing laptop weight using MODAF style.visibility Describing laptop weight using UPDM 2 style.visibility An example of modelling the weight of a particular kind of laptop style.visibility style.visibility style.visibility style.visibility style.visibility MODEM: Pattern usage 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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. style.visibility style.visibility Architect: I have a need to show roads that overlap as part of my architecture model style.visibility style.visibility ppt_x ppt_y style.visibility ppt_x ppt_y style.visibility style.visibility style.visibility style.visibility Architect: The actual intersection is of special interest style.visibility style.visibility style.visibility An overlapping types example style.visibility style.visibility Intersection between overlapping types style.visibility style.visibility ppt_x ppt_y 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. style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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 processWholePart that asserts a Process is part of a Process. style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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 Trumpet notes Trumpet notes Trumpet notes style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility 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 style.visibility style.visibility style.visibility style.visibility style.visibility MODEM representation style.visibility style.visibility A Search and rescue representation in UPDM style.visibility style.visibility The same representation within MODEM with proper semantics style.visibility style.visibility 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. style.visibility style.visibility style.visibility style.visibility