Addressing Common Obstacles to Digital Engineering

The Problem of Parallel Teams

As defense organizations have moved to digital engineering, many have found themselves saddled with an unexpected obstacle. Instead of a single team of engineers collaborating on the digital model, two parallel groups have sprung up, each working on the model in different ways.

System Engineers: Resistance to Digital Tools

Typically, one group consists of system engineers who aren’t comfortable with the tools used to build digital models, such as those without formal systems engineering training. In the early stages of digital engineering, the tools were often cumbersome, confusing, hard to learn, and hard to use. 

Many system engineers, though they saw the theoretical value of digital engineering, were daunted by the tools, questioning whether they were truly practical. They found that it often took just as long—if not longer—to develop systems digitally as it did using the older paper-based methods.

System Architects: Personal Preference Dictates Process

The other group in the parallel setup consists largely of system architects, along with some system and software engineers who are more comfortable with the unified modeling language (UML)-based tools. System architects have generally made the transition to digital engineering more easily, as many of the digital tools evolved from system architecture tools which they were already using.

However, there is often little consistency in how the system architects actually use the tools. Processes may be dictated by personal preferences rather than rigorous methodology. For example, different architects may work on the same digital model with different tools, and in different ways.

Inefficient Together: Manual Digital Engineering Workflow

The system architects and system engineers work together to create and modify digital models—but in an inefficient way. Typically, the system architects go to the system engineers, get their input manually, and then enter it into the tools. This parallel-team approach is usually an ongoing, iterative process, and the back-and-forth takes so long that the time savings of digital engineering often is almost entirely lost.

At the same time, since there’s no standard approach to using the tools, the models may be replete with inconsistencies and even errors that can take time to discover and sort out. Such flawed models often make system engineers even more distrustful of the tools—and the digital process in general—further entrenching the model of parallel teams.

Removing the Obstacles

In recent years, digital engineering has been moving past what might be thought of as its awkward stage. Today’s digital tools are far more user-friendly, intuitive, and efficient than in the past. At the same time, cloud-based approaches are making it much easier to integrate formerly siloed digital models and environments. 

This enables system engineers, system architects, and others to seamlessly share their work. Despite these improvements, however, many defense organizations still find themselves mired in parallel teams and the inconsistent use of tools.

Fortunately, there is a way out of this morass. By being strategic about why and how they want to use digital engineering, chief engineers and program managers can bring their disparate teams together, with everyone working with the same tools and toward a common purpose. Effective digital engineering strategies include:

Mature Use Case Strategy

One of the chief reasons many system engineers balk at using digital tools—and why many system architects use them inconsistently—is that no one is quite clear about how the digital models will be used. For example, if system engineers aren’t sure what data needs to be captured and what doesn’t, they don’t know how to use the tools. And if system architects don’t have consensus about what the digital model should look like, they’re likely to go about building it in haphazard ways.

One of the first steps is to gain clarity about how the digital models will support the specific goals of the organization and the mission. Organizations then need to ask questions, such as, What information should be captured to achieve those goals? How should it be analyzed? How should the information in digital models be used to inform decision making?

Mature Tool Strategy

As digital engineering has grown, so has the variety and number of tools. With so many options, many system architects and engineers have found it difficult to make sure they’re using the right tools in the right ways. 

For example, it’s not uncommon for organizations to use tools that aren’t compatible with one another—which often requires time-consuming manual data exchanges between tools. Or, organizations may use tools that are too complicated or data-intensive for the job, making things even more daunting for the system engineers. 

With a mature tool strategy, organizations can make sure they’re using digital tools appropriately and consistently, and in the best ways for system architects and engineers alike.

Consistent Lexicons and Taxonomies

Another common problem is an inconsistent approach to information used by the model. Different system architects, for example, may vary the order that data is presented, or use different lexicons and taxonomies for the same information. 

This can cause confusion, errors, and the need for time-consuming rework, such as when the same information is inadvertently captured twice—in two different ways—or when some measurements in a model are presented in metric and others in imperial, so it’s unclear whether the numbers are in centimeters or inches. Consistent lexicons and taxonomies keep everyone on the same (digital) page.

With strategies such as these, defense organizations can begin to break down the parallel-team paradigm and make sure that system engineers and architects alike are developing digital models in the most consistent and efficient ways. This clears the way for the defense community to get the full power and potential of digital engineering.

Learn more about our digital engineering capabilities.