El Co>Operating System® es un entorno para armar, integrar y ejecutar aplicaciones

empresariales. Es la base que soporta todas las tecnologías de Ab Initio, como el Enterprise
Meta>Environment®, Continuous>Flows®, Conduct>It®, Business Rules Environment™, entre
otras. Estas tecnologías proporcionan un entorno completo y sin fisuras para el desarrollo y la
ejecución de aplicaciones.

El núcleo del Co>Operating System es un “motor de flujo de datos”. Este motor alimenta una
extensa biblioteca de “componentes” para el procesamiento de datos, los cuales manipulan los
datos que fluyen a través de una aplicación. Las aplicaciones se diseñan, implementan y
mantienen en un entorno gráfico mediante el Graphical Development Environment™ (GDE®) de
Ab Initio.

El principio central que guía el Co>Operating System es la idea de que las aplicaciones se
diseñan y se desarrollan de forma similar a como la mayoría de la gente diseñaría un sistema,
llegado el caso, sobre una pizarra o una servilleta. Utiliza iconos fáciles de reconocer que
representan las entradas y salidas, y que luego se combinan con rectángulos de procesamiento y
flechas para definir el flujo de procesamiento general. Al seleccionar los componentes adecuados
en la biblioteca y “conectarlos”, el usuario crea una aplicación de Ab Initio®.

Ab Initio integra con consistencia el diseño y la ejecución de aplicaciones. A todos los efectos, el
dibujo es la aplicación. Y la aplicación resultante puede ser por lotes, casi en tiempo real, en
tiempo real o, incluso, una combinación de todas ellas (en un entorno de computación, además,
potente y coherente).

Gracias a su planteamiento de flujo de datos gráfico, las tecnologías de Ab Initio se pueden

utilizar para armar la gran mayoría de las aplicaciones empresariales al uso. Como por ejemplo,
sistemas operacionales, integración de aplicaciones distribuidas, procesamiento de eventos
complejos, o sistemas de gestión de almacenamiento de datos y de calidad de datos. No obstante,
el diseño y el desarrollo gráficos solucionan únicamente una parte de los desafíos que enfrentan
las compañías. Al mismo tiempo, estas aplicaciones deben también satisfacer requisitos de
gestión y de operación muy exigentes.

Históricamente, las tecnologías de programación en un entorno gráfico suministraban imágenes

muy atractivas en lo visual pero que resultaban de nula utilidad a la hora de ponerlas en práctica.
El Co>Operating System no tiene nada que ver con aquellas tecnologías vistosas que luego
nunca funcionaban en el “mundo real”. Lo que lo hace diferente es, de hecho, que sí que
funciona. A continuación, se reseñan algunos ejemplos de implementaciones exitosas del
Co>Operating System (junto con los requisitos que hubo que tener en cuenta al adaptar la
tecnología a las necesidades variables de cada cliente):

 Una de las mayores bolsas de valores del mundo convirtió millones de líneas de código
Cobol para operaciones de misión crítica a aplicaciones de Ab Initio. Ahora, la solución
es una parte muy importante de la canalización del procesamiento de operaciones de
compra-venta. La implementación se conecta al bus de compra-venta en tiempo real, y
procesa transacciones a una velocidad de más de 500 000 mensajes por segundo.
 Uno de los más grandes comercios al por mayor del mundo recibe, en tiempo real, datos
de cartera de mercado desde las cajas registradoras de miles de tiendas. Se facilita así el
control de inventario y la detección de fraudes.
 Una de las mayores compañías telefónicas del mundo procesa información de detalles de
llamadas para poder aplicar la tarifa correcta a cada llamada, simplificando el
seguimiento del uso de los datos y el monitoreo de la red. A diario, se procesan miles de
millones de registros de detalles de llamadas, así como millones de consultas de uso.
 Uno de los mayores fabricantes de chips del mundo extrae información en tiempo real
acerca de la calidad de sus productos desde la misma línea de fabricación. El objetivo es
incrementar la productividad.
 Una de las mayores redes de tarjetas de crédito del mundo utiliza Ab Initio como su
backbone de datos, procesando y pasando todas las transacciones a sistemas de servidor
por lotes y en tiempo real. Con la ayuda de Ab Initio, la red acumula un petabyte de datos
de transacciones al año en un sistema de retención de datos. Además, se logra dar soporte
a los centros de llamadas de atención al cliente para que el tiempo de respuesta sea
inferior a un segundo.
 Una de las mayores compañías de Internet del mundo procesa decenas de miles de
millones de impresiones de publicidad al día, para poder así agilizar la facturación y
mejorar la inserción de anuncios.
 Una de las mayores compañías aseguradoras del mundo realiza muchas partes del
procesamiento de sus reclamaciones con Ab Initio. El sistema de reaseguramiento y de
procesamiento de tratados de la compañía contiene muchas decenas de miles de reglas,
todas ellas implementadas ahora con nuestro software.
 Una de las mayores empresas de mensajería del mundo genera todas sus facturas y
computa las compensaciones para el personal de ventas utilizando aplicaciones de Ab
Initio.
 Uno de los mayores bancos del mundo consolida la información acerca de sus clientes (y
desde todas las líneas del negocio) en un almacén de datos enorme armado con el
software de Ab Initio. La misma compañía utiliza Ab Initio para personalizar y procesar
el tráfico de transacciones SWIFT entre sus filiales internacionales.
Es muy posible que usted se pregunte qué es lo que lleva a todas estas empresas de primer nivel
a elegir a Ab Initio. Nuestra empresa se distingue por haber logrado una combinación de
prestaciones única en la industria del software. La tecnología de Ab Initio no sólo es intuitiva y
fácil de utilizar, sino que resulta además compatible con la más compleja lógica de aplicaciones.
Es, al mismo tiempo, capaz de manejar grandes volúmenes de datos. Y todo lo anterior, lo
consigue con un alto rendimiento y una robustez notable.

Los ejemplos referidos más arriba dan cuenta de distintas implementaciones realizadas por
clientes de Ab Initio (implementaciones, por cierto, que tienden a ser muy amplias). Satisfacer
requisitos tan dispares obliga a poner en juego un sinfín de capacidades. Destacaremos algunas:

 la capacidad de expresar gráficamente y con facilidad grandes cantidades de una lógica

compleja;
 conectividad prácticamente plena; una amplia gama de bases de datos, sistemas de colas,
archivos planos, sistemas ERP, protocolos de mensajes estándar y más;
 soporte nativo para estructuras de datos complejas; cualquier clase de datos desde
cualquier origen; jerárquicos (XML y heredados), internacionales, objetos grandes,
longitud variable, datos en formato bit-packed y muchos más;
 soporte para una amplia gama de sistemas operativos (Unix, Linux, Windows,
mainframe) y procesamiento distribuido en todas estas plataformas;
 arquitectura abierta para la integración rápida con aplicaciones, datos y entornos
heredados y de terceros;
 alta eficacia y alta escalabilidad, junto con la capacidad de habilitar una computación
similar a la computación en “nube” en redes de servidores;
 procesamiento por lotes y en tiempo real de alto rendimiento (servicios web y
arquitecturas orientadas a servicios (SOA), así como la transmisión por secuencias);
 alto grado de reutilización de fragmentos grandes y pequeños de aplicaciones, incluidas
las reglas de negocio.
 alta resistencia frente a problemas con los datos y los fallos en el sistema; control de
usuario fuerte frente a la respuesta de error;
 capacidades de gestión exhaustivas; soporte para el ciclo de vida de desarrollo de
software, incluido el control de versiones y la promoción de versiones; programación,
monitoreo y avisos de ejecución; análisis de aplicaciones y mucho más.

La única forma de satisfacer los requisitos anteriores consiste en diseñar, desde el principio, una
arquitectura que pueda cumplirlos. Y esto es así porque, una vez que se ha establecido una
arquitectura, resulta prácticamente imposible añadirle nuevas capacidades fundamentales. El
Co>Operating System fue diseñado desde el primer momento para que incluyese todas las
capacidades mencionadas. Es una tecnología robusta y comprobada que se utiliza con éxito para
una gama muy amplia de complejas aplicaciones de procesamiento de datos.

¿Qué es una aplicación de Ab Initio®?

El núcleo de una aplicación de Ab Initio es un grafo de flujo de datos (o un “grafo”, según la

expresión abreviada). Un grafo consta de componentes que se conectan mediante “flujos” de
datos.
Pongamos un ejemplo. El grafo siguiente es una aplicación sencilla que, primero, lee cada
registro desde un archivo plano donde se contienen transacciones de clientes. La aplicación
reformatea luego los datos (aplicándoles reglas) antes de ordenarlos. Seguidamente, la aplicación
agrupa (o agrega) los datos. A continuación, los resultados de este procesamiento se escriben en
una tabla de una base de datos, como Oracle.

Gracias al uso de componentes altamente configurables, el Co>Operating System de Ab Initio

proporciona los bloques funcionales fundamentales para el procesamiento de datos
empresariales. A saber:

 transformaciones de datos;
 selección/filtrado;
 desduplicación;
 unión/fusión;
 normalización/desnormalización;
 compresión/descompresión;
 agregación/escaneado;
 ordenación;
 generación y validación de datos;
 ...y muchos más.

Además, el Co>Operating System se distribuye con una surtida biblioteca de componentes

integrados que permite procesar prácticamente todo tipo de origen o de destino de datos. Esta
biblioteca incluye componentes para:

 conectar con cualquier clase de archivo plano en Unix, Windows y mainframes;

 conectar con todas las bases de datos comunes y algunas menos comunes (Oracle, DB2,
Teradata, SQL Server, Netezza, Greenplum, mainframe DB2, IMS, IDMS, Adabas, ...);
 conectar con todas las infraestructuras de colas de mensajes estándar (IBM MQ, JMS,
Microsoft MQ);
 conectar con infraestructuras de servicios web (WebSphere, WebLogic, IIS,
Apache/Tomcat, ...);
 conectar con muchos productos de terceros (SAP, Siebel, SAS, PeopleSoft,
Salesforce.com, ...);
 análisis y manipulación de estructuras de datos jerárquicas (XML, ASN.1, Cobol, ...);
 análisis, manipulación y generación de formatos de datos específicos a un dominio
(Swift, FIX, EDIFACT, ...);
 enrutamiento de mensajes con base en contenido;
  conectividad de metadatos con una amplia gama de definiciones de datos y productos de
inteligencia empresarial (ERWin, ERStudio, Microstrategy, Business Objects, Cognos,
...).

Las aplicaciones pequeñas pueden tener entre tres y cinco componentes. Las aplicaciones
grandes pueden tener hasta un centenar de componentes. Las aplicaciones muy grandes pueden
tener muchos miles de componentes. Las aplicaciones también pueden constar de muchos grafos,
cada uno de los cuales puede tener a su vez muchos componentes.

A lo largo del espectro que va desde las aplicaciones más pequeñas hasta las mayores, las
aplicaciones de Ab Initio explotan reglas y componentes reutilizables, habilitando una respuesta
rápida a necesidades empresariales cambiantes.

Lógica empresarial especificada de una forma completamente gráfica

Por debajo del nivel de componentes, el Co>Operating System puede aplicar prácticamente
cualquier tipo de regla y de lógica especificadas por el usuario a cualquier tipo de datos. Y esas
reglas se especifican de una manera gráfica. Comparada con otras tecnologías, el Co>Operating
System representa un salto importante. En la medida en que estas tecnologías proporcionan una
especificación gráfica de las reglas, sólo se aplican a reglas sencillas. Cuando las reglas se
vuelven complejas, el usuario se enfrenta a obstáculos insuperables. Al final, el usuario con
frecuencia tiene que abandonar la tecnología por otra más compleja, y en su lugar utilizar
métodos de programación tradicionales (Java, C++, scripts, procedimientos almacenados, Perl,
...).

Cuando los usuarios tienen acceso al Co>Operating System, se dan cuenta de que es más fácil
especificar una lógica compleja desde dentro del Co>Operating System que desde fuera. Esto
entraña implicaciones formidables para la productividad, la facilidad de uso y la transparencia.
De una parte, especificar reglas en un entorno gráfico es más sencillo y más rápido. Y de otra,
resulta más simple para los empleados de negocios comprender esas reglas.

En el Co>Operating System, el usuario especifica reglas utilizando el Lenguaje de manipulación

de datos (DML) de Ab Initio. Estas reglas se incorporan en los componentes de
“transformación”, que son los bloques funcionales básicos para procesar datos. Existen
componentes de transformación para asignar una clase de estructura de registros a otra, para
agregar datos, para filtrar datos, para normalizar y desnormalizar estructuras, o para unir varias
secuencias de registros, entre otras situaciones. Cada uno de estos componentes puede aplicar
reglas (especificadas en DML) a los registros a medida que éstos se procesan.

La captura de pantalla siguiente ilustra una regla sencilla que computa la salida de un
componente de asignación. A la izquierda aparecen los campos que entran en el componente; a la
derecha, los campos que salen de los componentes; y en el medio, las reglas.

Las reglas individuales se pueden armar con el “Editor de expresiones”, que mostramos a
continuación. Las expresiones pueden ser arbitrariamente largas y complejas, y el DML incluye
una biblioteca bien surtida de operadores y funciones integradas.
Ab Initio es también compatible con un conjunto alternativo de interfaces de usuario a través de
las cuales se especifican las reglas de negocio. Estas interfaces han sido pensadas para que
puedan ser usadas por personas con una capacitación técnica inferior: a menudo, analistas de
negocios y expertos en materias muy concretas. Son usuarios que utilizan una terminología
propia del ámbito de los negocios, en lugar de una terminología técnica, y que organizan las
reglas en un formato semejante a una hoja de cálculo:
Obtenga más información acerca del Business Rules Environment.

El Co>Operating System procesa nativamente cualquier tipo de datos

Con Ab Initio, los datos son exactamente lo que el Co>Operating System o el usuario quieran
que sean. Y esto es posible gracias a que el Co>Operating System no necesita convertir los datos
a un conjunto determinado y limitado de formatos integrados. En su lugar, el Co>Operating
System procesa los datos en su formato nativo (y los procesa, además, en cualquiera de los
sistemas operativos compatibles). El Co>Operating System, al igual que el resto de los
componentes de Ab Initio, puede procesar nativamente datos del mainframe en servidores Unix y
Windows, XML en mainframes, estructuras jerárquicas y bit-packed complejas, datos
internacionales con transcodificación automática, y así sucesivamente. A partir de los mismos
datos, el Co>Operating System generará idénticos resultados, independientemente de dónde se
esté ejecutando la aplicación.

Las aplicaciones pueden leer y escribir información desde un conjunto heterogéneo de sistemas,
mientras que los datos pueden tener formatos muy diferentes en diferentes puntos de la
aplicación. El siguiente ejemplo muestra una aplicación que lee datos del mainframe desde un
archivo plano, lee datos XML desde una cola de MQ, procesa esos datos con diferentes formatos
intermedios y da salida a los resultados en un archivo plano utilizando un conjunto de códigos
internacional.
El Co>Operating System sabe cómo obtener formatos de datos cualquiera sea el lugar donde
estén almacenados: catálogos de bases de datos, productos de definición de esquemas,
Copybooks de Cobol, DTD o XSD de XML, WSDL, hojas de cálculo o sistemas de formatos de
datos internos.

El formato de registros para el flujo intermedio marcado como “ASCII hierarchical” en el

