Naval Digital Systems Engineering Transformation Strategy

Elephant 1: SysML is not the center of the modeling universe. SysML supports system architecture descriptions, that is its role in the modeling practice. Quoting from the OMG SysML specification - "a general-purpose modeling language for systems engineering". UML supports software definition, UTP supports test system description and definition, etc... Too many practitioners treat SysML as the proverbial 'Hammer' and thus treat all things to be modeled as 'Nails'. The extensive family of UML profiles exists for a reason. Use the right tool for the job.

Elephant 2: "Single Source of Truth" is a misnomer! A "Digital Twin" requires numerous federated models to address the multitude of domains required to specify it. A matter of selecting the right tool for the job. Next is the federation of these models. It can be an expensive undertaking requiring a viable execution strategy across the DoD. Proprietary Point-to-Point adapters will be unsupportable in the long term. Just as modeling and simulation within the DoD was brought under a unified point of control at the Modeling and Simulation Enterprise (formerly the Modeling and Simulation Coordination Office) in 2006. Similar strategy of unification, curation, and quality control is required in support of Digital Twins. Quality models are expensive to produce and maintain. Model libraries are a must!

Elephant 3: Model security classification and portion marking issues. Classified systems are problematic in support of reuse and centralized control. Does a central configuration managed profile exist supporting security classification portion marking?

Elephant 4: There is no single source of SysML and modeling knowledge. If the only texts that have been read are 'A Practice Guide...' or 'SysML Distilled' much more reading is required. Read papers about ontology, taxonomy, OOA & OOD. Read the OMG UML & SysML specifications. Read the early texts written by the inventors of UML (Booch, Jacobson, Rumbaugh). My reading list is quite long. Some authors worth reading: Wymore (Model-Based Systems Engineering Chapter 1 on Google Books), Guizzardi (Ontology), Micouin (System, PMM & PBR (NOT SysML PBR)), Weilkiens (UML & SysML modeling, Architecture), Douglass (UML & SysML modeling). To name just a few.

Elephant 1: SysML is not the center of the modeling universe. SysML supports system architecture descriptions, that is its role in the modeling practice. Quoting from the OMG SysML specification - "a general-purpose modeling language for systems engineering". UML supports software definition, UTP supports test system description and definition, etc... Too many practitioners treat SysML as the proverbial 'Hammer' and thus treat all things to be modeled as 'Nails'. The extensive family of UML profiles exists for a reason. Use the right tool for the job.

Elephant 2: "Single Source of Truth" is a misnomer! A "Digital Twin" requires numerous federated models to address the multitude of domains required to specify it. A matter of selecting the right tool for the job. Next is the federation of these models. It can be an expensive undertaking requiring a viable execution strategy across the DoD. Proprietary Point-to-Point adapters will be unsupportable in the long term. Just as modeling and simulation within the DoD was brought under a unified point of control at the Modeling and Simulation Enterprise (formerly the Modeling and Simulation Coordination Office) in 2006. Similar strategy of unification, curation, and quality control is required in support of Digital Twins. Quality models are expensive to produce and maintain. Model libraries are a must!

Elephant 3: Model security classification and portion marking issues. Classified systems are problematic in support of reuse and centralized control. Does a central configuration managed profile exist supporting security classification portion marking?

Elephant 4: There is no single source of SysML and modeling knowledge. If the only texts that have been read are 'A Practice Guide...' or 'SysML Distilled' much more reading is required. Read papers about ontology, taxonomy, OOA & OOD. Read the OMG UML & SysML specifications. Read the early texts written by the inventors of UML (Booch, Jacobson, Rumbaugh). My reading list is quite long. Some authors worth reading: Wymore (Model-Based Systems Engineering Chapter 1 on Google Books), Guizzardi (Ontology), Micouin (System, PMM & PBR (NOT SysML PBR)), Weilkiens (UML & SysML modeling, Architecture), Douglass (UML & SysML modeling). To name just a few.

Geoffrey, great points. Some add-ons to your elephants:

Elephant 1: Totally agree. I would further say that, while all system architectures are system models, not all system models represent system architectures. SysML is a great modeling language, but it is actually not that good with many aspects of systems architecture. As you say, I have also found that many folks treat the Systems Modeling Language as if it would be the Systems Engineering Language... and in many cases this leads, in my opinion, to significant problems.

Elephant 2: I believe that the community is finally opting for the term "Authoritative Source of Truth" over "Single Source of Truth." While originally the "Single source" was appealing because the apparent benefits in terms of information consistencies, having a single source of information has problems associated with it. For one, incredibly vulnerable...

Elephant 4: The descriptions out there for SysML are strongly confounded with descriptions of systems engineering approaches. This leads to problems of confusing the power of the language with the suitability of its usage. I find that, in general, good references for the language provide poor examples of SE practice. So, I agree, deep and diverse reading is instrumental. Wymore and Micouin essential, in my opinion, to make good use of SysML.