1 / 29

MODEM: Reason for being and examples

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.

stimmy
Download Presentation

MODEM: Reason for being and examples

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. So why is MODEM needed?Current tool and architecture framework use situation Strategy and planning • 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. GenEA a GenEA b GenEA c Operational processes GenEA d GenEA e Specification UML EA a UML EA b Implementation UML EA c UML EA d UML EA e

  6. Possible tool situation based on MODEM MODEM basis Strategy and planning GenEA a • 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. GenEA b GenEA c Operational processes GenEA d GenEA e UML EA a Specification UML EA b Implementation UML EA c UML EA d UML EA e e.g. RDF

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

  8. What does give us that MODAF M3 does not ? • Consider the following text: 'Twas brillig, and the slithy tovesDid 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)

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

  10. MODEM: A simple example

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

  12. Describing laptop weight using MODAF

  13. Describing laptop weight using UPDM 2

  14. An example of modelling the weight of a particular kind of laptop

  15. MODEM: Pattern usage

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

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

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

  19. Architect: The actual intersection is of special interest

  20. An overlapping types example

  21. Intersection between overlapping types

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

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

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

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

  26. MODEM representation

  27. A Search and rescue representation in UPDM

  28. The same representation within MODEM with proper semantics

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

More Related