Gestión de metadatos para sistemas de datos multidecadales

El campo TRANS-AMT-CD en un programa COBOL ha estado en producción desde 1981. La entrada FD lo define como PIC S9(9)V99 COMP-3Un campo numérico decimal con signo, once dígitos y dos decimales implícitos. Esa es la información técnica. La información comercial, es decir, qué significa realmente TRANS-AMT-CD, en qué moneda está denominado, si los dos decimales implícitos representan centavos o puntos base, si un valor negativo representa un crédito o un débito, y cómo debe interpretarse un valor cero, no se encuentra en el código fuente. Existía en un documento de especificaciones funcionales impreso en 1981, archivado en un archivador, y no se ha vuelto a ver desde entonces. Los dos desarrolladores que originalmente sabían qué significaba TRANS-AMT-CD se jubilaron en 2014.

Esta es la situación de metadatos a la que se enfrenta toda organización con sistemas de datos de varias décadas, y es la situación de metadatos que los marcos modernos de gobernanza de datos no fueron diseñados para abordar. Collibra, Alation, Atlan y cualquier otra plataforma de catálogo de datos empresariales son excelentes para gestionar metadatos de datos ya descritos, bases de datos en la nube con esquemas documentados, almacenes de datos con semántica de columnas definida y puntos finales de API con especificaciones OpenAPI. No están diseñadas para reconstruir metadatos que nunca se capturaron formalmente, que existen solo en el comportamiento de programas escritos antes de que la gestión de metadatos fuera una disciplina, y que han sido modificados por decenas de desarrolladores durante cuatro décadas sin que nadie actualizara un registro central del significado de cada campo.

La gestión de metadatos para sistemas de datos de varias décadas no es el mismo problema que la gestión de metadatos para sistemas modernos. Requiere un enfoque fundamentalmente diferente, que comienza con la extracción de metadatos de los artefactos de origen en lugar de la ingesta de metadatos de sistemas conectados.

Las tres capas de metadatos heredados

Para comprender el problema de los metadatos en sistemas que abarcan varias décadas, es necesario reconocer que los metadatos en estos entornos existen en tres capas distintas, cada una con diferente capacidad de extracción, diferente nivel de completitud y diferentes implicaciones para la gobernanza.

Los metadatos técnicos constituyen la capa más fácil de extraer. Describen la estructura física de los datos: nombres de campos, tipos de datos, longitudes, posiciones dentro de los registros, especificaciones de precisión numérica y relaciones entre campos dentro de un diseño de registro. En entornos COBOL, los metadatos técnicos se encuentran en los artefactos del código fuente: las entradas FD definen diseños de registro, los miembros COPY definen estructuras de datos reutilizables, las cláusulas SELECT definen la organización de archivos y los métodos de acceso, y las sentencias JCL DD definen los conjuntos de datos asociados a cada ejecución del programa. Esta capa es, en principio, legible por máquina; un analizador sintáctico que entienda la sintaxis COBOL puede extraerla del código fuente, pero se encuentra distribuida en miles de archivos fuente en lugar de estar centralizada en un registro de esquema.

Los metadatos operacionales describen cómo se mueven los datos a través del sistema: qué programas generan qué conjuntos de datos, qué programas los consumen, en qué secuencia y mediante qué transformaciones. En entornos de mainframe, los metadatos operacionales se distribuyen entre los flujos de trabajos JCL (que definen las secuencias de ejecución y las asociaciones de conjuntos de datos), los gráficos de llamadas de programas (que definen el flujo de datos entre programas) y la configuración del planificador (que define la temporización y las dependencias). Esta capa también se puede extraer automáticamente de los artefactos de origen, aunque la extracción requiere comprender no solo los programas individuales, sino también las relaciones entre ellos.

metadatos comerciales o semánticos es la capa menos extraíble y más valiosa. Responde a las preguntas que los metadatos técnicos no pueden: ¿qué es TRANS-AMT-CD ¿Qué significa realmente en términos comerciales? ¿Cuáles son los valores válidos para ACCT-TYPE-CD ¿Y qué significa cada valor? ¿Qué regla de negocio determina cuándo? CUST-STATUS-FLG transiciones de A a IEsta capa existe, cuando existe, en los documentos de especificación, en la memoria del desarrollador, en el conocimiento institucional que poseen los empleados que pueden haberse jubilado y en la lógica procedimental de los programas que imponen reglas de negocio a través de sentencias IF y bloques EVALUATE en lugar de a través de restricciones de la base de datos.

