Systems Design, a key part of systems engineering in danger of being overlooked, forgotten even - at least, in some sectors of industry. The practice has grown of customers/stakeholders providing detailed requirements to engineering companies, for those companies to effectively 'build to order.' Systems engineering, however, runs from conception to grave, from lust to dust, or whichever contemporary expression is used to indicate the extremes of the so-called life cycle.
For a customer to give detailed requirements to a contractor for a system-to-be-engineered, implies that the customer has undertaken the earlier stages himself, including: exploration of the problem space; problem survey; generation of conceptual remedial solutions; purposing; generation of CONOPS; threat assessment and management; systems design; systems optimization; etc. Some customers have the necessary expertise, and undertake the full systems design themselves, considering perhaps that they are the experts in a particular problem domain, that they understand their problem best, and that they know exactly what they want as a solution to their problem.
If the customer has done all this vital work, (or has, perhaps, employed others to do it for him) then the information would prove invaluable to the contractor, and so should form part of the requirement documentation, allowing the contractor to understand the context, as well as the specifics. The contractor can then appreciate the systems design rationale, identify other systems with which his part will interact operationally, appreciate the future operating environment, etc., etc. If needs be, the contractor may review the customer's systems design, and query obscure, invalid or missing aspects. If, on the other hand, the customer has neither done this work, nor had it done for him, then there may be problems ahead for the contractor; if the contractor creates to the customer's specification, and the solution 'bombs,' then it will not be the customer whose reputation is sullied...
A byproduct of this recent practice (previously, systems engineers provided turnkey solutions to customers' problems, i.e., 'did the lot') is that contractors, maybe, and customers, probably, are less practised at designing systems from scratch to solve customers' problems. So much so, that many current practising systems engineers may not recognize systems design as any part of systems engineering, let alone a key part.
This is unfortunate, since systems design can be (should be?) the most creative, innovative phase of systems engineering, and one where it is possible to manage great complexity using systems methods, systems thinking, systems science, etc. So much so, that contractors who have been presented with a customer's requirement specifications only, may consider it advisable to undertake overall systems design for themselves, to see if the customer has identified the real problem (customers have been known to be so close to a situation that they do not identify the real problem...), if they really understand the customer's problem, and if they concur with the customers designed solution...
"A good idea in principle, but how would you go about it in practice?" Good question.
Systems design methods have been considered, in the past, to be esoteric, arcane even; to be sure, systems design can involve abstract, conceptual processes, and it is not everyone's 'cup of tea.' It is, perhaps, for the more serious student of systems engineering, for those vying to become systems architects. Systems design, if it is to be sound, adopts the 'systems approach', and observes the following basic principles:
- holism: concerned with the creation of wholes, i.e., complete, self-contained systems; and with a complex system being more than the sum of its parts (whence emergence)
- organicism: the conception of systems as organismic, i.e., being organized, having internal organ systems, yet behaving as a unified whole
- synthesis: making a whole out of parts; the combination of separate entities into a unified whole
In that spirit, see the following monographs, which should ideally be read in order for the first time of reading, since each builds on what has gone before.
- Systems Engineering Open Systems.This paper looks at open systems, those that exchange information, material and energy with their environment, and identifies the internal features that must exist within every open system to manage that exchange and flowthrough. These features form the basis for a reference model, which can guide the design of systems, and which can be used to test for design integrity and completeness
- Synthesis - the Essence of Systems Engineering. This paper gets to the heart of what systems engineering is: not engineering management, not even design, really, but synthesis to create solutions with emergent properties
- System Design Feasibility Study for The Autonomous Peace Officer (APO).An APO is one that can think and act autonomously. No such thing exists at present, but trying to design one reveals the ins and outs of systems design... In this design study, you can see the essential creativity and innovation, for which systems engineering is renowned, in action
The three monographs will not explain how to design specific systems; but, they should give the reader some idea of how to go about systems design for him-or her-self. Together, they give some idea of how systems design might be approached as an integral part of the Systems Methdology: which may consequently make useful follow on reading
Watch this space for more on the same subject... systems design is at the heart of systems engineering: so much so that, if some process, project or program omits systems design, it may be unreasonable to consider that process, project or program as systems engineering... By comparison, would a process without engineering design be worthy of the title 'engineering'?
Derek Hitchins.......................................................................................................................................August 2008