By Dr. Hiren Patel, U.S. Air Force Institute of Technology Data Science and Model-Based Systems Engineering Instructor
As the United States military adapts to prepare for the Great Power Competition (GPC) with near-peer powers such as China, it has become increasingly clear that it needs to accelerate the development and delivery of new capabilities. In the whitepaper titled, “An Accelerated Future State,” General “Duke” Richardson, Commander of the Air Force Material Command, states that China delivers a major weapon system on average in seven years, compared to sixteen for the US. This will eventually put the US at a disadvantage as GPC competitors outpace the US.
A key tool for delivering the acceleration we need lies in Digital Material Management (DMM). By using modern digital tools through every aspect of the acquisition lifecycle, efficiencies can be realized that can help drive down delivery schedules.
Modern weapon systems are enormously complex, with teams of thousands of professionals working across multiple geographic sites. Information is siloed at each of these nodes in the form of presentations, reports, and spreadsheets of different versions and histories. This leads to outdated program knowledge and wasted labor hours trying to synchronize data. DMM aims to fix that by storing the most current version of any given data in a central repository, so that all members of the acquisition team use the data.
Benefits go much beyond data synchronization. Requirements can be updated with DMM and linked to system components, and test results can be incorporated to verify that these requirements were met. These can be updated in real-time as tests are conducted. Program deliverables can be incorporated into the program’s digital model, improving accounting and accessibility.
DMM boosts the drive for Modular and Open Source (MOSA) solutions by allowing program managers and engineers to digitally test very large combinations of options for system components through simulation before any physical components are purchased or manufactured. Leaders can now predict program success or identify potential pitfalls during the planning phase when errors are cheaper to fix.
As with all things in life, great benefits don’t come free. Having such a powerful tool can also mean a very complicated tool. As an instructor of Model-Based Systems Engineering (MBSE) at the Air Force Institute of Technology, I’ve taught hundreds of students who work on dozens of programs across the DoD. Universally they worry about the feasibility of adoption of DMM tools by the program workforce.
Major weapons systems such as the F-35, B-21, and B-52 take the joint power of thousands of individuals to get them successfully acquired, tested, fielded, and sustained through their lifecycles. Is it realistic to expect each of these individuals, experts in their respective fields, to learn to use these complex DMM tools and their associated digital modeling languages?
The Subject Matter Expert (SME) who trained me at my first job in the military was the best test engineer in our squadron. She knew the F-16 inside and out, how to handle in-flight emergencies, put together a test plan and test report, and command a control room. If I were to ask her to use DMM tools, she would say, “Lieutenant, why don’t I give you the test results, and you enter them into your fancy model?”
Her priority, rightfully, was to get the test planned and conducted correctly. She, and the majority of the acquisition workforce, would not welcome having to learn the nine diagrams of the SysML model in MBSE or learn about Monte Carlo analysis tools. And she shouldn’t need to.
To improve DMM adoption, we need to meet these professionals where they’re at by noting what they are currently using to capture the product of their efforts. A test engineer produces test plans, cards, and reports, a Contracting Officer’s Representative (COR) reviews program deliverables such as spend plans and schedule projections, and engineers review program requirements and contractor-proposed solutions. Under this proposed solution, the system modeler should tailor a view specific to each role.
For example, for the test SME, build a view that contains only links to instance tables where she can input test plans and link them to system capabilities, and where she can enter test results that validate those capabilities. In this way, the test SME is not overwhelmed with information on the rest of the program model that may not pertain to her regular functions. She doesn’t need to know the principles of MBSE or which one of the SysML diagrams has the information she needs. Also, by making this tailored view in a format similar to what she is accustomed to, her pace of adoption would further improve.
These views can be tailored for other job roles as well. For the COR managing deliverables of a contract, give them a view that shows them a table that tracks when each was delivered and associated data, and a table for entering new cost and schedule updates. These would be familiar to the COR as these tables are similar to what they already use. While I’ve only mentioned a few duties for each role here, their other inputs can similarly be captured through different tailored views.
To be clear, these custom views go beyond the views presented in Architecture Frameworks such as the DoD Architecture Framework (DoDAF) and the Unified Architecture Framework (UAF). While those frameworks present different views of the system for operations, standards, data, capabilities, and other areas, the solutions proposed in this writing are more tailored and can combine or filter the information contained in different views of the DoDAF and UAF. Indeed, the DoDAF outlines “Fusion” and “Composite” views that approach the tailored view concept presented here.
Tailoring for a job role takes time and effort. It also requires a DMM SME to craft different views from the larger complete model. However, consider the time lost if this work is not done. The majority of the workforce that supports a system acquisition may refrain from using the model or take much longer to learn to use it. Further, it may add to their already full workloads. Tailored views do not need to be fine-tuned to individuals but can be created per job role, thereby applying to a subgroup of individuals and can be used across programs.
Lowering the “scare factor” of digital models by partitioning them to more digestible and familiar views will also lower distrust that is usually generated from getting “yet another tool” from management to use. If model views are painless to use, that will push for culture change toward adopting DMM from the ground up, increasing the chances of these models becoming true “authoritative sources of truth” as all new and relevant information from across the program gets captured by those generating the data.
DMM models are excellent tools to capture the authoritative source of truth for a system. However, without input from the program personnel, they will remain empty shells devoid of data. It is imperative that we change the culture of the entire workforce to use DMM models so that all information is captured, and tailoring model views per job role can be a key tool to get there.
Disclaimer: The views expressed are those of the author and do not necessarily reflect the official policy or position of the Air Force, Space Force, Department of Defense, or U.S. Government.
Related Blogs: