General. It would seem we need to better explain how the DM2 works in a few areas:

  1. TemporalWholePart, States, and sequences. It probably doesn’t’ jump off the page that Activity, Performer, … are actually states. That’s because DM2 / IDEAS employs 4-dimensionalism. So you can define temporal parts to as fine a level as needed. With that and beforeAfter, you can create any kind of behavior, state transition, etc. model.
  2. Precision. Because of the inheritance of wholePart, temporalWholePart, etc. from the foundation, the data can be as precise as needed. The DM2 appears high-level because it has so few parts. But that’s just because it’s mathematical and there aren’t that many mathematical primitives applicable to DoDAF. Further, the few parts can be composed in a dizzying number of combinations; the few parts allow for large combinatoric possibilities.
  3. CM. We envision CM of the DM2 at the DoD CIO for common core elements only. Extensions, in particular, symbology and common lists / controlled vocabulary / etc. we see as being federated.

NDIA Recommendation / Recommended DoD CIO Response
1 / Establish the industry standard architecture modeling language, the Unified Modeling Language (UML) and its systems engineering extension, the Systems Modeling Language (SysML), and the future DoDAF extensions to these languages, the Unified Profile for DoDAF and MoDAF (UPDM) as the standard architecture modeling methodology for more efficient DoDAF architecture development and maintenance. / UML/SysML may not be the preferred methodology for the other 5 core processes. If it is the preferred methodology in DoD for Systems Engineering, then perhaps a Systems Engineering instruction, guidance, or standard ought to be promulgated.
2 / Extend the DoDAF meta-model with the common set of standard architecture elements being developed by the Services and the Joint Forces Command to permit more standardization of architecture models. / This could involve adding many thousands of classes to the DM2.
1. We were thinking these would be "instance values" in a DM2 database or DM2-conformant tool. Adding them as classes means they'd by tags in the XML, but I think you probably want them to be values tagged as Activity, System, etc.
2. The DM2 CM process is not the correct process for managing these. The Navy has their own process for the NAERG as does JFCOM for the JCSFL.
3. By DM2 development and maintenance rules, the subclasses need to have some sort of structural difference from the super; otherwise, they're the same. This mathematical rule (a variation on Leibniz's rule) is good at the DM2 level but be too difficult to follow at the common lists levels which tend to be more langauge-oriented.
3 / Extend the all-important Performer element of the DoDAF meta-model with the semantics of the hierarchical state machine and add more definition of the Activity element, thereby permitting greater architecture behavior modeling and enabling execution/simulation of DoDAF architecture models. / DM2 Action Item # 199, State Machine Example in DM2, Nov 2008. However, the diagram provided shows a state machine is a part of a Performer that has parts States and Transitions. Perhaps we haven't emphasized enough in the documentation, but Performer is a state and as an Individual Type, it has temporal parts. (DM2 and IDEAS employ 4-dimensionalism as a foundation concept.) Are there examples of Performers that don't have temporal states and transitions?
4 / Extend the DoDAF architecture model exchange mechanism, the Physical Exchange Specification (PES), to include specification of diagrams for exchange and standardize the DoDAF Architecture Registry (DARS) on the PES for greater reuse and sharing of the DoDAF architecture models (or standardize DoDAF modeling to use the UML/SysML/UPDM, as recommended above, and use this standard's XMI exchange format which already incorporates diagram exchange). / 1. DARS isn't a repository anymore so it isn't clear what is meant by "standarize DARS on PES."
2. MOF tools are a subset of EA tools and data sources across the 6 core processes DoDAF supports. Within that tool sphere XMI is already a OMG standard. Our recommendation to the UPDM team has been to exchange XMI with MOF tools and PES outside that since PES is much simpler to parse-into and generate-from non-MOF tools and data sources. I don’t think anyone would expect a non-MOF tool or data source to make the large investment to parse and generate XMI. The view we’ve discussed many times with UPDM team is summarized in the following diagram.

5 / Expand the PES and the DARS to include specification, registry, and storage of architectural patterns, frameworks, and fragments, in addition to complete architecture models for greater reuse and sharing of architecture models within the DoD. / If I understand the recommendation, I think this is why we added the “comprehensive” XSD, to allow for “fit for purpose” exchanges, including fragments. (See above about DARS.)
6 / Add an "abstraction" relationship to the DoDAF meta-model to enable relating a more abstract architectural element to one-or-more less abstract elements, thereby supporting modeling of architectural abstractions. / We could do a better job of explaining how this works in DM2. The following diagram was developed after publication of 2.0 to explain how John Zachman’s “reification levels” worked in DM2. It is planned to be included along with explanation, in an errata. We’ve gone over this with UPDM team and in developer / integrating outreach briefings and it seems to work well.

7 / Add a "Computable Measure" element to the DoDAF meta-model that can be used to define computational metrics of architectures for use in quantitative analysis of architectures / We were advised by JFCOM and JTEM reps to not try to develop a Measures taxonomy. However, computable measure could be handled in a couple of ways and we should discuss more to figure out the right way. One way might be as part of the Rule that is part of the Measure Type. Another might be through Pedigree. The Pedigree way is more powerful in that the Rule followed in deriving the computed measure could be carried in the Pedigree. So there would be Rule specified, and then a Rule followed.
8 / Establish the Software Engineering Institute's Systems and Software Architecture Trade-offs Analysis Method (ATAM) as the standard method for DoDAF architecture analyses of alternatives.
9 / Establish the industry standard UML/SysML notation as the standard notation of DoDAF architecture models for greater common understanding and communications of formal architecture models.
10 / Add a "Symbolic Representation" element to the meta-model, perhaps as a specialization of the Representation element of the foundational meta-model, to permit specification of symbols or icons that can be used to symbolically represent an architecture element in model diagrams. / See DM2 TWG Action Item 389, “OV-1 graphic in XSD”, Aug 2009. The way the TWG fixed was by using RepresentationScheme to say what kind of representation it is. Also relates to aligning DM2 description, naming, and representation pattern with IDEAS (Action Items 367-370.)
11 / Establish a standard symbols library, perhaps akin to the DoD Metadata Registry, to provide a standard symbology for DoDAF architecture models. / Tried this in CADM but CM at the DoD CIO level was too cumbersome. Suggest federated CM, with OSD providing top-level, as in the federated architecture roadmap.
12 / Add a "Type Extension" to the DoDAF meta-model that will permit architecture stakeholders to extend an element of the architecture model with custom information which can be used in generating parts or all of a variety of architecture artifacts such as documents, specifications, trace matrices, program plans, and architecture briefings. / There is a Dublin Core element in the XSD that might be useful for this purpose. Because the DM2 represents “real world” entities, adding tagged values could be problematic. For example, in what sense is System Extended a subset of System? Or how is a Budget Tagged Value a spatio-temporal part of a System Extended. We understand they might be information parts of a System Extended report, but that is not what DM2 modeled. In fact, the TWG was very careful to distinguish between representations of “real world” entities and representation of information or representational entities which are indeed real world too, but they themselves are representations. So the DM2 represents representations too but we try to be careful in not mixing representation of something with representation of representations of those things.
13 / Establish a standard reporting and scripting facility that can be used to auto-generate these artifacts from the information contained in the DoDAF architecture model.

Questions on Report

  1. “While the generality of the DoDAF meta-model (DM2) enables its broad applicability to architecture modeling, it tends to reduce the ability to use the meta-model for specific and more detailed definition of particular architectures. To the extent semantics of the meta-model are so general, architecture models requiring more specific definition tend not to be supportable by the meta-model in terms of being standardized for common understanding and reuse.” The DM2 is a mathematical model, not a dictionary. However, the DM2 TWG would be interested in more detailed mathematical definitions and distinctions if some can be provided.
  2. Events are in the alias list, not the model. Event was in the model as a zero-duration activity but then the TWG observed that meant it was not really a distinct concept. The TWG researched and revisited Event many times, always with the same conclusion. If some new material can be brought to the TWG on why, mathematically, an Event is distinct from an Activity, that would be good. There is an Events research folder on the DM2 collaboration site.
  3. Mission and Strategy are in the alias list. Again, if mathematical distinctions can be provided, the TWG would be glad to look at them.
  4. The DM2 was used to revise the NAERG. To date, it has had all the relationships between elements needed.
  5. BTA performed an extensive mapping of the BPMN to DM2. It is in the BPMN references folder on the DM2 collaboration site.
  6. We can show you how Synch, Join, Fork, and Action are all achieved using temporalWholePart and beforeAfter. A decision is an Activity, takes inputs (the decision data) and transforms then to outputs (the decision).