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 Lars-Olof Kihlström, Generic Systems Sweden AB, Ian Bailey, Model Futures Limited, Chris Partridge, BORO Solutions Limited Introduction Introduction MODEM is an enterprise architecture framework that provides a vocabulary for describing an enterprise, its structure as well as its behaviour in a unified manner. There are several architecture frameworks and this presentation starts with a brief description of how they relate to one another and how they differ. MODEM is an evolution of the framework definied by the Ministry of Defence in the UK called MODAF. 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 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 Why did we start? For whom do we do it? ISAF Contributing nations Something about frameworks Defence 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 There are a lot of different frameworks and standards TOGAF NAF 3.1 DoDAF v1.5 UPDM SoaML OASIS DoDAF 2.0 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 Framework timeline C4ISR 1.0 C4ISR 2.0 MODAF 1.0 MODAF 1.1 NAF 2.0 NAF 3.0 DoDAF 1.5 MODAF 1.2 DoDAF 2.0 DoDAF 1.0 1996 1997 1998 2003 2004 2005 2006 2007 2008 2009 2010 2011 NAF 3.1 UPDM 1.0 UPDM 2.0 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 style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility MODAF Stack Block diagram © Model Futures 2008 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. Overview of MODAF Meta-Model The benefits of a EA based on a meta-model that defines the types of elements that can be used in an architecture model 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”. In the case of MODAF the meta-model was created using UML (Unified Modelling Language) where all types of elements to be used in an architecture model are extensions of standardised UML concepts. style.visibility 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 Semantic technology Building in a real world semantics The real problem in speech is not precise language. The problem is clear language. Richard Feynmann Formal Semantics Real World UML IDEAS style.visibility style.visibility style.visibility style.visibility 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 super-sub-type style.visibility style.visibility style.visibility style.visibility MODEM Recovering the supersubtype semantic structure M3 Need to harvest where it matches, and Refine where it does not. style.visibility style.visibility style.visibility An example of formal semantics Figure 15.12 - Protocol state machine” (p. 552 - UML Superstructure Specification, v2.3) A UML State Machine 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 Removing Implementation Structure Combining state machines style.visibility style.visibility style.visibility style.visibility Removing Implementation Structure Sub-typing state machines style.visibility style.visibility style.visibility style.visibility Building in a ‘clear’ real world semantics Formal Semantics Real World UML IDEAS Patterns MODEM relies heavily on the use of patterns The basic set of patterns include: Overlap and intersection Behaviour Agent Process Exchange These patterns are then specialised in order to be used in a variety of places, some examples are shown here. style.visibility style.visibility style.visibility style.visibility style.visibility 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 Tool support for EA 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 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 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, used by defence and industrial organisations to develop Enterprise Architecture. 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 any way defence specific and thus not limited to defence use only. style.visibility style.visibility style.visibility style.visibility style.visibility More details concerning MODEM can be found at: 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
BORO Publications
MODEM – Building a semantic foundation for enterprise architecture:
Reengineering the MODAF meta-model based on the IDEAS foundation model
17 June 2012Presented at Enterprise Architecture Conference Europe 2012, colocated with Business Process Management Conference Europe, 18-20 June 2012, London, UK
Overview
Introduction: A presentation of the background for the work concerning MODEM, its origins as part of the IDEAS group effort and the reasons behind starting the work as an effort funded by the Swedish Armed Forces. Discussions around the goal of harmonization and the difficulties presented by having multiple, different, national frameworks.
The starting point: MODAF in its current form: A brief introduction of the MODAF meta-model as well as the IDEAS foundation model and the reasons for modifying MODAF based on a UML profile based meta-model to a non-UML meta-model based on the IDEAS foundation model.
Semantic technology, the road ahead: The semantic basis for IDEAS is presented and how this can improve the utility of framework usage. Examples from the reengineering work are presented as well as how a semantic approach cleared up various areas within the MODAF meta-model.
MODEM, what was done, patterns and examples: The work that resulted in MODEM is presented. The use of semantic patterns is presented as a crucial part of the MODEM reengineering effort. Some of these patterns are presented as well as exemplified. Some examples of MODEM used to model the standard search and rescue example used extensively in framework development are also presented.
Relationship between this effort and other IDEAS foundation based models: The US DoD architecture framework DoDAF 2 DMM has also used the IDEAS foundation model as a basis for development and similarities as well as differences are presented.
Conclusions: Conclusions as well as future directions of this work effort are presented.