Written by Nathan Hartman

Digital Engineering in the DoD: 4 Takeaways from an Expert in Model-Based Enterprise

In June, the Department of Defense (DoD) released their digital engineering strategy document. As defined by the DoD, digital engineering is an integrated approach that uses “authoritative sources of system data and models as a continuum across disciplines to support lifecycle activities from concept through disposal.” In simpler terms, a digital engineering strategy means that the DoD will leverage digital, model-based product and process data during a product’s lifecycle–from design, to production, to maintenance, to disposal–rather than 2D drawings or other paper-based data.

The DoD predicts enormous cost-, time-, and resource-savings benefits by switching to digital. I’ve seen firsthand how important it is to work in a digital 3D format rather than a paper-based approach. I’ve been involved with product lifecycle management methods and tools for many years, first in industry and now as a researcher and professor at Purdue University and as director of Purdue’s Digital Enterprise Center. My experience in the private sector proves to me that the DoD can absolutely experience the anticipated benefits – and possibly more.

A digital engineering strategy means that the DoD will leverage digital, model-based product and process data during a product’s lifecycle–from design, to production, to maintenance, to disposal–rather than 2D drawings or other paper-based data.

Nathan Hartman

Reading through the full document, I couldn’t contain my excitement for the DoD’s step forward in digital engineering. However, transitioning to digital engineering isn’t a nicely packaged, step-by-step process. It’s iterative and a little bit messy. Having researched digital engineering (or model-based enterprise as it is known in industry) for many years, I know firsthand that there are many nuances to recognize and address in order to have a smooth transition. My four takeaways from the strategy document outline what to watch for during the transition.


When thinking about transforming to a model-based enterprise (MBE) or digital engineering strategy, it can be easy to focus on the design portion of a product’s lifecycle. Typically, you see an emphasis on design and development without considering actual deployment and maintenance. This focus has happened over the years because the design role is often responsible for creating the information artifacts used by other parts of the organization. These artifacts, often called model-based definitions (MBD), are 3D CAD models with embedded dimension and notation information. An MBD takes the place of traditional 2D paper-based drawings in the communications process.

It is important to acknowledge that the lifecycle portion beyond acquisition hasn’t been fully developed.

Nathan Hartman

The DoD avoided the exclusive focus on design by putting together a holistic plan that addresses full implementation, flowing from design through disposal, seen in Figure 1 below:

DoD's Plan

That being said, this graphic is a bit too simplistic. Visually, the DoD seems to place the same amount of emphasis on every step of the process. While visuals don’t always reflect the actual plan, the DoD affords acquisition (or design and development) more space in Figure 1than operations and sustainment of the end product.

But, that’s not the way it works in a product’s lifecycle. These platforms or systems are in use for years – sometimes even decades. If we were to look at this graphic in terms of representing an actual timeline, the “Operations & Support” section would extend way, way off the page. It is important to acknowledge that the lifecycle portion beyond acquisition hasn’t been fully developed. Both sides need to come together to create a truly holistic strategy and policy.


My favorite part of this announcement? We are talking about models and not drawings. But the fundamental differences between a digital and traditional enterprise goes beyond 3D digital modeling versus 2D drawings primarily on paper. A digital engineering approach brings together a whole host of complexities, such as new technologies, different data types, and different communication and business methods. Many individuals affected by a strategy like this may not be up to speed. The DoD needs to make sure they fully understand how much the employees’ workflows will change and help smooth the transition to enable users to continue collaborating efficiently.

Now, take the new complexities associated with internal collaboration and combine them with the effort of collaborating with OEMs and suppliers for different product iterations. Some DoD partners have already gone digital, some are just now implementing, and some are still paper-based. No two companies will use the exact same set of digital tools to design a product. It’s up to the DoD to find a way to collaborate efficiently with their OEMs and suppliers while managing internal collaboration processes.


Continuing from my previous takeaway, companies historically focused on 2D, paper drawings and documents because those were the tools of the time. Engineers provided their data to collaborators by physically handing them the drawing or sending it through the mail. As you might expect, recognizing insights and making decisions isn’t easy with this process.

It’s up to the DoD to understand how to manage the additional data without drowning in excess information.

Nathan Hartman

Now that both the DoD and many of their partners are moving towards digital engineering, that opens the door for a different type of data – and a lot more of it. Partners who have been working with MBE data for a while will have the opportunity to start providing more and more information during external collaboration as the DoD comes up to speed on their digital engineering efforts.

The DoD must have a very targeted understanding of how data accessibility and visibility will radically change their approach to doing work. Both the partners and the DoD will gain access to more data during a product’s lifecycle. It’s up to the DoD to understand how to manage the data without drowning in excess information. Furthermore, the DoD will also need to accurately express their needs for digital product data through the contract development and execution stages with their suppliers.


Reviewing the documentation, I am encouraged with how frequently the DoD references the model as an “authoritative source of truth.” I am also pleased that the DoD didn’t use the phrase “single authoritative source of truth.” The notion of singularity in this space is next-to-impossible to achieve in practice. Instead, organizations should strive to minimize their authoritative sources of truth.

Ideally, a model-based product definition would be dynamic. A user would use an editing tool to repurpose the model to make it the authoritative source of truth for their specific needs at the time. While this can be done in some ways with today’s CAD tools, not everyone looks at a model the same way or has the same needs and objectives when accessing model-based product information. We are all authors and consumers of information, and what’s authoritative and truthful to you may not be authoritative and truthful to me.


Overall, I commend the DoD for making this next step forward in product development and support. I predict that their biggest challenge may be internal culture changes. People are the crux of the matter, and how they accommodate to changes will ultimately dictate a smooth or bumpy transition. The DoD will need to be diligent and open-minded to ensure they don’t get caught up in the iterative process of transforming to digital engineering or lose sight of their employees’ information needs.

I predict that the DOD’s biggest challenge may be internal culture changes.

Nathan Hartman

Ultimately, I believe the adoption of model-based methods, tools, and data will lead to systems and processes that are more easily sustained in the long-term, which leads to increased savings for the DoD, supplier partners, and the public. I look forward to seeing how this impacts the future of our defense systems and the product lifecycle in both the public and private sectors.

About Nathan Hartman

Nathan Hartman is the Dauch Family Professor of Advanced Manufacturing and Department Head of the Department of Computer Graphics Technology at Purdue University, and Director of the Purdue University Product Lifecycle Management (PLM) Center. Dr. Hartman is also Co-Executive Director of the Indiana Next-Generation Manufacturing Competitiveness Center (IN-MaC). Professor Hartman’s research areas include the process and methodology for creating model-based definitions; examining the use of the model-based definition in the product lifecycle; and developing the model-based enterprise. Professor Hartman’s industry research partners include Rolls Royce, Cummins, Boeing, GM, Rockwell Collins, Textron, Gulfstream, Procter and Gamble, GM, Honda, and others. For more information, visit https://polytechnic.purdue.edu/profile/nhartman.