White Paper INTEGRABILIDAD

1

INTEGRABILIDAD

Ing. Gustavo Giorgetti

Integrabilidad una nueva métrica de la calidad funcional de las aplicaciones que debe tenerse

en cuenta al momento de priorizar los proyectos de desarrollo de las mismas.

Introducción:

Cuando:

• Cientos o miles de organismos públicos tienen sistemas y aplicaciones desarrolladas durante varios años sobre distintas tecnologías y plataformas…

• La velocidad del desarrollo de los grandes sistemas es ampliamente sobrepasada por los ciclos de avances tecnológicos, donde no hay forma de actualizarlas….

• Los nuevos proyectos de IT que se generan están limitados a las competencias del propio organismo que lo promueve…

• Los intentos para lograr interoperabilidad se frenan con desafíos y particularidades propias de cada caso y los casos son miles, con perspectiva a aumentar…

Se descarta por tecnológicamente obsoleto aquello que todavía es funcionalmente apto, en

vez de buscar la manera de aprovecharlo y ponerlo a disposición de los demás organismos.

Conociendo que en la actualidad:

• Los estándares de los grandes modelos de e-government descansan mucho más sobre las interconexiones que sobre las plataformas, sistemas de base, lenguajes utilizados o modelos de licenciamiento de software aplicados.

• En los foros informáticos se habla de Interoperabilidad, de Arquitectura Orientada a Servicios (SOA).

• Hay gran cantidad de proyectos para la automatización de las funciones de diversos Organismos.

El escenario es de alta complejidad y divergencia porque están en juego estructuras de poder e intereses comerciales que permanentemente dificultan y entorpecen la instrumentación de un modelo estable, auto-controlable y sustentable.

Es claro que lo que está faltando es:

• Poder clasificar los sistemas en función de una nueva métrica, la INTEGRABILIDAD, que no es otra cosa que la propia predisposición de un sistema para integrarse con otros de diferentes dueños, proveedores u organismos; y priorizar los proyectos de desarrollo también en función de esta métrica.

• No alcanza con trabajar en Interoperabilidad es necesario poder identificar los sistemas que están predispuestos a “trabajar en equipo”, el nuevo escenario así lo exige.

White Paper INTEGRABILIDAD

2

Definición de una nueva métrica

Para poder definir una nueva métrica de aplicación general se requiere determinar puntos de

comparación estables o invariantes que la hagan válida para el universo de aplicación y el

rango temporal de vigencia.

Determinación de los componentes claves del modelo:

En los años 70 Jean Dominique Warnier definió un modelo lógico de base de datos para

organizar los registros que genera una relación “cliente – proveedor” de una organización.

La relación cliente- proveedor sigue siendo la misma que en aquel momento y si bien el

planteo original estaba pensado en una empresa, un simple cambio en el nombre de los

actores (ciudadano / cliente y Estado / Empresa) lo permite aplicar a un modelo de relación

entre el Estado y el ciudadano.

Vamos a introducir una clasificación simbólica del tipo de Componentes que esquematizan el

modelo:

• Componentes Clase A: los que sirven para identificar a todos los actores del modelo.

• Componentes Clase B: los que identifican los productos o servicios que se transfieren

entre los actores y son el motivo de la relación. Son los objetos de intercambio.

• Componentes Clase C: los que identifican los pasos del trámite, serie de actividades o

transacciones que hacen posible que el intercambio entre los actores se concrete.

White Paper INTEGRABILIDAD

3

Este modelo tiene la suficiente generalidad como para poder representar cualquier relación

de un ciudadano con un organismo estatal.

Otro concepto que introdujo J.D.Warnier es que dada la existencia de múltiples casos del

modelo anterior, se terminan generando múltiples relaciones entre las bases de datos de

cliente y proveedores (cada elemento A, B..C del gráfico siguiente representa un nuevo caso de

una base de datos lógica cliente-proveedor).

J.D.Warnier planteó la necesidad de simplificar las múltiples relaciones bilaterales entre

clientes y proveedores que generan múltiples relaciones entre las distintas bases de datos, por

relaciones multilaterales que simplifican y hacen viable el modelo, introduciendo el concepto

de una entidad de vinculación, centralización y administración del flujo de información.

