DRAFT

MODEM Report on DoDAF Meta Model (DM2)30 January 2012

DoDAF Team SummaryDRAFT v.1

DoDAF Team Summary of

MODEM Report on DoDAF Meta Model (DM2)

30 January 2012

1Introduction and Background

LtCol Mikael Hagenbo (Swedish Armed Forces, Joint Concept Development & Experimentation Centre, Head of architecture, frameworks and International co-operation), acting in the capacity of the IDEAS Chairman, on 11 January 2012 provided to USA DoD CIO a report[1] on DM2 resulting from joint GBR MOD and SWE efforts to adopt IDEAS in the MODAF, an effort analogous to the USA adoption of IDEAS in the DM2 completed in May 2009. The product of their effort is MODEM. LtCol Hagenbo reported that their MODEM work "has yielded a model significantly different from DoDAF 2.0, especially as regards the use of the IDEAS foundation". He expressed concern, “given the fact that we all strive towards framework convergence.” Consequently, the DoDAF Team was tasked to review the report. This report is a summary of the team’s findings and recommendations.

2DoDAF Team Responses to Comments in the MODEM Report on DM2

The MODEM Report on DM2 is an update to prior commentaries on the DM2 by the same author as part of his roles in the IDEAS Group and the UPDM 2.0 team. It is a meticulously detailed 400-page document. In general, the DoDAF Team finds little technical disagreement with the report. There are about 16 comments that are Quality Assurance (QA) in nature and will be addressed before draft v2.03 comes out. There are also roughly 44 that are valid comments but not critical, perhaps to be discussed by the DoDAF-DM2 Working Group in the future and entered and processed as Change Requests (CR), after v2.03 is finalized.

The report has

1.Summary with nine comments

2.DoDAF model to DM2 elements rules

3.A list of five questions that need answering

4.Six detaled sections:

a)View comparisons

b)Previous versions of the DM2 model: Changes between 2.01 to 2.02

c)Changes from 2.02 to current working model 111228

d)The current working model 111228

e)IDEAS foundation integration history

f)A DM2 set based example

The following subparagraphs provide DoDAF Team responses to the comments in the report.

2.1Summary Comments