ejemplo anterior tendría este aspecto:
Por último, el Co>Operating System y sus componentes saben cómo convertir automáticamente
formatos cuando sea necesario. Por ejemplo, si los datos EBCDIC y packed decimal se presentan
a un componente que escribe en una base de datos de Oracle, el componente convertirá
automáticamente los datos en ASCII y decimales si las columnas tenían esos formatos en la base
de datos.

Rendimiento y escalabilidad

El Co>Operating System fue diseñado de abajo a arriba para lograr un rendimiento y una
escalabilidad máximos. Cada aspecto del Co>Operating System ha sido optimizado para obtener
un rendimiento máximo de su hardware. Y no se necesita recurrir a la tecnología de computación
en la “nube”, porque el Co>Operating System distribuye de forma natural el procesamiento entre
las granjas de servidores.

El Co>Operating System suele ser, como mínimo, cuatro o cinco veces más rápido que la
siguiente tecnología más rápida. Esto incluye programas codificados manualmente en Java y en
C++. De hecho, muy pocos programadores pueden escribir un programa que se ejecute tan
rápido como la versión de Ab Initio. Pero la dificultad es aún mayor, porque los pocos
programadores capaces de hacerlo necesitarán invertir semanas codificando algo que, con Ab
Initio, se logra en unos pocos días. Semejante situación es poco probable, en cualquier caso,
porque los buenos programadores no se dedican exclusivamente a programar durante mucho
tiempo. Enseguida se los transfiere a diseño, arquitectura o gestión de proyectos.

¿Cómo consigue Ab Initio una escalabilidad y un rendimiento tan extraordinarios? ¿Cuál es su

secreto? La receta exitosa la forman muchos ingredientes, pero los más decisivos son su
arquitectura y una atención obsesiva por los detalles. La arquitectura del Co>Operating System
fue diseñada “a partir de primeros principios” para habilitar una computación escalable.
La arquitectura del Co>Operating System es conocida por ser una arquitectura que no comparte
nada (“shared-nothing”). Como el Co>Operating System no requiere que las CPU compartan
nada, estas CPU se pueden ejecutar de una manera completamente independiente entre sí. Ello
permite que una única aplicación abarque tantas CPU en tantos servidores como se quiera. El
Co>Operating System tiene capacidades para distribuir la carga de trabajo uniformemente entre
muchas CPU, con lo que se logra que la mayoría de las aplicaciones alcancen una escalabilidad
lineal. Esto significa que, al doblar el número de CPU, también se duplica el rendimiento. Diez
veces más CPU se traduce en diez veces más rendimiento. El Co>Operating System combina el
paralelismo de datos y el paralelismo de flujo para crear el número máximo de oportunidades
para ejecutar simultáneamente fragmentos de una aplicación.

El ejemplo sencillo que se muestra a continuación sirve para ver cómo una aplicación podría
particionar los datos de manera que el componente Score se ejecute en paralelo en muchas CPU
(y servidores). El componente Partition by Round-robin divide los datos de clientes en
secuencias de datos iguales, como alguien que reparte las cartas de una baraja de naipes. Luego,
el Co>Operating System ejecuta varias instancias del componente Score, con cada instancia
trabajando con una secuencia de datos. A medida que se da salida a cada registro desde cada
instancia del programa Score, el componente Interleave vuelve a fusionar las secuencias antes de
escribir el resultado en el archivo de salida. Es así de fácil.

Las arquitecturas “shared-nothing” funcionan maravillosamente mientras no se produzcan

embotellamientos. Un simple embotellamiento las hará fracasar. Aquí es donde la atención a los
detalles cobra importancia. Para que nunca se convierta en un obstáculo, cualquier parte del
sistema capaz de provocar un embotellamiento en serie debe estar diseñada e implementada
cuidadosamente. Los algoritmos de todos los componentes deben funcionar de manera óptima en
muchos escenarios diferentes. La comunicación y el transporte de datos entre particiones y
componentes debe utilizar los canales más eficaces. Sólo cuando se ha prestado atención a todos
estos detalles, el sistema será escalable.

Otro detalle de suma importancia es la ejecución de las reglas de negocio. Cuando el sistema está
bien diseñado, es aquí donde se consume la mayoría del tiempo de CPU. El motor de
transformaciones del Co>Operating System es la instancia que ejecuta las reglas de negocio. Este
motor tiene un diseño especial llamado un “compilador just-in-time”. El concepto alude al hecho
de que las reglas de negocio son compiladas por el Co>Operating System cuando está finalmente
disponible toda la información acerca de lo que se supone que deben hacer. Es decir, en el último
momento posible. El aspecto “just-in-time” aporta una flexibilidad enorme. A su vez, el
“compilador” está altamente optimizado para ejecutar una lógica de negocios tradicional con el
máximo rendimiento. Ésta es la razón por la que es difícil para un programador que utiliza
tecnologías tradicionales el poder competir con el Co>Operating System.
El modelo de procesamiento del Co>Operating System

El Co>Operating System es un sistema de procesamiento peer-to-peer (de igual a igual)

distribuido. Debe estar instalado en todos los servidores que formarán parte de la ejecución de
una aplicación. Es posible que cada uno de estos servidores ejecute un sistema operativo
diferente (Unix, Linux y zLinux, Windows, o z/OS).

Así es como el Co>Operating System administra un conjunto distribuido de procesos en una red
de servidores:

1
|
2
|
3
|
4
|
5
|
1.
El Co>Operating System se inicia en el servidor "maestro", que lee definiciones de aplicaciones,
formatos de datos, reglas lógicas, parámetros,...

Como se ve en estos diagramas, una aplicación de Ab Initio puede ejecutarse dentro de un único
servidor o en una red de servidores. La definición de la aplicación, el diagrama gráfico
especificado por el desarrollador, es la misma en ambos casos. Para ejecutar una aplicación en un
conjunto diferente de servidores basta con cambiar la especificación de dónde se ejecuta el
componente; la aplicación en sí no cambia. Por tanto, y sin hacer modificaciones, una aplicación
alojada en mainframes se puede “re-alojar” en un servidor Unix, o una aplicación alojada en un
servidor único en una granja de servidores, por poner dos ejemplos distintos.

El Co>Operating System se ejecuta indistintamente en Unix, Windows, Linux y zLinux, y z/OS.

Además, una aplicación única se puede ejecutar en cualquier combinación de estas plataformas.
Cada componente de una aplicación de Ab Initio se puede ejecutar en cualquier plataforma en la
que se haya instalado el Co>Operating System (a excepción de unos pocos componentes
específicos a una plataforma, como el acceso de VSAM en los equipos mainframe). El
Co>Operating System se encarga de la tarea compleja de mover datos entre los equipos, por lo
que proporciona un software intermedio sin fisuras y con capacidad de procesamiento. Por otro
lado, la asignación de componentes a equipos de destino se puede cambiar antes de ejecutar una
aplicación.

Cualquier componente o grupo de componentes puede ser asignado a un recurso de equipos

diferente:
Por lotes, en tiempo real, servicios web: el Co>Operating System lo hace todo

Las necesidades que impone armar y operar aplicaciones por lotes y en tiempo real son, por lo
común, muy diferentes. Como lo son también sus tecnologías. Todo lo contrario de lo que sucede
con el Co>Operating System, que dispone de una arquitectura única que se aplica por igual a los
sistemas por lotes, en tiempo real y de servicios web (SOA). En vez de necesitar una multitud de
tecnologías y diferentes equipos de desarrollo para cada sistema (con potencialmente varias
implementaciones de la misma lógica empresarial), el usuario del Co>Operating System puede
hacer lo mismo con mucho menos. Apoyado en el Continuous>Flows, el Co>Operating System
hace posible reutilizar en diferentes sistemas una misma tecnología, un mismo equipo de
desarrollo y una misma codificación de la lógica empresarial.

Con el Co>Operating System, que una aplicación se ejecute por lotes o en tiempo real depende
de lo que la aplicación lee y escribe. A continuación, se muestra una misma aplicación ejecutada
en distintos “escenarios”. Primero, como un sistema por lotes (conectado a archivos planos para
las entradas y las salidas). Segundo, como un sistema de colas en tiempo real (MQ para las
entradas y JMS para las salidas). Y por último, como un servicio web (obteniendo solicitudes de
servicio desde un sistema externo y devolviendo los resultados a ese mismo sistema):

Lotes
|
Colas
|
Servicios Web

Obtenga más información acerca de Continuous>Flows.

Integración con códigos heredados

Aunque el Graphical Development Environment y el Co>Operating System permiten armar y
ejecutar aplicaciones de extremo a extremo, sucede a menudo que los usuarios tienen
aplicaciones preexistentes o productos de software de terceros que funcionan bien y que no
merece la pena volver a implementar. Ab Initio facilita la reutilización de esas aplicaciones
preexistentes, tanto si están codificadas en C, C++, Cobol, Java, scripts de shell, o en cualquier
otra tecnología. De hecho, el Co>Operating System permite integrar esas aplicaciones en
entornos para los que no fueron diseñadas originalmente.

Los códigos heredados se integran en las nuevas aplicaciones convertidos en componentes que se
comportan exactamente igual que el resto de los componentes de Ab Initio. Para la mayoría de
los códigos heredados, esto es fácil. Lo único que se necesita es una especificación para las
entradas y las salidas del programa, junto con parámetros de línea de comandos. El ejemplo
siguiente muestra cómo se puede tomar un programa de Cobol que lee y escribe archivos planos
y conectarlo a una aplicación de Ab Initio. El código Cobol, junto con los Copybooks y el JCL,
se convierte en un componente de Ab Initio. Luego, el componente se coloca en una aplicación
de Ab Initio que comprende servidores Unix y un servidor mainframe. A partir de ahí, la
aplicación se conecta a varios orígenes y destinos de datos (SAS y una base de datos). Por
último, para mejorar el rendimiento, la carga de trabajo se particiona para que el código Cobol
pueda tener varias instancias ejecutándose en paralelo.

1
|
2
Los usuarios recopilan y añaden un rango
de datos relacionados con Cobol, como:
Ese componente se puede conectar
a cualquier elemento con el que se
pueda comunicar Ab Initio.

Resistencia muy alta ante datos no válidos

Uno de los aspectos más difíciles del armado y el mantenimiento de sistemas reales tiene que ver
con el procesamiento de datos inesperados o no válidos. Su aparición es algo que ocurre con
frecuencia. Cuando reciben datos de ese tipo, la mayoría de las aplicaciones se comportan de
forma errónea. Si hay suerte, simplemente se bloquean. Pero si no la hay, las aplicaciones
pueden terminar haciendo algo extraño con los datos no válidos. Puede incluso ocurrir que nadie
se dé cuenta de la anomalía hasta que los resultados no válidos hayan pasado a los sistemas que
siguen en la cadena de procesamiento y los hayan contaminado. Como cabe imaginar, la
limpieza de un desastre así toma tiempo y perjudica la productividad.

El Co>Operating System es, por definición, resistente a los datos no válidos. Es una tecnología
que constantemente verifica que los datos satisfacen los criterios especificados por el usuario y
por el sistema. Y si no lo hacen, no se permite que los datos sigan adelante sin ser antes
transformados. Al mismo tiempo, para los desarrolladores resulta fácil armar en la aplicación un
procedimiento automatizado de intervención y de notificación. Hay dos opciones. La
intervención se puede diseñar para corregir datos erróneos y volver a alimentar el sistema con
ellos. O se puede también diseñar para segregar todas las entidades de datos relacionadas, de
forma que puedan ser procesados más tarde de una forma coherente.

A continuación se muestra un ejemplo de cómo un desarrollador arma una aplicación en Ab

Initio que 1 captura datos con problemas; 2 ejecuta los datos con problemas a través de un
conjunto de reglas de “limpieza”; 3 devuelve los datos limpios al procesamiento original; 4
secuestra los datos que no se pueden limpiar; y, por último, 5 genera un informe acerca de los
datos con problemas que 6 se envía mediante una cola de MQ.

Todos los componentes de Ab Initio que procesan datos de formas interesantes tienen puertos
“Reject”, “Error” y “Log” opcionales. El puerto Reject recibe todos los datos con problemas; el
puerto Error recibe un registro correspondiente que describe cada problema; y el puerto Log
recibe información de depuración. Esto permite armar canalizaciones de procesamiento de datos
extremadamente robustas.

Resistencia muy alta a los errores del sistema

Los servidores fallan. Las conexiones de red se pierden. Las bases de datos dejan de cargar…
Cuantos más servidores participen en una aplicación, mayor será la probabilidad de que se
produzca en el sistema algún tipo de error. Armar aplicaciones que se recuperen con
confiabilidad de los errores, no es fácil. Aunque muchos desarrolladores piensan que son capaces
de armarlas, la robustez de una arquitectura sólo se demuestra después de que ésta se ha
recuperado de varios errores diferentes. Y superar esta curva de aprendizaje puede ser muy
difícil.

El Co>Operating System fue diseñado desde el principio para recuperarse con confiabilidad de
todos estos tipos de errores. Siempre y cuando el entorno haya sido configurado para que los
datos valiosos no se pierdan, la capacidad de puntos de verificación/reiniciar del Co>Operating
System permite reiniciar una aplicación en el punto en que se detuvo antes del error. La
aplicación se reinicia, incluso, si la aplicación comprende varias redes, varios servidores y varias
bases de datos (con independencia de si se ejecuta por lotes o en tiempo real). El Co>Operating
System utiliza un mecanismo parecido a la confirmación en dos fases, con un rendimiento
mucho más alto que el protocolo XA que es de uso estándar en la industria. En cualquier caso, el
Co>Operating System es compatible con entornos que requieren XA (incluso en aquellas
tecnologías de bases de datos y de colas de mensajes suministradas por otros proveedores).

El Co>Operating System impulsa la productividad con la reutilización

Para dar correcta solución a los problemas que enfrentan, las aplicaciones de Ab Initio pueden
llegar a ser muy grandes y complejas. En general, la mayoría de los sistemas incluyen gran
cantidad de fragmentos muy parecidos entre sí. Con las tecnologías de programación
tradicionales, los desarrolladores suelen acabar creando muchas copias de estos fragmentos para
luego modificar ligeramente cada una de ellas. Sin embargo, este remedio deriva muchas veces
en una pesadilla desde el punto de vista del mantenimiento y de la productividad.

Gracias a su tecnología mucho más versátil, Ab Initio proporciona un buen número de

mecanismos para incrementar radicalmente la reutilización de fragmentos de aplicaciones. Los
fragmentos son almacenables en el Enterprise Meta>Environment (EME®) de Ab Initio, un
repositorio centralizado. Desde allí, es posible reutilizarlos tanto dentro de una misma aplicación
como en otras aplicaciones. Éstos son algunos ejemplos de los elementos que se pueden
almacenar, gestionar y reutilizar centralmente:

 Formatos de registros
 Reglas de negocio y de lógica
 Secciones de aplicaciones (las aplicaciones se llaman “grafos” y las secciones se llaman
“subgrafos”)
 Orquestaciones de aplicaciones (“planes” en Conduct>It de Ab Initio)

La capacidad de reutilización de Ab Initio es muy potente. Los fragmentos de aplicaciones

reutilizados se pueden vincular a la versión centralizada de la que proceden; pudiendo rastrear,
contemporáneamente, los cambios realizados. Además, estos fragmentos pueden ser compatibles
con personalizaciones aplicadas localmente (sin dejar por ello de hacer un seguimiento de la
versión centralizada).

A continuación se muestra un ejemplo de uno de estos módulos de aplicaciones reutilizables: el

