What is Systems Engineering?

Depending on your career trajectory, your educational background or even your industry, systems engineering may have a variety of definitions. Taking a first principles approach, let's look up the dictionary definition of systems engineering.

According to Merriam-Webster's dictionary, systems engineering:

"systems engineering”.

"The word you've entered isn't in the dictionary. Click on a spelling suggestion below or try again using the search bar above."

engineering
sanitary engineering
engineerings
software engineering
systematising
methods engineering
systematizing
ocean engineering
systemizing
reverse engineering
systems analyses

Not a great start; but also, not unexpected. Systems engineering means many different things to many different people, ranging from physical systems and their physical interfaces all the way through abstract diagrammatic representations of a high level system. With such a range of different definitions, we can look to how the professionals define systems engineering:

So in the spirit of December 2022, we decided to instead ask ChatGPT if it could define Systems Engineering for us...

This is a much better start, and interestingly (although probably not surprisingly) very closely aligned with our source material on how the professionals define systems engineering:

The engineers at the International Council on Systems Engineering (INCOSE) have the following definition for systems engineering:‍

"Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods." We use the terms “engineering” and “engineered” in their widest sense: “the action of working artfully to bring something about”. “Engineered systems” may be composed of any or all of people, products, services, information, processes, and natural elements."

Verbose, eloquent, and sweeping.

The rocket scientists at NASA have published a handy NASA Systems Engineering Handbook with an excellent definition of systems engineering:

At NASA, “systems engineering” is defined as a methodical, multi-disciplinary approach for the design, realization, technical management, operations, and retirement of a system. A “system” is the combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose; that is, all things required to produce system-level results. The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected.

It is a way of looking at the “big picture” when making technical decisions. It is a way of achieving stakeholder functional, physical, and operational performance requirements in the intended use environment over the planned life of the system within cost, schedule, and other constraints. It is a methodology that supports the containment of the life cycle cost of a system. In other words, systems engineering is a logical way of thinking.

Considering all that NASA has accomplished, it’s clear that their engineers have proven successful at applying this “logical way of thinking” to system development. In the 1960s, NASA landed mankind on the moon. They followed up the next couple of decades with the Skylab, the Space Shuttle program, and a slew of Earth-based and interplanetary scientific missions that have brought us images of dust devils on Mars, images of hydrocarbon ice blocks on the surface of Saturn’s moon Titan and even the sound of the soft hum of interstellar plasma. Voyager 2, the recorder of the sound of interstellar plasma, was built in the 1970s and is still functioning in interstellar space. We would definitely consider that a well engineered system!

And as an added bonus, ChatGPT seems to agree!

Systems Engineering as a Four-Letter Word

Despite the technical successes of the impressive systems developed by NASA, if you enter into some engineering organizations and ask for their definition of systems engineering, the answer would boil down to this:

“systems engineering” is a four-letter word.

i.e., the formal process of systems engineering should be avoided if we want to deliver our product on time, on budget, and meeting our specifications.

In our experience, there are two different reasons that systems engineering has turned into a four-letter word. 

First is the sentiment that systems engineering is just an exercise in paperwork. 

‍The process of systems engineering is viewed as “Engineering by PowerPoint™,” meaning you can take a series of PowerPoint slides, turn the crank through the Systems Engineering V-model, and eventually on the other side a new satellite, high-performance jet, or widget pops out, fully compliant with all requirements specified early in the process and never having to change any requirements during the design process. 

Unfortunately, no plan (or systems engineering requirements document) survives first contact with the enemy (schedules, budgets, gravity, physics); requirements often have to evolve and adapt to the engineering realities. These realities lead to an increase in the amount of paperwork that has to be generated with any change.

Engineers inherently prefer to be turning wrenches, soldering wires, writing code, and sometimes blowing stuff up in the process… not churning out updated PowerPoint specifications and text requirements documents.

‍
Second, more importantly, is a lack of modern tooling to support the 21st-century engineer. 

In the space industry, it’s a common refrain that “space is hard”. We agree with this sentiment and would expand it to say that engineering is hard. 

Engineering is not isolated from the second law of thermodynamics. As system design complexity increases, so does entropy within the system. Systems engineering, as a practice, seeks to provide a “big picture” view of this entropy, and in its own way help to constrain the entropy. 

Unfortunately, in a world of GitHub, Jira, and Google Drive, the modern knowledge worker expects modern and effective software tools. Any engineer who has used an Excel spreadsheet (likely named “System Requirements_v2_final_final_locked.xlsx”) to manage their requirements can attest that traditional systems engineering tools pale in comparison to the feature sets of standard software engineering tools like git, continuous integration, continuous deployment and linting.

Everyone is a Systems Engineer

Although the formal practice of systems engineering has received a bad reputation in some organizations, we strongly believe the sentiment that in an engineering organization, especially in the 21st century, everyone is a systems engineer. The software engineers' system has to interface with the firmware engineers' system. The firmware engineers' system has to interface with the electrical engineers' system. The electrical engineers' system has to interface with the mechanical engineers' system. The scheduling team has to interface with the timelines of electrical and mechanical engineers' hardware deliveries. The finance team has to interface with the electrical and mechanical engineers' costs. The formally trained systems engineers using model based systems engineering have to model all of these interfaces. If you’re reading this post, if you work as an engineer, if you’re building a product (most often physical, but software needs their systems engineers too!), even if you’ve worked on a major project before, then you have likely made decisions that qualify you as a systems engineer.

Even if an organization doesn’t have an official systems engineer, or systems engineering process, all of the teams will still inherently have to take a systems-level perspective of anything they are building. An engineer designing an electronic component will still need to consider how much power will be supplied by the power subsystem. Assumptions can lead to mistakes, rework, cost overruns, schedule delays, and the various other mistakes that can cause an overall system failure.

As INCOSE put it, Systems Engineering is “the action of working artfully to bring something about”. Whether that’s building a hobby rocket to launch at the annual Black Rock Desert Rocketry Research Festival, building a hypersonic commercial aircraft, designing a carbon sequestration system, or even designing the next consumer gadget.

To Artfully Bring Something About, with better software tools…

If you've read this post this far, and maybe gotten a chuckle out of a few of the insights, then we suspect it's highly likely that you, too, are a systems engineer. So could your team use some help to artfully bring something about? Do you want to manage your design complexity, build your widget faster, and break less hardware along the way?

We've been building our modern systems engineering tool Verve to help enterprises like yours adopt Agile Systems Engineering practices at the earliest stages of product development, with feature sets and capabilities that just make sense for the 21st century. We'd love to help solve your teams' systems engineer pain points. Let’s talk.