The MODEM report contains the following general statements in the summary. The DoDAF Team’s responses, if required, are listed below each one.

  1. “As can be seen the number of changes between 2.01 and 2.02 are extremely large something that will have direct impacts on the general enterprise architecture tools that have a plug-in for DoDAF 2, since most of them say they implement 2.01. The UML tool vendors that implement UPDM 2.0 at this point map their UML support towards 2.02.”
    RESPONSE: v2.02 was baselined in August 2010 and incorporated 29 CR’s; whether that is “extremely large” or not is probably subjective but it is what the WG deemed necessary. We have not heard of tool vendors implementing v2.01; can you provide us a list of vendors still on v2.01 (baselined February 2010) so we can contact them? It is good the UPDM 2.0 team chose 2.02 since it incorporates many of their comments, including the single PES XSD they favored over the 52 that were part of v2.01; this simplified their PES adoption.
  2. “The changes between 2.02 and 111228 are also fairly significant. It should be noted that the level of IDEAS integration has changed both up and down in the working models. In the working model 111101 the level reached its highest integration level yet when periods of time was integrated fully. This has since been scaled down again leaving only a fraction of this part of the IDEAS foundation within the DM2 model. The way that the integration has been performed (by introducing IDEAS foundation elements piecemeal into the DM2 model with several being modified as part of the integration) is also an issue since the original IDEAS intent was to keep the IDEAS foundation as a complete stand-alone entity that would be referenced in its entirety.”
    RESPONSE: There are 82 CR’s that have been processed for inclusion in v2.03 by the WG since August 2010 (date of v2.02 baseline), approximately 40 CR’s per year. With regards to IDEAS integration, the DoDAF Team has direction that it shall not retrofit DM2 to accommodate the deviations in MODAF. In terms of technical implementation, for a number of reasons, the WG found it not necessary for DoD architecture work to include certain IDEAS elements at this time (e.g., dispositionalManifestation; quintuple):
  3. Historic. As the first nation to adopt IDEAS, it was not possible to reference IDEAS in it entirety during DM2 development because IDEAS Foundation v1.0 was not complete until April 2009, long after DoDAF 2.0’s technical cutoff and only one month before DoDAF 2.0’s formal promulgation in May 2009.
  4. Incremental Adoption by DoD Community. The USA DoD supported IDEAS development since 2004 because we recognized the need for architecture data sharing and integration and that integration required formality and semantic precision beyond that available with then state-of-the-practice relational data models. However, we also realized that adoption by the DoD architecture user and vendor community of IDEAS’ formality would be incremental and that first, we must share data, and then we must integrate simple data, and then later engage in more complex integration. Consequently, we chose to expose the community to IDEAS formalisms incrementally. At some point in the future, we intend to reference the entirety of IDEAS as suggested. Note that even now we reference the entirety of IDEAS at the physical level by referencing the IDEAS XSD on the IDEAS Group web site.
  5. “When a 2.03 baseline will appear is not known but it is assumed that it will be based by and large on the 111228 model with some additional changes introduced, i.e. 111228 is considered as showing the direction taken for 2.03.”
    RESPONSE: The DoDAF-DM2 working copy is available to the entire 650 member DoDAF-DM2 Working Group; all IDEAS Group members are DoDAF-DM2 WG members as well. However, as has been noted before after similar reports by same author, the working copy is neither intended nor suitable for comprehensive review because it contains incomplete, tentative, draft, and other in-progress material that changes every bi-weekly WG meeting. Now that a technical cutoff has been reached, the working copy is being processed for completion, quality assurance (QA), and production into a draft v2.03 that will be submitted for formal coordination review. This is a major period of clean-up and many of the report’s comments are addressed by this period. Formal coordination normally results in around 1,000 comments. After adjudication of these comments, the final v2.03 will then be submitted for approval by an executive body and promulgated. These processes are documented in the DoDAF-DM2 Configuration Management Plan (CMP), available on the DoDAF-DM2 Working Group and main DoDAF websites.
  6. “The working model have for some time contained a set of elements in its own package and the status of these have not been known. In the 111228 model however, these have been integrated into overall model packages something that leads to the conclusion that these elements are to be considered as final. Some of these elements are part of the list where additional discussions are required.”
    RESPONSE: This is one of the risks in conducting a comprehensive review of the working copy, particularly when the reviewer(s) are not intimately familiar with the real-time activities of the WG and DoDAF Team. The extra material is to be regarded as a discard or junk pile. We have done this since DM2 inception in March 2008 in case we need to retrive deleted or non-included elements or revisit a deletion decision.
  7. “The mapping between various DoDAF views and elements as well as categorization of the various elements (see later) used to be empty but now seems to be made use of. It also seems clear however that this matrix does not contain the elements most recently integrated from the IDEAS foundation and neither does some of the new elements. There is therefore a great need to define how these new elements are to be categorized.”
    RESPONSE: The Team knew well the that there was much work to be done from the 28 November working copy to the draft v2.03 in this area, to make consistent the DoDAF’s matrix of the 52 DoDAF models versus the 250 DM2 data elements (nicknamed the “monster matrix”), the in-development DM2 diagrams of each DoDAF model, and the revised model narratives (aka, TECHEDITs) in-progress for the draft v2.03. The DM2 DoDAF model diagrams are a new feature for v2.03 developed at the urging of the WG and in response to a Change Request (CR) submitted by SPAWARSYSCOM several years ago. The TECHEDITs are being done in response to many CR’s submitted by the Marine Corps (Headquarters, CD&I, and MARCORSYSCOM) and a comprehensive review of the DoDAF model descriptions by SPAWARSYSCENLANT noting many inconsistencies, undefined terms, ambiguous, and technically erroneous text. The TECHEDIT revisions address those many problems while also corresponding to the new DM2 DoDAF model diagrams. Note the PES for draft v2.03 has not been generated as we complete all QA first. The PES generation is planned for 10 February.
  8. “The example at the end of this report still discusses an earlier version of the DM2 model and will only be updated once there is a new baseline. It still, in its current form, serves as an example of what a set based use of the DM2 meta-model would look like however.”
    RESPONSE: Thank you. This could be a good submission for the DoDAF Journal. However, if the example is to have lasting community-wide utility, it will need to be updated once v2.03 is baselined.
  9. “During the time between the last version of this report and this version, work on the creating an IDEAS based version of MODAF 1.2.004 has been performed by the Swedish Armed Forces with the aid of the original IDEAS foundation designers from the UK as well as the author of this report. While not complete as yet (the completion project has just started and is expected to be completed during the spring of 2012) this work has yielded a model significantly different from DoDAF 2.0, especially as regards the use of the IDEAS foundation. The differences are major and some of the overall questions that result from this work are listed at the end of this executive summary.”
    RESPONSE: See answers to the referenced questions below (paragraph 2.3, herein) and with regard to IDEAS integration in paragraph 2.8, herein.
  10. “The detailed analysis of the latest model indicates that there are a set of issues that need to be considered in addition to the issues identified in the summary above. These are listed in the table below:”