El desafío de los metadatos en sistemas con varias décadas de antigüedad radica en que estas tres capas se han gestionado de forma diferente, o directamente no se han gestionado, a lo largo de décadas de evolución del sistema. Los metadatos técnicos se capturaron en el código fuente, pero nunca se formalizaron en un diccionario de datos. Los metadatos operacionales estaban implícitos en los flujos de trabajo JCL, pero nunca se documentaron como un registro de linaje. Los metadatos de negocio se documentaron en las especificaciones durante el desarrollo inicial y nunca se actualizaron a medida que los sistemas evolucionaban.

El problema de la deriva de metadatos

Cada año que un sistema que lleva décadas funcionando sin una gestión sistemática de metadatos, la brecha entre los metadatos que existen en la documentación formal y los metadatos que reflejan el comportamiento actual real del sistema se amplía. Esta desviación se produce a través de cuatro mecanismos:

Evolución del significado del campo. Un campo que en 1978 se definió con un único significado empresarial puede haber adquirido significados adicionales a lo largo de las décadas siguientes. ACCT-TYPE-CD Es posible que originalmente se distinguieran las cuentas corrientes de las de ahorro. A lo largo de cuarenta años, se han añadido códigos adicionales para representar cuentas del mercado monetario, certificados de depósito, cuentas IRA y cuentas de depósito en garantía, documentándose cada adición únicamente en el código del programa que gestiona el nuevo valor del código, no en ninguna definición de campo central. El nombre y el tipo del campo permanecen sin cambios; su significado semántico se ha vuelto sustancialmente más complejo.

Reutilización silenciosa. En ocasiones, los campos se reutilizan sin cambiarles el nombre. Un campo que se usaba para un propósito se vuelve inconveniente para ampliar, y un desarrollador usa un valor previamente no utilizado de un campo de indicador adyacente para codificar información diferente. TRANS-FLAG-1 Ahora puede codificar tres conceptos distintos en diferentes contextos de programa, distinguibles únicamente examinando qué programas leen el campo y bajo qué condiciones. Los metadatos técnicos (nombre del campo, tipo, longitud) no indican que el campo esté sobrecargado semánticamente.

REDEFINES acumulación. Como se explica en los contextos de análisis de VSAM, las cláusulas REDEFINES superponen el mismo almacenamiento físico con diferentes interpretaciones de campo. Cada variante de REDEFINES puede haberse añadido en un momento distinto de la historia del sistema, por diferentes desarrolladores y con diferentes propósitos comerciales. El significado semántico completo de una jerarquía REDEFINES, qué variante se aplica en cada caso y qué significan los campos de cada variante, solo puede reconstruirse analizando todos los programas que acceden a cada variante y las condiciones bajo las cuales lo hacen.

Divergencia de Copybook. Cuando se modifica un copybook estándar de COBOL para incorporar un nuevo requisito, los programas que lo incluían y no se actualizaron para manejar el nuevo campo pueden comportarse incorrectamente o simplemente ignorarlo. Tras décadas de evolución, pueden existir múltiples versiones de lo que nominalmente es el mismo copybook en distintas bibliotecas, y diferentes programas utilizan versiones distintas. Los metadatos de un campo definido en el copybook pueden variar entre programas, dependiendo de la versión del copybook que incluya cada uno.

Lo que las herramientas modernas de metadatos no pueden hacer con los datos heredados

El mercado de catálogos de datos empresariales ha madurado considerablemente. Collibra, Alation, Atlan, Microsoft Purview e Informatica Axon son plataformas sofisticadas para la gestión de metadatos en entornos de datos modernos. Destacan por: el descubrimiento automático de esquemas a partir de bases de datos conectadas, el seguimiento del linaje de datos a nivel de columna en procesos ETL, el mantenimiento de glosarios empresariales con definiciones de términos seleccionadas y la visualización de métricas de calidad de datos junto con los registros de metadatos.

Lo que estas herramientas no pueden hacer por los sistemas COBOL y mainframe de varias décadas:

No pueden conectarse a lo que no ven. Los catálogos modernos descubren metadatos mediante conectores, conexiones JDBC a bases de datos, integraciones de API con servicios en la nube e integraciones de escáner con plataformas compatibles. Los archivos VSAM, los programas COBOL y los flujos de trabajo JCL no tienen conectores de catálogo estándar. El catálogo no puede descubrir lo que no puede acceder. Los datos gestionados por estos sistemas son prácticamente invisibles para el catálogo, lo que significa que los registros de linaje para los análisis en la nube posteriores que se derivan de estos datos están incompletos o no existen.

No pueden extraer metadatos que solo existen en el código. Un catálogo de datos conectado a una base de datos DB2 puede leer el esquema de la base de datos, las definiciones de tablas, los nombres de columnas, los tipos de datos y los índices. Sin embargo, no puede leer el programa COBOL que rellena la tabla DB2 para comprender qué reglas de negocio rigen la inserción de datos, qué variantes de REDEFINES existen en el registro de origen o qué nombres de condiciones de nivel 88 definen la validez semántica de cada campo. Los metadatos a nivel de código, la capa donde reside el significado empresarial de los datos heredados, requieren análisis de código, no escaneo de catálogo.

No pueden reconstruir el significado que nunca se capturó. Incluso con una extracción perfecta de metadatos técnicos, el significado empresarial de los campos que nunca se documentaron formalmente no se puede reconstruir automáticamente. Esta capa requiere una combinación de análisis de código (para identificar las reglas de negocio que los programas aplican a los datos, que son indicadores del significado empresarial) y revisión humana (para validar el significado reconstruido comparándolo con el conocimiento institucional mientras este aún existe).

El enfoque de reconstrucción de metadatos

En sistemas con décadas de antigüedad donde nunca se recopilaron metadatos formales o estos se han desviado significativamente de la realidad actual, la gestión de metadatos requiere una fase de reconstrucción previa a la fase de gobernanza. El enfoque de reconstrucción extrae las capas recuperables e identifica las lagunas donde se requiere conocimiento humano.

Fase 1: Extracción de metadatos técnicos de los artefactos de origen.

Analizar cada entrada COBOL FD, miembro COPY, cláusula SELECT y sentencia JCL DD para producir un inventario de metadatos técnicos a nivel de campo:

cobol

* Source FD entry -- technical metadata extraction target
FD  TRANSACTION-FILE
    LABEL RECORDS ARE STANDARD
    RECORD CONTAINS 200 CHARACTERS.
01  TRANSACTION-RECORD.
    05  TRANS-DATE          PIC 9(8).          *> YYYYMMDD format
    05  TRANS-TYPE-CD       PIC XX.            *> See 88-level values
        88 TRANS-PAYMENT    VALUE 'PM'.
        88 TRANS-REFUND     VALUE 'RF'.
        88 TRANS-ADJUSTMENT VALUE 'AJ'.
        88 TRANS-REVERSAL   VALUE 'RV'.
    05  TRANS-AMT-CD        PIC S9(9)V99 COMP-3.
    05  TRANS-CURRENCY-CD   PIC X(3).          *> ISO 4217
    05  TRANS-DETAIL        REDEFINES TRANS-TYPE-CD.
        10  TRANS-MERCH-ID  PIC X(12).
        10  TRANS-AUTH-CD   PIC X(6).
        10  FILLER          PIC X(84).

A partir de esta única entrada FD, la extracción de metadatos técnicos produce: nombres de campos, tipos de datos, longitudes, posiciones, la precisión decimal empaquetada de TRANS-AMT-CD (9 dígitos, 2 decimales, con signo), los cuatro valores semánticos de TRANS-TYPE-CD según lo definido por los nombres de condición de nivel 88 y la estructura REDEFINES que crea dos interpretaciones superpuestas de los bytes 10-105 del registro.

Los nombres de las condiciones de nivel 88 son particularmente valiosos como metadatos: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL son cuatro elementos del vocabulario empresarial que el propio código COBOL proporciona, más significativos que el subyacente. PM, RF, AJ, RV valores que vería un catálogo de datos que escaneara la base de datos.

Fase 2: Extracción de metadatos operativos de las dependencias del programa.

Construya el mapa de linaje operativo rastreando los flujos de datos a través del gráfico de dependencias del programa:

• ¿Qué programas escriben a? TRANSACTION-FILE (productores)
• ¿Qué programas leen de? TRANSACTION-FILE (consumidores)
• ¿Qué pasos del trabajo JCL invocan a cada productor y consumidor, y en qué secuencia?
• ¿Qué conjuntos de datos y bases de datos posteriores reciben datos transformados de TRANSACTION-FILE

