Systems Engineers Solve Complex Problems

Systems Engineering is one of those disciplines where you can track its origins but at the same time it’s not very clear what it means to be one, much less what one’s day to day would look like.

The cool thing about Systems Engineering is there is a problem solving methodology at its core and is specifically used for complex solutions. If I can break this down for you it might just be what you need to think about to solve some of your own problems whether if you think it is simple or complex.

Types of Systems Engineers

Think of it like there are many types of engineers who solve different problems for different industries. Civil, Aeronautical, Mechanical, Electrical, Software, etc.

Within those worlds, at some point, their solutions will have to implement different products, designs, processes and systems to solve it.

It’s this interface – multiple moving parts type scenario where systems engineering actually comes into play.

Here's some systems engineering jobs:

• Biological Systems Engineer

• Computer Systems Engineer

• Control Systems Engineer

• IT Systems Engineer

• Software Systems Engineer - extending to Site Reliability Engineering

• Space Systems Engineer

• Enterprise Systems Engineer

• Embedded Systems Engineer

• Safety Systems Engineer

• Security Systems Engineer

• Weapon Systems Engineer

Not a bad sounding list.

So the question becomes, what’s the difference between these different types? And then – are there similarities? Can they move across these fields?

What's the difference between the types of systems engineering?

So, the use of the word systems isn’t just coincidental in that it’s a generic term for systems of each of the branches of engineering. Its quite literally an “Interdisciplinary field” by definition. You can’t actually do the job and just focus in on one technology.

The whole point is a holistic view. Like a bird’s eye view. Mix that with the ability to have a microscopic view on any of the given technologies and the idea is to be able to switch between these views and make sure everything will align.

This is why the generic “Systems Engineer” doesn’t really do anything on its own per se. It needs to be embedded within another discipline of Engineering and more often than not – multiple disciplines.

So if you go to a job site, you can see many jobs for systems engineers but when you look at the education side there’s not as much that is offered outside of the context of a “traditional” engineering discipline.

Don’t get me wrong – they are there and you can study Systems Engineering.

But there’s 2 ways to look at the what systems engineering is:

1. Systems Centric – think of this as studying “Systems Engineering” itself – the related skills and methods

2. Domain Centric – Systems Engineering topics on top of another Major or domain

This reflects the real job world, except that, whether it is looking for something more systems centric or domain centric the job titles are usually some form of just “Systems Engineer”.

Okay, wait. So then what’s the differences and similarities?

The similarities are all to do with it being interdisciplinary and managing complexity. At the end of the day because you are dealing with situations that involve different discipline and domains it automatically creates a more complex situation.

Here's a real world example

It’s like when you have one group of friends here, say your high school friends, then, you have some family childhood friends and then, you have some university friends and work friends, let’s say.

Okay, now, when you hang out with any of those groups it’s pretty simple on you socially (give or take, I know, I know, some aren’t so much). Now if you organize a party, let’s say your birthday where you have to integrate all these different groups into a singular party where you host and have to mix and match your social interactions within all of these – it’s a little more complex.

And then depending on the number of people this increases the complexity the more people there are. And then let’s say the party is not your birthday – it’s now your wedding, you have to integrate the same set of complex friendship systems of your significant other and combine these 2 bodies of friends.

You see where I am going with this. You interacting within any one of these individual groups is relatively simple. Whilst integrating multiple groups makes it a little more complex.

Now if you were to think about making a helicopter work. That you would be confident enough that a human could sit inside, be lifted hundreds of metres into the air and not be dropped to their death. This would require a combination of parts, systems, technologies, science, and humans to do.

Let alone deadlines, budgets – you get the idea.

So the job is – will all these parts and parts of parts, and their overall systems work together? So you’re jumping between a macro and micro view…

This is why, whilst there is a methodology there to help achieve this, it helps tremendously to know a thing or 2 about all the types of systems or parts or steps involved.

Imagine going back to the wedding example, except you don’t know who you’re marrying and you don’t know any of their social circles but the wedding must happen without a hiccup or else you get cursed with “biting your tongue every time you speak, forever”?

Sorry I needed some “insert bad thing here” to complete the example.

Anyways, in that scenario it is a lot harder to make sure things go smoothly because you don’t know anything about one of the systems you are trying to integrate. Hence it is useful to know a thing or 2 about the underlying systems and technologies.