Table 1. MODEM Report’s Summary Comments
Elements affected DM2 111228 / Issues and/ or comments / DoDAF Team RESPONSE
BusinessService / This is a new element. It is a subset of service but also it seems a subset of activity. This is strange and needs further clarification. When dealing with services in various examples there is a need to distinguish between the ones that are shown as being used within a logical setting and one used within a solution type setting. This could conceivably be an embryo of this need. Since Business service is also a subset of activity, there would have to be some means to distinguish the sets within activity that are also a kind of service. The same instances would then also have to appear as part of Service. This seems to need further work. The definition for this is: The class representing a Business Service and subtype of Service and Activity. Using the word class here may be misleading and should in the view of the author of this report be changed. / Tentative, still awaiting WG confirmation and Component review. Arises from software uses of the term “service” and OASIS and DoD Net Centric Services Strategy use in a broader sense.
EnablingService / This element seems to have taken the place of the previous Service in 2.02 which was a subset of system. It is defined as: The class that represents an Enabling Service and a subtype of System.
There is no connection between service and enabling service something that would seem to be required if services are to be treated in accordance with general SOA concepts. / Same a business service.
EnablingServiceActivity / A Service function for an enabling service? Both EnablingService and BusinessService are subtypes of Activity. EnablingService however have EnablingServiceActivities that it can perform via a specified relationship. Why is there a difference? / Same as business service.
PerformerCapableOfResponsibility / This element has made a reappearance but only seems to exist at one level, it has no counterpart at the type type level or at the individual level. There is therefore a need to discuss whether this needs to be added. / Draft material to address that not all Performers can desire.
Activity / Activity is a powertype of IndividualActivity: the set of all IndividualActivities with a spatial temporal extent. The powertype is then the set of all possible subsets of the individual activities contained in the set of Individual activities. Obviously some of its instances can be regarded as essential categories of activities, i.e. activity types. The definition of a powerset also means that the set includes sets that are of no interest. This can be exemplified easily, assume the following activities as instances of the set IndividualActivity: ProjectManagementForProjectX (PMFPX), ProjectManagementForProjectY (PMFPY), ConfigurationManagementProjectX (CMFPX), ConfigurationManagementProjectZ (CMFPZ). These 4 individual activities create 16 different instances of the activity set, however two of those instances can be viewed as categories PMFP={PMFPX, PFMPY} and CMFP={CFMPX, CFMPZ}.
THis also implies that it is actually a subset of this powerset that a modeler should be using not the powerset itself. The powersets are to be considered as set theoretic plumbing nothing more and should not be used by any modeler. / We are well aware of this late-breaking change in IDEAS and are not prepared to introduce this degree of formalism and complexity at this time. Current structure is workable because most implementers are not concerned with the formality of powertype, merely that it indicates the source from which the instances of the types are to be drawn.
ActivityType / This is a powertype of a powertype, i.e. the set of all subsets of a set of all subsets of the set of Individual activities. Taking the above example this would yield a set of 2^16=65536 instances where each is a set of sets of the form exemplified below:
If the individual activity set contains {a, b}, the activity set contains {x={a}, y={b}, z={a, b}, t={}}. The next level (ActivityType level) contains instances of the following form { {x}, {y}, {z}, {t}, {x, y}, {x, z}, {x, t}, {y, z}, {y, t}, {z, t}, {x, y, z}, {x, z, t}, {x, y, t}, {y, z, t}, {x, y, z, t}, {} } i.e. { {{a}}, {{b}}, {{a, b}}, {{}}, {{a},{b}}, {{a},{a, b}}, {{a},{}}, {{b},{a, b}}, {{b},{}}, {{a, b},{}}, {{a}, {b}, {a, b}}, {{a}, {a, b},{}}, {{a}, {b}, {}}, {{b}, {a, b}, {}}, {{a}, {b}, {a, b}, {}}, {} }.
It is considered highly questionable whether anyone will be able to have any use for instances at this level of abstraction at least for this purpose. / See above on powertype.
Capability / Capability is now a subset of Property which makes sense. It is still a set of sets where the instances are those sets of instances that contain something that is capable of achieving something specific. As an example an instance of the capability set could be the set containing all cars capable of achieving more than 300 km/hour speeds (i.e. a dispositional ability). The instance of this set would in turn be individual cars having this possibility. / Made in conjunction with IDEAS meeting October 2010.
CapabilityType / This is the set of all subsets of a set of sets and a subset of this set could be viewed as capability categories. It should be noted that the need for its use solely depends on how the modeler chooses to deal with this. A category could for instance be Speed capabilities and this set would then contain all set of sets that are associated with speed abilities. This would then be a set of sets where each instance would be a set of all sets that deal with speed capabilities, i.e. the 300 km/hour speed would be one of this sets. A similar set can however be created at the lower level where the set would contain all sets of individual instances associated with speed of any kind and here a subset of this set would be the 300 km/hour set discussed above. / Current informal and v2.03 guidance is to use higher-order types only if there is no other way to accomplish otherwise. This IDEAS guidance was obtained October 2010.
DomainInformation / This is an example of elements that by and large originate from Information, i.e. where the individuals are individual utterances of the piece of information. The definitions of all of these do not necessarily distinguish the different sets from one another in a clear manner. / Valid CR but not causing problems at this time.
IndividualActivity
Connectors:
Generalization (element - is a specialisation of): «IDEAS:superSubtype»
IndividualActivity - Individual
Dependency (element - is instance of): «IDEAS:powertypeInstance»
IndividualActivity - Activity
Dependency (element - is instance of): «IDEAS:typeInstance»
IndividualActivity - SingletonActivity / The set of all individual activities that have a spatio temporal extent.
SingletonIndividualType is a subset of IndividualType as well as Singleton and is a set of sets where the instance sets only contain a single individual instance. Singleton contains all sets that contain a single instance, these however may not just be individuals but could be other sets. Singleton Activity then becomes the set of all sets where the instance set contain a single activity. If the Individual activity set A={a, b} then Activity contains PtA={ {a}, {b}, {a, b}, {} }, i.e. A is an instance of PtA. In order for SingletonActivity to have IndividualActivity as a typeInstance it would have to contain { {a, b} } and since the instance set contains more than one instance this would seem to be a problem, indeed SingletonActivity would seem to contain SA={ {a}, {b}, {} }. It would therefore seem that the typeInstance relationship between IndividualActivity and SingletonActivity is wrong. / See above on powertype. However, comment noted and we will implement a consistent approach.
IndividualPersonRole / This element is defined in the following manner:
Person roles defined by the role or roles they share that are relevant to an architecture. Includes assigned materiel.