El comercio globalizado

Por otra parte, y sin evidencia registrada de haberse tenido en cuenta los trabajos que J.D.

Warnier de los ‘70, el mundo comercial en su proceso de globalización guiado en Europa por

la European Article Number (EAN) y por otra parte en Estados Unidos por la Uniform

Commercial Code (UCC), organizaciones que terminaron confluyendo y fusionándose en la

Global Standar conocida como (GS1), llegaron a las mismas conclusiones estructurales en el

modelo que se utiliza hoy en día para poder soportar todo el comercio global y su logística, o

sea las mismas clases de registro A, B, y C.

White Paper INTEGRABILIDAD

4

La organización GS1 materializa la implementación de los acuerdos multilaterales del modelo

de J.D.Warnier administrando los Componentes Clase A, ya que todos los actores deben estar

registrados unívocamente a nivel global con Componentes Clase A = GLN, Por otra parte todos

los productos deben estar definidos por un GTIN = Componentes Clase B, donde se reservan

rangos de códigos de identificación de productos que están subordinados a cada GLN y

finalmente los envíos logísticos o mensajes, Componentes Clase C = SSCC que identifica

unívocamente a cada paquete o palet de envió y cuya administración corre por entera cuenta

de los actores involucrados en la cadena de valor.

Buenas Prácticas de e-government

En Europa encontramos muchos países con complejas estructuras políticas conformadas por

regiones y comunidades no siempre jerárquicamente coincidentes. El desafío es mayor si

miramos a la propia Unión Europea que debe lograr integrarlos a todos en un “espacio

europeo común”.

Si analizamos los casos considerados modelo de referencia y de buenas prácticas de

infraestructura de e-government, podremos observar que muchos han desarrollado modelos

de integración que implementan el esquema de relaciones multilaterales, entre otros

podemos mencionar el Crossroads Bank de Bélgica o el X-Road de Estonia. El siguiente

análisis lo haremos sobre el modelo X-Road dada su simpleza conceptual lo que ayudará a

visualizar rápidamente los conceptos buscados sobre integrabilidad.

White Paper INTEGRABILIDAD

5

Amen de los detalles técnicos de la plataforma X-Road desarrollada en Estonia para integrar y

compartir datos de organismos públicos y el sector privado, podemos volver a identificar

claramente las zonas, módulos o sistemas encargados de soportar a cada uno de esa clase de

Componentes A, B y C.

En este caso podemos decir:

White Paper INTEGRABILIDAD

6

• El Componente Clase A que es administrado por un organismo independiente y que

utilizando parte de la información del organismo “registro de personas” más los propios

organismos y empresas registra todos los actores en forma única (directorio). Esto

permite la correcta autenticación en el sistema.

• Cada Componente Clase B tiene solo un organismo del estado responsable del proceso de

su creación y mantenimiento (fuente auténtica). Son los Componentes de los productos o

servicios que requieren los ciudadanos. Hay que comprender que estos Componentes son

lo que se obtienen al final de un proceso, el cual no estamos viendo en este nivel de

análisis.

• El Centro X-ROAD es el administrador del modelo multilateral de las relaciones, mantiene

los Componentes clase C. Contiene un esquema de macro procesos y autorizaciones más

los registros “log” de; Quien, Cuando y Que Componentes Clase B se usaron. Todos los

organismos se alinean; autenticando con Componentes clase A y consumiendo, según las

leyes, todos los Componentes clase B que necesitan para sus actividades.

Es importante remarcar que a diferencia de los Componentes clase C identificados por

J.D.Warnier que es a nivel detallado de todas los mensajes entre cliente y proveedor, los

Componentes clase C soportados por el modelo de Estonia son solamente los que generan

relaciones cliente-proveedor entre los sistemas de los mismos organismos del estado.

Entonces podemos decir que existen otros Componentes clase C de las relaciones entre los

usuarios y los procesos internos de los propios organismos.

También se observa el propio centro de administración del X-Road se encarga de materializar

un modelo de servicios con relaciones multilaterales, por supuesto este rol es independiente y

no puede ser ejecutado por ninguno de los otros organismos que operan en el modelo.

Pero el caso de Estonia va más lejos y resuelve el problema de la calidad de los datos y la

