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".

Second Secret of Systems Integration - It's All about Networks

The (infamous) Vee-model of Systems Development Process tells us that the Systems Integration is all about hierarchies - you divide your systems into smaller and smaller pieces until you're able to make or buy the components and then you integrate them into larger and larger pieces until you've got the entire system. It's an illusion.

Really what you see in Systems Integration is a network of things interacting with each other in various ways depending on the external (or internal) excitations. You see matter, energy and data flow back and forth. And frequently your may discern the parts of the network that has much more interactions inside than outside those parts - so you can (for a time being) abstract that part as being an entity on higher level of hierarchy than the nodes of the network.

When you design the system you're free to abstract parts of it, define requirements from these parts, interfaces and input-output relations. That's convenient. In the Integration you are frequiently deprived of this luxury - everything looks like the network that doesn't organize itself naturally into the neat hierarchy of the design. Most surprizes are in those situations when the neat hierarchy shows its (unexpected) network-ness.

So the Second Secret of Integration may be formulated as "Everything is a Network - Hierarchy is an Illusion".