Cool, that’s a bit to digest, but all I’ve done so far is say here’s some systems engineering types and that the similarities are that it is interdisciplinary and it exists to help solve complex problems.

The differences

Which means the differences all lie within the word prior to “systems engineer”. So weapon systems, embedded systems, control systems generally give you the domain and technologies - and then one more distinction depends on the industry and the company.

This will dictate where on the spectrum your day to day would look like.

Not all Systems Engineer are IT focused and in fact there's several industries where although there are use of common technologies, the circumstances and type of systems engineer is completely different. This is where the term Operational Technology was coined and it is to make this distinction. Some systems engineers are focused on OT and not on IT which completely changes what you might do. There's differences in how they approach problems, the technology used, the type of company and industry, even how they approach cybersecurity.

Systems Engineer Day to Day

It varies from creative thinking very high level design to critical thinking detail oriented assessments.

From heavy office work, to, boots on the ground, field work.

From project management, communication focus to very technical, concise articulation.

Now onto how it might actually solve these problems. Well there’s definitely an overarching methodology, but depending on what type as I said, will mean where along that methodology you might spend most of your time on.

The Systems Engineering Process

Let’s take a quick look into a high level methodology… This can roughly be broken down into 4 main stages.

1. Task Definition (informative definition),

2. Conceptual Stage (cardinal definition),

3. Design Stage (formative definition), and

4. Implementation Stage (manufacturing definition).

In some cases, this could look more like,

1. Analysis

2. Design

3. Build

4. Install+Commission

These 2 scenarios may be dissected or categorized differently but the reason why I bring these 2 up is one is product focused and the other is more service focused. The former getting you to a point of making a product, the latter more focused on integrating a system.

Let's break it down a little more…

In the earliest stages the whole idea is to try and define the problem, roughly in the beginning. So task definition and analysis both are looking at the requirements, the problem statement, the goal of the project - all that stuff - clarifying what should be included in the scope in the first place, who is responsible for different parts of the picture. So Step 1. Define your problem.

The next stages come to starting to conceptualize a design, potential solution options and what that might look like, for all parties involved. So you’re looking at your scope and then will have that placed within context of other things that are related but are out of scope and showing where they interface and where the lines are.

For example, your solution might propose a computer or a PLC to be installed. Within scope might be a power supply, but the source of that power, the electricity might be out of scope. You would still show this connection exists but might show a line that says this part of the equation belongs to us, so I’ll provide the physical computer, cable of the PS and plug it into a port somewhere and that part, behind the port connecting to electricity, belongs to a 3rd party.

You start with conceptual, high level designs and ideas and you progress to a more detailed low level design. This is no longer just saying this box will be used, you are now saying specifically this box will be used and port 2 of this device will be connected to port 3 of that device. Sizing, power, technology, protocol, IP ratings, configuration. All the variables that could have an impact on the overall design.

Once that’s done for all the individual parts, you go back to the more conceptual look and see if all the parts would connect together, not just be compatible but are also still mapping back to the scope and requirements defined in the first step.

So that’s High Level / Conceptual design through to Detailed Design. Here you’ll also have schedules, milestones, resources and things like this starting to come together because you can’t just think of the system coming together at a technical level. It’s like having money for the wedding but you haven’t got a partner yet or haven’t booked anything yet.

So this can all get a bit confusing and actually be quite bland. But the key here is

to use models.

Systems Engineering Models

Models are a key tool of Systems Engineers allowing all the moving parts to be defined, have a home and all different processes and people can quite literally be “on the same page” – They say “a picture can say 1000 words” and if you remember back to Episode 16 of the engineering podcast, we say that “1 drawing can solve 1000 problems”.

Just to touch on some of these Systems Engineering Modeling tools:

• Function flow block diagrams

• Data flow diagrams

• Use Case Diagram

• System Architecture Diagrams

• Model Based Design diagrams

• Systems Modelling Language

You can then use these diagrams to start framing up the different technologies that address the problem. Compare the solutions and the Systems Engineer can decide what is best. These drawings are super useful when iterating through design options and finally landing at a refined solution.

Next you have a build stage this is where you put together initial parts of the system but in a factory type setting. You now, it’s not going to solve the actual problem just yet, we are putting it together to test that after building it is of good quality, meets the requirements etc.

