El dilema del integrador de sistemas

Esta charla técnica trata del desarrollo tecnológico en general, pero quizá más concretamente del desarrollo tecnológico incremental. Evidentemente, está influida por mi propia experiencia en la industria óptica, donde el módulo óptico no es más que un componente de un sistema más amplio que combina diversas disciplinas de ingeniería, desde la mecánica a la óptica, pasando por las matemáticas y el software.

Expectations – make sure to manage them

No todas las cosas sencillas son sencillas. Si se hace que un número suficiente de cosas sencillas dependan unas de otras, el resultado a menudo deja de ser sencillo. Este suele ser el caso de los integradores de sistemas, que pueden subcontratar o adquirir componentes de gama alta, añadir su propia tecnología especializada y sus conocimientos del mercado para ensamblar productos complejos.

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.

Sin embargo, algunos productos aún están a punto de alcanzar estos límites. En nombre de la diligencia debida, ¿no debería todo propietario de producto saber en qué punto se encuentra su producto en relación con los límites fundamentales? A medida que los productos (en los segmentos de gama alta) maduran, tienden a llegar allí.

La niebla de 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.

El dilema del incrementador

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.

¿Y ahora qué? ¿Dejamos de mejorar? ¿Hemos alcanzado los límites físicos? Aquí es donde necesitamos saber exactamente cómo y por qué funcionan los productos que construimos. Errores bastante sustanciales pueden esconderse dentro de una varianza y, si no hacemos los detalles, no sabremos cuál atacar primero hasta que hayamos logrado eliminar un montón de contribuciones menores que lo ocultaban. Y existe el riesgo de que nunca tengamos la oportunidad de llegar allí.

Una anécdota

Tengo aquí una historia de mi propio pasado, la calibración un modulador de luz espacial con espejo basculante (SLM). A pesar de lo sencillo que puede parecer hoy en día, en aquella época se consideraba difícil. Para resolverlo, construí un modelo que contenía lo que creía que serían las variables relevantes. Probé varias ideas y, al final, una de ellas dio resultado.

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.

Disponer de un modelo lo bastante detallado resultó crucial durante este desarrollo. Tardé menos de dos semanas en escribirlo, y eso que era mi primer intento. Valió la pena cada segundo. Estoy bastante seguro de que, sin él, me habría derrumbado bajo presión intentando resolver problemas que no me correspondía resolver.

Para llevar

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.