subgrafo. Un subgrafo puede contener los componentes de una subsección de una aplicación
(grafo). El tamaño o la complejidad posibles de los subgrafos son ilimitadas. Además, los
subgrafos pueden estar anidados. Los subgrafos se comportan de todas las formas en que se
comportan los componentes convencionales, y se pueden guardar en una biblioteca para ser
reutilizados en muchas aplicaciones.

Este subgrafo corresponde a la parte de control de errores de la aplicación que se describió

anteriormente:
Observe que los componentes de este subgrafo no se conectan en forma explícita a ningún
componente de entrada o de salida. En su lugar, están conectados a los puertos de entrada y de
salida del subgrafo “Standard Error Handling Process”.

A continuación, se muestra la misma aplicación que antes, armada ahora con el nuevo subgrafo
reutilizable para control de errores (los subgrafos se identifican visualmente en el GDE mediante
la línea de borde extra que los rodea):

Conclusión

El Co>Operating System es el software básico sobre el que se construye toda la arquitectura de

Ab Initio. Así, los conceptos arquitectónicos clave de Ab Initio se manifiestan en el
Co>Operating System. Y puesto que todas las tecnologías de Ab Initio incorporan de una forma
u otra el Co>Operating System, esos mismos conceptos quedan también incorporados de manera
coherente y sin fisuras.
Los resultados de esta arquitectura son:

 Se pueden armar sistemas de aplicaciones completos en un entorno gráfico sin tener que
recurrir a la codificación tradicional.
 El personal de desarrollo y mantenimiento técnico es mucho más productivo trabajando
con un paradigma gráfico que con la codificación tradicional.
 El personal técnico logra mejorar el tiempo de respuesta a las necesidades cambiantes del
negocio.
 Las aplicaciones son mucho más transparentes (y por ende, más fáciles de entender) para
los usuarios y los analistas de negocio.
 Los sistemas de aplicaciones son mucho más robustos en todos los sentidos. Tienen una
escalabilidad ilimitada. Son portátiles entre muchas plataformas. Pueden procesar
cualquier clase de datos complejos. Pueden implementar reglas de negocio muy
complejas. Pueden tolerar datos no válidos y errores del sistema… Y así sucesivamente.
 Las aplicaciones pueden volver a utilizar la lógica empresarial en aplicaciones por lotes,
en tiempo real y de servicios web.

Estos logros, entre otros muchos, son posibles gracias a que el Co>Operating System ha sido
diseñado, desde el principio, con una arquitectura única.

La infraestructura de tecnología de la información es el sistema nervioso central de los negocios

modernos, por lo que la gerencia de cualquier empresa necesita comprender su funcionamiento
en profundidad. ¿Qué información fluye a través de dicha infraestructura? ¿Qué representa esa
información y qué tan precisa es? ¿Cómo fluye de un lugar a otro? ¿Cómo se procesa y dónde se
almacena? La respuesta a todas esas preguntas la brindan los metadatos, que cabría definir como
“información acerca de la información”.

Obtener esos metadatos no es una tarea tan sencilla. Aunque hay productos que prometen
satisfacer la exigencia de lograrlos, su planteamiento es demasiado académico. De hecho, el
concepto de “información acerca de la información” nos lleva a preguntarnos a qué nos
referimos cuando hablamos de “información”. Es por ello que los productos de metadatos se han
centrado en definir conceptos y en averiguar cómo esos conceptos se relacionan entre sí. Aunque
los conceptos están en última instancia asociados a información real, la asociación es muy débil.
Los metadatos deben ser introducidos manualmente por personas y son, por consiguiente,
subjetivos, incompletos y sujetos a errores humanos. Son también metadatos que pronto quedan
inevitablemente obsoletos, puesto que hacen un seguimiento de sistemas reales que están
cambiando constantemente.

El planteamiento de Ab Initio es muy diferente, pues su tecnología se centra en metadatos

operacionales. Los metadatos operacionales pueden ser modificados por la gerencia empresarial
y por los responsables del departamento de tecnología de la información. Presentan, además,
características propias. Se basan en los sistemas que procesan los datos, las aplicaciones
instaladas en esos sistemas y las reglas definidas en esas aplicaciones. Se basan en conjuntos de
datos por toda la empresa (qué contienen, de dónde proceden y quién los utiliza). Se basan en la
calidad de los datos y en cómo esa calidad ha cambiado a lo largo del tiempo. Se basan, en
última instancia, en los múltiples elementos que forman los sistemas de tecnología de la
información.

Ab Initio también asocia estos metadatos operacionales a los metadatos de negocio (que son
definiciones empresariales, creadas por el personal de negocios, de los fragmentos de
información repartidos por la empresa). El resultado es un sistema de gestión de metadatos
corporativos, el Enterprise Meta>Environment® de Ab Initio®, o EME®.

Un sistema de gestión de metadatos corporativos debe ser, al mismo tiempo, muchas cosas
distintas para personas que pueden estar lidiando con situaciones diversas:

 El CFO necesita poder decir a los reguladores qué significa un campo de un informe y
cuál es el origen de sus datos.
 El CIO quiere conocer los sistemas de tecnología de la información, el hardware y el
software, de la compañía. ¿Quién tiene este sistema en propiedad? ¿De qué sistemas
depende? ¿Cuáles dependen de él? ¿Cuál es el nivel de calidad de los datos a través de
estos sistemas, y cómo cambia de un sistema a otro?
 El analista de negocios que está ayudando a un jefe de departamento a gestionar su
negocio necesita un glosario del negocio. Lo necesita para que le ayude a buscar
fragmentos de datos a los que debe acceder para elaborar un análisis que tiene que
entregar antes de las 5 de la tarde de hoy.
 El personal de operaciones desea saber qué ocurrió en la producción: hoy y en días
pasados. ¿Qué trabajos se ejecutaron con éxito? ¿Cuánto tiempo se tardó en ejecutarlos?
¿Cuántos datos fueron procesados? ¿Cuánta capacidad de reserva hay disponible? ¿Qué
tan buena es la calidad de los datos?
 El arquitecto de sistemas está preocupado por el inventario de aplicaciones, tablas de
datos, archivos y mensajes que componen los sistemas de la compañía. ¿Cómo están
conectados? ¿Qué genera cada uno? ¿Qué lee cada uno? ¿De qué depende cada uno?
 Los desarrolladores de aplicaciones desean conocer el historial de cambios hechos en su
código. ¿Qué aspecto tienen los datos ahora? ¿Qué corrigió cada uno? ¿Cuándo? ¿Cómo?
¿Por qué? ¿Qué fue lanzado? ¿Qué trabajo todavía está sin terminar?

La lista de posibles preguntas que favorecen la buena marcha de un negocio es interminable. Sin
embargo, existe un denominador común a todas ellas: la urgencia con la que hay darles una
respuesta. Esto es, precisamente, lo que se consigue con el Enterprise Meta>Environment de Ab
Initio.

Metadatos diferentes en contextos diferentes

El término “metadatos” encierra distintos significados según las diferentes industrias. Ab Initio
utiliza el término “metadatos” en el contexto del mundo de la computación empresarial. En el
mundo del procesamiento de imágenes, por ejemplo, significa algo completamente diferente.
Alude a la información acerca de cuándo fue capturada la imagen, qué clase de dispositivo la
tomó, la calidad de la luz, etc. Las páginas web también tienen metadatos: información sobre el
lenguaje en que se escribió la página, las herramientas utilizadas para crearla y cómo encontrar
más detalles acerca de este tema.
Exploración y comprensión de los metadatos

La interfaz gráfica para metadatos de Ab Initio, el Portal de metadatos del EME, permite al
usuario comenzar en cualquier punto del sistema y explorarlo en cualquier dirección. Todos estos
metadatos se presentan en el grado de detalle adecuado para cada audiencia. Los usuarios de
negocios no se ven así abrumados con detalles técnicos cuando están intentando responder
preguntas del negocio. Sin embargo, los desarrolladores y el personal de operaciones pueden
buscar fácilmente los detalles que les interesen.

Pensemos, por ilustrarlo con un ejemplo, en un archivo que el EME ha identificado como el
origen más remoto para un cálculo utilizado en un informe. ¿Qué le puede decir el EME a un
usuario acerca de este archivo? Gracias al planteamiento utilizado por Ab Initio, en el que se
relacionan elementos de metadatos, es posible reunir información importante acerca del archivo
a partir de la intuitiva interfaz gráfica. Recopilar detalles tales como los siguientes:

 qué aplicaciones utiliza el archivo;

 el formato de registros;
 la calidad de los datos;
 su tamaño a lo largo del tiempo;
 los valores documentados esperados para cada uno de sus campos;
 el censo de valores encontrados;
 los stewards (y sus gerentes) responsables del gobierno;
 la documentación acerca de su significado empresarial y el uso de cada uno de sus
campos;
 su relación con modelos lógicos y conjuntos de datos similares, como tablas de bases de
datos y mensajes;
 una lista de programas que leen o escriben el conjunto de datos.

A continuación, se muestra una captura de pantalla del EME durante el proceso de exploración
de los metadatos. La pantalla subyacente es un diagrama de linaje que visualiza un número de
conjuntos de datos y sus relaciones de procesamiento. Cada una de las imágenes superpuestas
muestra diferentes tipos de metadatos que se han vinculado al mismo elemento.

El EME puede mostrar

LINAJE DE DATOS e:
INFORMACIÓN DE STEWARDS DE DATOS
ESTADÍSTICAS OPERACIONALES
RESULTADOS DE PERFILADO DE DATOS
DEFINICIONES CONCEPTUALES
DETALLES DE CONJUNTOS DE DATOS
ESPECIFICACIONES DE ASIGNACIÓN
RELACIONES ENTRE ENTIDADES
MÉTRICAS DE CALIDAD DE DATOS
HEATMAP DE CALIDAD DE DATOS
MODELOS SEMÁNTICOS
Integración de metadatos

La captura de tantos metadatos y su almacenamiento en cubos independientes serían de por sí

logros importantes, pero el EME hace mucho más. Establece relaciones entre elementos de
metadatos, lo cual enriquece de forma efectiva su valor, revelando a los usuarios un significado
más profundo acerca de cuál es el negocio particular de una compañía.

El reto pasa, obviamente, por conseguir componer todos estos metadatos de una forma que sea
útil. Y en organizaciones grandes y complejas con entornos heterogéneos distribuidos que
pueden llegar a ser globales, el desafío es especialmente difícil. Al encararlo, se presentan
problemas de escalabilidad e integración. ¿Cómo se logran reunir metadatos desde un conjunto
tan dispar de orígenes y de tecnologías? ¿Cómo es posible procesar tanta información? ¿Cómo se
puede almacenar y visualizar la información de forma inteligente, sin abrumar al usuario pero sin
simplificar en exceso el contenido? ¿Cómo se logran unir metadatos salvando las barreras que
separan negocios, países y hasta idiomas?

El EME integra todas las clases diferentes de metadatos almacenados en él. Y como resultado,
multiplica el valor de cada uno de ellos. Esta integración habilita, por poner varios casos, el
linaje de datos de extremo a extremo a través de tecnologías dispares; estadísticas operacionales
consolidadas para una planificación de capacidad exhaustiva; o estadísticas de perfiles de datos y
métricas de calidad de datos totalmente vinculadas.

Para empezar, toda la información acerca de la definición y la ejecución de las aplicaciones de

Ab Initio se captura automáticamente y se carga en el EME. Esto incluye reglas de negocio,
estructuras de datos, estructura de aplicaciones, documentación y estadísticas de tiempo de
ejecución. Y como los usuarios arman aplicaciones operacionales de extremo a extremo con el
Co>Operating System®, todo lo relacionado con esas aplicaciones se captura también
automáticamente.

A continuación, estos metadatos se integran con metadatos externos a través de una combinación
del Metadata Importer del EME y de un procesamiento de metadatos complejo con el
Co>Operating System.

El soporte de Ab Initio para combinar metadatos desde varios orígenes permite que los
metadatos de un sistema de orígenes sean enriquecidos con metadatos procedentes de otros
orígenes. Por ejemplo, el Metadata Importer podría cargar los detalles centrales de las tablas de
bases de datos y columnas desde un catálogo de bases de datos para enriquecer luego los
metadatos con descripciones y vínculos lógicos desde una herramienta de modelado y, por
último, vincular los metadatos importados a métricas de calidad de datos. El Metadata Importer
puede cargar metadatos externos tales como:

 herramientas de notificación: MicroStrategy, Business Objects, Cognos, …;

 herramientas de modelado: ERwin, ERstudio y Rational Architect, …;
 catálogos de sistemas de bases de datos para todos los sistemas de administración de
bases de datos relacionales principales y casi todos los secundarios;
 metadatos tabulares, normalmente almacenados en hojas de cálculo que utilizan plantillas
predefinidas o “layouts” específicos a los clientes;
 protocolos estándar de la industria para los intercambios de metadatos, como el formato
Common Warehouse Model XML Metadata Interchange (CWM XMI).

Los orígenes de metadatos no estándar y personalizados también se pueden importar e integrar

en el EME. Los usuarios pueden aplicar las potentes capacidades de procesamiento de datos del
Co>Operating System a orígenes de metadatos arbitrariamente complejos. El Co>Operating
System puede extraer metadatos desde estos sistemas no estándar, procesarlos según sea
necesario y cargarlos e integrarlos con otros metadatos en el EME.

Muchos tipos de metadatos

El EME integra una gama muy amplia de metadatos y es completamente ampliable. La página
inicial del Portal de metadatos permite al usuario explorar directamente el tipo de metadatos que
le interesa:

Desde esta página se puede seleccionar un área de interés y examinar en profundidad:

Metadatos acerca de proyectos y aplicaciones. El EME almacena y gestiona toda la

información acerca de los proyectos de Ab Initio y las aplicaciones que contienen. Los proyectos
están organizados en jerarquías y se pueden compartir o mantener privados. El EME hace un
seguimiento de qué proyectos hacen referencia a otros proyectos, así como de los objetos dentro
de un proyecto.

Detalles acerca de las versiones de las aplicaciones. El EME mantiene información de versión
completa e historiales acerca de cada detalle de las aplicaciones de Ab Initio. Las diferencias
entre las versiones de los grafos, los formatos de registros y las reglas de transformación se
visualizan gráficamente. Los usuarios pueden ver detalles acerca de las versiones exactas que
están siendo utilizadas en producción.

Usuarios, grupos, bloqueos y permisos. El EME proporciona administración de controles de

acceso para todos los metadatos. Además, como parte de un sistema de gestión de código fuente
completo, el mecanismo de bloqueo exclusivo del EME para aplicaciones enteras o fragmentos
de aplicaciones impide que los desarrolladores interfieran entre sí.

Organización jerárquica de metadatos. Los metadatos se pueden organizar en jerarquías y en

carpetas arbitrarias para ayudar a capturar el significado de negocios y para proporcionar una
navegación focalizada.

Diccionarios de datos. El EME es compatible con la creación de uno o varios diccionarios de

datos o modelos de datos conceptuales. Los diccionarios de datos pueden ser una lista jerárquica
sencilla de términos de negocios, o un modelo semántico más complejo con relaciones complejas
entre los términos de negocios.

Las implementaciones diseñadas conjuntamente para un grupo empresarial tienen, por lo común,
varios diccionarios de datos: uno para cada división o gama de productos, así como un modelo
para la empresa. En el EME, los términos empresariales de una división se vinculan directamente
a columnas y campos, y establecen relaciones en sentido inverso hasta el modelo empresarial.
Esto permite a las empresas armonizar los conceptos de negocios dentro de la empresa sin tener
que forzar a cada división a abandonar su propio diccionario de datos.

