Blackboxing, AppleWatch and Engineering

The Science and Technology studies by Bruno Latour, John Law and others have used the concept of “blackboxing” to indicate the ability of scientific facts or technological artifacts “to stand on their own”, without need for explanation, justification or training.

For example, there are scientific facts that have become “common knowledge”, that “everyone knows them”, that nobody disputes them. The matter is made of atoms, atoms are made of elementary patricles. Elementary, Watson? Who’d discovered that? Historians of science will tell us. Do we care? Not so much. Is it true? No, it is not. There are elementary particles that are not bound in atoms (think free electrons in the electrical wire). Quantum physics even disputes the notion of particle replacing it with a wavefunction of probability.

Why do we think that the abovementioned facts are true? Because they were “blackboxed” by the scientists and educators for public consumption. Inaccuracy makes things more simple, details confuse. The abovementioned scientific facts are models of reality sufficient for some situations, insufficient for others. And when we’re faced with the best models we don’t ask for the provenance, we don’t question the authorities that utter them.

What is it about machines? When I drive my car I don’t think of all the parts it’s made of. Wait until the car breaks down and is hauled to the mechanic’s shop – then I’ll learn about its parts. The hard way. From the mechanic’s bill. Coils, switches, shafts. Dollars, Euros, Shekels.
AppleWatch is beautifully blackboxed. Nobody but hackers (and Apple technicians) will ever open it, will ever allow the layperson to be interested about its innards. All the consumer needs to know is that the Watch comes from Apple and thus it’s cool by definition. What if somebody is shown the AppleWatch and not told that it comes from Apple – will it be cool? Yes, I think so.

Hey, wait a minute! What can the Watch do without a nearby iPhone? Not much. It cannot be connected to the AppleVerse of applications, iTunes and other cool things that Apple is so good of integrating together. So to be AppleWatch, the watch cannot be totally blackboxed.

Is the Watch+iPhone integrated pair blackboxed?. No, it isn’t, at least not out of the box. If Iphone is too far then the Watch is less AppleWatch. The user has to “mind the gap”. Actually, in some situations the user may forget about the iPhone-Watch interface and enjoy the blackboxed experience, until she leaves her iPhone on the desk and walks away with less-AppleWatch-ed watch.

In the integration phase of Systems Engineering we gradually blackbox components and hope that they will stay blackboxed. We blackbox the suppliers statements that the components work as required, after (or not) perusing the test reports – more thoroughly for the first article and more perfunctorily for the next one, until its design is modified and then we’re surprised that we have to un-blackbox it and start to question the supplier again.

When we deliver the system. we try to blackbox it to the customer. The customer will blackbox it for the user, making, for example, the power supplies or communication networks “transparent”.

But when some problems appear – the power supply doesn’t comply with the spec, the communication bandwidth is insufficient – then, presto, the whole picture is un-blackboxed, the robustness of the artifacts is questioned, their internal structure exposed, and the debugging begins in earnest.

So, we Systems Engineers have to mind the tension between our desire to blackbox things and the Nature’s desire to open the Pandora’s blackboxes!

No it remains to be seen how the black-boxed Apple fan-base will respond to the actual sales of the AppleWatch!

Advertisements

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.

Engineering in 3D – Design, Debug, Deliver

Engineering in 3D- Design, Debug, Deliver

Generally, Engineering is all about Design. No Design, no Engineering – at least that’s what almost every Engineering graduate may think. No Design, and the Engineering becomes trial and error.

But the engineers forget that the Design is only one dimension. Two others are: Debugging and Delivery.

Quoting the great Thomas Edison: “It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that “Bugs” — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached”. 

Design abstracts the reality of the product in order to make the engineering reasoning and communication easier. Modern design techniques allow the engineers predict with reasonable conviction that when produced, the product will work as expected. But this prediction is not enough. There’s still a need for the prototypes to test and debug the design.

Let’s assume that the product have passed all the tests designed to verify its conformance to the requirements. That’s not enough too – the product must work in the intended environment, as part of larger system – either another product, a system or the customer’s business or operational environment.

During the product’s integration into its intended environment one can expect bugs – lots of bugs. Some will be caused by the product, some by the environment, some by the interaction between the product and the environment. Only when these bugs are eliminated then the product will finally be delivered.

So the engineers must see their profession in 3D – Design, Debug, Deliver!

 

Philosophy, science, engineering and Systems Engineering