transparencia de la información al ciudadano.

White Paper INTEGRABILIDAD

7

CALIDAD DEL DATO

Otros de los problemas muy importantes que aquejan a los grandes sistemas de información

es el de la calidad de los datos. Aquí Ken Orr define y soluciona el problema con extrema

simpleza y claridad.

Las leyes de calidad de datos de Ken Orr dicen lo siguiente:

• Ley #1 - “Los datos que no son usados no están correctos!”

• Ley #2 - “La calidad de los datos depende más de su uso que de la forma de almacenarlos!”

• Ley #3 - “La calidad de los datos no será mejor que la de los distintos usos que tenga!”

• Ley #4 - “Los problemas de calidad de datos crecen con la edad de los sistemas!”

• Ley #5 - “Cuando existe menos probabilidad de ocurrir un error, más traumático es

cuando ello sucede!”

Leyes de cumplimiento obligatorio para dar calidad, ningún otro artilugio tecnológico ha

podido demostrar mayor eficacia y eficiencia.

Podríamos resumir las 5 leyes en una que dijera: Dato que no es usado por el que conoce su

valor no tiene calidad y por lo tanto es erróneo.

En el caso de Estonia el 80% de los ciudadanos ha revisado todos los datos (los Componentes

Clase B) que el estado tiene registrados sobre él en cada uno de los sistemas de los distintos

organismos (llamados fuentes auténticas). La calidad de los datos de Estonia es realmente

envidiable.

TRANSPARENCIA

La transparencia es otro aspecto clave en un modelo donde existen múltiples propietarios de

diferentes conjuntos de datos. En Estonia todos los ciudadanos pueden consultar los

Componentes Clase C en que se ven involucrados, pudiendo auditar así, Quién y Qué datos se

están usando de él.

El tema de la calidad de datos y el de transparencia requiere disponer de la capacidad para

poder integrar en un sólo front-end la información proveniente de múltiples sistemas.

A este tipo de Componentes de integración “virtual” los llamaremos Componentes Clase D.

White Paper INTEGRABILIDAD

8

Ken Orr nos ilustra en otras de sus claras y conceptuales presentaciones como ha sido también

la evolución de los sistemas y las condiciones de contexto que imperan en la actualidad.

Hace 100 años en el apogeo del desarrollo rural, era común el desarrollo autosuficiente donde

integradamente se atendían todas las necesidades, aquí el concepto es INTEGRADO,

AUTOSUFICIENTE pero al mismo tiempo aISLAdo. El la actualidad el desarrollo Urbano, es

totalmente dependiente de la infraestructura de servicios de todo tipo y por ello

necesariamente INTEGRABLE.

White Paper INTEGRABILIDAD

9

En el mundo material es posible integrar productos de distintos proveedores y conectar

cañerías de distintas tecnologías, viejas y nuevas para lograr que los servicios sean prestados.

Lo paradójico es que el en mundo virtual donde parece que todo es posible, aplicaciones de

distintos proveedores permanecen aun hoy en día aisladas y se insiste en que la única solución

es volver a desarrollar todo en nuevas soluciones mas integradas que no son otra cosa que

islas mas grandes. La otra paradoja es que si bien lo que esta dentro de su alcance lo integran

muy bien, lo que no cubren queda totalmente fuera de posibilidad de ser tratado e integrado.

Otro ejemplo de la falta de integrabilidad es que tanto las capas funcionales como las bases de

datos y las aplicaciones, sus workflows e interfaces web para el usuario, sólo están siendo

utilizadas dentro de cada uno de los propios productos o sistemas isla, pero poco se las aplica

para, realmente, dar integrabilidad a las aplicaciones entre sí, posibilitando un modelo de

integrabilidad en el que los productos se complementen verticalmente y compitan

horizontalmente.

Este modelo de integrabilidad le brinda al usuario un sistema como “un todo” además de otras

características como la flexibilidad y robustez tan necesaria cuando de “sistemas urbanos”

estamos hablando.

Este modelo de integrabilidad se puede presentar también a mayor detalle, logrando vincular

3 capas fundamentales como son los procesos, las aplicaciones y los datos.

En este nivel de integrabilidad un proceso puede combinar y reutilizar transacciones de

