Il dilemma dell’integratore di sistemi

Questo Tech-Talk riguarda lo sviluppo tecnologico in generale, ma forse più specificamente lo sviluppo tecnologico incrementale. È ovviamente influenzato dalla mia esperienza nel settore dell’ottica, dove il modulo ottico è solo una componente di un sistema più ampio che combina diverse discipline ingegneristiche, tra cui meccanica, ottica, matematica e software.

Expectations – make sure to manage them

Non tutte le cose semplici sono in realtà semplici. Se le rendi abbastanza interdipendenti, il risultato spesso non è più semplice. Questo è spesso il caso degli integratori di sistemi che possono affidare la produzione di componenti di alto livello a terzi, aggiungere la propria tecnologia e le proprie conoscenze di mercato per assemblare prodotti complessi.

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.

However, some products are still in the process of reaching these limits. In the name of due diligence, shouldn’t every product owner know where their product stands relative to fundamental limits? As products (in the high-end segments) mature, they tend to get there.

La nebbia del 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.

The incrementor’s dilemma

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.

What now then? Do we stop improving? Did we hit the physical limits? This is where we need to know exactly how and why the products we build perform. Quite substantial errors can be hidden inside a variance and, if we don’t do the details, we won’t know which one to target first until we’ve managed to squash slews of minor contributions that used hide it. And there is a risk we will never get the chance to get there.

Un aneddoto

Ho qui una storia del mio passato: la calibrazione di un modulator ottico spaziale a specchio inclinabile (SLM). Considerata la semplicità di questa soluzione oggi, all’epoca era considerata difficile da risolvere. Per risolvere il problema, ho costruito un modello che includeva le variabili ritenute rilevanti. Ho testato diverse idee e alla fine una di esse si è rivelata la migliore.

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.

Disporre di un modello sufficientemente dettagliato si è rivelato cruciale durante questo sviluppo. È bastato meno di due settimane per scrivere tutto, e questo era persino il mio primo tentativo. Valeva ogni secondo. Sono abbastanza sicuro che senza di esso sarei crollato sotto pressione nel tentativo di risolvere problemi che non erano miei.

Il messaggio principale

Cos’è dunque l’importante da trarre da tutto questo? Dal mio inizio, 25 anni fa, fino all’ultima settimana di quest’anno, mi viene ricordato il valore di sapere quale dovrebbe essere il risultato finale. Come dovrebbe funzionare il prodotto. Qualunque cosa io abbia sviluppato, il mio obiettivo è stato quello di conoscere come funziona il prodotto prima che venga realizzato. Non sempre è possibile, ma l’ambizione porta con sé intuizioni inestimabili. A volte non ci sono giganti su cui appoggiarsi. Quando mancano i giganti, costruisci modelli – modelli dettagliati abbastanza da cogliere le complessità del tuo prodotto, così da sapere cosa aspettarsi quando accendi la luce.