by Prof. Derek K Hitchins
If you've never heard of systems engineering, you probably have some questions. If you have been a systems engineer for years, chances are you still have some questions, which you have put to one side while you get on with work. So:-
Trickier than you might think.
In fact, it seems to be one of the most overused words in the
English language.
So, let's try this:-
Perhaps the key feature of the definition is the word "interactions".
Why is this important?
But let's not get carried away - meanwhile, back at the definition. It may appear complicated, but then it has to cover a lot of cases.
all come together, then the result is "whiter than white". A trivial example perhaps, but it does work.
The idea of systems is important - it's a way of managing complexity. The Thames Barrier is (part of) a complex system for combating flooding in low-lying areas of London.
The Barrier is an example of how systems engineering can produce innovative - unprecedented - systems. If the Barrier were put in the wrong place, or if the designers had underestimated the tidal extremes that the barrier was intended to combat, then the Barrier would not work. Worse, it could cause flooding rather than prevent it.
So...yes, systems are important.
Sometimes it's easier to see what happens when people try to
create complex systems and don't use systems engineering.
Hubble was a recent, high-profile example. When the telescope was
launched, it was discovered that the mirror had not been ground
correctly.
Perhaps the engineers should have tested all the parts together
before launch, rather than wait until after launch
to find the problem? At least, that's what sound systems engineering
would have proposed.
So, why didn't NASA do full, pre-launch integration and test? I
believe the reason was "to save money". If so, the saving plan
cost a reputed $550M to rectify. Mind you, putting the
telescope right was turned into a PR triumph, and perhaps all is well
that ends well...
Sometimes it's easier to start-off by saying what you are not talking about - getting it out of the way, so to speak. Piecemeal development treats each part of some eventual system as independent. In the process, the developers of each separate part do their best, we might hope and expect, to produce the optimum part or product. So far, so good, but...
...Optimizing part of any system de-optimizes the rest. This message is pretty obvious if you think about it. Imagine some surgeon-type deciding to optimize the human heart by creating a new mechanical replacement.
Some students trying this as an exercise produced a fine mechanical heart. But:-
You see what happens when you try to optimize a part, instead of the whole system?
There are ways to optimize parts of a system. The general approach is to measure the whole system in some way, and to vary internal parts until the whole system measure indicates some optimum point.
Systematic engineering:-
True Systems Engineering creates a broad strategy to reach a Goal, using the best information available at the time.
So, True Systems Engineering is adaptable rather than rigid-prescriptive. It is truly dismaying to watch people trying to come to terms with systems engineering. Almost without exception, the first thing they try to do is to divide processes, products, etc., into separate boxes and bits. Imagine a surgeon trying to cure you by cutting out all your organs, putting them in a pile, examining and treating each one separately and then reassembling you. Woops.
This is the antithesis of systems engineering - the very problem that systems engineering is designed to overcome. Yet we seem so ingrained with Cartesian reductionism that we find it really hard to approach design and development in any other way. Just think a different way for a moment.
That surgeon uses X-rays and scanners to inform about the goings-on inside your body. He, or she, does not pull everything apart. Instead the surgeon works on any organ while it is in operation, intimately and dynamically connected to all the other organs. We must learn to do the same, not only when maintaining systems, but also when conceiving, designing and creating them, too. Instead of decomposition, we must learn to "magnify", to elaborate, to look inside at the detail while it is still in place, working and interacting in an environment provided by all the other parts and their interactions.
Well, there seem to be as many definitions as there are systems engineers. Most definitions are a bit complicated, so let's try something really simple:-
The first definition emphasizes holism, and presumes that the solution system will have a lifetime, and implies a technological/business ethic. The second, broader, definition emphasizes optimality as opposed to effectiveness, and considers the problem or issue that requires solving. Both definitions identify systems engineering as both a science and an art.
- First Principle of Systems:-
- The properties, capabilities and behaviors of a system derive both from its parts and from the interactions between those parts.
- Corollary to the First Principle:-
- Altering the properties or behavior of any of the parts, or any of their interactions, affects other parts, the whole system and interacting systems
It follows from this that neither piecemeal, nor systematic, engineering have any real chance of success.
Using these principles as a guide, systems engineering creates processes which result in the careful
of systems. The processes are designed to create systems and services which are effective, adaptable and durable. The processes also address issues of "senility" decommissioning, so covering the full life cycle.
Clearly, systems engineering is about both
process and
product. Commercial systems engineering emphasizes the
process , while unprecedented systems engineering may
emphasize the (one-off?) product or process. There is no
real consensus about a standard process model for systems
engineering. Indeed it may be that there is no such thing as a
standard process model, since this implies that it is possible to
take a single approach to any problem.
Nevertheless, the following figure shows a high-level process model:-
The view presented above is an overview of the process. In practice, this apparently sequential series of activities may turn out to be less ordered than might be expected, as situations unfold. The figure also skates over the derivation of the requirement, and the exploration of the problem space - which must, presumably, have been undertaken at some stage. The whole model is set out to be systematic, and does not reveal the essential aspects of systems engineering, i.e., creating an optimal, balanced system solution that demonstrably solves some complex problem. It may be all there, but is not visible.
The following figure takes a different stance:
The top level shows the development of a solution concept, and refers to Steps 1-6 of the Systems Methodology. The output, the preferred system option, will be a set of matched systems specifications, devoid of any solution such as specific people, process or technology, which will be realized in the lowest, project row.
The second, or middle row, looks at the business aspects of the project. It reveals that part of the role of systems engineering is to design the impending project, and in particular identify the process an the tools and methods to be employed. The project will not be run by a systems engineer, however, but by a project manager, who will execute a project management plan agreed between himself and the system engineering process designers. The project team will employ, inter alia, systems engineers along with equipment engineers, reliability and maintainability engineers, software engineers, etc., etc. So, systems engineering can be seen in each of the three levels in the diagram: exclusively in the top row; working with business and project management in the second row; and working for the project manager in the bottom row.
Looking specifically at the bottom row, it can be seen that Steps 2 to 7 of the Systems Methodology are being applied. So, although this model is systematic, it is also systems engineering. Note particularly that the final proving sessions will include the original symptoms from the Problem Space - top left - so proving the overall process has, indeed, resulted in an optimal solution system to the original complex problem.
Note:
|
USA |
|
Japan |
|---|---|---|
|
Profit |
|
Survival |
|
Free |
|
Between circles |
|
Free Market |
|
Indiginization |
|
Production Push |
|
Market Pull |
|
Cost Plus |
|
Market Minus |
|
Adversarial |
|
Synergistic |
|
Specialist |
|
Homogeneous |
|
Hire and Fire |
|
Jobs for Life |
|
Specialization |
|
Multi-skilled |
|
Lowest Bid Wins |
|
Vital source - protect |
|
Supplier stocks |
|
Nobody stocks |
Japan is already commercially-based. The West is struggling with transition, still dominated by its Cold War defense heritage. Both parties seem to be overlooking item 3.
The archetypal modern approach. Often criticized for being slow, since each stages is required to be finished and completed before going on to the next. This waterfall approach has the effect of maintaining proper balance between the developing parts, however, and the waterfall approach is much easier to manage than other approaches, all of which can be seen as variations on this archetype.
the Spiral is employed where those creating the solution are uncertain as to the technology, or perhaps even the overall solution. A series of prototypes are produced and tried, with the creators learning as each prototype succeeds or fails. The spiral can be unwound, when it appears as a waterfall.
Disguised waterfall, using an eclectic collection of techniques
Concurrent engineering is popular as a means of reducing time to market, and of cost - which is often seen as proportional to time. There is something of a risk, in the context of telescoping activities, that crucial information will emerge only late in the execution of some activity, rendering earlier outputs from that activity in adequate or even incorrect. If the earlier outputs have been used by successive activates, it may be necessary to rework some of the activity network. In the worst case, there can be a ricochet through the project. Essentially, then, concurrent engineering can result in a project that is somewhat brittle, i.e., susceptible to shock.
This is a straightforward approach, as the figure shows. It totally eschews all notions of reduction, being instead entirely based on synthesis. It presumes that the customer knows what he/she wants and needs - not always the case. Customers sometimes know what they want, but rarely know what they need.
One view of systems engineering is of a series of procedural phases. This is, to be sure, much more a view of systematic engineering than of creative systems engineering. However, it is a view held by many engineers, and so is included here.
The figure above shows one notional phase, Phase N. The input to this phase is the output from a previous phase, namely a specification of some kind. This is largely a data-driven view of systems engineering, i.e., that what flows through the project is an ever-increasing tide of information describing every aspect of the future solution system. See the table of specifications below:
In keeping with this notion of creating a tide of data and information about the solution system, a wide variety of skills is envisaged. A typical list follows:
The SE Project phases can be shown in waterfall form, see below. Note that Equipment Engineering and Software Engineering are not considered as Systems Engineering, per se, but are viewed as classic engineering, with all that implies in terms of reductionism, decomposition, etc., all of which are alien to systems engineering.
The same is true for the following diagram, which shows the outputs expected from each project phase.
The five project subsystems referred to are:
The following diagram is an organization chart, showing typical influences, activities, considerations and outputs. Note that Project Support activities apply across the board.
It may be practicable to organize all of the above into one machine-supported system for conceiving and creating system solutions to complex problems. The picture above presumes a number of such systems at various sites. The whole program would consist of a set of projects, with the whole set constituting the whole solution system. Each major part/subsystem/partition of the overall solution system would itself be a major system, and would be subject to a team of analysts and engineers using SEAMS to support their activities. Built into SEAMS would be, not only the specifications from above, but also the tools from the so-called Shadowboard below, which shows the range of tools, methods and techniques often used by system engineers and others working on systems projects.
Well, that's just a flavor of one of the most important subjects about at the present time. If you want to know more then you might consider joining INCOSE the International Council on Systems Engineering.
Last updated: 2005