distintas aplicaciones las cuales son expuestas en las actividades del workflow mediante la

utilización de servicios web transaccionales. Es así que una actividad del proceso puede estar

involucrando varias transacciones soportadas por varias aplicaciones. Estas aplicaciones

estarían interactuando con una o varias bases de datos, locales o remotas.

El usuario opera un solo front-end, el que a su vez está interactuando con varias aplicaciones y

varias bases de datos.

White Paper INTEGRABILIDAD

10

Conclusiones:

– Los sistemas se deben alinear en lo que respecta a los Componente Clase A, los cuales

siempre estarán administrados en forma “centralizada” por una tercera parte o

entidad independiente que cumple exclusivamente este rol. El formato más utilizado

de soporte de estos Componentes Clase A es mediante Directorios LDAP (bases

jerárquicas, replicables, robustas de alta disponibilidad).

– Los sistemas deben exponer los productos y servicios que brindan mediante

Componentes Clase B (fuente auténtica) y consumir los Componentes Clase B de

otros para evitar duplicar todo lo que sea posible los datos que no produce. Aquí no

estamos analizando la calidad o eficiencia del proceso interno, sino su capacidad de

integración.

– Los sistemas deben dejar rastro de los mensajes de entrada y salida fuera de sus

límites para fines de control y auditoria de la operación. Estos Componentes (los de

Clase C) deben ser administrados por otras terceras partes.

– Los sistemas deben poder integrarse en un mismo fron-end (otro sistema) para poder

presentarse de manera clara y armónica ante los usuarios propietarios de la

información Componentes Clase B y C como mínimo para su control y validación.

Los roles del modelo:

Rol tipo A: Administra centralizadamente la Autenticación mediante los Componentes

Clase A.

Rol tipo B: Muchos Sistemas generan y consumen Componentes Clase B de fuente

autentica.

Rol tipo C: Autorización y Control de los acuerdos multilaterales entre los sistema

mediante Componentes Clase C.

Rol tipo D: Clientes que consumen y utilizan en forma integrada Registros Clase A, B y C.

Es fundamente comprender que cada actor de los cuatro tipos de roles es potencialmente un

dueño diferente o estructura de poder diferente, que tiene derechos y oblidaciones.

DEFINICIÓN de INTEGRABILIDAD de un sistema:

Funcionalmente: Capacidad para formar parte de una red de sistemas en la que cada uno es,

hacia los demás, proveedor de los datos que produce (sistema de fuente auténtica) y a su vez

es cliente de los demás por los datos que necesita y no produce. Todos los datos son

compartidos, según la ley con los demás sistemas integrantes de la red.

Técnicamente: Capacidad para formar parte de una red integrada por sistemas de diferentes

proveedores o dueños, que operan en diferentes plataformas y están desarrollados en

diferentes lenguajes, sin necesidad de cambios o adaptaciones.

White Paper INTEGRABILIDAD

11

Métrica para determinar el grado de integrabilidad de un sistema, la existencia de un nivel

superior implica el cumplimiento de todos los requisitos de los niveles anteriores:

Nivel 1: inicial – in/out de archivo en formato txt, grandes islas con primitivos puentes. – Acceso directo a las bases de datos sin control de integridad transaccional

Nivel 2: One Login – Componentes clase A

– El sistema se integra al modelo de Autenticación global. – Mapea sus códigos Registos Clase A internos con los de Directorio de

Autenticación. Nivel 3: WS (consulta) Producto – Componentes Clase B

– El sistema es Service Provider de consultas sobre cualquiera de los productos o servicios prestados por la aplicación.

– El sistema consume Componentes Clase B de las fuentes autenticas definidas, evitando la duplicación de datos no auténticos en las bases propias.

– El sistema mantiene sus propios mecanismos de autorización Nivel 4: Autorización Global - Componentes Clase C

– El sistema se integra a un modelo de Autenticación centralizada de relaciones multilaterales.

Nivel 5: WS (transaccional) – Componentes Clase D

– La aplicación ofrece WS que implementan transacciones completas para ser integradas en otro front-end conjuntamente con otros WS de otras aplicaciones.

– Para el usuario se presentan actividades dentro de un Workflow donde utiliza de manera transparente múltiples aplicaciones.