Emerson
Sistema de diseño multipropósito
La situación
Emerson desarrolla software industrial a escala — DeltaV, AMS, Guardian, y decenas más — con equipos divididos por zona horaria, país, unidad de negocio y stack tecnológico. Cada equipo que necesitaba una tabla, un formulario o un gráfico de dashboard construía el suyo.
Los mismos primitivos, resueltos de cien maneras distintas. Arrancar el primer borrador de un proyecto tomaba meses, porque no había nada desde donde partir. Y la calidad dependía enteramente del equipo de diseño: cada pantalla pasaba por revisión de diseño, por lo que el retrabajo se acumulaba y diseño se convertía en el cuello de botella de toda la organización.
La tensión
La solución obvia — una biblioteca de componentes compartida — tenía una trampa. Los equipos de Emerson estaban divididos entre React y Angular. Construir para un solo framework dejaba a la mitad de la organización sin adoptar, y un sistema de diseño que nadie puede usar no sirve de nada.
Construir para ambos duplicaba la superficie de mantenimiento para toda la vida del sistema. Ninguna opción era gratuita, y elegir mal habría hundido la adopción antes de que se enviara el primer componente.
La decisión
Hicimos de React y Angular objetivos de primera clase — 52 componentes cada uno, mismo comportamiento, misma API, misma documentación — y priorizamos la adopción por encima de nuestro propio costo de mantenimiento.
Tratamos la gobernanza como parte del producto, no como burocracia: un modelo de contribución, una Definición de Done, puertas de calidad, notas de versión e informes a la dirección ejecutiva — el andamiaje que mantiene vivo un sistema cuando el equipo fundador sigue adelante. Y en los gráficos dejamos el motor expuesto — Chart.js v4, SSR, tematización por tokens, tree-shaking — en lugar de sellarlo detrás de una abstracción, porque los dashboards industriales necesitan un control que una envoltura limpia no puede anticipar.
El resultado
104 componentes en producción, React y Angular en paridad, entregados en menos de seis meses. El tiempo de arranque de proyectos pasó de meses a componer desde piezas funcionales — aproximadamente un 30% menos de esfuerzo de entrega por proyecto.
Un conjunto de pruebas unitarias en cada componente trasladó la responsabilidad de calidad fuera del equipo de diseño y detectó regresiones antes de que llegaran a los equipos consumidores, en lugar de enrutar todo a través de revisión de diseño. La adopción se extendió a DeltaV, AMS, Guardian y más de 50 equipos globales.
La conclusión
Cuando cada equipo reconstruye los mismos primitivos, el instinto es darles una biblioteca de componentes. Pero la biblioteca es solo la mitad fácil.
Lo que hizo que esto funcionara fue encontrarse con los equipos en los stacks que ya usaban y construir la gobernanza para mantener el sistema honesto a medida que crecía. Para la próxima organización fragmentada entre frameworks y zonas horarias, ese es el orden de operaciones: paridad y gobernanza primero, componentes después.