Capitulo 8

Arquitectura de Integración de Información 1

Capítulo 8.

Arquitectura de Integración de
Información.

8.1 Revisión ejecutiva.

Los enfoques y prácticas de la integración han
cambiado en la última década, pero lo que era viejo,
es nuevo otra vez. Las técnicas y tecnologías de
Integración relacionadas con la información no
estructurada en reportes y medios digitales y la
información estructurada en bases de datos, se
están convirtiendo en una parte importante del
panorama de integración otra vez. Esto es debido a
una variedad de factores, incluyendo el surgimiento
de XML como estándar de formato de datos, el
entendimiento de que no habrá un enfoque que
resuelva toda la integración requerida y el hecho de
que en el núcleo de todo proyecto de integración se
encuentra la necesidad de acceder, agregar,
propagar y publicar información. Finalmente, las
organizaciones se han dado cuenta que la
información es su negocio y necesitan tener más
control sobre su uso ante esta habilidad para
mejorar los negocios.

La información y los datos son en el centro de
cualquier proyecto de integración. A fin de cuentas,
la integración tiene diferentes tipos de intercambio
de datos, en diferentes formatos. El problema está
en el centro de todos los proyectos de integración y
es como permitir la interoperabilidad entre los
sistemas con diferentes estructuras y formatos de
datos. La Arquitectura de Integración de Información
defina la infraestructura y procesos para permitir que
la información se encuentre accesible a lo largo de
los sistemas.

La solución EAI a éste problema es representar los
Integración Empresarial


datos en un formato canon. El formato canon incrementa la reutilización y
disminuye los costos de implementación, tiempo y operación. Cada sistema
necesita ser programado una sola vez en el formato canon y luego puede
interactuar con otros sistemas en el mismo formato. Hay un sinnúmero de
beneficios de utilizar un formato canon y la mayoría de éstos se pierden si el
formato es propietario y no puede interactuar con las soluciones de otros
vendedores.
Esta es la razón por la que XML es tan importante hoy en día. La aceptación y
adopción universal de XML se ha debido a las necesidades de describir datos
en un formato común para reducir tiempos y costos de integración y el hecho
de que no hay otra alternativa realmente. XML es el mejor y el único.

Sin embargo, mientras XML provee estándares basados en un formato canon,
el valor real de los datos depende de mantener la integridad de éstos entre los
sistemas. Propagar la información incorrecta entre los múltiples sistemas en
una fracción de tiempo, llevaría a los sistemas no integrados a dar un mínimo
valor a la empresa. La solución para mantener el valor, significado e integración
de datos entre las aplicaciones son los metadatos. Los metadatos son la
información acerca de los datos. Mientras más descriptiva, precisa y completa
se encuentra ésta información, mejor será la integración. Mientras que existe
un acuerdo de metadatos en los sistemas, y hay un gran número de
herramientas en el mercado que pueden extraer los metadatos desde la fuente
de los sistemas, la calidad de los metadatos que puede producir la herramienta
depende en lo que está disponible en la fuente del sistema. Para alcanzar los
beneficios completos de los metadatos, las organizaciones deban asegurar que
todos éstos son precisos y completos. Esto también requerirá una inversión
significativa. Sin embargo, al final, la inversión pagará con incrementar la
calidad y reutilización de datos y disminuir los tiempos y costos de
implementación.

Los metadatos no son sólo buena idea de tener en la arquitectura empresarial,
sino que son absolutamente necesarios. No es solamente el cómo la
información acerca de los sistemas y dentro de éstos puede ser representada
independientemente de todos ellos, sino también permitir la interacción entre
los sistemas. Los buenos metadatos son la base del éxito a largo plazo de la
integración.

La Arquitectura de Integración de Información define los metadatos de la
compañía independientemente de las tecnologías o plataformas, de forma que
sean utilizables por todos los proyectos de integración.



Caso 8.1
El eXtensible Markup Language (XML)

8.2 Comprensión de los metadatos.

