Un producto conectado puede parecer terminado mucho antes de que se complete su desarrollo. El prototipo es estable, los datos llegan a la nube, la aplicación muestra los valores correctos y los primeros dispositivos ya están en manos de los usuarios. En ese momento, el backend puede ser lo suficientemente simple como para que el equipo conozca casi cada dispositivo individualmente. El aprovisionamiento se puede gestionar con un script, los cambios de configuración se pueden realizar manualmente y, si algo falla, un ingeniero generalmente puede rastrear el problema directamente.
Entonces, debe comenzar a desenvolverse en el mundo real. Aparece una segunda revisión de hardware. Algunos clientes siguen utilizando la primera revisión. Las versiones de firmware comienzan a divergir. Se necesita una nueva configuración para un cliente o mercado diferente, mientras que los dispositivos más antiguos aún requieren actualizaciones y soporte.
No es necesario que nada esté roto. El software que hay detrás del dispositivo simplemente ha adquirido su propio ciclo de vida.
Esa transición puede pasar desapercibida fácilmente, ya que el prototipo puede seguir funcionando a la perfección. Pero cuando varias versiones del mismo producto físico deben coexistir en el mercado, el backend deja de ser simplemente la infraestructura que respalda el hardware y se convierte en parte de la arquitectura del producto en sí.
Un prototipo funcional y conectado aún no es un producto escalable.
Un prototipo tiene una función importante: demostrar que el sistema funciona de principio a fin. El dispositivo realiza su función principal, el firmware se comunica con el sistema de backend, la telemetría llega a su destino, los comandos se envían de vuelta y una interfaz móvil o web expone la funcionalidad al usuario.
Lo que normalmente no ha demostrado es cuán bien maneja la variedad el mismo sistema.
Es posible que los primeros veinte dispositivos utilicen el mismo firmware, se hayan fabricado con la misma revisión de hardware y hayan sido configurados por los mismos ingenieros. En esa etapa, el registro manual, los cambios de configuración directos o un pequeño script de incorporación pueden ser perfectamente adecuados. Sin embargo, desarrollar herramientas de producción antes de que el producto haya demostrado su valía podría ser prematuro.
La escala cambia el problema. Los dispositivos se desconectan, se reemplazan, utilizan firmware diferente y requieren configuraciones de cliente distintas. El equipo de soporte debe distinguir entre una unidad que nunca se configuró correctamente y una que está mal configurada o simplemente inaccesible.
La deuda técnica de los prototipos suele comenzar así: no con una mala decisión, sino con una temporal que permanece vigente incluso después de que el producto haya evolucionado. Y uno de los primeros factores que hacen evidente esta transición es el propio hardware. Una nueva versión no simplemente reemplaza a la anterior; debe coexistir con ella.
Cada revisión de hardware crea un problema en el ciclo de vida del software.
Es raro que una nueva revisión de hardware sustituya directamente a la anterior. En la práctica, ambas versiones permanecen en uso, a veces durante años. Si a esto le sumamos un lote de transición, algunas variantes de firmware y configuraciones específicas para cada cliente, la flota se vuelve rápidamente más diversa de lo que sugiere el modelo de producto original.
La capa de software ya no puede tratar cada unidad como un “dispositivo” abstracto. Necesita saber de qué es capaz esa unidad en particular.
Una placa revisada puede usar un sensor, módulo de comunicación o controlador diferente. Un comando válido para la última versión puede no ser compatible con una versión anterior. Los valores de calibración pueden cambiar. Los límites de configuración pueden variar. Un paquete de firmware adecuado para una generación puede no ser seguro para otra.
Los ingenieros de productos físicos ya trabajan de esta manera. Dos componentes que parecen casi idénticos no son intercambiables si sus revisiones, tolerancias o especificaciones difieren. Los productos conectados plantean el mismo problema en el ámbito del software: la plataforma necesita una forma fiable de comprender con qué versión del producto físico se está comunicando y qué reglas se le aplican.
Consideremos un producto cuya primera revisión utiliza un procedimiento de calibración, mientras que la segunda introduce un nuevo sensor y un conjunto diferente de parámetros. Para el cliente, ambas unidades pueden seguir siendo el mismo producto. Para la plataforma, no pueden serlo.
Si esas diferencias no se representan explícitamente, tienden a filtrarse en la lógica de la aplicación como casos especiales. Un flujo de trabajo verifica un rango de números de serie. Otro utiliza una versión de firmware como indicador de la generación de hardware. Un tercero contiene una excepción añadida después de que el soporte técnico detectara que un lote anterior se comportaba de forma diferente en el campo. Ninguna de estas soluciones parece especialmente peligrosa por sí sola, pero en conjunto dificultan la comprensión de cualquier cambio futuro.
El hardware antiguo rara vez desaparece según lo previsto. Los equipos de producto se centran, naturalmente, en la revisión más reciente, mientras que los clientes suelen conservar las versiones anteriores mucho más tiempo del esperado. Por lo tanto, la plataforma debe ser compatible con varias generaciones simultáneamente, en lugar de asumir que la base instalada convergerá en un único estado actual.
Una vez que esto sucede, la evolución del hardware y la gestión del ciclo de vida del software se vuelven inseparables. La plataforma necesita saber no solo dónde se encuentra un dispositivo y si está en línea, sino también qué es, qué puede ejecutar, cómo debe configurarse y qué cambios se pueden aplicar de forma segura.
Y antes de que se puedan responder de forma fiable a cualquiera de esas preguntas, cada dispositivo tiene que entrar en el sistema de forma coherente.
El aprovisionamiento es donde la ingeniería manual deja de ser escalable.
El aprovisionamiento parece sencillo cuando la flota es pequeña: se crea un registro de dispositivo, se introduce un número de serie, se generan credenciales, se asigna la unidad a un cliente, se aplica una configuración y listo. Sin embargo, para varias docenas de dispositivos, gestionar parte de este proceso manualmente puede seguir siendo la mejor opción.
Sin embargo, a escala de producción, el aprovisionamiento se sitúa en la intersección de la identidad del dispositivo, las credenciales, la propiedad, la configuración y el estado del ciclo de vida. Un error cometido durante la incorporación puede afectar al funcionamiento y al soporte de la unidad mucho después de que salga de fábrica.
Una hoja de cálculo puede no coincidir con lo que está realmente instalado. Un dispositivo de reemplazo necesita la asociación de cliente correcta sin heredar la identidad incorrecta. Los restablecimientos de fábrica crean otra ruta en el proceso. Un instalador puede asignar una unidad a la cuenta incorrecta, lo que obliga al soporte técnico a determinar si está sin conexión, si se ha configurado incorrectamente o si simplemente tiene la configuración errónea.
Cuando responder a esas preguntas requiere de forma rutinaria que un desarrollador inspeccione una base de datos o ejecute un script interno, el proceso deja de ser escalable al ritmo del producto.
La duplicación es otra señal de alerta. Cada variante de producto empieza a tener su propio script de incorporación, herramienta de configuración o flujo de trabajo de instalación. Estas diferencias pueden parecer insignificantes, pero la responsabilidad subyacente es la misma. El aprovisionamiento se ha convertido en una infraestructura de plataforma reutilizable, en lugar de una tarea de configuración asociada a un dispositivo específico.
Y rara vez es la única capacidad que necesita volverse reutilizable.
La capa de plataforma debería convertirse en una infraestructura reutilizable.
Cuando varios productos o revisiones de hardware comparten las mismas necesidades básicas, algunas funcionalidades de software dejan de ser específicas de un producto. La identificación del dispositivo, el aprovisionamiento, la conectividad, la telemetría, la distribución de firmware, el estado del ciclo de vida, la visibilidad de la flota y el diagnóstico son buenos ejemplos. Reconstruirlas para cada nueva variante genera más código y más rutas operativas que mantener, sin que el producto en sí sea más distintivo.
Los equipos rara vez se proponen crear esta duplicación. Pequeñas diferencias se acumulan en torno a cada producto hasta que el equipo termina manteniendo varias implementaciones de lo que se ha convertido en la misma responsabilidad de ingeniería.
Una delimitación más clara consiste en separar la capa de producto de la capa de plataforma. La capa de producto contiene el comportamiento, los flujos de trabajo, las interfaces, las integraciones y la lógica de dominio que hacen que un dispositivo en particular sea valioso. La capa de plataforma gestiona los aspectos mecánicos que deben mantenerse consistentes incluso cuando el hardware cambia.
A medida que los productos conectados superan su lanzamiento inicial, el aprovisionamiento de dispositivos, la gestión del ciclo de vida de los dispositivos, la gestión de flotas y las herramientas de soporte se convierten en infraestructura compartida en lugar de detalles de proyectos puntuales. Una plataforma PaaS de IoT para empresas puede proporcionar esa capa de plataforma reutilizable para múltiples productos o variantes de productos, gestionando la administración estándar de dispositivos y datos mediante bloques de construcción reutilizables, mientras que los equipos de ingeniería centran sus esfuerzos en el hardware, los flujos de trabajo y la experiencia del usuario.
Una base común debe dejar espacio para las diferencias reales entre productos. Un nuevo dispositivo puede requerir un modelo de datos, un flujo de configuración, una integración o una lógica de control diferentes, y estas diferencias deben ser fáciles de implementar. El objetivo es, sencillamente, evitar que cada diferencia implique la necesidad de añadir un nuevo registro de dispositivos, un nuevo sistema de telemetría, un nuevo mecanismo de aprovisionamiento o un nuevo conjunto de herramientas de gestión de flotas.
La plataforma puede parecer un gasto adicional mientras el equipo desarrolla el primer producto, y convertirse en un activo fundamental para el segundo o tercer producto. Una vez que se establecen los mecanismos operativos comunes, una nueva variante puede heredar una base funcional en lugar de incorporar un sistema backend que el equipo tendría que mantener durante el resto de la vida útil del producto.
Mantén la ingeniería personalizada donde el producto sea realmente diferente.
Una plataforma reutilizable no debería hacer que los productos conectados sean más genéricos. Su función es eliminar la ingeniería repetitiva de las piezas que no generan diferenciación.
El trabajo de personalización sigue siendo fundamental en el comportamiento del dispositivo, la lógica específica del dominio, los flujos de trabajo, la experiencia del usuario, las integraciones especializadas y la forma en que un producto en particular interactúa con el mundo físico. Precisamente en estas áreas, las decisiones de ingeniería pueden marcar una diferencia significativa entre un producto y otro.
Lo que rara vez recibe el mismo trato es la infraestructura operativa circundante. Una versión básica y una versión industrial de la misma máquina pueden necesitar sensores, controles e interfaces diferentes, pero no deberían requerir métodos distintos para identificar dispositivos, realizar un seguimiento de las versiones del firmware o gestionar una flota.
Prefiero que los ingenieros dediquen ese tiempo a perfeccionar el comportamiento del producto en el campo, en lugar de reconstruir mecanismos que el equipo ya tiene implementados para otro producto. Una base compartida no reduce el alcance de la ingeniería personalizada; lo que hace es evitar que ese esfuerzo se vea absorbido por la infraestructura.
La verdadera prueba llega cuando el equipo empieza a producir el segundo producto.
Una buena plataforma hace que el siguiente producto sea más fácil que el primero.
Si el producto número dos requiere prácticamente el mismo trabajo de plataforma que el producto número uno, en realidad se ha reutilizado muy poco.
Una nueva variante debería poder heredar las partes del modelo operativo que no han cambiado: flujos de aprovisionamiento, identidad, mecánica del ciclo de vida, herramientas de flota, procesos de firmware, visibilidad del soporte e integraciones comunes. El esfuerzo de ingeniería se centra entonces en las diferencias —quizás un nuevo paquete de sensores, un flujo de trabajo de control diferente o una integración específica para el cliente— en lugar de reconstruir la base.
Una nueva generación de hardware ejerce mayor presión sobre esta misma idea. Sus capacidades pueden cambiar sustancialmente, mientras que las unidades más antiguas siguen en funcionamiento. Una plataforma madura puede soportar ambas sin obligar al equipo a mantener dos pilas de plataformas separadas para lo que los clientes aún perciben como una sola familia de productos.
Nada de esto requiere un backend monolítico. Los diferentes productos pueden seguir necesitando límites arquitectónicos claros. Lo importante es evitar una segunda implementación de la misma responsabilidad de ingeniería sin una buena razón.
Es entonces cuando la plataforma se convierte en un activo en lugar de un gasto acumulado. El equipo de soporte tiene menos herramientas paralelas que comprender, los lanzamientos siguen rutas más consistentes y la incorporación de un nuevo producto se convierte en una extensión controlada en lugar de otro sistema de backend que la empresa hereda indefinidamente.
Trate la plataforma como parte de la arquitectura del producto.
Los productos físicos se diseñan teniendo en cuenta las revisiones, la facilidad de mantenimiento, la capacidad de fabricación y los cambios futuros. Los productos conectados requieren la misma disciplina en lo que respecta al software.
El primer backend puede ser temporal. Lo mismo ocurre con el primer script de aprovisionamiento o la primera herramienta de soporte. No hay nada intrínsecamente malo en ello. Los problemas surgen cuando esos mecanismos temporales se convierten, sin que nos demos cuenta, en una arquitectura permanente mientras el producto en sí sigue evolucionando.
Para entonces, el producto conectado ya no es solo hardware, firmware y una aplicación. También depende de la infraestructura que identifica cada dispositivo, comprende sus capacidades, aplica la configuración adecuada, admite actualizaciones y ayuda a los equipos a diagnosticar problemas años después del envío.
Una vez que esa capa se trata como arquitectura de producto, la división se vuelve más clara: la mecánica estándar se mantiene reutilizable, mientras que el trabajo personalizado se centra en lo que realmente distingue a un producto o familia de productos de otro.
La plataforma más robusta no es simplemente la que hace posible el primer producto conectado, sino la que permite al equipo de ingeniería desarrollar el segundo, el tercero y el cuarto sin tener que heredar un nuevo sistema de backend cada vez.
