← Perspectivas

Serie · Dos estrategias sobre el mismo patrimonio · Parte 1 de 7

modernización · gobierno de datos · operaciones · estrategia

Dos estrategias sobre el mismo patrimonio

Cuidar lo que corre y barrer todo hacia una plataforma única son dos estrategias distintas, cada una con media razón. Esta serie combina la mitad cierta de cada una.

Estudio RGC · 3 minutos

En el artículo anterior planteamos la modernización de un ecosistema de aplicaciones como una evolución guiada, no como un reemplazo. Esta serie baja esa base conceptual a un caso que se repite dentro de casi cualquier operación grande. No es la historia de un cliente. Es un patrón que aparece una y otra vez, con las mismas caras y los mismos argumentos.

Adentro de la organización conviven dos estrategias distintas. No están enfrentadas: son dos maneras legítimas de resolver, y cada una resuelve una parte. Una cuida lo que corre: los dueños de la tecnología y de los sistemas que hoy sostienen la operación, que valoran la continuidad y saben dónde están los cables que no hay que cortar. Su frase es "esto funciona, no lo toques". La otra llega de afuera, con frecuencia desde otra metodología, y propone barrer todo hacia una sola plataforma: borrón y cuenta nueva, un solo proveedor. Su frase es "así no se puede escalar".

Cada estrategia ve con claridad lo que la otra no llega a ver. La que cuida lo que corre ve el riesgo del cambio. La que propone barrer ve el costo de no cambiar. Las dos miran la misma foto desde ángulos distintos, y cada una tiene razón en su mitad.

Arriba de esa tensión suele bajar un tercer problema, más silencioso y más caro: un gobierno de datos diseñado con la lógica de un libro contable, aplicado a datos que tienen que moverse a la velocidad del campo. Con la mejor intención, termina asfixiando la operación que dice proteger.

La tesis de esta serie es simple. Ninguna de las dos estrategias resuelve el problema entero, y la operación necesita las dos mitades. La estrategia guía, la del artículo anterior, no elige una de las dos: combina la mitad cierta de cada una y rechaza el extremo de ambas. Y un buen gobierno de datos no es el que más controla, es el que hace fluir datos confiables.

Pero antes de combinar las dos, hay que ver por qué cada estrategia, por su lado, se queda a mitad de camino. Esa es la próxima nota.

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.

La implementación del cambio que impulsa su operación.

Contactanos