Este mapa de linaje son los metadatos operativos que las herramientas de catalogación de datos necesitan para la visualización del linaje, pero que no pueden construir sin acceso al código fuente del programa y al JCL.

Fase 3: Extracción de reglas de negocio como proxy de metadatos semánticos.

Las reglas de negocio codificadas en la lógica de la DIVISIÓN DE PROCEDIMIENTOS COBOL son representaciones del significado empresarial. Un programa que valida TRANS-AMT-CD para asegurar que se encuentre dentro de ciertos rangos antes de procesarlo está proporcionando evidencia sobre el rango válido del campo. Un programa que convierte TRANS-AMT-CD Enviar la información a una unidad diferente antes de escribirla en un sistema posterior revela una convención decimal o de unidades implícita.

La extracción de estas reglas de negocio mediante el análisis del código genera un conjunto de metadatos semánticos inferidos: los rangos de validación aplicados a cada campo, las transformaciones que se producen entre el origen y el destino, y las condiciones bajo las cuales se ejecutan las distintas rutas de código. Estos metadatos semánticos inferidos son imprecisos; muestran lo que los programas hacen con los datos, no necesariamente lo que estos pretendían significar, pero se pueden recuperar del código de una manera que no es posible con el documento de especificación original.

Fase 4: Validación humana y enriquecimiento semántico.

Los metadatos técnicos y operativos extraídos y los metadatos semánticos inferidos forman la base para las sesiones de validación humana con expertos en el dominio y desarrolladores que se retiran. El objetivo es convertir la semántica inferida en semántica confirmada, validando que TRANS-AMT-CD Significa lo que el código sugiere que significa, identificando casos en los que el comportamiento del código ya no refleja el significado comercial previsto y capturando el conocimiento institucional sobre el historial del sector que el análisis del código no puede recuperar.

Esta fase está limitada en el tiempo por la disponibilidad de conocimientos especializados: con cada año que pasa, una mayor parte de este conocimiento se va perdiendo junto con las personas que lo poseen.

La brecha de metadatos heredados en el límite del sistema moderno

El déficit de metadatos generado por sistemas obsoletos no se limita al entorno heredado, sino que se propaga: cada sistema analítico, almacén de datos y canalización de aprendizaje automático que consume datos de sistemas heredados hereda esta brecha de metadatos.

Un almacén de datos en la nube que recibe una extracción diaria de un archivo plano de un programa por lotes COBOL tiene, en sus definiciones de columna, lo que el equipo de ingeniería de datos eligió nombrar las columnas cuando construyeron la canalización ETL. Si el campo original era TRANS-AMT-CD y el desarrollador de ETL nombró la columna de destino transaction_amount, el almacén de datos parece tener metadatos completos: nombre de columna, tipo de datos, descripción del negocio agregados al catálogo. Lo que el catálogo no registra es que transaction_amount originado desde TRANS-AMT-CD in TRANSACTION-FILE, que es producido por un programa COBOL llamado TRNSRC01, que se ejecuta en un trabajo JCL TRANSDAY Todas las noches a las 2 de la madrugada, y que aplica una conversión de moneda específica que se programó en 1987 basándose en una convención de tipo de cambio que puede que siga vigente o no.

El registro de metadatos descendente parece completo. El linaje se rompe en el límite heredado. Cualquier carga de trabajo analítica o de IA que dependa de comprender la procedencia y el significado de transaction_amount Existe una laguna en la que no se documenta el origen real de ese valor.

El hallazgo de Gartner de que el 60 por ciento de los proyectos de IA que no cuentan con datos preparados para la IA serán abandonados hasta 2026 es en parte una declaración de metadatos. Los modelos de IA que consumen transaction_amount Sin saber que se originó a partir de un campo COBOL decimal empaquetado con una posición decimal implícita, denominado en una moneda que podría haber sido convertida utilizando una convención de tipo de cambio de 1987, se entrena con datos cuya procedencia es opaca. El modelo no puede saber si desconfiar de este contexto o ajustarlo, ya que los metadatos que lo comunicarían no existen en ningún catálogo al que el modelo o su canalización de datos puedan acceder.

Creación de un programa de gestión de metadatos para sistemas heredados

Un programa de gestión de metadatos para sistemas de datos de varias décadas tiene cuatro componentes que difieren de las implementaciones estándar de catálogos de datos empresariales:

Componente 1: Extracción de metadatos del código fuente. Antes de que cualquier herramienta de catalogación pueda gestionar los metadatos heredados, estos deben extraerse de los artefactos fuente donde se encuentran. Esta extracción debe abarcar: entradas FD y copybooks (metadatos técnicos para estructuras de datos), cláusulas SELECT (organización de archivos y método de acceso), sentencias JCL DD (asociaciones de conjuntos de datos y características de archivos) y nombres de condiciones de nivel 88 (vocabulario de valores semánticos integrado en el código fuente). El resultado es un inventario de metadatos a nivel de campo que puede cargarse en un catálogo como punto de partida para el enriquecimiento de datos empresariales.

Componente 2: Reconstrucción del linaje. El linaje de datos para sistemas heredados debe reconstruirse a partir del análisis de dependencias de programas, en lugar del seguimiento del linaje de la herramienta ETL. El mapa de linaje rastrea los datos desde su programa COBOL de origen, pasando por programas de transformación intermedios, hasta sus consumidores finales, incluidos los procesos ETL que los entregan a los sistemas analíticos modernos. Esta reconstrucción cierra la brecha de linaje en el límite del sistema heredado, conectando los metadatos de las columnas del almacén de datos en la nube con los metadatos de las entradas de la función de dependencia de COBOL mediante una cadena documentada de dependencias de programas.

Componente 3: Enriquecimiento semántico con conocimientos especializados del dominio. Los metadatos técnicos extraídos proporcionan la estructura; el significado comercial confirmado requiere experiencia en el dominio. El proceso de enriquecimiento utiliza los metadatos técnicos como una indicación estructurada para entrevistas con expertos: “Este campo se define como PIC S9(9)V99 COMP-3Se valida que es no negativo en 14 programas y se convierte a una escala diferente antes de escribirlo en la base de datos posterior. ¿Puede confirmar qué representa y qué significa la conversión? Este enfoque estructurado utiliza el análisis de código para maximizar el valor informativo de cada interacción con el experto, lo que permite un enriquecimiento más rápido y completo que las revisiones de documentación no estructuradas.

Componente 4: Integración de la gobernanza con plataformas de catálogo modernas. Una vez extraídos, reconstruidos y enriquecidos los metadatos heredados, deben integrarse con la infraestructura de gobernanza de metadatos moderna. Esta integración conecta el inventario de metadatos heredados con el catálogo de datos empresariales, proporcionando: linaje a nivel de columna desde la fuente COBOL hasta el destino en la nube, términos del glosario empresarial vinculados a definiciones de campos heredados y metadatos de calidad de datos para conjuntos de datos heredados que se integran en el mismo marco de gobernanza que los metadatos del sistema moderno.

Cómo SMART TS XL Extrae metadatos heredados

SMART TS XL Aborda los dos primeros componentes del programa de gestión de metadatos heredados, la extracción de metadatos del código fuente y la reconstrucción del linaje, mediante la aplicación de análisis estático a todo el conjunto de COBOL, JCL y copybooks.

La capacidad de análisis de código estático analiza cada entrada FD, miembro COPY, cláusula SELECT y definición de nivel 88 en todo el conjunto de programas COBOL, generando un inventario de metadatos técnicos a nivel de campo: nombre de campo, tipo de dato, longitud, especificación COMP, pertenencia a REDEFINES y nombre de condición de nivel 88 en cada programa y copybook del entorno. Para un conjunto de miles de programas COBOL, esta extracción genera en horas el inventario de metadatos técnicos que la documentación manual tardaría años en producir, si es que pudiera generarse por completo.

El mapeo de dependencias de la aplicación construye el mapa de linaje operativo: cada relación entre programa y conjunto de datos (qué programas producen qué conjuntos de datos y cuáles los consumen), cada dependencia entre programas (qué programas llaman a otros y qué flujo de datos hay entre ellos) y cada relación entre JCL y programa (qué pasos de trabajo invocan qué programas y en qué secuencia). Este mapa de linaje es la capa de metadatos operativos que cierra la brecha entre los sistemas de origen heredados y los registros de linaje del catálogo de datos moderno.

La capacidad de expansión de JCL rastrea la cadena de ejecución completa de cada trabajo JCL: resuelve las referencias PROC, expande los parámetros simbólicos y construye los metadatos operativos completos para la producción y el consumo de cada conjunto de datos, el contexto de planificación, los trabajos dependientes y la secuencia de ejecución que determina las características de puntualidad y actualidad de cada conjunto de datos.

