Systems Engineering is a Thing

From Daniel Elizalde, claiming the Internet of Things requires a new breed of Product Manager.

Each industrial revolution has created the need for a new kind of engineer who can implement, maintain, and innovate on its new technologies.

The First Industrial Revolution of the late 18th and early 19th centuries gave birth to the field of Mechanical Engineering.

As electrification began to spread across the world during the Second Industrial Revolution of the late 19th century, universities began to offer programs in Electrical Engineering for the first time.

The same need emerged in the 1960s and 1970s with the Digital Revolution (the Third Industrial Revolution). The rapid explosion of the computer industry gave birth to new degrees in Computer Science.

The Internet of Things is considered by many to be the 4th Industrial Revolution. But unlike the first three, it is not a new technology — it is a new way of combining existing technologies. As a result, it will not require a new kind of engineer.

But it will require a new kind of Product Manager.

I’ve never thought about how new technologies create new engineering fields. It was easy to overlook, since to me there have always been mechanical, electrical, and software engineers. It’s a good lede, and the article is a great overview of the IoT stack: device hardware, device software, communications, cloud platform, and cloud applications.

But as he elaborated upon each layer it began to sound familiar, because the same layers apply to a satellite constellation:

• device hardware = satellite
• device software = flight software
• communications = comm subsystem¹
• cloud platform = ground software
• cloud applications = data platform

Indeed, the new challenges wrought by IoT don’t sound that new at all: this is classical systems engineering. As a term, SE has been around since the 1940s. Practically, it exists whenever the whole is greater than the sum of the parts — acknowledged or not — and its scope grows whenever new specialties are added to the body of human knowledge.

Example traits of this supposedly “new kind of PM”:

…understand your users and the “job to be done” of your product. When designing your end-user applications, it is very important to understand who is your user and what is their primary goal for using your product.

Systems engineering must deeply understand the problem-to-be-solved from the perspective of a customer or user. That context helps ensure the implementation addresses the problem and doesn’t morph into to building something just because its cool.

…think about what kind of data you are collecting, and what hardware is needed to do that.

…understand some implications of cost, size, ease of deployment, reliability, useful lifetime, etc.

A vague but accurate description of how to run a system-level trade study that considers a multitude of factors. It’s standard practice in systems engineering to consider the ‑ilities² and programmatic considerations like cost and schedule.

[Regarding device software:] It’ll be up to you and your team to decide how much functionality is placed here versus in the Cloud.

Nothing screams systems engineering like the thoughtful allocation of functions to different segments of the architecture…

…should each sensor perform control and communicate to the Cloud? Or should you have ten simpler (and cheaper) sensors that communicate to a central gateway for aggregation and long-range transmission of data?

…or at a lower level to individual components and parts.

As the Internet of Things continues to grow, the world will need an army of IoT-savvy Product Managers. And those Product Managers will need to understand each layer of the stack, and how they all fit together into a complete IoT solution. Product Managers will need to make strategic business and technical decisions at each layer in order to ensure the success of their products.

In the end I agree with half of the closing. In any complicated system there’s an important role for someone who understands the “full stack”, what each part does, and how they interact. But none of this is new, and frankly it’s not the responsibility of a program or product manager to understand these things. Systems engineers benefit when they understand things like building schedules, staffing and managing an integrated product team, budgeting, and the building of a business case; conversely, PMs can be more effective when they understand systems engineering. But a PM can be effective with few SE skills — if they have a solid systems engineer (or SE team) to rely on — and nothing about that is new.