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

What is an EA good for? Why bother? Their use should aid decision making concerning the enterprise and enable questions such as the one below to be answered. 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? EA Model based on an architecture framework 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? 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? Too often, this has not been achieved due both to the way users deal with EA and due to how tools support EA development.

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

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 Currently different tools are in use in various communities and for different purposes. They are essentially isolated and their abilit to exchange architecture data is limited or non-existent without substantial manual effort. This is hurting the overall EA usage in general to a very marked degree. The next slide may seem a bit over the top but somewhat light-heartedly represents the way in which NAF, MODAF and DoDAF have been dealt with both by some users and by some tool developers.

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 MODEM could be used to expand th utility of the EA field in general and make it possible to use the different products where they are the strongest and still be able to interwork seamlessly. e.g. RDF

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

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)

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.

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.

Describing laptop weight using MODAF The shows what this would look like in ”pure” MODAF. It should be noted that the only way of getting 2.4 kg into the Sone laptop is to define a default value for the property, i.e. this is not as semantically clean an approach as one would wish to have.

Describing laptop weight using UPDM 2 The above model uses the UPDM profile in its ”raw” published form. Different tools can make the diagram look nicer since they have added presentation functionality inherent to the tool on top of the profile. Beneath the nicer presentation the elements shown here will however be found.

An example of modelling the weight of a particular kind of laptop This may seem more complicated but this is not really the case since only the parts below the dotted line have been added by the architect. The elements above are part of the already defined framework, i.e. modelling implies just continuing from where MODEM ends.

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

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.

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

Architect: The actual intersection is of special interest

An overlapping types example

Intersection between overlapping types

Another reappearing pattern in MODEM The set of all wholePart relationships where the part is an Xpart individual and the whole is an X individual. 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 wholePart relationships where the part is an Xstate individual and the whole is an X individual. The set of all X individuals The set of all wholePart relationships where the part is an X individual and the whole is an X individual.

A real example of the pattern A wholePart that asserts an Individual is part of a Process An Individual that 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 ProcessPart that is a temporal part of a Process A ProcessPart that is an Individual whose extent is defined by its involvements. A processWholePart that asserts a Process is part of a Process.

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

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

MODEM representation

A Search and rescue representation in UPDM

The same representation within MODEM with proper semantics

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.