Los datos en los sistemas representan las entidades del negocio, como
Clientes, Empleados, Productos, etc., y proveen un registro persistente de los
eventos del negocio. Los metadatos, información que describe dichos datos,
permiten a la información ser examinada, reportada, consolidada, sincronizada
e integrada.

Sin embargo, como dice el dicho, “basura entra-basura sale”. Para que la
integración proporcione un valor al negocio, la información necesita ser precisa
y correctamente aplicada en las diferentes aplicaciones. El valor a largo plazo
que los datos darán a la empresa depende de asegurar la integridad de los
sistemas de información. Esto requiere la validación tanto semántica como
sintáctica. La validación semántica asegura que la información tenga sentido y


la validación sintáctica asegura que los datos tengan el formato correcto. La
integridad de los datos requiere de las dos.

Un estándar de modelo de metadatos incluye la información que permite la
validación sintáctica y permite la automatización de la traducción,
transformación y entrega de los datos a los sistemas deseados, en el formato
nativo. No obstante, esto no incluye los metadatos que definen el significado
semántico, incluyendo el contexto, relaciones y dependencias. Los diagramas
entidad-relación (E-R) son frecuentemente utilizados para éste propósito, sin
embargo son utilizados en la fase de descubrimiento y diseño. Las reglas de la
integridad reveladas por los diagramas E-R necesitan añadirse como código en
las aplicaciones o triggers y procedimientos almacenados en la base de datos.
El significado semántico no ha sido parte de los metadatos tradicionalmente y
ésta limitante ha tenido un número de implicaciones, especialmente cuando las
transacciones de metadatos cruzan aplicaciones. No se han especificado
reglas de integración a través de aplicaciones, lo que significa que para la
integración a nivel de transacciones, reglas adicionales de procedimientos
necesitan ser especificadas y codificadas. Esto hace significativamente más
lenta la implementación de las soluciones de comercio electrónico.

Debido a la gran importancia y valor de mantener y comunicar el significado
semántico de los datos en forma portable y reutilizable, hay un gran número de
esfuerzos en camino, para definir un modelo de metadatos semánticos.
Mientras muchos de estos esfuerzos siguen en las primeras etapas, es
importante saber que existen, aunque sea solamente para entender que los
metadatos creados para agregar dato por dato e integrar la aplicación es el
único comienzo de la Arquitectura de Integración de Información. Con el
tiempo, las organizaciones necesitarán crear arquitectura de metadatos más
completos y en capas para expresar completamente y proteger el significado y
valor de la información de los negocios.

8.3 Arquitectura de metadatos.

Existen diferentes tipos de metadatos para describir diferentes aspectos de los
sistemas. La mayoría de los desarrolladores de sistemas están familiarizados
con los metadatos que describen la información en el sistema. Estos tienen que
ser definidos en la misma aplicación. Pero en las soluciones de integración
empresarial, las transacciones generalmente atraviesan múltiples sistemas.
Sería más conveniente capturar los requerimientos de integridad en los
metadatos para que se encuentren disponibles para todos los sistemas, en
lugar de codificarlos en cada uno. Luego, cuando las reglas de las
transacciones distribuidas sean cambiadas. Solo se necesitan cambiar los
metadatos de la empresa, en vez de hacerlo en cada sistema. La agilidad del
negocio requiere diferentes tipos de metadatos que representen
completamente al significado de datos del negocio, transacciones e
interacciones entre los sistemas.