Metadatos desde herramientas de notificación. El EME importa metadatos desde todas las
herramientas de notificación de inteligencia empresarial (BI) más importantes, como
MicroStrategy, Business Objects y Cognos. Ello incluye detalles sobre informes y campos de
informes, así como objetos de notificación internos como Facts, Metrics, Attributes y
Aggregates. Las consultas de linaje pueden rastrear los cálculos de varios campos de informe (a
través de las herramientas de BI) hasta el data mart o el almacén de datos, y desde allí hasta los
orígenes más remotos.

Metadatos desde sistemas de bases de datos. El EME importa metadatos (esquemas, tablas,
columnas, vistas, claves, índices y procedimientos almacenados) desde muchos sistemas de bases
de datos. El EME realiza un análisis de linaje a través de varios niveles de vistas y
procedimientos almacenados. En sistemas de bases de datos grandes, el EME suele ser la única
forma de comprender la interrelación de tablas de bases de datos, vistas y procedimientos
(especialmente en las consultas sobre análisis de impacto, los ejercicios de reutilización de tablas
y los proyectos de consolidación).

Metadatos desde archivos. El EME importa metadatos acerca de archivos, incluidos los
formatos de registros jerárquicos complejos como XML y Copybooks de COBOL.

Linaje de datos de extremo a extremo. El EME arma modelos completos del flujo de datos a
través de una empresa recopilando metadatos desde un gran número de sistemas operacionales
diferentes, herramientas de notificación, sistemas de bases de datos, productos ETL, scripts de
SQL, etc. Este modelo integrado permite a los usuarios hacer consultas acerca del linaje de los
datos, cómo se computaron y qué impactos causa un cambio.

Diagramas de sistemas. El EME almacena imágenes gráficas que pueden representar diagramas
de sistemas u otros diagramas de organización de metadatos. En el Portal de metadatos, al hacer
clic en un elemento gráfico vinculado dentro de un diagrama, el usuario se desplaza hasta el
objeto de metadatos conectado.

Modelos lógicos. El EME importa modelos lógicos y físicos desde herramientas de modelado
comunes. Modela vínculos a partir de modelos lógicos convirtiéndolos en modelos físicos, que
luego se fusionan con la información de esquema en las bases de datos reales.

Dominios y datos de referencia. El EME almacena datos de referencia (incluidos los dominios
y los valores de códigos de referencia). Puede ser el gestor primario para ciertos datos de
referencia, o puede hacer un seguimiento de los datos de referencia y mantener una copia desde
un sistema diferente. También es compatible con las asignaciones de código entre valores de
dominio lógicos y varias codificaciones físicas.

Perfiles de datos. El EME almacena resultados de perfilado de datos y los vincula a conjuntos
de datos y campos individuales. Se computan muchas estadísticas, como valores comunes y
distribuciones de datos. Estas estadísticas se pueden computar a petición, o automáticamente,
como parte de una aplicación de Ab Initio.

Estadísticas operacionales. El Co>Operating System genera estadísticas en tiempo de ejecución

para cada trabajo y para cada conjunto de datos que se lee o se escribe. Estas estadísticas se
pueden almacenar en el EME para análisis de tendencias, planificación de capacidad y consultas
operacionales de carácter general.

Métricas de calidad de los datos. Para su compatibilidad con un programa exhaustivo de

calidad de datos, Ab Initio computa las estadísticas de calidad de datos y las agregaciones de
errores y los almacena en el EME. El EME puede analizar y visualizar métricas de calidad de los
datos para conjuntos de datos y para colecciones de conjuntos de datos. Las métricas de calidad
de los datos también se pueden combinar con el linaje de los datos para ver un “mapa de riesgo”
que muestra dónde hay problemas con la calidad de datos en la empresa.

Especificaciones previas al desarrollo. El EME puede capturar especificaciones de asignación

como parte del proceso de desarrollo. El Portal de metadatos permite a los analistas especificar
orígenes y destinos preexistentes o propuestos junto con expresiones de asignación arbitrarias. Al
utilizar el EME para definir asignaciones, los usuarios pueden ver cómo las asignaciones encajan
dentro de un linaje de empresa más amplio.

Estas especificaciones se pueden utilizar para guiar a un equipo de desarrollo y para registrar
requisitos permanentemente. Después de la implementación de producción, el EME seguirá
mostrando estas especificaciones en diagramas de linaje al lado de sus implementaciones
actuales.

Reglas de enmascaramiento de datos. El EME almacena reglas de enmascaramiento de datos,

que luego cabe aplicar a los datos que fluyen a través de las aplicaciones de Ab Initio. Ab Initio
proporciona muchas reglas integradas, y los usuarios pueden definir sus propios algoritmos de
enmascaramiento personalizados. Estas reglas pueden estar asociadas a campos o a columnas; o
estar asociadas a términos de negocios en el modelo conceptual. Cuando están vinculadas en un
nivel conceptual, las reglas de enmascaramiento de datos se aplican automáticamente a las
columnas y a los campos físicos correspondientes.

Stewards de datos y metadatos acerca de personas y de grupos. El EME almacena metadatos

acerca de personas y de grupos. Estos metadatos pueden estar vinculados a otros objetos de
metadatos para documentar roles de gobernabilidad de datos tales como los stewards de datos.
Los metadatos acerca de personas y de grupos se pueden importar automáticamente desde
sistemas externos tales como los servidores LDAP corporativos.

Informes de metadatos integrados y personalizados. El EME proporciona muchos informes

integrados. Los usuarios también pueden definir informes personalizados que se ejecutan con
metadatos almacenados en el EME y a los que se accede desde el Portal de metadatos.

Metadatos personalizados. Los usuarios pueden extender el esquema del EME para permitir
que una amplia variedad de metadatos adicionales sean integrados en el EME. Las extensiones
de esquema incluyen la adición de atributos a objetos preexistentes, así como la creación de
nuevos objetos de metadatos que se pueden vincular a otros metadatos preexistentes. Los
usuarios pueden personalizar fácilmente la interfaz del usuario del EME para habilitar las vistas
tabulares y gráficas tanto en los metadatos estándar como en los personalizados.

El EME® es un sistema abierto

El EME es un sistema abierto basado en tecnologías estándar dentro de la industria y que

enumeramos a continuación:

 Un esquema relacional extensible publicado. El EME viene preconfigurado con un meta

esquema bien surtido que contiene una amplia variedad de tipos de metadatos. El meta
esquema se puede personalizar y extender con tablas y columnas para su compatibilidad
con una variedad de metadatos definidos por el usuario. El EME administra estas
extensiones y personalizaciones en colaboración con los objetos de metadatos integrados,
y suministra una personalización completa de pantallas e informes.
 Una base de datos relacional comercial estándar (actualmente Oracle, DB2 o Microsoft
SQL Server), que contiene todos los metadatos de negocio y resúmenes de los metadatos
operacionales y técnicos. Los metadatos técnicos se almacenan en un almacén de datos de
objetos al que se accede con ODBC.
 Una interfaz de usuario gráfica que se puede alojar en cualquier navegador web estándar.
Además, el EME es compatible con la navegación hasta repositorios externos de
metadatos detallados, como sistemas de administración de documentos, bases de datos de
imágenes y productos de terceros.
 Una arquitectura de tres niveles que utiliza una tecnología de servidores de aplicaciones
común. Encima de la base de datos hay un servidor de aplicaciones Java estándar
(actualmente WebSphere, WebLogic, JBoss o Apache Tomcat) que administra la
seguridad, calcula vistas basadas en roles e implementa los flujos de trabajo teniendo en
cuenta el mantenimiento de los metadatos.
 Compatibilidad con herramientas de informes externas. Aunque el EME es compatible
con una amplia gama de informes integrados mediante el Portal de metadatos, hay
 productos de informes de terceros que también pueden acceder directamente a los
metadatos de la base de datos para realizar informes personalizados. El esquema
relacional está completamente documentado e incluye vistas de bases de datos
preconfiguradas para la compatibilidad con estas herramientas de informes.
 API de servicios web para habilitar, como un servicio, una arquitectura y unos metadatos
orientados a servicios. Las interfaces permiten que los sistemas externos puedan consultar
metadatos de negocio y confirmar solicitudes de cambios de metadatos. Los sistemas
externos también se pueden suscribir a cambios en los metadatos, con lo que se permite
que el EME envíe mensajes cuando se produzcan cambios aprobados. Por ejemplo, si el
EME está administrando valores válidos, el flujo de trabajo de aprobación (que se
describe más adelante) puede enviar mensajes a sistemas operacionales externos para
actualizar sus consultas almacenadas en la memoria caché de estos valores válidos.
 Exportaciones de metadatos. Además de las interfaces de acceso a los datos, el EME
también puede exportar metadatos de muchas formas. Por ejemplo:
o Prácticamente cada pantalla tabular del EME se puede convertir en una hoja de
cálculo de Excel haciendo clic con el mouse.
o El EME puede exportar metadatos en el estándar emergente para el intercambio
de metadatos, CWM XMI.
o El EME puede generar un universo de Business Objects y rellenarlo con
metadatos.

Gobierno de datos

El EME suministra procesos de gobierno de datos complejos que se pueden personalizar para
satisfacer las necesidades de empresas grandes.

Para los metadatos técnicos (aplicaciones y reglas de negocio), el EME es compatible con un
sistema de administración de control de versiones completo, con operaciones de “check-
in/check-out”, bloqueo, versiones, ramas y diferenciación.

Para los metadatos de negocio y operacionales, el EME incluye un flujo de trabajo de gobierno
de metadatos integrado, que incluye colas de trabajo, aprobaciones y auditorías. El EME también
puede comunicarse con herramientas de flujo de trabajo de aprobación externas. El mecanismo
de flujo de trabajo de propuesta/aprobación del EME está basado en los conjuntos de cambios.
Los usuarios crean conjuntos de cambios (para proponer adiciones, actualizaciones o
eliminaciones de metadatos) y después los confirman para su aprobación.

La captura de pantalla siguiente muestra el proceso de confirmación de un conjunto de cambios:

Cuando un usuario confirma un conjunto de cambios para su aprobación, el EME envía un
mensaje de correo electrónico a los stewards de metadatos adecuados. Estos stewards pueden
inspeccionar los cambios propuestos y aceptarlos, o rechazarlos. Si se aceptan, el conjunto de
cambios se aplica y se vuelve visible para todos los usuarios.

El EME también es compatible con la integración de conjuntos de cambios mediante la API de

servicios web, así como con sistemas de gestión de los procesos del negocio (BPM) o de
aprobación de flujos de trabajo externos, como AquaLogic de Oracle. En este caso, el sistema de
flujo de trabajo externo es responsable de comunicar elementos en colas de trabajo, documentar
comunicaciones, administrar remisiones y solucionar estados finales.

Los conjuntos de cambios aprobados quedan incorporados en las nuevas versiones de los
metadatos en el EME, donde se mantiene un historial completo y detallado de todas las versiones
previas.

La administración de metadatos empresariales ha sido durante mucho tiempo un objetivo que

ambicionaban las compañías grandes, aunque poco viable. Los “repositorios” pasivos (simples
diccionarios de datos muy sofisticados, en la mayoría de las ocasiones) sólo contenían una
fracción de los metadatos pertinentes. Además, estos repositorios pronto se volvían “islas” de
metadatos desfasadas. Llama la atención que las organizaciones que más necesitaban un enfoque
exhaustivo para administrar metadatos fuesen las que menos probabilidades tenían de hacerlo
con éxito. Nos referimos a compañías globales complejas con problemas inherentes de
escalabilidad. Compañías con orígenes de metadatos diversos, con grandes cantidades de
información para visualizar y explorar, y con problemas de seguridad que atravesaban las
fronteras entre sus negocios.

El Enterprise Meta>Environment de Ab Initio ha hecho posible, por fin, la administración de

metadatos empresariales y la ha convertido en un reto asequible para las compañías más grandes.
Veamos varios ejemplos del impacto que, para algunos de nuestros clientes, ha traído el uso de
esta novedosa tecnología:

 Con el EME, un banco global pudo después de muchos fracasos satisfacer las solicitudes
de su regulador para que su contabilidad fuese verificable. Un programa de calidad de
datos a escala completa a través de la empresa, incluidas las mediciones de calidad en
varios puntos del linaje de los datos, se puso en marcha utilizando el EME.
 Una institución financiera muy importante ahorró decenas de millones de dólares en el
reemplazo de un sistema de software clave. Gracias al EME, la entidad logró comprender
cabalmente cómo funciona el código heredado (lo que habilitó al negocio y al
departamento de tecnología de la información para colaborar en la descripción de los
requisitos de funcionamiento del nuevo sistema). Se eliminaron así muchas personas y se
ahorraron años de esfuerzos en planificación.
 Varias empresas multinacionales que operaban en entornos de tecnología de la
información increíblemente complejos –con operaciones en 100 países, miles de sistemas
diferentes y cientos de miles de archivos, tablas de base de datos y mensajes– pasaron a
utilizar el EME para inventariar cada fragmento de datos y definir su significado y su
valor. El EME funciona para ellas como un sistema de gestión de activos. Estas
compañías saben ahora que los datos son activos a los que hay que dar seguimiento, igual
que se le da seguimiento a los automóviles, los edificios o el equipamiento de sus
oficinas.

El EME de Ab Initio no se creó de un día para otro. Tampoco surgió en un laboratorio lleno de
ingenieros geniales pero desconectados del mundo. Su desarrollo es el resultado de años de
trabajo y compromiso serio entre compañías que buscan soluciones concretas a problemas reales.

El procesamiento de datos empresariales en tiempo real representa un verdadero desafío cuyos

requisitos muy pocos productos de software son capaces de satisfacer. Ab Initio® es uno de ellos.

Ab Initio es compatible con una amplia gama de aplicaciones en tiempo real, como la aplicación
“mini-batch”, la aplicación de “mensajería asincrónica” de alto volumen, las aplicaciones
orientadas a servicios de cliente (en inglés “Service Oriented Architecture”, o SOA), o las
aplicaciones de “solicitud/respuesta” de baja latencia. Aplicaciones todas ellas con una
tecnología única: el módulo Continuous>Flows del Co>Operating System®.

El Co>Operating System® es un “motor de flujo de datos” que hace que secuencias de registros,
o de transacciones, fluyan a través de una secuencia de “componentes”. Cada uno de estos
componentes realiza varias computaciones con registros de entrada para generar registros de
salida (aplicando, por ejemplo, reglas de negocio). La lógica de procesamiento compleja se
descompone en pasos de fácil comprensión, cada uno de los cuales lo realiza un componente
diferente. Los registros fluyen a través del conjunto de componentes necesario hasta que el
procesamiento se completa.

Este modelo de flujo de datos es adecuado tanto para el procesamiento por lotes como para el
procesamiento en tiempo real. Aunque la mayor parte de una aplicación por lotes y su
correspondiente aplicación en tiempo real sean muy similares (o incluso, idénticas), son los
componentes de punto final los que determinan si la aplicación será por lotes o en tiempo real.
Una aplicación por lotes se conecta a archivos planos y a componentes de tabla de base de datos
estáticos. Por el contrario, una aplicación en tiempo real se conecta a colas de mensajes, servicios
web, RPC, servidores CICS y/o componentes especiales (normalmente vía sockets TCP).

Con Ab Initio, la ventaja de que las aplicaciones por lotes y las aplicaciones en tiempo real
tengan tanto en común redunda en una complejidad significativamente más baja y en un
rendimiento mucho más alto (a lo que ayuda el que ambas aplicaciones utilicen una única
tecnología, el Co>Operating System). La menor complejidad se traduce así en una más alta
productividad y en la consiguiente reducción de costos.

