Digital Engineering: Before the Software, There Is Engineering

Some concepts enter the market together with a genuine transformation. And then an almost inevitable phenomenon follows: before long, specialists, methodologies, presentations, platforms, courses, consulting services, and an ever-growing collection of acronyms begin to appear.

Digital Engineering has been no different.

But it would be a mistake to begin this discussion by criticizing what Digital Engineering actually proposes.

Because the proposition is sound. Very sound.

Perhaps the real problem begins when an idea this important risks being reduced to the tools used to implement it.

So what does Digital Engineering actually propose?

The first distinction is fundamental:

Digital Engineering is not software.

Strictly speaking, an organization does not “install Digital Engineering.” It can acquire platforms, modeling systems, collaborative environments, simulation tools, requirements-management systems, databases, product lifecycle management systems, and many other technologies.

But Digital Engineering is something broader.

One definition adopted by the United States Department of Defense, for example, describes Digital Engineering as an integrated approach that uses authoritative sources of data and system models continuously across disciplines and throughout the lifecycle.

Its objectives include using models to support decisions, maintaining reliable sources of information, incorporating new technologies, creating collaborative environments, and transforming organizational culture and professional capability.

In other words, its essence is not the more impressive drawing, the three-dimensional model, or the dashboard.

It lies in the quality, integration, and continuity of engineering information.

The acronyms have a purpose — and an important one

One of them is Model-Based Systems Engineering — MBSE.

The idea is to progressively move away from engineering that is excessively centered on disconnected documents and toward models capable of supporting requirements, design, analysis, verification, and validation throughout the development and lifecycle of a system.

There is also Model-Based Definition — MBD — in which the digital model carries technical information that previously depended on several separate documents. In manufacturing applications, for example, product-definition information can follow design, manufacturing, and inspection.

Another fundamental concept is the Digital Thread. It may be one of the most interesting ideas in this entire field.

Its purpose is to preserve information continuity across different lifecycle stages, connecting design, analysis, manufacturing, inspection, operation, and support.

Then comes perhaps the most widely recognized expression of all: Digital Twin.

Here, the objective is to establish a digital representation of an asset, system, or process that maintains a meaningful relationship with its physical counterpart.

Around these concepts there may also be Product Lifecycle Management platforms, requirements management, BIM in applications related to the built environment, multiphysics simulations, integrated databases, configuration systems, cloud collaboration environments, field sensors, data acquisition, statistical analysis, artificial intelligence, and many other technologies.

So this is not an empty idea.

It is a technically consistent movement toward making engineering cease to exist as a succession of disconnected documents and instead operate through models, data, and relationships capable of following a system throughout its life.

And precisely because the proposition is valuable, it is worth discussing how it can be distorted.

The problem begins when the tool arrives before the transformation

Imagine an organization with poorly defined assumptions, scattered criteria, unclear responsibilities, and decisions that cannot be traced back to their origin.

Now give that organization an excellent digital platform.

• Migrate the documents.
• Integrate the databases.
• Create dashboards.
• Model the installation in three dimensions.
• Implement a lifecycle-management system.
• Perhaps even add artificial intelligence.

What will we have?

If the organization has not changed the way it creates, validates, relates, and uses engineering information, the most likely result will be the same engineering problems — now operating inside a more sophisticated technological environment.

In other words:

digitizing disorder does not produce Digital Engineering. It produces digitized disorder.

And that is not a criticism of Digital Engineering.

It is almost the opposite.

It is a defense of it.

Reducing Digital Engineering to the acquisition of tools diminishes the very transformation it is intended to create.

Digital Engineering itself recognizes this

An especially important point is that the most consistent references on the subject do not treat this transformation as a matter of technology alone.

The U.S. Department of Defense Digital Engineering Strategy, for example, explicitly includes transformation of culture and workforce among its major objectives, alongside models, infrastructure, technological innovation, and authoritative sources of information.

That matters.

Because no tool creates an engineering culture by itself.

Software does not independently determine which assumption is acceptable. It does not establish technical responsibility. It does not automatically determine which data should be considered reliable. It does not necessarily identify when two disciplines are working from incompatible assumptions. It does not decide what level of risk is acceptable.

And it does not assume responsibility for the consequences of a decision.

Technology can dramatically increase an engineer’s capability.

But there must still be engineering to amplify.

Before the digital model, there is a mental model

In engineering practice, a decision rarely exists in isolation.

A requirement generates an assumption. The assumption influences a calculation. The calculation determines a design condition. That condition affects equipment selection. The equipment affects the installation.

The installation changes operating conditions. Operation establishes control, maintenance, and validation criteria.

It sounds obvious when written this way.

But keeping those relationships identifiable throughout a project is much more difficult.

This is precisely where concepts such as model-based engineering, the Digital Thread, lifecycle management, and authoritative sources of information can create enormous value.

They begin to make it possible to answer apparently simple questions with confidence:

• Why was this solution selected?
• Which requirement led to it?
• Which assumption supported this calculation?
• If that condition changes, which calculations, documents, equipment, or decisions are affected?
• Which revision introduced a particular change?
• What was actually installed?
• How will what was designed later be verified?
• Which information must remain available to whoever operates or modifies the installation in the future?

This is very different from simply possessing digital files.

