July 5, 2024

Better Solution Design Outcomes: Digital Engineering vs. Digital Transformation

Whether in federal government or commercial contexts –  there are both similarities and differences in engineering solutions for a cyber-physical asset (e.g., a missile, an electric-gas power turbine, or a tractor) versus transforming an organization to leverage modern digital Information Technology (IT) more effectively.

But how are they different? And why does it matter?

Digital Engineering (DE) / Model-Based System Engineering (MBSE)

DE / MBSE are “not new”, and the picture that comes to mind might be a 3-D digital twin of a cyber-physical asset, where scientists and engineers (S&E's) can run complex, multivariate simulations, before building an expensive physical prototype. The desired outcome of those S&E's might be to build a new missile that has better stealth capabilities, or a turbine that uses less fuel and produces more thrust. Robin Yeman and Dr. Suzette Johnson have a lot to say about this in their book, “Industrial DevOps“.

Digital Transformation (DT) / Frictionless Bizops Design

DT is also “not new” – for many years, we have tried to “pull the levers” to make improvements in the areas of people, process and technology.  Easier said than done — IT is complex, and it's “all too easy” to buy the technology and expect good outcomes to help deliver frictionless business & operations – for example, improving IT Service Management (ITSM) processes to give more time back to the S&E's who are trying to build cost-effective physical prototypes and get technology into the hands of warfighters… or improving the Customer/Employee Experience (CX/EX) for getting product support on a web portal.

In fact, US Office of Personnel Management built a report in 2022 focused on federal workforce priorities, which has important guidance, relevant for both federal agencies and commercial organizations.


So, if DE / MBSE helps S&E's design missiles, and Digital Transformation / frictionless bizops design helps to give more time for S&E's to build those missiles, can't we just buy a single design tool and hit all desired outcomes faster?

Not likely.

For delivery of faster, higher-quality products & services at a sustainable pace, solution design for both Digital Engineering (DE) and Digital Transformation (DT) needs improvements across people, process, and technology. Furthermore, solution designs are just “boxes and lines on a page” unless they actually help guide DevSecOps – faster software development and engineering implementation, which makes holistic solution integration important.

Let's take a look at similarities and differences in each dimension.


For either DE or DT, people need to work together (in cross-functional teams) to maximize the combined power of their diverse backgrounds and skillsets to build a missile, or design a complex IT system integration.  It has been proven over and over again that embracing agile principles can help with forming effective teams that deliver faster experimentation, learning and value delivery (and yes, that applies to cyber-physical systems too — ask Robin & Suzette about that… and no, you don't have to sacrifice quality!)

It's “all too easy” to buy the technology and expect good outcomes to help deliver frictionless business & operations

Typical blockers for people to work together are culture related – such as “superhero syndrome” (a few “deep experts” spend more time “saving the day” rather than teaching others), or practices related, such as working on a different cadence and out-of-sync, causing lots of unnecessary delays.  These, and other agility-at-scale maturity practices are applicable to people, whether we are designing a missile or improving a purchase-to-pay business process.

PEOPLE verdict: People / Culture issues are largely the same for both MBSE & business/IT ops improvement.


Let's expand “process” to “digital modeling”, which might include more than just process models, but complex system integration models — for example:

  • UML / SysML notations, and Business Process Model and Notation (BPMN)
  • COBIT for GRC (Governance, Risk & Compliance) process & control framework guidance
  • Scaled Agile Framework for Enterprise (SAFe) for agility-at-scale framework guidance
  • NIST reference models to leverage best-practice controls, accelerating risk mitigation

Digital design notations, frameworks and methods are tailored to be fit-for-purpose, not “one-size-fits-all”.  For example, BPMN process modeling and UML data modeling are useful standards in both MBSE & business/IT ops contexts, but SysML lightweight extensions to UML help system engineers collaborate with software engineers (e.g., adding requirement diagrams, and  parametric diagrams for performance and quantitative analysis).

PROCESS / DIGITAL MODELING verdict: Process/Digital modeling notations, frameworks and reference models can overlap, but are tailored to be fit-for-purpose.


“It takes a village” for effective digital engineering / solution design, and one tool can seldom do the job.  Scaled Agile calls this “Solution Intent“, which is the (integrated tooling) repository for storing, managing and communicating the knowledge of current and intended solution behavior and design.

For example, Cameo is a popular choice for Modeling, Simulation & Analysis (MS&A) in a digital engineering context, and and Software AG ARIS / Alfabet are popular choices for business/IT modeling and Enterprise Architecture, and designed for easier use by “non-technical” persons (aka, “democratizing” the design to include more diverse inputs).  Both Cameo and ARIS support BPMN and UML standards, but Cameo has SysML support and is more suitable for engineers — and ARIS has more flexible / easier-to-use web collaboration / AI features.

Solution designs are just “boxes and lines on a page” unless they actually help guide DevSecOps – faster software development and engineering implementation, which makes holistic solution integration important.

In addition to accommodating fit-for-purpose digital modeling, such MS&A tools should make it easier to turn models into actual code & physical prototypes — e.g., supporting automated integration with “runtime” agile project management tools (e.g., Jira) and Continuous Delivery Pipeline (CDP) DevSecOps tools (e.g., Gitlab), with built-in features needed to realize model-defined requirements, such as Secure Software Supply Chain (SSSC).

TECHNOLOGY verdict: Process/Digital modeling tools can overlap, but should be “selected-and-tailored-for-purpose” to support “fit-for-purpose” MBSE or business / IT ops modeling and integration.


It's a mixed verdict – “people challenges” are the same everywhere, and process / tools need to be selected and tailored for the best possible outcome: high-quality outcomes, delivered at the “speed of relevance” and at the same time, at a “sustainable pace”.

Do you see more challenges in one area, or all of them? Please comment below and share your context and experiences!