Das Dilemma des Systemintegrators

In diesem Tech-Talk geht es um Technologieentwicklung im Allgemeinen, aber vielleicht noch spezieller um die inkrementelle Technologieentwicklung. Er ist natürlich durch meine eigenen Erfahrungen in der Optikindustrie beeinflusst, wo das optische Modul nur eine Komponente in einem größeren System ist, das verschiedene technische Disziplinen wie Mechanik, Optik, Mathematik und Software vereint.

Expectations – make sure to manage them

Nicht alle einfachen Dinge sind auch wirklich einfach. Wenn man genügend einfache Dinge voneinander abhängig macht, ist das Ergebnis oft nicht mehr einfach. Dies ist oft der Fall bei Systemintegratoren, die High-End-Komponenten auslagern oder erwerben und ihre eigene Nischentechnologie und Marktkenntnis hinzufügen, um komplexe Produkte zusammenzustellen.

Eventually, the question becomes, do we meet the expectations? What expectations? In a mature market, expectations are fairly well known. Sometimes, expectations are set by the fundamental physical limits. Many mature products operate at some small factor above limits set by fundamental physics. Your phone is one such example. Already 25 years ago, phone receivers operated not that many dB above the noise limit set by temperature and Boltzmann’s constant.

Einige Produkte sind jedoch noch dabei, diese Grenzen zu erreichen. Sollte nicht jeder Produkteigentümer im Namen der Sorgfaltspflicht wissen, wo sein Produkt in Bezug auf die grundlegenden Grenzen steht? Wenn Produkte (in den High-End-Segmenten) reifen, kommen sie in der Regel dorthin.

Der Nebel von var

No, I didn’t spell that wrong. You read that correctly. So what do I mean by that? This tech talk is about system integrators and in this context, that would mean, someone who assembles a product with many moving parts which the final result depends on. As engineers, we know about calibration. This allows us to compensate for some fairly complex phenomena as long as they are repetitive, be it in time or space. For this reason, the quality of many products is measured in how far, or rather, how close, we follow the nominal target on average. The measure for this is usually the variance, but since we like to talk about primary variables instead of squared ones, we prefer to take the square root, and instead we talk about standard deviations. Nevertheless, the underlying measure of quality emerges from a sum of squares of (often) independent phenomena.

Das Dilemma des Inkrementators

This is not a dig at Clayton Christensen, but it is about the pros and cons of incremental engineering, especially in the context of system integrators. When we are measured by a quality number based on a variance, the knowledge of what ails our product can be dramatically blurred because of the nature of a large sum of squared errors, eventually represented as a standard deviation. Say we jump into a project and completely squash one of those errors, and in the end, all that effort was rewarded by a 3% improvement in the standard deviation by which we benchmark our product. That is not a fun meeting with the management. We spent 3 or 6 months of profit on a marginal performance improvement. Won’t happen again.

Was nun? Hören wir auf, uns zu verbessern? Haben wir die physikalischen Grenzen erreicht? Hier müssen wir genau wissen, wie und warum die Produkte, die wir entwickeln, funktionieren. Erhebliche Fehler können sich in einer Abweichung verbergen, und wenn wir uns nicht um die Details kümmern, werden wir nicht wissen, welches wir zuerst angehen sollen, bis wir es geschafft haben, Unmengen von kleineren Beiträgen zu beseitigen, die es zuvor verborgen haben. Und es besteht die Gefahr, dass wir nie die Gelegenheit dazu bekommen.

Eine Anekdote

Ich habe hier eine Geschichte aus meiner eigenen Vergangenheit: die Kalibrierung eines Kippspiegel-Raumlichtmodulators (SLM). So einfach das heute erscheinen mag, so schwierig wurde es damals betrachtet. Um das Problem zu lösen, erstellte ich ein Modell mit den Variablen, die ich für relevant hielt. Ich testete verschiedene Ideen, von denen sich schließlich eine bewahrheitete.

However, my approach was met with scepticism. The machine did not perform to expectations, and I received a fair amount of blowback. However, since I did pay attention to detail, I knew all intermediate results during the calibration process were perfectly aligned with model expectations. And here lies the first lesson, to keep track of our expectations. Therefore, I didn’t need to keep my head down too much, the problems were not in the algorithm. It took almost three years for the SLM charging and mechanical drift problems to be solved, and lo and behold, the algorithm started to deliver the results anticipated in the model.

Ein ausreichend detailliertes Modell zu haben, erwies sich bei dieser Entwicklung als entscheidend. Es hat weniger als zwei Wochen gedauert, es zu schreiben, und das war sogar mein erster Versuch. Das war jede Sekunde wert. Ich bin mir ziemlich sicher, dass ich sonst unter dem Druck zusammengebrochen wäre, Probleme zu lösen, die ich nicht zu lösen hatte.

Der Mitnahmeeffekt

So, what is the takeaway from all this? From my early days 25 years ago, all the way until as late as last week, I am reminded of the value of knowing what the result should be. How the product should perform. Whatever I have developed, it has been my goal to know how the product performs before it is built. Not always possible, but the ambition produces invaluable insights. Sometimes there are no shoulders of a giant to stand on. When short on giants, build models- models detailed enough to capture the complexities of your product, so you know what to expect when you turn on the light.