System Validation is the System Integration

Systems Engineering process as outlined in the ISO/IEC 15288 standard and in the INCOSE SE Handbook includes the triad of processes:

– Verification – basically testing the system against its requirements

– Transfer – delivering the system to its actual operating environment

– Validation – testing the fitness of the system to provide the intended value to its users in the real-life operating conditions.

The Verify-Transfer-Validate pattern may be considered conspiracy of the Systems Engineers against the customers and the users:

1. The Verification usually happens under the controlled conditions – in the lab or in carefully orchestrated field tests, while the Validation happens in the real-life environment.

2. The Verification is performed by the professionals – systems engineers, T&E engineers, while the Validation is performed by the users – may be with the support of some engineers, may be not.

3. The Verification is performed when the system is fresh from its assembly and the engineers that perform it have the access to the insiders’ information and to the inner working of the systems, while in the Validation the systems is almost perfectly “black-boxed” and only its inputs and outputs are visible to the evaluators.

4. The Transfer (usually accompanied by the significant payment to the contractor) ensures the interests of the contractor.

Why so many systems that are verified fail their validation. There may be several reasons:

1. The Verification is against requirements that reflect the predicted use of the system and not its actual use. More so – the conditions that the system is used in change over time -both during the system’s development cycle and especially during the system’s long period of service.

2. The Verification is done against the simulations of the systems environment and not against the real one.

3. And the most interesting of all – when the system is put to use, there is no more System – Environment boundary but actually the ongoing change in the network of artifacts and people that try together to perform their missions, disturbed by the introduction of new set of artifacts.

When the System-Environment boundary is set in the beginning of the development cycle, the whole world of the users’ experience is actually “black-boxed” for the sake of reducing the complexity.

During the Validation phase this Black Box (may I say – the Pandora’s box?) is opened and the system is integrated with the gamut of entities that were “transparent” to the system’s developers – even if “stakeholders analysis” was really done by the contractor and not delegated to the customer, as I witnessed in many cases.

So I claim that the real Systems Integration happens after the system’s transfer to the users, during the Validation phase, and what we usually call Systems Integration is just the system’s assembly for the verification.

What’s ironic that there is almost no discussion about the systems’ fate after the transfer, at least not in the SE literature. The real Systems Integration is concealed from the inquiry.

May it be so that this SI is done not by professional SEs but by the users themselves?

On the Project Management – Systems Engineering Divide

It would be nice to study how the companies divide the responsibilities of the PM/SE roles.

PM+SE is essentionally one role of project leader responsible for the whole process of developing and delibering the final product that will satisfy the customers needs at the agreed time, bring revenue and profit to the company etc etc.

When the endevour become more complex there is a need for a team such as in business where large companies cannot operate with just CEO but need CTO, CFO, CXO etc. PM (Prime Minister!) is clearly assigned the role of the boss and financist (CEO+CFO) while the chief engineer is assigned the subordinate role.

The problems usually arise on the personal level when the PM is an engineer, or the Chief Engineer think that she understands finances better than the PM. The problem here is not between the disciplines but in the specific company’s culture or in the specific project’s arrangement.

Usually the Engineering training is weak in the finances and too many projects failed due to wrong business model or sloppy financial management, so it may be prudent for the companies to place the Financier in charge and not the Engineer. I’m sorry for the SEs – I really am!

The fairy tale of Systems Engineering

Once upon the time the giants walked the Earth. They built spacecrafts, aircrafts, big ships, submarines, air defence systems. The gold was not a problem – any time when the Russian Bear growled in the woods, the Wise Councils opened their purse.

And then the Russian Bear have thrown the towel and the gold spring has gone dry (almost). Meanwile the mean gnomes have overcome the world with their fancy software gadgets, and Dragons took over the commodities market. And then the Internet came – the wild beast that nobody could tame but everybody could ride.

And the giants retreated into there cave called NCOSE and then INCOSE. Meanwile their legacy was forgotten and replaced by endless scrolls of SE standards and procedures.

Many young knights, peasants and serfs tried to seek their wisdom but they could not understand the language the giants spoke so they invented many languages of their own and the story of Babel tower repeated once more. But the giants laid silently in their cave speaking only once in a while and their voice has grown feebler and feebler until nothing was heard anymore.

I hope that I overreacted in the sadness of the fable – but this is the impression young SEs has of the SEs of old – there is a lot of wisdom but spoken in the obscure language.

Am I right or am I wrong or may be I just dreaming?

Systems Engineering is just plain old Engineering – not more and certainly not less

Sometimes the Systems Engineering community entangles itself in some kind of identity crisis and tries to explain to itsels and to the world what are Systems, what is SE and how it fits into the Engineering landscape.

I’d like to ask much more simple quiestion – what is Engineering?

I’ve read that the first person that was formally granted the title of Engineer was Leonardo da Vinchi that was tasked with “providing solutions” for (if I remember right) the Duke of Milano – either to fortify the city, build machines to invade another city or (mich more important) to organize a proper party. So it seems that initially the Engineer meant somebody that provides solutions and it didn’t matter of which kind.

With the evolution of modern science (based on the reductionistic approach that ran contrary to the Leonardo’s style of holistic enquiry – pity that his notebooks were regarded as pieces of art rather than drafts of scientific publications) the Science became fragmented to disciplines and the Engineering followed suit.

The Systems Engineering was born as a method to make large teams of engineers to collaborate to provide a solution that was not achievable by the efforts of any one of the disciplines. The Project Management was born to the same parents so these siblings became very much entangled together.

Now we have “Engineering Systems” (MIT) movement that combines technology, management and social science in order to solve problems – they claim to include the SE their technological component – so we’re back where Leonardo has stardet but the problems we face now are much more complex that those faced by the Duke of Milano.

The conclusion – Systems Engineering (or Engineering Systems according to MIT, or Integrative Engineering according to UK Engineering Academy)) is the plain old Engineering that provides holistic solutions for the customers (the modern Dukes of Milano). When the technology is required to implement a part of the solution – specialized engineers are invited to provide the tech.

The SE is not Engineering applied to Systems – that’s the “Engineering at large”.

This starting point is more comfortable and defendable (IMO) than the one that tries to carve a place of the SE amongst the multiple Engineering Departments – political establishments that will defend themselves, their jobs and funds.