If you look in the regular places, you’ll see that Systems Engineering is described, but the words are all Gartneresque. That’s all well and good for a wiki or report, but what does Systems Engineering actually mean?
Basically, it’s a process to reduce complexity.
First of all we define everything as a System. A computer can be a system, a factory can be a system, even people following processes can act as a system. In fact the details of what’s inside the system can even be largely ignored at the start of the process. A system has inputs and outputs, but at a high level, so long as the outputs are correct relative to the inputs, the insides of your black box system could be microchips, cogs, bacteria, or something else entirely. It really doesn’t matter.
To solve the problem, the first thing you do is describe the problem as a series of inputs and outputs, which form your requirements. Whether you’re transporting cargo, processing information, or trying to achieve some effect, your system will have requirements, which define the boundaries of that system. For example a space shuttle may need to deliver one ton of cargo to low earth orbit within 24 hours of launch. As you can see, the requirements don’t detail the solution, only the boundaries of the problem.
With your requirements in hand, you now have the boundaries of the system. You have a black box, and ‘something’ will go inside that box to solve all of your problems.
So how does this reduce complexity? The black box, ie the system can be reduced into smaller and smaller sub systems. At each reduction you are architecting the system and defining the boundaries between which the engineers of each sub system will work. For example, you might break a space shuttle down into a fuel subsystem, life support subsystem, navigation subsystem, etc. This makes a lot of sense, because the chemical and mechanical engineers designing the fuel subsystem, likely don’t care about and don’t know how to engineer the software navigation subsystem, or the medical life support subsystem, so they interface through the tightly defined boundaries created when breaking the system down into its subsystems. These boundaries make the problem workable and ensure the best person for the job is designing the exact details of each subsystem. This is a good thing because too much detail in an architecture can miss the mark through naivety, you really just want to design the boundaries and the effects achieved by the super system.
Systems Engineering then focusses on Verification and Validation, where each sub system is tested against the requirements, and the overall System is approved to undertake the mission.
Without the clearly defined boundaries, a complex System can quickly become something unwieldy. Using the space shuttle again as an example, what if the fuel line requirements were not clearly defined? It’s easy to imagine a scenario where engineers (who are often not in the same building or even country) get their wires crossed and the fuel is not delivered fast enough, or at the right temperature, or even the right fuel type for the engine. Would the shuttle take off? And if it did, will it achieve the mission, or or will it fall back to Earth? Even if the fault was discovered before the shuttle is launched, the costs of re-engineering can be astronomical (no pun intended). Particularly delays, where you may have to pay a bunch of staff to do nothing for weeks, re-engineering costs can quickly add up.
Another example is anything relating to Services Oriented Architecture or SOA. In SOA, every service can be regarded as a subsystem. It can be quite flexible, as software services can be reused with no additional work, and depending on how well the system is designed it can degrade gracefully if services become unavailable or have not yet been developed.
Having well defined boundaries and a series of tests to be performed on each subsystem, depending on which requirements the subsystem had allocated to it, allows the engineers on each subsystem to ignore the other side of the boundaries, which reduces the complexity of the problem to something manageable.
As you move through the process, the complexity of the links between every line of every artifact increases, as if absorbing the complexity of the system. It can be difficult to manage these traces, but worth it to maintain the context of the system. Without context the purpose of a sub task is often lost (“Why are we testing this nut against ISO1404 again? Why does this wire need to transfer 10Mbits? Can I get away with using a cheaper cable?”). But with the context of traceability you can not only see exactly why each task is important and which stakeholder is asking for it, you can be sure that every subsystem is tested and every requirement is met. Being able to trace back to stakeholders is also great, as anyone can identify the stakeholders originally responsible for every component of the system being built and tested, and ask them for feedback and clarification if necessary rather than simply being lost in some enormous process.
A common criticism of this process is that it all sounds very ‘waterfall’, something that has been replaced by the ‘agile’ software development life cycle. But three points should be made:
1. A lot of what people these days call agile is simply staged waterfall. You can still stage the requirements under this method. You can also stage the order the subsystems will be implemented, and even defer finalising or even deciding on whole parts of the design, because they’ve been neatly compartmentalised for you through Systems Engineering. You can use Systems Engineering to define the goals of the subsystems, then use the Agile method to develop any or all of them.
2. An Agile organisation is one that is not burdened by classical engineering like this. But really their flexibility does not come down to their technical people, these extremely agile startups are actually in search of a business model. And it goes without saying that you can’t architect a system to meet the user needs if you don’t know what the user needs are in the first place. Under these conditions you don’t use Systems Engineering, but the fact that the system under development needs to be constantly re-engineered is quite wasteful, a price you just have to pay for continually going back to the drawing board. For established businesses however, the project needs can usually be quite easily determined and documented, making the entire process much more efficient, which saves both time and money. Systems Engineering can be the difference between a project being feasible or not going ahead at all.
3. Sometimes the Systems Engineering process itself can be quite costly, depending a great deal on the tools being used and the level of mandatory processes and regulations in place at the organisation. The size of the system will determine whether the costs of using a rigid systems engineering process is proportional or not. For vehicles, infrastructure, any enterprise software, weapon systems, etc, it would be crazy not to, but for a very small component individually (maybe a resistor or a motor), the complexity of that job might not warrant the overhead of the full systems engineering process. Once again though it’s up to the tools and the organisation, Agile Systems Engineering is definitely possible
And at the end of the day if done right, eliminating all of that waste and having your systems delivered on time and to specification will ultimately save you a great deal of time, money and heart ache.