Predicting the future of Systems Engineering

When invited to the Stevens Institute of Technology to speak about Systems Engineering, former NASA head Dr. Griffin talked about bringing to life "elegant systems" and by "elegant" he meens effective (bringing value to the users - system that actually works), efficient (bringing the value with acceptable use of resources - including mental resources of the users), robust (bringing the value in the broad range of conditions and situations) and without unintended and unexpected negative behavior.

Jack Ring talks about "Quality, Parsimony and Beauty".

There seems to be an agreement what "good system" is.

Dr. Griffin also talks about the origins of Engineering - in civil/military engineering first there were "best practices" or "state-of-the art' passed to talented apprentices from successful masters , then there was the science that explained why "the best practices" actually work (structural analysis explained why the bridges didn't fall).

Now in SE we're in the stage of artistry just like other branches of Engineering were in the 19th century.
Until the SE will not be able to provide consistent stream of "good systems" (just like it did in 50s and 60s aerospace and missiles) this profession will suffer more and more indignity from other practitioners.

I'll dare to say that the the Software Engineering is in the very same position, even that the SWE and SE are in the same category of "Complexity Engineering".
It's ironic that the ubiquity of SW in our world, increasing reliance of systems on the SW components and the williness of the public (until the Apple revolution) to accept non-elegant SW (Microsoft?) will not harm the SWE but will harm SE that builds non-elegant systems based on non-elegant software. Vulnerability of critical systems to cyber-attacks is seen as the SE problem not the SWE problem, while any success of anti-hacker software will be credited to SWE and the success of systemic solution to the same problem will go unnoticed.
Just as the UK INCOSE brochure states - bad SE is in the news, good SE is invisible.
As I said earlier - our profession suffers from the fact that its successes are not celebrated anymore (as the Apollo's success was).

Have we examples to celebrate "good systems' and credit them to the success of the SE? These will be the examples for the "elevator's speech" - "I'm the Systems Engineer and I'll do for you what my collegues did for those guys!". Anyone?

So I'll dare to predict that if the SE will not find the way of consistently bringing to life "elegant systems" and receive the credit for this our profession will wane and disappear. The future is in systems. But if consistent methods will be found then the sky (or space) is not the limit!

Practitioners vs Professors

When one talks about a SE discipline it's good to know whether we're in academic or industrial settings.

Academic engineering is a pretty new thing - once the engineers were educated by apprenticeships not by universities.

I think that in industry the SE is assigned rather specific task in the new product development process - in the defence setting the SE tasks are even mandated.

In academy the situation is different. What is Electronics Engineering Research if not the search of the new electronic technologies - sometimes the advances in physics are needed to advance the electronics but not always - so that's application of science not discovery.

The "hard engineering" disciplines are rooted in the exact sciences. That's not so for SE - the scientific component of the SE borders (some say lays in) social sciences domain - sore spot for academicians that thrive to belong to the Engineering part of the campus near the Physics, Chemistry etc buildings. The same challenge is faced by the Industrial Engineering practitioners and researchers.

So until we don't admit that SE science is inherently social we'll be stuck. Let's be true to ourselves - SE science is the science of social behavior of large groups of technical practitioners and managers (project teams) engaged in solving complex problems for other groups of people (stakeholders) by defining, developing, integrating and putting to use physical artefacts (systems).

On the discussion what is Systems Engineering

In the still active discussion of what Se is I think we've forgotten the primary tenet of the SE - the functional/structural duality.

"Systems Engineering" is a set of functions in the systems development process - encompasses different subfunctions such as requirements engineering, integration, V&V, technical coordination - see Sarah Sheards 12-role of SE for the reference. The core of functions contained inside SE is rather clear but there are "border skirmishes" in the areas of overlap with Industrial Engineering, PM and - yes - Systems Admin activities in the IT industry.

"Systems Engineer" is a structural element in the company/project organization (organizational position) that may (or may not) be assigned to perform SE functions. The company may call the position SE and may call it something else - for the person that fills the position the functionality and responsibility is what counts.

"Systems Engineer" as a person is something else - it's a matter of abilities and knowledge. David Snowman in his ASHEN model of knowledge distinguishes between various components of knowledge - Natural talents, certified Skills, gained Experience, mastery of the field Heuristics and access to the Artefacts of the professional field - reference books, special equipment (DOORS?) etc.

So the problem is of the degree of overlap between the specific persons's abilities (defined chiefly by herself), the responsibilities and authorities of the specific job position (as defined by the appropriate functions in the organization) and between the field of SE defined rather well by INCOSE or by SE degrees curricula.

We as SEs must not confuse functions, strructural elements and people!

Systems Integrator's Three Worlds

Austrian philosopher Karl Popper has distinguished between Three Worlds:

• World 1 of physical object and events, accessible by all human beings given the right perceptions or equipment
• World 2 of mental objects and events, the inner world of human being accesible by only this human, and
• World 3 of objective knowledge that comprized the products of human thought - ideas, theories, stories, myths etc.

The World 3 objects are frequently encoded as Words 1 objects - books, articles, drawings, paintings that are commonly known as information artefacts.

I think that the difference between Systems Integrator/Engineer and Specialty Engineers is fundamental and stems from the difference in their World 3 products (as encoded in information artefacts):

• Specialty Engineers (SpecIs) encode their mental models in executable information artefacts that allow production of physical objects by machines or skilled humans that don't have to share the engineers mental models. Examples - computer code is used by compiler/builder to encode physical computer file that may be run by a computer, mechanical drawing allows production of parts by workers/robots, electrical diagram allows to produce a circuit.
• Systems Engineers'/Integrators' mental models are encoded in information artefacts (or even communicated without physical encoding building the common understanding -the pure World 3 object) that are meant to create compatible mental models in the minds of other engineers. In that SE/SI are just like to architects, managers and leaders.

The line of distinction between SE/SIs and SpecIs may move with the evolution of technology - once non-exectutable information artefacts may become executable - one example is executable specifications/models that once needed skilled programmer (SpecI) to convert them to the executable code and now this job can in some cases be done by a machine.

It's common that engineers perform both roles of SE/SIs and SpecIs so they have to be educated in these fairly distinct skill sets.

Summarizing: SpecIs produce executable information artefacts meant to be used in production, SEs/SIs produce World 3 objects meant to communicate mental models between engineers and other professionals, without directly leading to the production.

Test to Learn, Test to Debug, Test to Evaluate

The lot of discussion is going on about the differences between Systems Integration, Systems Testing, Development Testing, Operational Testing etc. A lot of confusion... totally unnecessary in my opinion.

The problem with the above definitions that they reference the types of testing to the methods, responsibility etc. but not to the purpose.

I'd like to propose more natural (for me) distinction - Test to Learn (or to Discover), Test to Debug (or to Solve Problems) and Test to Evaluate (or to Judge).

Learning is the process of acquiring knowledge that previously was not in the posession of the learner. The testing that is focused on learning is always explorative, with the path that may wind and twist and loop. More than that, Test to Learn will never end - there will be always missing knowledge.

Debugging is the process of finding anomalies, investigating the causes and fixing the system. Integration is essentially System Debugging.

Evaluation is the judging the system against some criteria in order to accept or reject some proposition. Testing is the activity that may be a part (but not the whole thing) of either the Debugging or the Evaluation. (System Testing is essentially System Evaluation.

When the managers say "Start Testing. When you'll find severe problems, investigate them and change the system. When the problems are not severe - proceed" they ask to start in the Evaluation Mode and change to Debugging Mode amidstream. Start as ST and change to SI if needed. No wonder that it's difficult for me to explain the difference between SI and ST - the managers frequently perceive the pair-wise encounters of some sub-systems that are done as part of sub-system testing combined with interface checking as the sufficient SI activity and try to drive the project into ST mode without conclusion of all SI activities such as E2E thread testing - they afterwards wonder why the ST phase takes as long as SI+ST phase that was proposed in the initial project plan and rejected as "too long ST".

I'd be delighted to forfeit talking about "System Testing" or "System Integration" and change to "System Debugging" (Subsystem Debugging, Interface Debugging, Whole System Debugging") and "System Evaluation" (or "System V&V").

Learning, Debugging and Evaluation are not just Testing - there is a lot more that's going on - discussions, arguments, reading, eriting, thinking - but when the Testing is concerned the disctinction of the type of Testing by purpose has its merits and for me is more useful.

Fourth Secret of Integration - Intelligent Evolution

Some circles still dispute relative merits of the Theory of Evolution and Belief of Intelligent Design. Without entering the fray myself I want to ask: Intelligent? Design? The proponents of ID claim that the complex system we observe in nature are so beutiful that this suggest that somebody has designed them. The Book doesn't support this claim - it specifically states that God has created the world and not designed. So I suppose the ID people just grant us engineers too much credit - we tend to give up design and turn to evolution when faced with complexity not other way around.

Paul Graham in his essays reveals the secret of creative programming (and writing, and building start-ups) - build something that works and then iterate until it's good. Refactoring patterns of Agile Programming suggest the same. Fast Prototyping - once again. We know that the evolution is better than design. It's exactly what Integration is all about - evolving the system until it's fit for the Judgement Day - sorry - the System Testing.

So the Fourth Secret of Integration may be formulated as "The Integration is an Intelligent Evolution of (hopefully) Intelligently Designed Systems until they're fit to be Judged".

Third Secret of Systems Integration - There is Always Lack of Knowledge

One more illusion of Systems Engineering is the assumption that the system will behave as required and designed. This illusion is not hubris - in the software world it is possible (at least theoretically) to design the system to do exactly what is required - as long as the logic is the only concern. But when the real world starts to assert its rules of physics, chemistry and more than that - biology, psychology etc. - the lack of knowledge how the system will really behave becomes profound.

Sure that it is possible to know enough to any purpose as long as we're aware that the lack of complete knowledge harbors the eternal promise of surprizes. When the surprize hits it becomes the really wicked problem. The only solution to this eternal lack of knowledge is the eternal learning - and the Systems Integrators have to excel in learning just for their professional survival.

The Systems Integrators always start with the lack of knowledge - for all things equal they usually are not those who have designed this vile creature to be integrated. More that that - there are always parts on the bottom of the hierarchy (the Second Secret nonwithstanding) that are not created by us but are bought from somebody that may not reveal the whole bunch of their properties. Or even the natural things that for them the lack of knowledge is inherent.

The lack of knowledge is not an excuse for Systems Integrators. They have to tell the system's story (the First Secret) and to deal with the networked nature of the system (the Second Secret). So the Third Secret of Systems Integration may be formulated as "There is always missing knowledge that th SI has to discover in order to succeed".