Reutilización de la lógica de negocios entre aplicaciones por lotes y en tiempo

real

En la mayoría de los casos, los componentes de la lógica de negocios entre los componentes de
entrada y de salida permanecen iguales, lo que significa que la misma lógica se puede reutilizar
entre las aplicaciones por lotes y las aplicaciones en tiempo real. Esto último tiene implicaciones
decisivas para la productividad. En aquellas soluciones que no usan la tecnología de Ab Initio,
las tecnologías y las metodologías para el procesamiento por lotes y en tiempo real suelen ser
muy diferentes (lo que obliga a implementar la misma lógica de negocio varias veces dentro del
rango de usos que va desde la ejecución por lotes a la ejecución en tiempo real). Con Ab Initio,
la lógica del negocio sólo se desarrolla una vez, para integrarse luego en las infraestructuras por
lotes y en tiempo real de Ab Initio:
Mejora del rendimiento para diferentes modelos de ejecución en tiempo real

Los arquitectos de aplicaciones se enfrentan a menudo a dificultades que nacen de la necesidad

de satisfacer requisitos de rendimiento aparentemente en conflicto:

 Las aplicaciones por lotes necesitan procesar datos lo más eficazmente posible. Puede
ocurrir que un trabajo por lotes tarde mucho en ejecutarse porque hay demasiadas
transacciones para procesar, de manera que ninguno de los resultados está disponible
hasta que se completa el trabajo. Sin embargo, durante la ejecución, se espera que un
trabajo por lotes procese un número muy alto de registros por segundo.
 Las aplicaciones “mini-batch” son colecciones de trabajos por lotes que procesan
individualmente pequeños volúmenes de datos. A veces sucede que en un día se ejecutan
miles o decenas de miles de pequeños trabajos de ese tipo. Al limitar la cantidad de datos
procesados por un trabajo, se minimiza el tiempo de respuesta. Este planteamiento
también permite que las mismas aplicaciones procesen con eficacia volúmenes de datos
muy grandes en una modalidad por lotes tradicional. La administración de decenas de
miles de trabajos al día presenta su propio conjunto de complejidades, que Conduct>It®
de Ab Initio resuelve con solvencia.
 Las aplicaciones de mensajería asincrónica se conectan a colas de mensajes. Se trata de
aplicaciones que también necesitan procesar transacciones tan eficazmente como sea
posible. Sin embargo, los sistemas que siguen en la cadena de procesamiento esperan, en
general, sus mensajes de respuesta en un plazo que oscila entre unos pocos segundos y
decenas de segundos. De hecho, si una aplicación asincrónica puede responder dentro de
un plazo de un segundo o dos, puede también ser compatible con el uso interactivo.
 Se espera que las aplicaciones de mensajería de “solicitud/respuesta” o asincrónicas
procesen una transacción tan pronto como aparezca y que respondan tan rápido como sea
posible (por lo común, con una latencia menor a un segundo). Si varias aplicaciones de
ese tipo trabajan juntas para procesar una transacción, es posible que las aplicaciones
individuales necesiten emitir respuestas en un plazo que oscila entre décimas y
centésimas de un segundo. Ab Initio se mueve en ese “punto óptimo” donde las unidades
de trabajo significativas se realizan confiablemente en el rango de las decenas de
milisegundos (por contraste con los umbrales más amplios dentro de los cuales se
manejan otros sistemas especializados más estrechos).

Continuous>Flows del Co>Operating System de Ab Initio es una tecnología única que los
clientes utilizan de forma eficaz en todos los modos referidos anteriormente. Y ello es factible
porque la arquitectura del Co>Operating System fue diseñada, desde el primer momento, para
satisfacer los requisitos impuestos por los más diversos planteamientos de trabajo.

Ab Initio presenta dos diferencias primordiales entre las aplicaciones por lotes (incluidas las
“mini-batch”) y las aplicaciones en tiempo real:

 Terminación: Las aplicaciones por lotes finalizan cuando han terminado de procesar
todos los datos de sus entradas. Después de la terminación, no queda ningún recurso del
sistema asociado a una aplicación por lotes.
 Una vez iniciadas, las aplicaciones en tiempo real permanecen activas indefinidamente
hasta recibir y procesar las transacciones que llegan a sus entradas. Si hay un período de
inactividad en el flujo de transacciones, una aplicación en tiempo real espera hasta que
aparezcan nuevas transacciones.

 Puntos de verificación y recuperación: Las aplicaciones por lotes toman puntos de

verificación en ubicaciones predeterminadas. Todos los datos que pasan por una de estas
ubicaciones se guardan en el disco (a no ser que el punto de verificación no haya sido
comprobado con éxito). La recuperación consiste simplemente en reiniciar una aplicación
en el último punto de verificación que tuvo éxito.

Las aplicaciones en tiempo real pueden tomar puntos de verificación entre transacciones
con una frecuencia que puede ser tan alta como para hacerlo con cada transacción. O
pueden, también, hacerlo con menor frecuencia y según otros criterios (como el tiempo
transcurrido, o el número de transacciones). Una aplicación reiniciada automáticamente
retoma el procesamiento en la última transacción registrada con éxito por el punto de
verificación.

Interfaz con una amplia gama de sistemas en tiempo real

Continuous>Flows de Ab Initio suministra interfaces con una amplia gama de sistemas en

tiempo real:

 sistemas de colas de mensajes de terceros: IBM MQ, JMS, RabbitMQ, Kafka y Microsoft
MQ. Ab Initio proporciona componentes para conectar directamente con todos estos
sistemas de colas de mensajes.
 servicios web: WebSphere, WebLogic, IIS y Apache/Tomcat.
 colas de mensajes de Ab Initio y RPC para conexiones de punto a punto de latencia baja
y volumen alto entre aplicaciones de Ab Initio.
 software de mensajería heredado o interno.

Soporte nativo para servicios web y SOA

Las aplicaciones de Ab Initio pueden implementar fácilmente servicios web en una arquitectura
orientada a servicios (SOA). Esto se logra mediante un servlet proporcionado por Ab Initio que
está instalado en el servidor de aplicaciones estándar que elija el cliente: WebSphere, WebLogic,
IIS o Apache/Tomcat. El servlet proporciona un mecanismo de registro para asociar
invocaciones a un servicio web determinado con aplicaciones de Ab Initio específicas. Cuando
se recibe una invocación a un servicio web, el servlet se comunica con la aplicación de Ab Initio
vía TCP (la aplicación de Ab Initio se ejecuta en su propio conjunto de procesos y está fuera del
servidor de aplicaciones), para devolver después al solicitante original los resultados remitidos
por la aplicación de Ab Initio.
El Co>Operating System también proporciona compatibilidad total con el análisis de mensajes
definidos por WSDL.

Interfaces con sistemas de mensajería de propósito especial y heredados

Los productos de colas de mensajes comerciales y los servicios web son relativamente nuevos en
la industria y ofrecen tasas de rendimiento modestas. Los clientes con grandes volúmenes de
mensajes han armado soluciones de mensajería internas de alto rendimiento (como también lo
han hecho aquellas empresas cuyas necesidades son anteriores a la aparición de productos
comerciales de colas de mensajes).

Continuous>Flows suministra interfaces robustas compatibles con estas soluciones heredadas a

través de componentes de procesamiento especiales (“Universal Subscribe” y “Universal
Publish”). Estos componentes invocan subrutinas de C++ personalizadas que se comunican con
el sistema de mensajería heredado. También manejan la restitución y la recuperación en caso de
errores.
Ab Initio, en combinación con los sistemas de mensajería de propósito especial, puede alcanzar
tasas de rendimiento extremadamente altas. Se han llegado a medir tasas continuadas de más de
500 000 mensajes por segundo en aplicaciones de misión crítica.

Además, los componentes Universal Subscribe y Universal Publish se utilizan de la misma forma
que los componentes de Continuous>Flows para productos de colas de mensajes creados por
terceros. Esto proporciona a los usuarios la opción de cambiar su solución de colas de mensajes
interna por un producto de colas de mensajes de terceros. Y de forma sencilla, además: haciendo
simplemente unos cambios menores en sus aplicaciones de Ab Initio.

Robustez en caso de errores

Los puntos de verificación del Co>Operating System proporcionan un manejo robusto de los
errores de la aplicación. Un punto de verificación permite que una aplicación confirme cambios
en varias bases de datos y sistemas de entrada y de salida (colas). En el caso de que se produzca
un error en la aplicación, el Co>Operating System “restituye” el entorno hasta el último punto de
verificación que tuvo éxito. Cuando se haya solucionado el problema subyacente (“la base de
datos no se puede cargar”, “no hay espacio suficiente en el disco”, “hay un error en la red”, son
algunos de los mensajes), la aplicación se puede reiniciar. En ese caso, retomará el
procesamiento automáticamente desde la última transacción procesada con éxito.

Es sabido dentro de la industria que, en general, los esquemas de puntos de verificación

consumen una cuota elevada de recursos computacionales. Los intentos de los desarrolladores
por minimizar ese gasto suelen dar lugar a aplicaciones inestables y complejas. La arquitectura
del Co>Operating System fue diseñada tanto para tener un rendimiento extremadamente alto
como para que sea robusta. El Co>Operating System proporciona alternativas a los puntos de
verificación que compensan la latencia de transacciones frente al tiempo de recuperación. En
todos los casos, el Co>Operating System garantiza que, en última instancia, cada una de las
transacciones sólo se escriba una vez en todos los dispositivos de destino (bases de datos,
archivos y colas).

El Co>Operating System recurre a dos mecanismos básicos para fijar los puntos de verificación.
El más conocido es el protocolo estándar XA para confirmaciones en dos fases. El Co>Operating
System incluye un administrador de transacciones que coordina las confirmaciones a través de
productos de bases de datos y de colas de mensajes dispares (que puede, incluso, procesar
transacciones por lotes en una confirmación única para incrementar así el flujo transmitido).

Sin embargo, el protocolo XA entraña ciertas limitaciones. Además de incurrir en un gasto

elevado de recursos computacionales y de ser complejo de administrar, no es compatible con
todos los dispositivos de entrada y de salida deseados. De ahí, que la mayor parte de los usuarios
de Ab Initio dependan del mecanismo de puntos de verificación nativo del Co>Operating
System, muy similar a una confirmación en dos fases. Este mecanismo, que destaca por su
rendimiento elevado y robustez, funciona con todos los dispositivos de entrada y de salida con
los que se conecta Ab Initio (bases de datos, archivos y colas). Y funciona, además, con
servidores en ambientes heterogéneos y distribuidos. Ab Initio también ha integrado en sus
componentes de conector maneras de compensar las limitaciones de ciertos productos de colas
de mensajes de otros desarrolladores de software. Quizá se entienda con un ejemplo: en ciertos
productos, el fallo de un administrador de colas de mensajes puede hacer que las transacciones se
entreguen más de una vez.

Con el sistema de puntos de verificación nativo del Co>Operating System, se puede controlar la
frecuencia de los puntos de verificación de varias maneras. Como por ejemplo, a través del
número de transacciones y el tiempo transcurrido; o a través del resultado de un evento como un
testigo especial en la secuencia de mensajes. Además, se puede controlar el grado de coherencia
transaccional en el tiempo del punto de verificación a través de varios dispositivos de salida. Las
opciones de configuración por defecto dan como resultado un rendimiento muy alto, ya que
nunca se pierden transacciones y tampoco se sacrifica la corrección de la aplicación.

Robustez operacional

El Co>Operating System satisface con rigor las exigencias operacionales para las aplicaciones en
tiempo real de misión crítica. Algunos ejemplos de mecanismos son:

 la ejecución de varias instancias de una aplicación en tiempo real, y al mismo tiempo,

para el equilibrio de las cargas y la conmutación por error;
 la desactivación de fragmentos de un sistema de aplicaciones para que unos módulos
actualizados puedan ser iniciados sin suspender un sistema nonstop que brinda soluciones
las 24 horas del día;
 la agrupación de conexiones con las bases de datos para limitar el uso de recursos;
 la agrupación de varios componentes (“folding”) en un proceso único para disminuir el
gasto de CPU y el consumo de memoria;
 la utilización de “micrografos” (lógica de grafos que se puede cargar dinámicamente)
para reducir dramáticamente el uso de recursos del sistema operativo.

El enfoque con el que Continuous>Flows resuelve el procesamiento en tiempo real combina tres
elementos. A saber: un incremento de la productividad fruto de la implementación de flujos de
datos gráficos; un modelo general para establecer la conexión con secuencias de datos; y, por
último, mecanismos robustos para trabajar de manera confiable con puntos de verificación y para
coordinar transacciones.
Ab Initio satisface las necesidades de una amplia gama de usuarios. Por una parte, facilita el
trabajo de los desarrolladores de aplicaciones, quienes tienen a su cargo el diseño y armado de
sistemas sofisticados capaces de procesar grandes cantidades de datos en entornos complejos. A
estos usuarios, Ab Initio les ofrece el Graphical Development Environment™ (GDE®), una
tecnología que simplifica el armado de procesos complejos en un entorno gráfico bajo una lógica
de negocio también complicada. Las aplicaciones resultantes se ejecutan en el Co>Operating
System®, que es extremadamente robusto y escalable.

Por otra parte, Ab Initio simplifica el día a día de aquellos usuarios que proceden del área de
negocios, los cuales no están ni capacitados ni interesados en la mecánica de procesamiento de
terabytes de datos o de miles de mensajes por segundo. Estos usuarios, no obstante, tienen muy
claro cuáles son las cosas que sus sistemas deben lograr. De hecho, con frecuencia, ellos conocen
mejor que nadie los detalles de los datos y las reglas que controlan el negocio.

A lo largo de los años, se ha ido produciendo un distanciamiento, a veces hostil, entre los
equipos encargados de la tecnología de la información de las empresas y los usuarios de
negocios a quienes asisten. Éstos últimos conocen cuáles son los objetivos y lo que significan
para el negocio. A su vez, los profesionales de la tecnología de la información son quienes saben
cómo hacer dichos objetivos asequibles. El departamento de tecnología de la información pide
las especificaciones y los usuarios de negocios hacen lo que está en su mano para proveerlas en
detalle. Claro que es inevitable que se produzcan ambigüedades y errores, tanto en las
especificaciones propiamente dichas como en su conversión a código de programación. El
proceso (dentro del cual se incluyen además las fases de comprobación y lanzamiento) nunca
funciona ni con la fluidez ni con la rapidez esperada. En cada etapa, a alguna persona le toca
descifrar lo que quiso decir otra. Esto toma mucho tiempo. Y lo que es peor: las distintas fases
propician nuevas ocasiones para cometer errores. Pasa además que cada vez se tarda más tiempo
en encontrar los errores, contrastarlos con las especificaciones y cambiar el código. Todo lo
anterior hace que la productividad se resienta y que la corrección nunca quede asegurada por
completo. Y sucede a veces que el ciclo nunca converge, por lo que el proyecto acaba
fracasando.

¿Se imagina que los usuarios de negocios controlaran los fragmentos específicos de los sistemas
con los que se implementa su lógica de negocio? ¿Se imagina que sus reglas de negocio se
pudieran expresar de una forma fácil de comprender y que fueran reglas que incluso ellos
mismos pudieran escribir, las cuales se pudieran además convertir automáticamente en un código
de programación ejecutable dentro de un sistema de mayor envergadura? Suena maravilloso, ¿no
es cierto? Ese es, precisamente, el concepto en el que se basa el Business Rules Environment.