Una estructura que sirve para la comprensión de las diferentes posibles capas
de los metadatos es el Grupo de Administración de Objetos (Object
Management Group OMG) Arquitectura de Metadatos de Cuatro Capas. La
definición de Arquitectura de Metadatos es parte del OMG (Arquitectura por
Modelos (Model Driven Arquitecture MDA), para diseñar la estructura de
sistemas que se pueden correr en cualquier plataforma con su diseño nativo,
sin que sean re codificadas o recompiladas. Cada capa de la Arquitectura de
Metadatos provee un alto nivel de funcionalidad.

La primera capa, Capa 0, es la información existente y los valores de datos.
Nivel 1, es la capa de metadatos que tiene información comprimida que
describe a esos datos. El modelo de integración de datos soporta la adición de
datos desde sistemas de respaldo dispersos y define los atributos de los datos
para permitir la validación y limpieza automáticas. Los metadatos de cada
entidad de negocios son agregados al modelo de metadatos, que es acerca
del sistema y la información en el sistema. Los ejemplos de modelos de
metadatos del OMG incluyen el Modelo de Lenguaje Unificado (Unified
Modeling Language UML) y Lenguaje de Definición de interfaces (Interface
Definition Language IDL).

El Nivel 2, la capa de meta-modelo, es donde es añadido el significado
semántico. El meta-modelo es un lenguaje abstracto que define la estructura y
la semántica de los metadatos. Añadir la semántica al modelo significa que las
reglas de integridad y del negocio no necesitan ser codificadas en los triggers
propietarios y procedimientos almacenados, o en el código de las aplicaciones.
En el nivel de metadatos, las reglas del negocio y significado de los datos se
encuentran contenidos en los metadatos y están disponibles para todos los
sistemas. El OMG enlista los meta-modelos UML y IDL como ejemplos.

El Nivel 3 es el meta-metamodelo, un lenguaje abstracto para definir los
diferentes tipos de metadatos. Esto es equivalente al repositorio de metadatos.
El ejemplo de OMG es el Meta Object Facility (MOF). MOF define un lenguaje
abstracto y una estructura para especificar, construir y administrar los meta-
modelos neutrales de tecnología y una estructura para implementar
repositorios de datos.

Cada capa en la arquitectura de metadatos de OMG aumenta el nivel de
reutilización y eficiencia y hace de la integración sea una tarea más fácil.
Mientras que la estructura de metadatos del OMG es parte de la Especificación
del MOF, también sirve para la comprensión de los estándares de metadatos
que están siendo desarrollados por otro conjunto de estándares.

Conforme la arquitectura de metadatos se hace más completa, el costo, tiempo
y complejidad de integrar sistemas disminuye. Los metadatos son la clave de la
futura integración de la automatización y administración.



8.4 Estándares de Metadatos

Los estándares son extremadamente importantes para permitir la
interoperabilidad de los datos. Sin embargo, hay muchos de ellos y es difícil
entender como están relacionados entre ellos. Los diferentes estándares de
metadatos están siendo definidos por organizaciones, incluyendo: el World
Wide Web Consortium (W3C), abriendo el camino para XML y los estándares
relacionados con la Web; la Organización para el Avance de Estándares de
Estructura de la Información (Organization fro the Advancemente of Structured
Information Standards OASIS), corporación basada en estándares de comercio
electrónico; el Grupo de Administración de Objetos (Object Management Group
OMG), enfocada en diseño y desarrollo; y el Grupo de Aplicación Abierta (Open
Application Group OAG), creando modelos de metadatos enfocados en la
industria. Esta sección presenta una revisión de los estándares de los que cada
una de estas organizaciones es responsable y provee las pautas de como los
estándares pueden ser la parte más importante de la organización.

8.4.1. World Wide Web Consortium (W3C)

El W3C es responsable por un sinnúmero de estándares Web. Aquí nos
enfocamos en evolucionar los estándares de metadatos para la
Semántica. La Semántica Web asegura que la información Web tenga
sentido mediante la provisión de una representación de datos en la Web
que incluye el significado. La “Semántica Web es una extensión de la
actual Web en cuya información son dados los significados bien
definidos, permitiendo a las personas y computadoras trabajar mejor en
cooperación” (Berners-Lee, Hendler, and Lassila 2001). Parte de la
Semántica Web es la noción de una ontología. Una ontología define una
serie de términos comunes que describen y representan un dominio
particular- un tema específico o área de conocimiento como venta,
manufactura o medicina. Las ontologías incluyen definiciones usables
por la computadora de las entidades del negocio, relaciones y
propiedades o atributos. Estas capturan el valioso conocimiento del
negocio en un formato de reutilización y adaptación, y son los
parámetros para implementar la Semántica Web. Las ontologías
representan un Nivel 2 de metadatos, contienen tanto la estructura como
la semántica de los metadatos y son usualmente expresadas en un
lenguaje basado en lógica para proveer detalles, consistencia y
distinciones significativas entre las clases, propiedades y relaciones. Los
lenguajes que son especificados por el W·C son RDF y OWL. Las
compañías interesadas en el desarrollo y funcionalidad de la Web
avanzada querrán ver más de cerca a las ontologías y los estándares de
metadatos que están siendo propuestos por W3C.

8.4.2. The Organization for the Advancement of Structured
Information Standards (OASIS)



OASIS es una compañía no lucrativa, a través de la Web, enfocada en
los negocios electrónicos y “seguridad, servicios Web, conformidad de
XML, transacciones del negocio, publicaciones electrónicas, mapas de
temas, y la interoperabilidad entre y con los lugares de negocio”
(http://www.oasis-open.org). OASIS tiene más de 600 corporaciones y
miembros individuales en 100 países alrededor dl mundo, por esa razón,
ebXML es un estándar importante de metadatos en B2B. OASIS y las
Naciones Unidas conjuntamente patrocinan ebXML. Las compañías
involucradas en comercio electrónico global querrán poner atención a los
estándares de ebXML.

OASIS (The Organization for the Advancement of Structured Information
Standards) ebXML.

EL electronic Business Extensible Markup Language (ebXML) es una iniciativa
internacional para investigar e identificar las vases tecnicas en las que la
implementación de XML puede ser estandarizada. La meta es proveer un
parámetro técnico abierto, basado en XML para permitir que la utilización de
XML sea una forma consistente y uniforme para el intercambio de datos de
negocios electrónicos en ambientes aplicación-a-aplicación, aplicación-a-
humano, y humano-a-aplicación. La meta principal de ebXML es el crear un
solo mercado electrónico global.

Las especificaciones de ebXML incluyen un Acuerdo de Perfil de Socio
Colaborativo, una Especificación de Servicio de Mensajes, un Modelo de
Registro de la Información (RIM), y una Especificación de Registro de
Servicios. El RIM provee un Nivel 3 de metadatos para la implementación de
registros de ebXML. Le provee a los implementadores información del tipo de
metadatos que son archivados en registro, así como las relaciones entre los
metadatos de las clases.

8.4.3 Object Management Group (OMG)

La Arquitectura de Metadatos OMG descrita a continuación, forma parte
de la iniciativa de la Arquitectura dirigida a Modelos (Model Driven
Arquitecture MDA). La meta de MDA es permitir la completa
independencia de la tecnología desde el diseño de los sistemas hasta la
implementación. Una aplicación desarrollada utilizando MDA puede ser
desplegada en múltiples plataformas son cambiar el código. La OMG
también es responsable de los estándares UML, donde es
universalmente utilizada para el desarrollo de aplicaciones. Los dos
estándares de metadatos de OMG que hay que observar, son XMI, que
permite la portabilidad de los modelos de diseño de UML, y el Common



Warehouse MetaModel (CWM). Las compañías que han adoptado UML
como estándar de desarrollo estarán interesadas en XMI y CWM.

OMG (Object Management Group) XMI y CWM.

XMI define un formato de intercambio basado en XML para UML y modelos a
través de la estandarización de formatos de documentos XML y DTDs.
Mientras hace eso, también define un mapa de UML a XML. Esto es
importantepara permitir la protabilidad de los modelos de diseños así como el
intercambio de información entre modelos. Hay una especificación que
permitirá extender XMI para que soporte también esquemas de estándares
W3C además de los metamodelos MOF ya soportados.
El CWM estandariza un metamodelo que permite la extracción de datos entre
las bases de datos y forma el mapa MDA para los esquemas de base de datos.

8.4.4 Open Applications Group (OAG).

El OAG es un consorcio industrial no lucrativo basado en la promoción
de la interoperabilidad entre las aplicaciones de negocios, creando
estándares de lenguaje de negocios para soportar esta meta. De
acuerdo con el sitio Web (http://www.openapplications,org), es el más
grande publicador de contenido basado en XML para interoperabilidad
de software de negocios en el mundo. Ha publicado un sin número de
esquemas de negocios y el OAGIS, que contiene in lenguaje de
negocios canónico basado en estándares. El OAG será de gran
importancia para las compañías en la industrias relacionadas con la
implementación de transacciones B2B específicas a través del esquema
OAGIS.



Open Applications Group Integration Specification (OAGIS), y Business
Object Documents (BODS).

El enfoque de OAGIS es permitir las comunicaciones de la información
requerida para hacer negocios electrónicamente. Utilizando estándares de
servicios Web, provee una arquitectura canon de mensajes que las industrias
verticales pueden utilizar para insertar en si industria información específica,
terminología, contenido y restricciones. Una de las metas es el preservar la
terminología para cada una de las industrias verticales y guiar las inversiones
existentes a los estándares de la industria. Los BODs son mensajes definidos
horizontalmente comunes entre las industrias. Algunos ejemplos incluyen el
pedido de órdenes, facturación y embarque, por nombrar algunos. BODs
pueden extenderse a grupos verticales de la industria para proveer campos
adicionales, compuestos, componentes, nombres, restricciones y contexto.
En la Arquitectura de 4 capas de OMG, los BODs representan el Nivel 1 de
los metadatos. Sin embargo, hay un grupo de trabajo de Integración
Semántica en el OAG, buscando acentuar el significado y usabilidad de los
modelos de información.

La administración de metadatos se esta convirtiendo esencial para la
agilidad del negocio, permitiendo la rápida integración e interoperabilidad
de los sistemas. Las solucionas basadas en estándares ayudan a
maximizar la reutilización y disminuyen los costos de operación. Mientras
muchas compañías se empiezan a enfocar el las primeras 2 capas de la
arquitectura de metadatos, es importante entender la evolución de los
estándares en otras áreas. Estos esfuerzos eventualmente
transformarán la forma de construir e implementar aplicaciones,
permitiendo la rápida integración y automatización, La creación de
modelos de metadatos representa tanto una inversión considerable
como un valor corporativo añadido. Finalmente, los buenos metadatos
disminuyen el tiempo y costo de implementación. Aumentan la
reusabilidad y maximizan el ROI para las inversiones de integración.

8.5 Patrones de Integración de la Información.

Hay dos tipos de integración de la información: agregación y publicación. La
Agregación de la información es juntar toda la información de múltiples
recursos en un solo modelo de metadatos que provee una sola vista de los
datos entre los sistemas. Un buen ejemplo de la necesidad de agregación es la
creación de una aplicación de call-center que provea una vista unificada de las
relaciones con el consumidor en lugar de que los operadores utilicen una
caridad de sistemas e interfaces combinados con su propia inhabilidad de
agregar toda la información junta para realizar la misma tarea.



La Publicación de la información es empujar la información a múltiples sistemas
de respaldo. Hay múltiples modelos diferentes incluyendo publicación uno-a-
uno, publicación uno-a-muchos y publicación de múltiples pasos. La
publicación uno-a-uno es la más simple. Permitir a un usuario cambiar su
dirección en línea y actualizar un sistema con esta información es un ejemplo
común. La publicación uno-a-muchos requiere soporte de transacciones entre
los sistemas si hay dependencias que deben ser mantenidas. Sin embargo hay
instancias donde no hay dependencia y la falla de publicar con un nodo no
impacta el orden de los nodos. Por ejemplo, si un cliente tiene diferentes
relaciones con un negocio, como tener que checar cuentas y préstamos a
través de un banco, es razonable el asumir que cada sistema es actualizado
con la información de la dirección. Esto no necesariamente requiere la
integridad transaccional, no obstante si dinero es transferido de una cuenta de
cheques para pagar un préstamo, la integridad transaccional será requerida. El
modelo final es una publicación de múltiples pasos donde la información es
publicada a diferentes nodos en una serie de pasos. Cada paso ocurre solo
después de una conclusión exitosa del paso anterior. Por ejemplo, el actualizar
una dirección seguido de enviar una conformación escrita puede realizarse en
publicación de 2 pasos.

8.6 Tecnologías de la Integración Empresarial de Información

La integración empresarial de información (EII) es uno de los sectores con
mayor crecimiento en el mercado de la integración. Las tecnologías EII proveen
una consolidación de la información más rápida y fácil desde diferentes fuentes
en una sola interface, como si la información viniera de una sola base de datos.
EII crea una arquitectura de información federada y aliada.

Las soluciones de consumidores y autoservicio pueden ser mucho más
amigables desde una sola vista al consumidor, pacientes u otras entidades del
negocio. Los metadatos consolidados permiten suministros de información en
tiempo real a los paneles de instrumentos y herramientas analíticas. Esto
provee un almacén virtual de datos para reportes en tiempo real. EII permite a
toda la información de respaldo ser vista como si viniera de una base de datos
unificada. El acceso unificado a los datos en bases de datos dispersas,
simplifica muchas aplicaciones proveyendo integración fácil y barata para un
sinnúmero de soluciones de negocios.

EII se enfoca en los Niveles 0 y 1 de la Arquitectura de 4 capas de Metadatos
OMG. En este nivel, el significado semántico necesita ser representado y
preservado a través de reglas de integración. Las reglas de integración
necesitaran incluir relaciones entre las aplicaciones. EL Nivel 1 de metadatos
es apropiado para la integración dirigida a la información, pero es menos
apropiada para la integración dirigida a transacciones.

Las soluciones EII contienen típicamente un repositorio de metadatos- un
servicio de agregación de datos que puede jalar datos desde diferentes


sistemas de respaldo y agregarla de acuerdo al modelo común de metadatos,
enlistando datos dispersos como si vinieran de una misma fuente. Y más
capacidades de administración incluyendo el linaje de los datos y análisis de
impactos. El linaje de los datos provee la habilidad de rastrar los calores de
datos del recuso del sistema del que vienen. Esto es de mucha ayuda para
mantener la calidad de los datos entre los sistemas. El análisis de impactos
ayuda a determinar cómo los sistemas que van con la corriente son afectados
por ciertos cambios Es también de mucha ayuda para optimizar sistemas y
realizar su mantenimiento. El repositorio de metadatos y administración de EII
son importantes para todos los tipos de administración de datos integrados. Por
lo tanto, esperamos que EII se convierta en una parte importante de la
arquitectura integrada.

8.7 Especificación de la Arquitectura de Integración de Información.

8.7.1 Introducción.

Este documento es una guía para crear la especificación de la
arquitectura de la integración de información para soluciones de
negocios dirigidas a la información.

8.7.2 Alcances.

El alcance de la Especificación de la Arquitectura de Información puede
ser de la totalidad de la empresa o limitada a un solo proyecto de
integración. El documento debe definir la información requerida por el
negocio, metadatos importantes y resaltar la arquitectura de la
integración. El alcance debe describir la variedad de información cubierta
por el negocio, así como los sistemas y recursos de datos involucrados
en el proceso.

8.7.3 Participantes clave.

Esta sección identifica a todos los participantes clave e inversionistas
involucrados en la información que se está integrando, incluyendo los
administradores del negocio que controlan toda o parte de la
información, diseñadores de sistemas y arquitecturas y el equipo de
desarrollo, quienes ejecutaran la implementación. Cualquier otro
participante o inversionista debe ser identificado, incluyendo los roles.

8.7.4 Requerimientos de programación para el Diseño de Patrones
de Integración de Información.

Esta sección se utiliza para identificar y programar todos los
requerimientos del diseño de los patrones de integración de información
(ver Figura 8-1). Los dos patrones de diseño básicos son la agregación y
publicación de información. Para identificar los requerimientos de


información del negocio que necesiten ser definidos en esta parte de la
especificación, se debe comenzar con la Declaración de Propósitos y el
alcance de las responsabilidades definidas en la Especificación de
Estrategias e Iniciativas del Negocio. Luego se deben usar los patrones
de diseño para identificar el mejor enfoque a la implementación.

Ejemplos de requerimientos que se adecuan a la integración de
información incluyen la creación de paneles de administración, vistas
únicas de clientes u otros recursos del negocio, propagación de la
información para reducir la recaptura de la información a los sistemas,
almacén de datos virtuales, suministro de datos en tiempo real a las
herramientas analíticas o la automatización del uno de documentos de
Microsoft Office (u otras herramientas de escritorio). Estos tipos de
requerimientos se enfocan en la agregación en tiempo real de los
recursos donde la información es recolectada y combinada para
alimentar la creación de nuevos paquetes de información o la habilidad
de publicar un documento en diferentes recursos de información para
proveer una sola actualización a través de los recursos de datos.



8.7.5 Diagrama de flujo de datos

El diagrama de flujo de datos (Figura 8-2) traza el flujo de la información.
Usualmente el flujo de información es bosquejado en un solo sistema
entre los procesos y uno o más almacenes de datos, con sistemas
externos trazados fuera del círculo. En integración, estamos
primeramente interesados en el flujo de la información entre sistemas,
así que esencialmente todos los sistemas son externos. Por lo tanto,
tenemos que adaptarnos al tradicional diagrama de flujo de datos con el
propósito de identificar los sistemas que comparten un tipo de
información. Los sistemas externos (trazados con cuadros sombreados)
son los sistemas externos a la empresa.

El propósito de crear un diagrama de flujo, es determinar cuales
sistemas están involucrados en el flujo de datos para determinar
después las reglas de integridad entre los sistemas (lo cual es realizado
en el Modelo de Relaciones mostrado en la figura 8-4).

8.7.6 Modelo de Metadatos

Una administración efectiva de metadatos es crítica para la arquitectura
dirigida a información. Cada aplicación requerirá un modelo de
metadatos que combine el nuevo modelo para la aplicación con los
modelos existentes en cada recurso de datos utilizado. El modelo de



metadatos es utilizado para definir el acceso y reglas de transformación
y establece un linaje de datos que permite análisis de impactos.

El modelo puede ser utilizado también para una ventaja estratégica,
disminuyendo el costo de administración de operaciones y nuevas
implementaciones y ayuda a asegurar la calidad de los datos mediante
la administración de accedo a datos e integridad. También ayuda a
maximizar las inversiones en sistemas de conocimientos.

Los metadatos para los recursos de datos existentes, deben ser
capturados para cada elemento. El modelo mostrado en la figura 8-3
puede ser utilizado como punto de partida. Muchas de las herramientas
de integración empresarial de la información que se encuentran
actualmente en el mercado, incluyen repositorios de metadatos que
proveen sus propios modelos de metadatos. Adicionalmente, si se está
usando el enfoque basado en estándares o un modelo de ontología de
específico de la industria, también tendrá sus propios metadatos. La
figura 8-3 define los tipos de metadatos que se deben considerar como
parte de la arquitectura de integración de información total de la
empresa.



8.7.7 Modelo de Relaciones.

El Modelo de Relaciones define las reglas de integridad a través de los
objetos de datos y sistemas. Si se implemente un modelo de metadatos
en Nivel 1, las reglas de integridad necesitaran ser explícitamente
definidas en las lógica de enrutamiento o en los triggers de base de
datos y procedimientos. El Nivel 2 del modelo de metadatos contiene el
significado semántico en el modelo mismo.

El Modelo de Relaciones define las dependencias y reglas para la
eliminación por cascada, roll-backs y transacciones compensatorias;
define el linaje de datos; y permite el análisis de impactos. La Figura 8-4
describe el tipo de información requerida. Como se menciono



anteriormente, la evolución de estándares de metadatos describirá de
manera más completa estas relaciones.

8.7.8 Revisiones del Diseño de Información.

Las revisiones del diseño de la información son críticas para el completo
éxito y agilidad del sistema. Las revisiones del diseño deben incluir todos
los inversionistas y participantes descritos en la parte de participantes
clave de la sección 8.7.3. Todas las partes del modelo necesitan ser
revisadas u verificadas. Los participantes necesitan revisar las porciones
de la información de la que son responsables, incluyendo la definición de
todos los elementos, como son creados, actualizados, los formatos y los
mecanismos de acceso. Los usuarios del negocio necesitan proveer las
definiciones por la información requerida en la nueva aplicación. En
adición, será critico para los inversionistas el asegurar el trato de las
discrepancias, en las cuales el recurso de datos contiene el “estándar de
oro” de la organización cuando hay conflictos o replicas. Esto es
frecuentemente la tarea más difícil que el grupo enfrentara. El proceso
completo debe revisar oportunidades para mejorar la consistencia y
calidad de la información a lo largo de la organización.

Se deben usar las siguientes normas para una revisión de diseños
exitosa:

Asegurar que todos los participantes e inversionistas estén
presentes.



Explicar el proceso y las normas básicas antes de la revisión del
diseño.
Criticar el diseño, no a la persona.
Los diseñadores solo podrán hablar para clarificar el diseño y
proveer información de fondo. No deben “defender” el diseño.
Identificar a los “dueños” de la información.
Identificar a los sistemas de registro de información.
Definir un proceso para calidad de datos.

8.7.9 Conclusiones y Comentarios.

Esta sección debe proveer los comentarios finales sobre la información,
diseño y uso del sistema.

8.8 Mejores prácticas en el Diseño de la Información.

Conducir revisiones de diseño. Un modelo de metadatos representa la
definición agregada de los datos desde los diferentes sistemas en un
formato canon. La única manera de asegurar que la definición común es
correcta, es tener un modelo de verificado por los inversionistas y
participantes- aquellos que tengan conocimientos de cada uno de los
sistemas y los que necesiten utilizar e integrar datos.

Crear un repositorio de datos. Un repositorio de metadatos basado en
estándares, provee una plataforma para almacenar, acceder y
administrar metadatos y permite acceso a la información a lo largo de la
organización. Esta es la base de los datos dispersos de la empresa. El
repositorio puede crecer con el tiempo, en una base proyecto-a-
proyecto, sin embargo, necesita ser manejada activamente para
asegurar la integridad y calidad de datos y maximizar la reutilización.

Administrar el repositorio en el centro de competencia. Hay
diferentes tipos de integración y diferentes tipos de metadatos. Sin
embargo, el trabajo de la investigación, definición y verificación de los
intentos y significado de los datos en los sistemas, lo cual forma la base
de la integración, necesita ser administrados y conducidos. Esto
representa una inversión considerable y un valioso recurso de
reutilización en la organización. Mientras diferentes proyectos pueden
trabajar con diferentes datos o niveles de metadatos, el centro de
competencia puede rastrear y administrar como los datos son utilizados
a través de los proyectos, cómo los diferentes niveles de metadatos se
relacionan y cuales estándares son los más apropiados.

Añadir significado semántico a los metadatos. Mientras más
significado de metadatos contenga, menor trabajo tendrán que hacer los
programadores. Los metadatos ricos en semántica permiten



implementar transacciones electrónicas a través de los sistemas sin
necesidad de añadir aplicaciones o códigos de base de datos para
asegurar la integridad de los datos. Es la clave para permitir el comercio
electrónico más rápido y con menor costo que ha existido.
8.9 Siguientes pasos.
La información y datos están al centro de todos los proyectos de integración, La
definición de la información independientemente de la tecnología o las
herramientas es un mejor enfoque para la agilidad a largo plazo y la
reutilización. Esto permite que el trabajo hecho en un proyecto este disponible
para el siguiente. Las compañías interesadas en la agilidad del negocio a largo
plazo invertirán en todos los aspectos de la arquitectura de integración
empresarial, incluyendo la definición del proceso de integración de
arquitecturas (Capitulo 9). Las compañías enfocadas en urgentes necesidades
tácticas definirán solo lo que es absolutamente necesario y se moverán a la
implementación (Parte III). Ver figura 8-5.


Capitulo 8

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Similar a Capitulo 8

Similar a Capitulo 8 (20)

Más de guesta81561

Más de guesta81561 (6)

Capitulo 8