It is about building engineering continuity.

The document still exists — but it stops being an island

A drawing remains a drawing.

A calculation report remains necessary.

A specification continues to serve its purpose.

A technical report continues to be required.

Digitalization does not automatically eliminate these documents, nor should it do so merely in the name of modernity.

The difference lies in understanding that they are different manifestations of the same engineering construction.

Behind them are requirements, assumptions, calculations, interfaces, responsibilities, decisions, revisions, and validation criteria.

The stronger the relationships between this information, the higher its quality.

And the better the information, the better the conditions for a technically sound decision.

Perhaps this is the point at which Digital Engineering stops being primarily a technology discussion and becomes an engineering discussion again.

This is exactly what made the subject relevant to Zapaterra

At Zapaterra, we did not begin organizing our work by thinking about Digital Engineering.

Much less by selecting software or searching for a methodology with which we could associate our name.

The movement began for much more practical reasons.

We needed to reduce improvisation. Preserve assumptions. Increase predictability. Record decisions. Control revisions. Define responsibilities.

We needed to prevent a change made in one part of a project from leaving forgotten consequences somewhere else.

We needed calculations, drawings, specifications, procurement, execution, and later validation to communicate with one another.

Over time, this began to form a working standard that we continue to improve.

A very natural sequence emerged:

• document;
• trace;
• connect;
• structure;
• preserve.

Document so that engineering exists in a clear and verifiable form.

Trace so that it is possible to understand not only which decision was made, but why it was made.

Connect because a change rarely ends in the document where it was introduced.

Structure so that important information does not depend exclusively on the memory of the people who participated in the project.

Preserve so that knowledge produced during design and execution can remain useful during commissioning, operation, maintenance, and future modifications.

When we later began looking more carefully at what had come to be called Digital Engineering, the convergence became evident.

Not because we had implemented all of its tools.

We had not.

Not because we could claim mastery of all of its disciplines.

We could not.

But because we recognized in its proposition many of the same problems we had been trying to solve through everyday engineering practice.

For us, that distinction is fundamental.

Can Digital Engineering begin without all of this technology?

We believe it can.

A small or medium-sized company will rarely begin its transformation by acquiring the entire technological infrastructure available to large industrial organizations.

Nor does it need to.

Perhaps its first step is simply to establish a controlled source for certain information.

Or formally relate requirements and decisions.

Or improve the control of assumptions and revisions.

Or prevent a project change from failing to reach an associated specification.

Or structure equipment data so that it can accompany design, procurement, installation, commissioning, and maintenance.

These steps may appear modest when compared with a sophisticated Digital Twin.

But there is an enormous difference between possessing Digital Engineering technology and developing the maturity required to use it.

The tool can be acquired quickly.

The maturity must be built.

And this is where distortion begins

Every relevant technology also creates its own market.

That is natural.

The problem appears when mastering the vocabulary begins to substitute for mastering the practice.

It becomes easy to speak about MBSE. Digital Thread. Digital Twin. PLM. Integrated models. Artificial Intelligence. Digital Transformation.

And the impression can emerge that we are dealing with a completely new form of engineering that began together with these terms.

It did not.

The tools changed dramatically.

Integration capability changed.

The amount of data changed.

Speed changed.

Simulation capability changed.

And all of this represents extraordinary progress.

But old questions remain:

• What is the problem?
• What is the assumption?
• What is the criterion?
• What is the risk?
• Which decision are we making?
• Why?
• Based on which information?
• And who is responsible for it?

No acronym eliminates these questions.

Perhaps digital transformation begins before the software

We are entering an era in which digital tools will have an increasing capacity to produce drawings, models, simulations, calculations, texts, analyses, and recommendations.

This does not reduce the importance of the engineer.

It increases the engineer’s responsibility.

The greater the amount of information available, the greater the need to distinguish reliable data from data that is merely available.

Relevant information from accessory information.

Hypothesis from evidence.

Correlation from causation.

Automated recommendation from technically responsible decision-making.

Decision quality does not improve simply because more information exists.

It improves when better information exists — organized according to sound criteria and made available to people capable of interpreting it.

That may be one of the greatest contributions Digital Engineering can offer.

And precisely for that reason, it deserves more than being reduced to a commercial argument for selling software.

In the end, there may be a small irony

When we began improving our way of working, we were not trying to practice Digital Engineering.

We did not begin with acronyms.

We did not begin with the tool.

We did not search for a trend to which we could attach what we were doing.

We began by trying to solve concrete problems:

• how to preserve assumptions;
• how to reduce uncertainty;
• how to connect decisions;
• how to prevent important information from disappearing between design and execution;
• how to make responsibilities clearer;
• how to make a project verifiable;
• how to turn experience into method.

Now, looking at what Digital Engineering actually proposes, we see a convergence worth studying, developing, and incorporating wherever it makes sense.

Not to claim that we have always done everything that today falls under this name.

That would be as superficial as the very attitude we are criticizing.

But to recognize that the real digital transformation of engineering may depend less on how quickly an organization adopts new terminology and more on how consistently it builds its own way of thinking and working.

Perhaps that is precisely why Zapaterra can take part in this discussion.

Because we did not begin by trying to talk about Digital Engineering.

We began by trying to do engineering properly.