El Business Rules Environment™ (BRE®) de Ab Initio® permite a los analistas empresariales

especificar las reglas de negocio en un formato familiar y cómodo: el formato de las hojas de
cálculo con filas y columnas. En el BRE, las reglas se especifican en términos empresariales, y
no técnicos, mediante expresiones que conoce cualquiera que haya trabajado con Microsoft
Excel. Gracias a ello, no sólo se pueden especificar reglas con rapidez y precisión, sino que
también su comprensión acaba siendo más fácil para el resto de los empleados de negocios.
Pero hay más ventajas. El BRE otorga a los usuarios de negocios el control sobre la verificación
de las reglas. Los usuarios de negocios no sólo pueden especificarlas directamente en el sistema,
sino que también pueden ver de inmediato los resultados de su aplicación en los datos de
comprobación. Y si no están satisfechos, pueden cambiar las reglas allí mismo. El tiempo que se
ahorra es enorme.

El Business Rules Environment de Ab Initio® no es una herramienta autónoma

Los “motores de reglas” tradicionales son herramientas autónomas. Es preciso personalizarlas

para que puedan interactuar con otros productos y con el resto de la infraestructura de
computación. Además, su rendimiento y su escalabilidad son limitados. Sólo pueden procesar
estructuras de datos sencillas. Su perspectiva se reduce a las reglas que procesan, por lo que no
pueden hacer un seguimiento del linaje a través de sistemas enteros.

Las limitaciones y problemas enumerados los soluciona el BRE de Ab Initio, en la aplicación

web Express>It®. Y los puede resolver porque el BRE está íntimamente relacionado con el
Co>Operating System y con las tecnologías de metadatos de Ab Initio. Su arquitectura y su
implementación fueron concebidas de esa forma. O para decirlo de otra manera: esta
característica suya no es un accidente ni el resultado de una estrategia de marketing.

 Las mismas reglas del BRE se pueden ejecutar sin necesidad de volver a implementarlas
en aplicaciones por lotes, continuas, de servicios web y en tiempo real.
 Las reglas del BRE se ejecutan con una eficiencia extraordinaria y se pueden escalar para
ejecutarlas así en varias CPU y en varios servidores. La escalabilidad de los sistemas
armados con Ab Initio es, por lo tanto, ilimitada.
 Las reglas del BRE pueden procesar datos jerárquicos heredados complejos. Cualquier
elemento que pueda existir en un entorno heredado (EBCDIC, decimales empaquetados,
formatos internacionales, XML, Copybooks de Cobol, etc.) puede procesarlo el BRE
nativamente junto con el Co>Operating System.
 Las mismas reglas del BRE se ejecutan de forma idéntica en todas las plataformas
compatibles con el Co>Operating System (Unix, Linux, Windows, z/OS y z/Linux).
 El BRE aprovecha las ventajas de todas las operaciones del Co>Operating System, como
el control de errores, los puntos de verificación, etc.

¿Qué son las “reglas de negocio”?

El BRE es compatible con tres estilos diferentes de reglas de negocio: reglas de decisión, reglas
de validación y reglas de asignación. Aunque sean similares en lo fundamental, los usuarios de
negocios están acostumbrados a clasificar las reglas en una de las categorías anteriores.

Según lo requiera la naturaleza del negocio, las reglas pueden ser sencillas y breves, o ser
complejas y muy largas. El BRE admite ambos extremos. Actualmente, los mayores conjuntos
de reglas del BRE en producción tienen más de 50 000 reglas.
A continuación se muestra un ejemplo de una regla de negocio de decisión muy sencilla que ha
sido especificada en el BRE y que corresponde al cálculo del importe a pagar en la declaración
del impuesto sobre la renta de los Estados Unidos (lo que se conoce como el formulario 1040):

Esta regla tiene dos entradas, Filing status y Taxable income line 43, y computa una salida
llamada Tax (line 44). En el BRE, hay un operador AND implícito entre las columnas y un
operador ELSE implícito entre las filas. Por tanto, las primeras filas de esta regla son:

IF Filing status es Single AND Taxable income line 43 es menor o igual que 100000, THEN Tax
(line 44) equivale a consultar el valor de Taxable income line 43 en Tax from Table y devolver el
monto para declarantes Single, o sea, solteros.

ELSE IF Filing status es Single AND Taxable income line 43 es mayor que 100000 y menor o
igual que 171550, THEN Tax (line 44) equivale al valor de Taxable income line 43 multiplicado
por 0.28 menos 6280.00.

ELSE IF Filing status es Single AND Taxable income line 43 es mayor que 171550 …

… ...y así sucesivamente. …

A continuación se muestra el ejemplo de una regla que valida varias entradas en la misma regla,
y que establece varias salidas en cada caso:
Y éste es un ejemplo de una regla de asignación de origen a destino. Para este estilo de regla, el
BRE visualiza a la izquierda una lista de los valores de entrada posibles (la columna “Inputs”)
como campos, variables, constantes y valores calculados. En el medio hay una lista de los
campos de destino (la columna “Output Name”). A la derecha de cada campo de destino hay una
columna (“Expression/Rule”) hasta donde el usuario puede arrastrar valores desde la columna
“Inputs” o crear una expresión para calcular esa salida. (Explicaremos más adelante en qué
consiste la columna “Computed Value”).

Las reglas del BRE® pueden incluir una lógica compleja arbitrariamente.

La lógica que subyace a las reglas del BRE puede ser sencilla, como sucede en los ejemplos
anteriores. Sin embargo, en el día a día de las empresas, los usuarios de negocios suelen
proponer reglas mucho más complejas. En aquellas tecnologías distintas a las de Ab Initio, esas
reglas no se pueden implementar en el producto que gestiona las reglas de negocio. Muy al
contrario, las reglas requieren que se escriba manualmente código de programación en lenguajes
de programación tales como C++ o Java. Esto puede afectar muy negativamente a la usabilidad y
la productividad, ya que se regresa al ciclo de “especificación-interpretación-codificación-
comprobación-solución” que suele propiciar el que los proyectos fracasen.

No es así con el BRE de Ab Initio. El BRE hereda en su totalidad la capacidad de procesamiento

de datos del Co>Operating System. Esto significa que los centenares de funciones del
Co>Operating System, así como estructuras de lógica complejas, están disponibles en el BRE.

Resultado de lo anterior, el tamaño o la complejidad de las expresiones dentro de las reglas son
ilimitados (como lo pueden ser el tamaño o la complejidad de las reglas, o el número de reglas
dentro de un conjunto de reglas).
La comprobación integrada permite a los usuarios de negocios verificar las
reglas por sí mismos.

Una ventaja clave del Business Rules Environment de Ab Initio es su capacidad de

comprobación integrada. Las reglas desarrolladas dentro del BRE se pueden ejecutar con datos
de muestra sin tener que abandonar el entorno de edición. Durante la comprobación, el BRE
notifica las salidas computadas para cada registro de comprobación, así como los estados de cada
variable y cada cálculo intermedios. Un usuario del BRE puede inspeccionar los registros de
salida y hacer luego clic en cualquier valor computado, para ver exactamente cómo y por qué fue
computado ese valor:

Para cada registro de comprobación, el BRE muestra en amarillo los casos que desencadenó y en
un color oscuro las celdas que se derivaron en una comparación fallida. El BRE también cuenta
el número de veces que se desencadenó cada regla determinada (“Times Fired” en la captura de
pantalla). Esta información se puede utilizar para buscar casos de pruebas que faltan o reglas
construidas de una forma no válida (si un caso nunca se desencadena).

Las comprobaciones se pueden ejecutar en cualquier momento durante el desarrollo de las reglas,
lo que facilita un planteamiento incremental en la creación de conjuntos grandes de reglas.
Además, no es necesario esperar hasta que se hayan introducido todas las reglas para empezar a
evaluar su comportamiento.

Las salidas de una ejecución de comprobación se pueden guardar para compararlas

automáticamente más adelante con ejecuciones posteriores (a fin de evaluar prestaciones). Y
cuando se cambian las reglas, ya sea durante el desarrollo o al diseñar las modificaciones, se
pueden ver todas las diferencias entre el comportamiento actual de las reglas modificadas y los
resultados de evaluación de prestaciones guardados. Esta operación tiene un valor incalculable a
la hora de evaluar el impacto de los cambios propuestos. Sin el BRE de Ab Initio, los usuarios de
negocios trabajan muchas veces “a ciegas” al cambiar las reglas.
Además, también están disponibles detalles de ejecución de las reglas a partir de los conjuntos de
reglas que se estén ejecutando en producción. Los usuarios pueden configurar la cantidad de
información de seguimiento que se guarda. El rango va desde sólo información acerca de qué
casos de reglas (filas) se desencadenan para cada registro de entrada, hasta todos los valores de
entrada, de consulta, intermedios y finales. La tecnología permite a los analistas estudiar el
comportamiento de las reglas a lo largo del tiempo, lo que a menudo sirve para ajustar la lógica
del negocio y mejorar los resultados. Estos detalles también pueden ser muy importantes para
responder a preguntas acerca de cómo se tomaron ciertas decisiones en el pasado.

Transparencia: Por fin la lógica de negocio queda expuesta

Los sistemas grandes y complejos de reglas de negocio llegan a constar de muchas reglas
implementadas encima de reglas anteriores. Comprender las relaciones entre ellas y el modo
como fluyen los datos a través de unas y otras, resulta clave. Pero desafortunadamente, lo más
común es que los usuarios de negocios rara vez vean cómo funcionan sus sistemas.

Cuando se utiliza el BRE sucede todo lo contrario. Gracias a su tecnología, los usuarios cuentan
con una visibilidad completa de los sistemas. Y esto es así porque el BRE visualiza diagramas
sobre cómo los datos fluyen a través de las reglas interconectadas (con independencia del tamaño
y de la complejidad de esas reglas). Además, el BRE permite visualizar el linaje gráfico de
aquellas aplicaciones que constan de muchos conjuntos de reglas, independientemente de que
éstas se distribuyan por una aplicación, o por varias aplicaciones.

La siguiente figura ilustra un ejemplo de linaje sencillo para el conjunto de reglas que ya se
mostró anteriormente; donde se calcula el impuesto sobre la renta con base en el formulario 1040
EZ (el formulario utilizado para presentar la declaración de impuestos en los EE. UU). Los
óvalos color verde representan las reglas (cálculos) y los rectángulos de esquinas redondeadas
representan las variables. En el modo de comprobación, los valores de muestra aparecen debajo
de cada nombre de variable, junto con todos los cálculos intermedios. Debajo del diagrama del
linaje completo hay una sección aumentada que muestra cómo el cálculo de la deducción (línea
5) influye sobre el reintegro o sobre el monto que se debe pagar.
La capacidad del BRE de hacer un seguimiento del linaje permite a los usuarios de negocios
comprender cabalmente cómo funcionan grandes conjuntos de reglas complejas.

Olvídese del “algoritmo RETE”

