Updated: Feb 16
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
Updated: Feb 16
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:
Systems Centric – think of this as studying “Systems Engineering” itself – the related skills and methods
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.
Which means the diffe