Congelar todo y barrer todo resuelven, cada una, media parte del problema y se quedan a mitad de camino en la otra.
Esta nota es parte de la serie Dos estrategias sobre el mismo patrimonio. Una estrategia quiere congelar lo que corre; la otra propone barrerlo todo hacia una sola plataforma. Acá vemos por qué ninguna de las dos, sola, alcanza a resolver el problema entero.
El problema no es que una tenga razón y la otra no. El problema es que cada estrategia, llevada sola hasta el final, resuelve la parte que ve bien y se queda corta justo en la parte que no mira.
La estrategia de la continuidad, llevada al extremo de congelar todo, no conserva la operación: la deja envejecer. La operación cambia aunque el software no lo haga: los volúmenes crecen, el proveedor deja de dar soporte, la persona que entendía la planilla se jubila, la regulación pide un dato que el sistema viejo no captura. Congelar no elimina el riesgo, lo acumula fuera de la vista hasta que estalla, y estalla sin que quede nadie que sepa cómo estaba armado. La continuidad que se defendía termina siendo la primera víctima.
La estrategia del barrido, llevada al extremo de reemplazarlo todo por una plataforma única, se queda corta por el lado opuesto, y por tres motivos concretos. Primero, la plataforma genérica aplana lo que tenía valor: la lógica específica de un proceso de completación o de un flujo de datos de campo no entra en un molde pensado para todos, y forzarla es perder justo la profundidad que hacía competitiva a la operación. Segundo, la migración total tarda años, y durante esos años hay que vivir con los dos mundos en paralelo, que era exactamente el problema que se quería resolver. Tercero, apostar todo a una sola plataforma y a un solo proveedor te vuelve rehén de su hoja de ruta, de sus precios y de sus tiempos, justo cuando más flexibilidad necesitás.
Los dos instintos comparten el mismo error de fondo: tratan la modernización como un evento con final. Se congela y se termina, o se barre y se termina. No hay tal final. La modernización de un ecosistema es un proceso, no un cierre.
Por eso ninguna de las dos estrategias puede imponerse a la otra sin hacerle perder a la operación. La estrategia guía no es un punto medio tibio entre ambas. Es un criterio que combina lo cierto de cada una, el riesgo del cambio y el costo de no cambiar, y rechaza el extremo de las dos. Y justo cuando parece que un buen gobierno de datos podría ordenar todo esto, aparece la trampa que lo arruina: aplicarle a la operación el rigor de un libro contable. De eso hablamos ahora.
Glosario
- Sistema de registro (system of record)
- La fuente oficial y auditable de un dato: contabilidad, activos, contratos. Necesita rigor, inmutabilidad y trazabilidad, y puede permitirse ser más lento porque su valor es que nadie pueda discutirlo después.
- Corriente operativa de datos
- El flujo de datos que nace en el campo y tiene que moverse a la velocidad de la operación: partes, lecturas de sensor, avances, eventos de cuadrilla. Sirve aunque esté incompleto y se corrige aguas abajo; exigirle rigor de registro la asfixia.
- Contrato de datos
- Acuerdo explícito en la interfaz entre dos sistemas sobre el esquema del dato, el significado de cada campo, y las garantías de calidad y frecuencia. Desacopla al productor del consumidor, de modo que cada uno puede evolucionar por dentro sin romperle al otro.
- Gobierno fit-for-purpose (según su propósito, por consecuencia)
- Modelo de gobierno que clasifica los datos por cómo se usan y por la consecuencia de que estén mal, y aplica rigor en proporción a esa consecuencia. Evita tanto el descontrol donde la decisión es grave como el ritual inútil donde no lo es.
- Calidad en la fuente de información
- Validar el dato donde nace, con reglas simples y feedback inmediato a quien lo carga. Cuesta mucho menos que reconstruir la calidad aguas abajo y es la forma más barata de evitar que un error se propague.
- Rigor progresivo
- Estrategia de gobierno que empieza liviana, con visibilidad y contratos sobre los pocos flujos de mayor consecuencia, y agrega control donde la consecuencia lo justifica. Es lo contrario de un programa total que intenta gobernar todo de una vez y nunca termina.
- Rehén de proveedor (vendor lock-in)
- Situación en la que la operación queda atada a la hoja de ruta, los precios y los tiempos de un único proveedor o plataforma, porque apostó todo a él. Estandarizar el tejido conectivo en lugar de la aplicación es lo que preserva la opcionalidad y evita quedar rehén.
- Tejido conectivo
- El conjunto de conexiones por donde las piezas del ecosistema conversan: interfaces, identidad, contratos de datos, observabilidad. Estandarizar el tejido conectivo, y no la aplicación, es lo que permite cambiar cualquier pieza sin rehacer el conjunto.
- AS-IS (estado actual)
- El mapa honesto de cómo está hoy el patrimonio de aplicaciones: qué hay, qué está obsoleto, qué depende de qué. El punto de partida real, sin maquillar.
- TO-BE (estado objetivo)
- La dirección hacia donde se quiere llevar el ecosistema, dibujable y discutible, que se corrige sobre la marcha. No una foto fija, sino un rumbo firme.