Habrá quien se pregunte qué es el algoritmo RETE. Gracias al BRE un usuario no necesita, en
realidad, saberlo. Pero por si al lector le gana la curiosidad, lo explicamos. En los productos de
reglas tradicionales, éstas se ejecutan en un orden determinado por un algoritmo de
reconocimiento de patrones llamado el “algoritmo RETE”. En ese esquema, una persona cuya
especialidad son los negocios y no la tecnología está obligada a comprender un concepto
bastante complejo del campo de la inteligencia artificial o las ciencias de la computación
(consulte http://es.wikipedia.org/wiki/Algoritmo_Rete para obtener información más detallada).

En la práctica, el planteamiento del RETE hace más difícil entender las consecuencias detrás de
un cambio en una regla, ya que es posible que dicho cambio influya en otras reglas muy lejanas
en las especificaciones. El rendimiento es, además, muy difícil de tunear, pues pequeños cambios
pueden tener consecuencias grandes e inesperadas.

En el BRE, las reglas se ejecutan en el orden en que fueron especificadas. El rendimiento no es

sólo sustancialmente más alto, sino que es también predecible. Para plantearlo de una manera
llana: no es necesario ser un ingeniero de sistemas para entender cómo funcionan las reglas.

¿Cómo interactúa el BRE con el Co>Operating System®?

Es sencillo. El BRE toma las reglas creadas por el usuario y las coloca en un componente de un
grafo ejecutado por el Co>Operating System. (Obtenga más información acerca de los
componentes, los grafos y el Co>Operating System).

Al ejecutarse en el Co>Operating System, las reglas de negocio heredan todas las ventajas y los
puntos fuertes del Co>Operating System. Las reglas pueden interactuar con cualquier origen o
destino de datos. Pueden procesar cualquier clase de datos. Pueden procesar cualquier volumen
de datos. Pueden ejecutarse por lotes y/o en tiempo real. Pueden ejecutarse distribuidas a través
de varios servidores que ejecutan sistemas operativos diferentes… Con el detalle, además, de que
todas estas acciones se realizan en una forma completamente robusta. El Co>Operating System
incluye todo lo necesario para armar y ejecutar aplicaciones de misión crítica robustas, y el BRE
hereda todas estas funciones.

A continuación se muestra un ejemplo de un grafo (aplicación) del Co>Operating System en el

que un
componente clave contiene reglas especificadas con el BRE:

Gestión y gobierno exhaustivos de las reglas

Todas las reglas se almacenan en el Enterprise Meta>Environment® (EME®) de Ab Initio, que

incluye funciones completas de gestión de código fuente, incluido el control de versiones. Los
usuarios del BRE pueden elegir entre dos metodologías de implementación:

 Tratar las reglas como otros elementos de las aplicaciones. Esto significa que los usuarios
deben recorrer todas las etapas estándar de promoción del código: desarrollo,
comprobación y, por último, promoción al entorno de producción. Aunque esta
metodología robusta es muy conocida entre los profesionales de los departamentos de
tecnología de la información, el número de pasos puede alargar demasiado la tarea. Sin
embargo, la comprobación integrada del BRE simplifica y acorta el proceso general.
  Tratar las reglas como si fueran datos de código de referencia de una base de datos
operacional. Los usuarios de negocios suelen poder introducir cambios (adiciones,
actualizaciones y eliminaciones) para hacer referencia a código sin ejecutar esos cambios
a través del proceso completo de promoción del código de aplicaciones, lo que les
permite responder con rapidez a las necesidades del negocio.

Ab Initio no privilegia un planteamiento sobre el otro. Simplemente, brinda a sus clientes la

opción para que elijan el que mejor se adapte a sus necesidades.

Por último, y por ser el EME compatible con el control de versiones, los usuarios pueden
configurar fácilmente su entorno para habilitar la implementación de reglas según el modelo
“champion/challenger” (I+D orientado a elevar la eficiencia). Lo que se persigue es poder
ejecutar dos versiones de las mismas reglas en paralelo para comparar y contrastar sus salidas. A
continuación, los usuarios establecen procesos para revisar estas diferencias y mejorar sus reglas
hasta obtener los resultados deseados.

Unificar la empresa con la tecnología unificada

Gracias a la comprobación integrada e interactiva y a la generación automática de módulos

ejecutables listos para producción, el BRE permite a los usuarios de negocios participar
directamente en el desarrollo de aplicaciones. De esta forma, sus conocimientos puede
combinarse con la experiencia del personal de tecnología de la información. Al presentar la
lógica de negocios de una forma que los responsables del área de negocios puedan expresar y
comprender con sencillez, el BRE reduce la incertidumbre y los riesgos que surgen durante el
desarrollo y la implementación de nuevas aplicaciones.

Las reglas del BRE y las aplicaciones controladas por ellas son ejecutadas por el Co>Operating
System. Eso significa que pueden ser arbitrariamente complejas sin que por ello dejen de poder
ejecutarse con suma eficacia y con una escalabilidad completa. Paralelamente, las mismas reglas
se pueden ejecutar en aplicaciones por lotes y en aplicaciones de servicios web (sin que haya que
cambiar para ello el código de programación). Cada prestación del Co>Operating System, de
hecho, se materializa a través del BRE. ¿Por qué?, se preguntará más de un lector. La respuesta
es simple: porque el BRE fue diseñado con la misma tecnología unificada que el Co>Operating
System. El BRE y el Co>Operating System trabajan juntos, y sin errores, para favorecer un
mejor entendimiento entre las distintas áreas dentro de la empresa.

Nunca conviene subestimar su importancia, ya que los problemas asociados con la calidad de
datos pueden tener un fuerte impacto sobre el balance de resultados de una compañía. Los datos
no válidos provocan muchas veces que el trabajo sea en vano y que se pierdan oportunidades.
Los problemas con la calidad de datos se acumulan conforme éstos circulan por una empresa, lo
que incrementa su impacto y alcance. En los peores casos, los datos deficientes pueden conducir
a los ejecutivos a inferir conclusiones incorrectas y a tomar malas decisiones empresariales. Pese
a la seriedad del asunto, la mayor parte de las compañías no disponen de programas de control
que midan y mitiguen los problemas derivados de la calidad de datos formales. Es más: la
mayoría de las organizaciones ni siquiera son conscientes de que muchas veces están lidiando
con un problema de calidad de datos.

La solución consiste en recurrir a un programa de calidad de datos (DQ) empresarial. Por su

naturaleza, un programa así va más allá de las prestaciones típicas incluidas en un único paquete
de software. La calidad de datos requiere un planteamiento de conjunto, con puntos de contacto
colocados a lo largo del negocio e implementados a través de un rango de tecnologías. La calidad
debe ser una pieza fundamental de la canalización del procesamiento de datos, sin que se limite a
un análisis retrospectivo sin conexión a la red. La calidad de datos no tiene que ver solamente
con la limpieza de los nombres y las direcciones de los clientes. También atañe a la coherencia y
la representación de toda la información de una empresa.

Para formar parte de la canalización del procesamiento, es preciso que las tecnologías utilizadas
en la calidad de datos ofrezcan robustez a nivel de producción. Tienen que ser capaces de
enfrentarse a datos heredados complejos, a transacciones en tiempo real y a volúmenes de
procesamiento elevados y continuos. Los planteamientos que no cumplen con estos requisitos
acaban siendo relegados a implementaciones sin conexión a la red, que raramente satisfacen las
expectativas. Esto suele suceder con herramientas de calidad de datos concebidas para propósitos
muy especializados y que sólo se pueden utilizar en un número reducido de circunstancias.

El planteamiento de Ab Initio es diferente, ya que propone un enfoque de extremo a extremo.

Como el Co>Operating System® es un entorno para el desarrollo y la ejecución de aplicaciones,
el planteamiento de Ab Initio® para la calidad de datos funciona en cualquier lugar en el que se
pueda implementar el Co>Operating System (en la práctica, casi en cualquier entorno
operacional o analítico). El Co>Operating System se distingue por varias cosas. A saber: procesa
nativamente datos heredados complejos; se ejecuta en conjuntos de servidores en ambientes
heterogéneos y distribuidos; ofrece un rendimiento elevado y es completamente escalable; y
puede, por último, implementar una lógica muy compleja. (Obtenga más información acerca del
Co>Operating System).

Nuestro planteamiento de extremo a extremo para la calidad de datos está basado en patrones de
diseño que utilizan las tecnologías perfectamente acopladas de Ab Initio (porque su arquitectura
fue diseñada conjuntamente), tales como el Co>Operating System, el Enterprise
Meta>Environment® (EME®), el Business Rules Environment™ (BRE®) y el Data>Profiler™. Al
utilizar Ab Initio, una compañía puede implementar un programa de calidad de datos completo
que incluye, al mismo tiempo, la detección, la resolución, la notificación y los avisos.

Visión general de la arquitectura

No existe un modelo que se adecue a todas las situaciones donde la calidad de datos es central
(mucho menos, cuando hablamos de organizaciones grandes que trabajan con muchos sistemas
heredados). Ab Initio proporciona una serie de bloques funcionales muy potentes que permiten a
los usuarios reunir soluciones personalizadas para cumplir necesidades específicas. Para los
usuarios que acaban de empezar a implementar un programa de calidad de datos, Ab Initio
suministra una implementación de referencia que puede servir como la base de un programa
completo. Para los usuarios que tengan necesidades diferentes, o que ya tengan funcionando
algunas piezas de un programa de calidad de datos, los bloques funcionales de la tecnología de
calidad de datos de Ab Initio se pueden conectar a la infraestructura preexistente según se desee.

Una implementación de calidad de datos típica comienza con la construcción de un componente

de procesamiento de DQ potente y reutilizable con el Co>Operating System, como se explica en
el ejemplo siguiente:

El Co>Operating System permite que los componentes contengan aplicaciones enteras. Este
componente de proceso de calidad de datos reutilizable es una aplicación en sí mismo, que
incluye:

 Un subsistema que detecta problemas de calidad de datos y que los corrige cuando sea
posible. El Co>Operating System constituye la base sobre la que se implementa la
detección de defectos. El BRE se puede utilizar para especificar reglas de validación en
una interfaz adecuada para los analistas. A su vez, el Data>Profiler se puede integrar en
el proceso para el análisis de tendencias y la detección detallada de problemas.
 Un sistema de notificación de calidad de datos. El EME incluye una notificación de la
calidad de datos que se integra con el resto de los metadatos, las métricas de calidad de
datos y recuentos de errores, y los resultados del perfilado de datos de una empresa. Los
usuarios pueden ampliar el esquema del EME para almacenar información extra acerca
de la calidad de datos y para aumentar las prestaciones básicas del EME con su propia
infraestructura de notificación.
 Una base de datos de notificación de problemas. Los registros que presentan problemas
con la calidad de datos se registran en una base de datos o en un archivo para que puedan
ser luego examinados como parte de un flujo de trabajo de la calidad de datos más
exhaustivo. Ab Initio proporciona la tecnología para almacenar, recuperar y ver esos
registros (aunque los usuarios son libres de seleccionar la tecnología de almacenamiento
de datos que mejor se adecue a sus necesidades).
Este componente de procesamiento de la calidad de datos se suele ejecutar como parte de las
aplicaciones preexistentes. Si una aplicación ha sido armada con Ab Initio, el componente de
calidad de datos se puede conectar con ella fácilmente. Para las aplicaciones que no fueron
armadas con Ab Initio, el componente de procesamiento de calidad de datos necesita ser
invocado en forma explícita. El componente de calidad de datos también se puede implementar
como un trabajo independiente que toma datos directamente desde sus orígenes. A continuación,
se muestran ejemplos de los dos modos de implementación, el autónomo y el integrado, en una
aplicación preexistente:

Flujo de trabajo del procesamiento de la calidad de datos

El diagrama siguiente ilustra un flujo de trabajo completo para la detección de la calidad de

datos. Es importante recordar que cada implementación de la calidad de datos se ajusta a las
necesidades específicas del usuario.
Como se indicó previamente, las entradas en este Proceso DQ A pueden ser datos de cualquier
tipo y origen. Puede ser un archivo plano, una tabla de base de datos, una cola de mensajes o una
transacción de un servicio web. También pueden ser las salidas de otro proceso implementado
con Ab Initio o con otra tecnología. Como el Proceso DQ se ejecuta sobre el Co>Operating
System, los datos pueden ser de cualquiera de los tipos que maneja el Co>Operating System:
datos heredados complejos, transacciones jerárquicas, datos internacionales, etc.

Las salidas del Proceso DQ B también pueden ser de cualquier tipo de datos dirigidas a cualquier
destino.

El primer paso consiste en aplicar las Reglas de validación 1 a los datos. Las reglas de validación
pueden ejecutarse en campos individuales, registros enteros o conjuntos de datos enteros. Como
cada registro puede tener uno o varios problemas, las reglas de validación pueden generar un
conjunto de problemas con la calidad de datos para cada registro E. La gravedad de estos
problemas y lo que se debe hacer para solucionarlos se decide más adelante en la cadena de
procesamiento.

A continuación, se aplican reglas de limpieza a los datos 2, y las salidas son el resultado del
Proceso DQ B. Los usuarios pueden utilizar las reglas de limpieza integradas de Ab Initio o
pueden armar sus propias reglas con el Co>Operating System. Aunque las reglas de validación y
las reglas de limpieza se introducen fácilmente con el BRE, la complejidad de esas reglas es
ilimitada, dado que pueden aprovechar toda la potencia del procesamiento de datos del
Co>Operating System.

A los registros que no se hayan podido limpiar se les da salida a través del Archivado de
problemas 4. Estos registros suelen pasar por un flujo de trabajo manual para solucionar sus
problemas.
La lista de problemas para cada registro E también se puede analizar 3 con vistas a generar
informes y alertas 5. Como este proceso se arma con el Co>Operating System, utilizando en la
tarea “grafos” estándar de Ab Initio, el usuario puede realizar prácticamente cualquier tipo de
notificación y de procesamiento. El planteamiento estándar de Ab Initio para la calidad de datos
incluye:

 calcular las métricas de calidad de datos, como integridad, precisión, coherencia y

estabilidad;
 determinar las distribuciones de frecuencia para campos individuales;
 generar conteos de agregados de códigos de error y de valores;
 comparar valores actuales para todos los anteriores con valores históricos;
 señalar desviaciones importantes en cualquiera de las mediciones actuales con respecto a
las pasadas.

Toda la información generada más arriba se almacena en el EME de Ab Initio para ser
monitoreada y consultada en el futuro. Toda la información de calidad de datos puede integrarse
con los metadatos restantes, incluidos los datos de referencia que también se hayan almacenado
en el EME.

Aunque toda la computación asociada a estos pasos puede consumir recursos considerables de
CPU, la capacidad del Co>Operating System de distribuir la carga de trabajo entre varias CPU (y
potencialmente entre varios servidores) permite que el procesamiento de la calidad de datos
forme siempre parte de la canalización de procesamiento.

Como se ha demostrado más arriba, el planteamiento de Ab Initio a la hora de medir la calidad

de datos incluye un conjunto rico de opciones personalizables y configurables para satisfacer las
necesidades de cada usuario. El procesamiento de datos, el cálculo de los resultados y los pasos
intermedios, se implementan utilizando el Co>Operating System de Ab Initio. Esto significa que
la detección de la calidad de datos puede ejecutarse prácticamente en cualquier plataforma (Unix,
Windows, Linux y mainframe z/OS). Y que puede ejecutarse, además, con cualquier tipo de
datos, con un rendimiento muy elevado. En aquellas situaciones en las que se procesen grandes
volúmenes de datos, la secuencia completa de detección de la calidad de datos puede ejecutarse
en paralelo, para minimizar la latencia.

Las secciones sucesivas muestran ejemplos de interfaces de usuario adecuadas para que los
analistas creen reglas de validación y notifiquen resultados acerca de la calidad de datos.

Reglas de validación

La mayoría de los problemas con la calidad se detectan aplicando reglas de validación al

conjunto de datos de origen. Con el patrón de diseño de la calidad de datos de Ab Initio, se
pueden definir reglas de validación, registro por registro, utilizando el Business Rules
Environment (BRE) de Ab Initio. El BRE ha sido diseñado para permitir al mismo tiempo que
usuarios sin una gran capacitación técnica, expertos en la materia y analistas empresariales, creen
y comprueben reglas de validación utilizando una interfaz parecida a una hoja de cálculo.
Hay dos formas de definir las reglas de validación cuando se usa el BRE. En la mayoría de los
casos, los usuarios definen reglas rellenando una hoja de cálculo sencilla (grilla de validación)
con los nombres de campo colocados en el lado izquierdo y las pruebas de validación a lo largo
de la parte superior:

Esta interfaz hace más fácil especificar qué pruebas de validación han de aplicarse a cada campo
o columna de un conjunto de datos. El BRE incluye un número de pruebas de validación
integradas (valores null, en blanco, rangos de valores, formatos de datos, pertenencia al dominio,
etc.). Pero también está la opción de que el personal de desarrollo defina pruebas de validación
personalizadas aplicables a campos individuales. Los desarrolladores escriben las pruebas de
validación personalizadas utilizando el Lenguaje de manipulación de datos (DML) de Ab Initio,
para hacerlas más tarde disponibles en el BRE.

Para las reglas de validación más complejas, el BRE permite definir “reglas tabulares”. Estas
reglas de validación complejas pueden procesar varios campos de entrada de un registro al objeto
de determinar si hay problemas con la calidad de datos. Cada regla puede generar un error y un
código de disposición, a través de los cuales se controla conjuntamente el proceso de corrección.
El BRE hace posible que los expertos diseñen, introduzcan y comprueben reglas de validación
utilizando la misma interfaz del usuario. La función de comprobación del BRE permite a los
usuarios ver en forma interactiva qué reglas se disparan para varias entradas. Con ello resulta
más fácil garantizar que las reglas se están comportando de la forma esperada.

La captura de pantalla siguiente muestra reglas de validación durante la comprobación. El BRE

visualiza conteos de desencadenadores para cada prueba de validación, así como información
detallada para cada registro de prueba.

Las reglas de validación se guardan en el EME, el cual suministra un control de versiones, un

control de acceso y una administración de la configuración. Para aquellas aplicaciones
completamente armadas con Ab Initio, incluido el proceso de calidad de datos, la aplicación y las
reglas de calidad de datos se etiquetan. Seguidamente, y de forma conjunta, las reglas son
promovidas a producción y asignadas con números de versión. Todo lo anterior garantiza un
proceso de calidad de datos robusto.

A pesar de que el BRE facilita que usuarios sin mayor capacitación técnica definan reglas de
validación, no es ésta la única forma de hacerlo. La potencia de la tecnología de transformación
del Co>Operating System está disponible también para implementar reglas más complejas.
Como el BRE y las reglas de transformación se ejecutan sobre el Co>Operating System, es
posible crear una estrategia de medición de la calidad de datos muy exhaustiva.

Notificación

La detección es la primera parte dentro de una implementación de calidad de datos completa. Y

la notificación la segunda.

La notificación de la calidad de datos se lleva a cabo mediante el Enterprise Meta>Environment

(EME). El EME de Ab Initio es un sistema de metadatos para aplicaciones que funciona a una
escala empresarial. Un sistema cuya arquitectura ha sido diseñada para gestionar las necesidades
de metadatos de los analistas de negocios, los desarrolladores y el personal de operaciones, entre
otros. El EME procesa muchos tipos de metadatos (entre los que se incluyen las estadísticas de
calidad de datos). Y los procesa, además, desde varias tecnologías y de acuerdo a tres categorías:
negocios, técnicos y operaciones.

Ab Initio almacena las estadísticas de calidad de datos en el EME con fines de notificación. Un
tipo de información de calidad de datos almacenada en el EME son los conteos de agregados de
códigos de error (problemas) de campos y conjuntos de datos individuales. Los conteos están
vinculados al conjunto de datos que está siendo medido y a aquellos campos que presentan
problemas. Los problemas se agregan y se notifican mediante un código de error, que se
encuentra en un conjunto global de códigos de referencia, almacenados en el EME (el EME es
compatible con la gestión de códigos de referencia).

La captura de pantalla siguiente muestra la capacidad del EME de visualizar problemas a nivel
de campo junto con grafos de tendencias históricas. Los conteos que sobrepasan los umbrales
configurables están resaltados en amarillo o rojo.

Como se muestra a continuación, Ab Initio puede calcular las métricas de calidad de datos para
conjuntos de datos y para campos (columnas). Estas métricas también se almacenan en el EME.
Existe un informe tabular correspondiente para ellas, que incluye grafos de tendencias y
umbrales en amarillo o en rojo.
Cuando las mediciones de la calidad de datos se registran en un entorno de gran envergadura, la
información cabe agregarla según la estructura organizativa del usuario. Esto facilita luego a los
gerentes la evaluación, en un solo informe, de las métricas de la calidad de datos para sistemas
enteros, aplicaciones y/o áreas temáticas. A partir de este informe, es posible examinar las áreas
problemáticas con detalle.

La captura de pantalla siguiente muestra varias áreas temáticas de alto nivel y sus métricas de
calidad de datos agregadas:

Notificación: Linaje

Muchos usuarios inician un programa de calidad de datos implementando la detección de la

calidad de datos de varios conjuntos de datos en un sistema único. Por ejemplo, no es tan raro ver
la calidad de datos medida para todas las tablas única y exclusivamente en un almacén de datos
empresariales. Aunque medir la calidad de datos en un sistema es mejor que no hacerlo de
ninguna otra forma, un programa de calidad de datos es más útil cuando incluye verificaciones
en varias etapas a lo largo de toda la canalización del procesamiento de una empresa. Para
ilustrarlo con un caso: la calidad de datos se podría medir en el almacén de datos empresariales,
pero también en el sistema del registro. Y se podría medir también en puntos de procesamiento
intermedios y, más adelante, en la cadena de procesamiento en los data marts o en los sistemas
de extracción. (Cada uno de estos sistemas puede capturar métricas de calidad tanto si se
armaron con Ab Initio como si no).

Cuando se realizan mediciones en varios puntos de una empresa, el EME multiplica el valor de
un programa de calidad de datos. Esto es así porque el EME puede combinar el linaje de los
datos y las métricas de calidad de datos para ayudar a identificar los sistemas en los que se están
introduciendo los problemas con la calidad de datos. Y con una localización exacta de los
problemas.

Consideremos la siguiente captura de pantalla:

Esta captura de pantalla muestra un diagrama de linaje de los datos expandido en el EME. Cada
recuadro gris grande representa un sistema diferente. Los recuadros verdes, rojos y grises más
pequeños representan conjuntos de datos y aplicaciones.

Es posible que las métricas de calidad de datos marquen elementos individuales. El color verde
es una buena señal. El rojo indica que hay un problema con la calidad de datos. Con estos
diagramas, es fácil seguir la trayectoria de los problemas con la calidad de datos, desde su origen
hasta su destino. Por primera vez, se permite a los gerentes ver cómo los datos y los problemas
fluyen por el entorno.

Por último, la notificación de la calidad de datos no queda limitada a las pantallas del EME
integradas. La información del EME está almacenada en una base de datos relacional comercial,
y Ab Initio proporciona documentación acerca del esquema. Los usuarios son libres de utilizar
sus herramientas de notificación de inteligencia empresarial favoritas para desarrollar vistas
personalizadas del programa de calidad de datos de su empresa.
Notificación: Data>Profiler™

Los resultados del Data>Profiler de Ab Initio también pueden utilizarse como parte de un flujo
de trabajo de calidad de datos. Como sucede con las mediciones de calidad de datos restantes,
estos resultados se almacenan en el EME y se ven en el portal web del EME.

Muchas organizaciones consideran el perfilado de datos como una actividad reservada para el
descubrimiento de los datos al inicio de un proyecto. Pero lo cierto es que un perfilado
automatizado y periódico puede añadir un valor considerable a un programa de calidad de datos
completo. Mientras que las métricas de calidad de datos capturan el buen estado en general de
los datos y sus características, las estadísticas del Data>Profiler permiten llevar a cabo un
examen más riguroso del contenido de varios conjuntos de datos.

A continuación se muestra una captura de pantalla del informe de nivel superior de una ejecución
del Data>Profiler sobre un conjunto de datos determinado. El Data>Profiler revela la diversidad
(qué tan distintos son los valores), la validez y la integridad, además de otros tipos de
información. Esta información puede utilizarse para seleccionar aquellos campos que requieren
un examen más exhaustivo.

La captura de pantalla siguiente muestra un campo que el usuario ha elegido para analizar en
mayor profundidad.
Desde ella, se examina el campo hasta obtener una presentación de los registros que contienen
valores específicos.

Conclusión

Aunque todas las compañías afrontan problemas con la calidad de datos, no existe un
planteamiento único para detectarlos, notificarlos y estudiarlos. Y menos aún existe uno que se
ajuste por igual a las necesidades de todas las empresas.

Los patrones de diseño de calidad de datos de extremo a extremo de Ab Initio pueden utilizarse
sin que haya que personalizarlos (o llegado el caso, basta con personalizarlos ligeramente). Para
los usuarios con necesidades específicas concernientes a la calidad de datos, como tipos
adicionales de detección, notificación o gestión de problemas, Ab Initio suministra un enfoque
flexible. Un enfoque de uso general basado en poderosos bloques funcionales preexistentes.

El planteamiento de Ab Initio para la calidad de datos se basa en el Co>Operating System. El

Co>Operating System suministra un entorno de computación de alto rendimiento compatible, en
la práctica, con todas las plataformas. El cual realiza, indistintamente, funciones de detección de
la calidad de datos, corrección, perfilado de datos y agregación de estadísticas para cualquier tipo
de datos. Y como el Co>Operating System suministra una escalabilidad ilimitada, su tecnología
puede realizar todas estas tareas con grandes volúmenes de datos.

El Business Rules Environment de Ab Initio permite desarrollar y comprobar reglas de

validación a través de una interfaz gráfica de fácil uso tanto para analistas como para expertos en
la materia. El resultado es una mejora significativa del rendimiento y de la agilidad con la que se
pueden crear y mantener reglas de calidad de datos.

Por su parte, el Enterprise Meta>Environment de Ab Initio suministra un nivel sin precedentes

de integración de las estadísticas de calidad de datos con otros metadatos, como el linaje de
datos, los diccionarios de datos, los conjuntos de código de dominio, las estadísticas
operacionales, el gobierno de datos (“data stewardship”) y otros metadatos técnicos,
operacionales y de negocio.

En resumidas cuentas, la combinación única de estas funciones dentro de un software integrado

convierte a las funciones de calidad de datos de Ab Initio en una tecnología sin parangón en el
mercado.

Conforme se incrementa el número y la complejidad de las aplicaciones de tecnología de la

información implicadas en un negocio, aumenta también la importancia de la gestión de
operaciones. Y con ello, crecen todavía más las expectativas empresariales para que los
resultados sean confiables y regulares. Pero como cualquier gerente de operaciones sabe, obtener
puntualmente unos resultados confiables representa un desafío difícil de abordar cuando hay
miles y miles de piezas que se mueven entre varias aplicaciones interdependientes (las cuales
pueden abarcar, por otro lado, varios servidores y ubicaciones geográficas).

Para tener éxito, el equipo de operaciones necesita:

 Comprender, articular y cumplir con todas las dependencias clave dentro de una
aplicación y entre varias aplicaciones. Por poner un ejemplo: el equipo necesita poder
decir que B sólo se ejecutará cuando finalice A, y que C se debe ejecutar cuando falle A.
 Administrar aquellas acciones que puedan desencadenar una parte del proceso. Un
desencadenador podría ser una hora específica en un día determinado, la llegada de uno o
varios archivos, la disponibilidad de uno o varios recursos, o –tal vez– una combinación
de las anteriores opciones.
 Monitorear de manera proactiva todas las dependencias para que se produzcan alertas
automáticas y para que éstas sean enviadas a las personas adecuadas. Las alertas se deben
desencadenar si no se satisface una dependencia o un evento dentro de los plazos
 establecidos, lo que permite informar y realizar un seguimiento de los acuerdos de nivel
de servicio (ANS o SLA) de negocios.
 Monitorear las características de procesamiento de nivel bajo de las piezas clave de una
aplicación, como el número de registros rechazados, la latencia de los mensajes que están
siendo procesados o el tiempo de CPU utilizado en la lógica de procesamiento. Una vez
más, las alertas se deben producir cuando se sobrepasen los umbrales.
 Desarrollar y comprobar el proceso operacional de extremo a extremo en un entorno de
comprobación especializado antes de promover formalmente el proceso al entorno de
producción.
 Registrar y analizar con detalle estadísticas operacionales, como las horas de inicio y fin
para cada pieza de una aplicación a lo largo del tiempo (de manera que se puedan
identificar tendencias de procesamiento para apoyar las actividades de planificación de
capacidad).

Conduct>It de Ab Initio suministra todas estas funciones y muchas más.

Conduct>It® es una aplicación de automatización de procesos que proporciona un entorno de

monitoreo y de ejecución para implementar aplicaciones complejas en entornos complejos. Su
tecnología facilita la definición de pasos de trabajos jerárquicos y arbitrarios para aplicaciones de
gran envergadura y en múltiples etapas, así como las dependencias, las secuencias y la
programación de estos pasos de trabajos. Las aplicaciones pueden estar compuestas por
definiciones de grafos y trabajos de Ab Initio®, así como por ejecutables personalizados y por
productos de terceros, todos los cuales son administrados por Conduct>It.

Conduct>It tiene dos elementos principales. El primero es un servidor de automatización de

procesos, llamado la Operational Console, que proporciona funciones de monitoreo y control de
trabajos en entornos de procesamiento complejos. En segundo lugar, allí donde se requiere una
lógica de administración de procesos más sofisticada, Conduct>It ofrece la capacidad de
desarrollar gráficamente y ejecutar una lógica compleja de flujos de control.

Examinemos la Operational Console.

Control>Center® Operational Console

La Control>Center Operational Console proporciona una amplia gama de funciones esenciales

para algunas operaciones diarias como la programación, el monitoreo y las alertas de trabajos
(así como para algunas acciones a nivel de trabajo tales como iniciar, detener y repetir la
ejecución de tareas). A través de todas las aplicaciones, la Operational Console recopila, integra
y administra los metadatos operacionales asociados, lo que ayuda al equipo de operaciones y a
los analistas de negocios en la planificación y el mantenimiento de las operaciones.

Cualquier operación se inicia en la página Home, en la interfaz basada en un navegador de la

Operational Console, tal como se muestra a continuación. La página Home proporciona un
resumen de todos los trabajos del día ordenados por aplicación, sistema o servidor. Allí se indica
si se están ejecutando (verde), si han finalizado (azul), si son erróneos (rojo), o si están en espera
(amarillo). También se enumeran todos los problemas o las advertencias que han surgido y que
siguen pendientes de resolución.

Desde la página Home el usuario puede examinar en detalle diferentes tipos de información para
cualquier trabajo del entorno: la razón de un fallo, a qué está esperando un trabajo, cuándo se
completó un trabajo o cuándo se espera que finalice, etc. Es posible, por ejemplo, ver todos los
trabajos relacionados con una aplicación específica, para comprender así su progreso:

Esta captura de pantalla de monitoreo muestra las dependencias entre las diferentes tareas dentro
de la aplicación seleccionada y su progreso. En cualquiera de las etapas, el usuario puede
examinar a fondo los detalles de seguimiento de una de las tareas:
Como se ve más arriba, la información de seguimiento de bajo nivel acerca de los segundos de
CPU invertidos, así como los volúmenes de datos y de registros procesados, está disponible para
cada componente dentro de una ejecución específica de un trabajo de Ab Initio. De forma
alternativa, es posible que el usuario también quiera averiguar cuál ha sido el rendimiento de los
trabajos a lo largo del tiempo, junto con una línea de tendencias con fines de planificación:

La Operational Console recopila una amplia gama de estadísticas para cada tarea, desde la
capacidad de cumplir con los ANS enunciados hasta la cantidad de tiempo de CPU de usuario y
de sistema utilizado.
Conduct>It ofrece otras prestaciones. Utilizando toda la potencia del Lenguaje de manipulación
de datos (DML) de Ab Initio, el equipo de operaciones también puede definir sus propios
sondeos operacionales, llamados “métricas personalizadas”, a fin de establecer alertas y
garantizar el seguimiento oportuno. Se pueden añadir sondeos sin que haya que cambiar o
perjudicar una aplicación (y sin ningún impacto sobre su ejecución). Estas métricas se pueden
computar utilizando cualquier combinación de información de seguimiento para cualquier flujo o
componente dentro de un grafo. Así pues, es fácil añadir una métrica personalizada que notifica
y avisa sobre el número de registros procesados por un componente específico. O también, sobre
la cantidad de tiempo de CPU utilizado, o la latencia de los mensajes en tiempo real que están
siendo procesados.

Todas las funciones de monitoreo de la Operational Console están disponibles para trabajos de
Ab Initio, tanto si han sido iniciados por la Operational Console como si lo han sido por otro
programador que utilizó una tecnología distinta.

Para aquellos clientes que no tienen acceso a un programador en sus empresas, la Operational
Console también suministra funciones de programación completas basadas en “día/hora”, evento
y archivo (lo que permite programar completamente aplicaciones complejas sin que haya que
escribir y mantener los scripts tradicionales). En la captura de pantalla siguiente vemos la misma
aplicación que hemos examinado anteriormente, pero con todas las dependencias basadas en
tiempo y en evento mostradas junto a las tareas:
Dado que las dependencias entre tareas se pueden volver extremadamente complejas en las
aplicaciones de gran envergadura, Conduct>It también provee un entorno gráfico que ayuda a los
desarrolladores a definir un flujo de control de trabajos avanzado.

Un flujo de control es una forma de expresar lógica detallada acerca de la secuencia de

ejecución. Utiliza una colección de tareas conectadas, llamada un plan, para describir lo que se
debe ejecutar (la conexión entre estas tareas especifica una dependencia de ejecución; por
ejemplo: “Ejecutar esta tarea antes de esa otra”):
El plan anterior muestra que la tarea 2 sólo puede ejecutarse una vez haya finalizado la tarea 1.
Muestra también cómo, posteriormente, se evalúa una condición (“Should the intra day process
run?”). Cuando la respuesta es negativa, la posición al final del día para cada oficina se calcula
entonces ejecutando repetidamente el “subplan” que aparece resaltado. Un subplan, como el
nombre indica, es una colección de tareas y de dependencias.

Las tareas personalizadas también se pueden desencadenar cuando fallan otras tareas (este caso
lo ilustra el plan anterior mediante la tarea “Error Actions”, que se ejecuta cuando la tarea 2 falla
por cualquier motivo). De manera similar, cada tarea puede tener “métodos” asociados que se
ejecutan cuando se producen ciertos eventos, como “At Start”, “At Success”, “At Shutdown”,
“At Failure” o “At Trigger”. Lo anterior permite que las funciones de notificación y de bitácoras
se añadan fácilmente al proceso de extremo a extremo.

Con los planes, Conduct>It proporciona un marco de tiempo de desarrollo para descomponer una
aplicación compleja en unidades de trabajo manejables que constituyen un sistema recuperable
único. Estos planes están disponibles a continuación para ser programados, monitoreados y
administrados utilizando la Operational Console. El resultado es un entorno operacional de
extremo a extremo muy complejo.