And the implementation stage / install and commissioning stage is really putting it in to actually do the job.

Both of these phases have many different tests to pass and get through and typically include benchmarks as defined in the design phases. Factory Acceptance testing, Unit and Integration testing as well as Site Acceptance testing are the types you will here. But essentially there are audits and checks at each stage.

Think of these latter stages as the execution phase – the day of the wedding. And the days leading up that are setting everything up.

Whew, that’s quite a bit to unpack, but you might have noticed I jogged through the later phases. And that’s not because I got tired but really it’s because most people understand the execution phases, the "going through the motions".

That’s the action that commits to memory.

You work in this realm in everyday life always.

You could put this level of detail work in everything you do but it wouldn’t be feasible. But it does mean that putting in a little effort in the prework would make a huge difference in making sure things will go as planned.

In a big complex situation, there is so much resources and investment involved that you really, really want it to work. And the best method we have for doing that is the Systems Engineering method.

You might pull off one event without spending much time in it, not likely, but could you do it again? What if the requirements slightly changed? Or some variable all of a sudden didn’t exist. It has to be repeatable and it has to last more than 1 day.

Most life expectancy of a complex system would be more like 10-20 years.

Heck, look at the Sony Playstation and their announcement to make the PS5 future proof.

Designing something that will last more than 7 years.

Look at a Space system.

A car isn’t designed for you to drive once per trip.

Anyway, my point is if you want to have sustained success you need to spend more time on planning, preparing and designing than you spend on the executing. Don’t get me wrong, you need both, that’s for sure. Only designing with no execution is worse.

Most people’s problems are spending too much time on only one of those things. Procrastinators only have ideas, and overworked with no success don’t spend enough time planning and designing.

The ones that do both benefit from designs being informed by lessons learned from executing. And Execution improves because the designs were better.

Top Systems Engineering Skills

For some context on the role here are the top skills in addition to the technical and problem solving skills. These are skills anyone could improve upon.

• Communication Skills

• Ability to serve as a technical project manager

• Width of Knowledge and familiarity with all the technologies

If you want to solve problems and more complex ones, you’d best believe you should improve in these things. Systems Engineer or not.

Simon Ramo, who is considered by some, a founder of modern systems engineering, said it best:

“Systems Engineering is a branch of engineering which concentrates on the design and application of the whole as distinct from the parts, looking at a problem in its entirety, taking account of all the facets and all the variables and linking the social to the technological.”

Which is a nice way of putting it.

How you can benefit from the Systems Engineering method in everyday life

At the beginning of this post I did say breaking all this down might help you.

1. Ask the right question and define your scope

One Lesson is to ask the right question/scope properly in order to solve anything slightly complex.

Using Socratic method ask, ask, ask - question your assumptions is the most important.

Are there some answers you're not happy with in your own life? Could it be you are not asking the right question? Could it be your expectation was not met because you didn't define the scope clearly?

“I’m unhappy because my job sucks” is a terrible definition and your solution of complaining about it is a terrible answer.

Dig deeper, question yourself why until you get it down to what the requirements would be for your job not to suck. Not the best example but you get the idea.

2. Communication is key, focus on their pain points and drivers

Another thing to consider is the fact that the key soft skill for a Systems Engineer is communication skills.

Dealing with all types of stakeholders and needing to know what their drivers and pain points are means that so many problems arise due to ambiguity - you need to clarify things.

It's not as easy when there may be personal feelings or drivers but not saying something generally winds up costing more in the end. It can be hard to explain the technical in a non-technical way and the drawing tools are a decent way to start.

There’s a book by Aristotle called the Art of Rhetoric which was written to help smart people who couldn’t convince anyone of anything to save their lives. The key is in understanding your audience.

It’s not good enough to be right.

Audit yourself.

You are a system, your ideas are a system, your peers are a system, your work is a system and society is a system.

Take a Systems Engineers approach and understand that to integrate any system big or small, you better be sure you are asking the right question and that you defined the scope clearly.

If you want to take your Engineering skills to the next level you could bring your own ideas to life by putting your money where your mouth is and 3d printing it! Get your free sample copy of the #1 Best Selling book on 3D printing available thanks to our partners 3DHubs and don't stay in theory anymore.