Philosophy, science and engineering are related to each other in rather interesting ways.
Philosophy starts when there is insufficient basis for science. The investigation of both the physical realm and the realm of the mind started with philosophy – the natural one and the cognitive one. The physics has almost completely replaced the former and the psychology gradually replaces the latter.
As the science replaces philosophy as the main method of inquiry, the philosophy moved further toward the philosophy of the science itself.
The engineering is something else. The engineering is an art to create things that work as required or expected. Some engineering uses science to predict the behavior of the artifacts, some engineering triggers scientific investigation into the reasons why something works.
In the recent years, there is a movement to create the philosophy of engineering that will try to explain how people create things.
By continuation of the trend, shall we speak in the future about the science of science, engineering of science, science of engineering or may be even engineering of engineering?
By the way, we already have engineering of science in the guise of the design of the scientific investigations and the engineering of engineering in the guise of Systems Engineering! Funny, isn’t it?

Posted from WordPress for Android

Re-search

One of the tenets of PhD research is to reach very extensive knowledge in the field of inquiry. When I wrote my MSc thesis on the properties of a specific type of antennas, the body of knowledge to cover was a fairly restricted one – I knew which journals published relevant papers, who are the people in the field.
I suppose that is the case in all established fields of study. The problem is that Systems Engineering is not an established field of study. Researcher of the systems development processes belong to the very diverse range of disciplines – I’ve found relevant papers in the business administration, marketing, industrial engineering, software engineering, anthropology, ergonomics and, yes, some systems engineering papers.
The flip side of the above problem that almost any topic one chooses is a greenfield study for the systems engineering. Everything’s good, nobody’s written anything on the topic. You can found a new field of research in minutes, only to found your ideas already discovered in, for example, industrial marketing. Does bringing an idea to the SE from another field count as new knowledge?
In the academic practice, the re-search means discovering existing knowledge, organizing it in some way and adding something new to the appropriate body of knowledge. In the field of SE, what does count as the body of knowledge – hard-won truths about how people develop systems or the documentation of “best practices”? I don’t know. I’ll try do discover.

PhD Advising philosophy

It seems that there is a wide range of the PhD advising philosophies. One of my friends that recently completed his PhD had an adviser that gave him research and other tasks that were seemingly unrelated to his declared topic, but in the end the results did amount to a thesis. That’s one end of the range – the adviser has total control on his student’s work.
My adviser is completely at the other end of the spectrum. When asked about her advising philosophy, she gave me three principles:
1. The student is totally responsible for his work.
2. Adviser’s job is to advise, to respond to the student’s questions, to evaluate drafts and notes and to help to navigate the academic establishment.
3. The student will not fail his exams and evaluations if the adviser says that the student is ready. But there is a catch: the adviser may say that the student isn’t ready indefinitely, it’s the student’s job to become ready.
Nice strategy, rather high-risk for the student but allows him the outmost freedom in his studies and research.
By the way, in this setting the adviser acts as a customer that represents the project stakeholders-the editors of the journals, examinators or grant benefactors. So the PhD may be organized as a project, even as an agile project. Our article on “Agile principles for research” awaits publication on the InfoQ website.

Posted from WordPress for Android

Why is this blog called “Sanity Test”

I need to be insane to start a PhD while working full time and raising three boys and a dog.

Actually one wise man said that to complete a PhD while working full time one has to be afflicted with OCD. Yes – Obsessive Compulsive Disorder. So I have to be insane to succeed. So I need to devise a sanity test – to test that I’m really insane.

What is more insane that I try to make my research in Systems Engineering while there is no SE department in my country, so one has to attach itself (gender-neutral!) to some Engineering Department – Aeronautical, Mechanical or Industrial. But I made my MSc in physics – well, applied physics but still not engineering. Sure, I have also ME in Systems Engineering – but that’s inter-departmental thing so no PhD track…

So I enlisted in Science and Technology Education Department. I have a swell adviser that some say accounts to at least 50% of the PhD. But – I have to take some credits in the Education-related courses – so I study psychology – developmental, cognitive and social, basic training in teaching and some more courses – nice broadening of horizons for the physicist/SE. 

My research interests and the department affiliation (teaching is interesting!) takes me to the topic of education and training of SEs, and because I’m an Integration&Test Engineer so naturally my interests focus on the “end game” of systems development ans assimilation, and certainly debugging, debugging, debugging (by the way that’s a hardware term abducted by software guys and gals).

Back to the insanity – as fit researchers in other field the best way to study a decease is to infect yourself and then report from within. So I’ll try to report in this blog how my life is going in my PhD studies while working full time, walking with the dog and waking with the kids.