La función de búsqueda empresarial permite consultar el inventario de metadatos extraído en todo el programa de gestión de metadatos: permite encontrar todos los campos definidos como COMP-3 (campos que requieren precisión y una asignación de destino cuidadosa), todos los programas que leen un campo específico (identificando a todos los usuarios de un dato concreto para su linaje y enriquecimiento semántico), y todos los nombres de condiciones de nivel 88 que coinciden con un término empresarial específico (asignando el vocabulario empresarial a las definiciones de campos técnicos). Esta función de búsqueda facilita el proceso de enriquecimiento semántico, permitiendo a los expertos del dominio encontrar todos los usos de un campo o valor específico antes de confirmar su significado empresarial.

Para las organizaciones que realizan modernización heredada programas, SMART TS XLLa extracción de metadatos proporciona la base previa a la migración: los metadatos técnicos a nivel de campo que las herramientas de migración necesitan para asignar los campos de origen a los esquemas de destino, el linaje operativo que los programas de migración necesitan para secuenciar correctamente las migraciones de conjuntos de datos y el vocabulario semántico de nivel 88 que permite una asignación precisa de los valores del código COBOL a las definiciones de restricciones relacionales.

La urgencia de recuperar los metadatos antes de que el conocimiento quede obsoleto.

El problema de la reconstrucción de metadatos tiene un plazo límite natural que no se aplica a la mayoría de los desafíos de gobernanza de datos: la jubilación de los desarrolladores que poseen el conocimiento institucional que el análisis de código no puede recuperar. Casi un tercio de los programadores de COBOL se jubilarán para 2030. La edad promedio de un ingeniero de mainframe es de 58.7 años. Cada año que pasa sin una extracción sistemática de metadatos y un enriquecimiento semántico reduce el tiempo disponible para la validación humana de los metadatos recuperados.

Los metadatos técnicos (definiciones de campos, especificaciones de tipos, dependencias de programas, linaje de datos) se pueden recuperar del código fuente indefinidamente, siempre que este exista. Los metadatos semánticos (el significado de cada campo en términos comerciales, las decisiones históricas que motivaron su diseño y las convenciones implícitas que no se documentan en las especificaciones técnicas) solo se pueden recuperar de quienes los conocen y únicamente mientras estén disponibles.

Un programa de gestión de metadatos para sistemas con décadas de antigüedad, que comienza con la extracción técnica y continúa con el enriquecimiento semántico mientras aún se dispone de conocimientos especializados, genera una base de metadatos completa y recuperable. El mismo programa, si se pospone hasta que el conocimiento se vuelva obsoleto, genera una base de metadatos técnicos precisa pero incompleta, correcta en cuanto a la estructura de los datos, pero sin información sobre su significado.

Los metadatos son el mapa. Los sistemas que llevan décadas funcionando lo han ocultado.

La gobernanza de datos para sistemas modernos comienza con metadatos actualizados, accesibles y al menos parcialmente documentados. La gobernanza de datos para sistemas con varias décadas de antigüedad comienza con metadatos distribuidos en miles de archivos de código fuente, parcialmente documentados en especificaciones anteriores a internet y parcialmente almacenados en la memoria de desarrolladores próximos a la jubilación.

El proceso, desde lo oculto hasta lo gestionado, pasa por la extracción, la reconstrucción y el enriquecimiento, en ese orden. Los metadatos técnicos extraídos del código fuente constituyen el inventario inicial. El linaje operativo reconstruido a partir de las dependencias del programa proporciona el mapa de procedencia. El enriquecimiento semántico, validado por expertos en el dominio, aporta el significado empresarial que permite utilizar los metadatos técnicos para el análisis, la IA y la gobernanza.

Las plataformas modernas de catalogación de datos son el destino de estos metadatos, no el punto de partida. Antes de que Collibra pueda gestionarlos, Alation pueda catalogarlos y los científicos de datos puedan confiar en ellos, primero deben encontrarse los metadatos que contienen los sistemas de varias décadas: en las entradas FD, en los copybooks, en los nombres de condiciones de nivel 88 y en las reglas de negocio codificadas en cuarenta años de lógica de PROCEDURE DIVISION.

El mapa existe. Solo hay que leerlo.