SIOEQ92009

Integración Dirigida a Procesos.

13.1 Revisión ejecutiva.

Los negocios se han enfocado en la mejora de procesos para mejorar la eficiencia operativa desde la era de la reingeniería de procesos (BPR). Sin embargo, BPR falló en muchas organizaciones porque los sistemas de soporte a la información no permitían cambios sin que se tenga que hacer un trabajo. La integración de procesos nació de la necesidad de permitir a los procesos de negocios ser rápidamente automatizados y ajustados. Además, se ha expandido para permitir a los procesos ser administrados y monitoreados en tiempo real, proveyendo un lazo de retroalimentación a los administradores de negocios. Los paneles de administración proveen vistas gráficas de los procesos de negocio críticos, eventos, indicadores claves de funcionamiento y son actualizados en tiempo real.

La integración de procesos es una herramienta poderosa para permitir a los administradores reaccionar rápidamente ante los eventos de negocio importantes, y ser proactivos cuando surgen oportunidades. No obstante, para obtener los beneficios de la integración de procesos, las compañías necesitan invertir en definición, mantenimiento y optimización de los procesos de negocio. Esto es todavía un gran salto para la mayoría de las compañías.

La integración por procesos es una aplicación que se encuentra en el top de las aplicaciones destacadas que realizan funciones de negocios. La capa de procesos define, monitorea y administra los procesos de negocio que expanden múltiples aplicaciones. La diferencia entre integración de procesos e integración de aplicaciones o de información, es que la integración es definida como un procesos en vez de mensaje entre aplicaciones o información. La integración de aplicaciones modulares y la integración de procesos son similares en varias formas. Sin embargo, hay tres diferencias clave entre la integración de procesos y la integración de módulos, y son que la integración por procesos está enfocada en la definición y creación de procesos de negocio en vez de código, es la meta de los analistas de procesos de negocio en vez de programadores y no presupone una arquitectura orientada a servicios.

La integración de procesos utiliza una variedad de tecnología en integración de aplicaciones e información, incluyendo adaptadores, agentes, etc. Para integrar entre las aplicaciones destacadas. Aunque la tecnología de integración de procesos puede ser utilizada para crear aplicaciones modulares, mediante la unión de servicios de negocio y componentes, las interfaces estandarizadas y los componentes y servicios de negocio no son un prerrequisito. Adem.as, los objetivos y desarrolladores de la integración de procesos y aplicaciones modulares son diferentes. Como se declaró en el Capítulo 12, las aplicaciones modulares son usualmente creadas por desarrolladores de aplicaciones y la meta es el rápido desarrollo de las aplicaciones mediante la reutilización. Los analistas del negocio, más frecuentemente definen las soluciones de integración de procesos y la meta es mejorar la eficiencia del negocio mediante la automatización de procesos y su gestión en tiempo real.

El segmento de mercado de integración de procesos esta predicho para crecer considerablemente en los próximos años. Este crecimiento será probablemente impulsado por las soluciones de integración o las plantillas de procesos que proveen un gran porcentaje de la solución. Las regulaciones de conformidad en finanzas y seguridad son adopciones dirigidas a soluciones basadas en integración de tecnología. La integración de procesos provee un excelente plataforma para estas soluciones porque las hace más fácil de personalizar. En el mejor de los casos, cualquier solución empaquetada satisfará del 75% al 85% de las necesidades. Una plantilla de integración de procesos puede reducir el tiempo y costo de personalizar soluciones, un vez que la tecnología pasa por la puerta de la industria o solución de conformidad, entonces puede ser utilizada en otros proyectos. El caso de estudio 13.1 muestra como el proceso de integración aceleró la integración de adquisiciones y permitió la flexibilidad de los procesos de negocio entre las divisiones (Gold-Berstein 2002).

La integración de procesos puede ayudar a las compañías a optimizar los procesos de negocio, reduce los costos de operación y mejora la agilidad del negocio. Este provee a los negocios y administradores operativos, las herramientas necesarias para mantenerse al tope del ambiente de los negocios en tiempo real, pero la tecnología no siempre garantiza el éxito. Para alcanzar una ventaja competitiva sostenida, las compañías necesitan comprometerse con la gestión de procesos y la mejora continua de estos.

Caso 13.1
Nextel International gana flexibilidad del negocio a través de Integración de Procesos.

Nextel International es el proveedor líder de servicios prefabricados de América Latina. La cuenta de suscriptores digitales de Nextel es del 30% del total de los suscriptores móviles en los países donde opera.
Hace unos años, Nextel adquirió siete compañías en seis países en Latinoamérica y filipinas, y necesito activar a los nuevos clientes de cada una de esas compañías lo más rápido posible. Esto requirió la integración de los sistemas de clientes y procesos de negocio de cada una de esas compañías, cada una con diferentes requerimientos de impuestos locales y procesos de negocio únicos.
La meta de Nextel era integrar los nuevos negocios, combinar las prácticas y ventajas, mientras se intentaba preservar la efectividad de los procesos de negocio, lo cual es un gran reto para cualquier compañía. Utilizando la solución BMP de Fuegos, Nextel pudo implementar procesos estandarizados a lo largo de la compañía, lo cual también podía ser ajustado a cada única y efectiva forma de trabajar de las divisiones. La integración de procesos de negocio permitió a Nextel activar las cuentas de los clientes 2400% más rápido de lo que hubiera podido de otra manera, mientras se automatizaban completamente los requerimientos de impuestos locales.
Una estrategia de integración de procesos es el enfoque arquitectónico más relevante cuando se necesita implementar un nuevo proceso de negocio que requiere integración entre diversas aplicaciones, donde los procesos cambian frecuentemente o donde los negocios quieren ganar mejor eficiencia y flexibilidad mediante la gestión de procesos.
Cuando se realiza correctamente, las organizaciones pueden obtener más valor al ver las mejores prácticas con los procesos existentes y dirigir estos conceptos “mejores en su clase” a las otras partes del negocio.

13.2 Escenarios de Integración de Procesos.

La tecnología de integración de procesos está bien adaptada a los siguientes requerimientos de negocio:

· Iniciativa de mejora de procesos. Se ha mostrado que las compañías que se enfocan en procesos y mejora continua han superado a sus competidores en su funcionamiento en un alto nivel (ver Capítulo 9). Estas compañías tienden a ser las líderes del mercado en sus industrias. Los procesos de mejora continua traen ventaja competitiva, peor requieren un alto nivel de compromiso e inversión.
· Procesos específicos de la industria. BPM provee una excelente tecnología para crear plantillas para implementar procesos de negocio específicos. Por ejemplo, un sistema de administración de riesgos financieros puede integrar información de múltiples sistemas para calcular el riesgo. Las soluciones de la industria proveen la mayoría de las soluciones y reducen los tiempos de implementación y el riesgo de fallo. La tecnología de integración de procesos hace más fácil el personalizar la solución.

· Soluciones modulares. Los vendedores de integración de procesos se han enfocado fuertemente en las soluciones modulares porque proveen un mercado cautivo. Las compañías de cuidado de la salud son requeridas por la ley para implementar transacciones electrónicas basadas en formatos del estándar HIPAA. Aunque las obligaciones usualmente representa costos, las organizaciones de cuidado de la salud están encontrando que están realmente alcanzando un ROI mediante las soluciones HIPAA Las transacciones electrónicas, combinadas con integración de programas de respaldo, disminuye los errores y costos de las transacciones.

Sarbanes-Oxley es otra solución de obligatoria que dirige las tecnologías de integración de procesos adoptadas. Requiere ejecutivos que certifiquen los procesos que generan las figuras financieras, como la forma en que son reconocidos los ingresos y mantiene ejecutivos personalmente responsables de firmar las declaraciones financieras y responsabilidad de crímenes de cualquier inconsistencia. La imagen de los ejecutivos de alto nivel siendo detenidos con esposas y yendo a la cárcel es un motivador poderoso para que los ejecutivos se interesen en las soluciones de tecnología que los protegerán. Las obligaciones también requieren limitar alguna variación de los procesos prescritos, para asegurar que el proceso ha sido seguido. La automatización de procesos e integración está bien adaptada proveyendo estas capacidades y la plataforma para soluciones obligatorias.

13.3 Elección de Tecnología para la Integración de Procesos.

La tecnología de integración de procesos incluye las herramientas de administración de los procesos de negocio (BPM) para automatizar y gestionar los procesos, administración del flujo de trabajo para los procesos manuales y herramientas de colaboración. Hay un buen tratado de convergencia en el mercado. Casi todos los vendedores de EAI incluyen el nivel de integración de procesos. Hay también un gran número de soluciones únicas de BPM que incluyen adaptadores para integración de respaldo o integran con otro agente de integración o transporte de servicios empresariales. Los vendedores de flujo de trabajo han entrado al mercado, así como los vendedores de Administración de Contenido Empresarial (ECM). Un par de vendedores de plataformas de reglas de desarrollo también se han reinventado como vendedores de BPM. De hecho, casi todos los vendedores con un procesador de procesos o reglas ha entrado al mercado. Los diferentes vendedores ofrecen soluciones optimizadas para diferentes tipos de procesos.

13.3.1 Modelado de Procesos de Negocio.

La tecnología de procesos de negocio típicamente incluye una herramienta de modelado para definir los procesos de negocio. Los estándares para el modelado y lenguaje de ejecución de los procesos están evolucionando (ver Capitulo 9), y la mayoría de las herramientas de modelado son propietarias. Sin embargo, muchos vendedores al menos están dando servicio a los estándares emergentes, especialmente BPEL. Este será importante para la portabilidad de modelos y permite a las compañías el dirigir su inversión en definir procesos de negocio y exportar los códigos de ejecución a diferentes herramientas. Como mínimo, si la herramienta puede importar y exportar BPEL, prevendrá el atasco de las tecnologías y asegurara viabilidad a largo plazo.

13.3.2 Procesadores de procesos y reglas.

Muchos vendedores de procesos están ofreciendo tanto como procesadores de procesos como de reglas. Los procesadores de procesos están diseñados para administrar el estado de los procesos, incluyendo procesos de larga duración, los cuales pueden tomar horas, días o incluso semanas. Por ejemplo, un cable o línea DSL puede ser instalada en días o semanas desde la orden inicial, y puede involucrar a subcontratistas terceros, como los instaladores. El sistema necesita rastrear el estado de cada tarea o subproceso en todo el conjunto de procesos punto-a-punto en un periodo de tiempo. Esto tiene implicaciones para administración de transacciones en procesos de larga duración. Una transacción enviada semanas atrás no tiene necesariamente que ser meramente eliminada. Puede requerir una serie de transacciones de compensación para deshacer la acción, como mandar una carta al cliente.

Se está convirtiendo más común para los vendedores, el ofrecer también un procesador de reglas para definir los parámetros que controlan los procesos. Las reglas son más fáciles de cambiar que el código sumergido en un lenguaje de ejecución de procesos o modelo de procesos. Además, las reglas pueden ser distribuidas y localizadas. Si el proceso expande entidades organizacionales, las partes del proceso son frecuentemente administradas por diferentes entidades, y cambiadas localmente. Por ejemplo, una regla puede decir que las órdenes de mas de $1,000 requieren aprobación administrativa. En tiempos muy ocupados, esta regla puede ser cambiada a $2,000. El proceso no necesita ser cambiado para nada, las reglas del proceso pueden estar localizadas por departamentos o geográficamente. La distribución y federación de reglas pone control en las manos de los administradores de la línea de negocio. Debido a la flexibilidad que proveen las reglas, se están convirtiendo más necesarias en la integración de procesos.

13.3.3 Soporte de Procesos Manuales.

Cuando se eligen tecnologías de procesos se debe determinar primero que tipo de procesos son predominantes en las organizaciones. Pro ejemplo, algunas herramientas de procesos fueron construidas primeramente para procesos automatizados, y tienen soporte limitado para procesos manuales. Si se está intentando reducir las ineficiencias en procesos manuales, se debe buscar una solución que ofrezca fuertes capacidades de flujo de trabajo, incluyendo balance de trabajo entre los roles de empleados y una interfaz para desplegar las asignaciones de trabajo individual. Es beneficial tener tanto el flujo de trabajo manual, como los procesos de negocio automatizados soportados por una sola herramienta de modelado, ya que reduce costos de capacitación y mantenimiento considerablemente. Pero los procesos que predominan involucran personas, especialmente un gran número de ellas, lo que requiere soluciones robustas y escalables.

13.3.4 Permitiendo la Mejora de Procesos de Negocio.

Si la implementación es parte de una iniciativa de mejora de procesos de negocio, se debe buscar un fuerte modelador y simulador de capacidades incluyendo el análisis balanceado de costo y tiempo de tareas y procesos. Las herramientas de simulación producen un análisis histórico basado en el funcionamiento de procesos pasados, junto con un análisis what if. El éxito también requiere un compromiso con la administración de procesos y el proceso de mejora continua. En este caso, la herramienta es solo tan buena como la gente la sepa utilizar.

13.3.5 Monitoreo de Actividad de Negocios (BAM).

Cuando se busca ganar visibilidad en tiempo real en los procesos de negocio, BAM es importante. El mercado BAM está todavía en sus primeras etapas y los vendedores de EAI, BPM, administración de software, únicamente de comienzo y administración de infraestructura están ofreciendo soluciones BAM.

Gartner, que acuñó el término, define diferentes etapas de BAM. La primera etapa es la informacional. El panel de administración provee visibilidad en tiempo real a los procesos de negocio y alertas de excepciones, cuando una persona necesita ir y decidir cómo responder a la alerta. Cuando la inteligencia del negocio es añadida, las alertas incluyen información analítica para ayudar a tomar decisiones mejor informadas y más rápidamente. El futuro de las BAM es tener una respuesta automática del sistema. Los investigadores de IBM están trabajando en computación autónoma con el objetivo de crear sistemas de computadores que se regulen a sí mismo, de la misma forma en que nuestro sistema nervioso funciona autónomamente en nuestro cuerpo. Muchas de las tecnologías BAM disponible actualmente está en el nivel de provisión de información en tiempo real en los paneles administrativos.

13.3.6 Soporte de Procesos Colaborativos.

El software colaborativo, también llamado groupware, ha existido desde mediados de los 80s. Sin embargo, ahora está comenzando a convertirse en parte de la infraestructura de integración. La integración de procesos colaborativos incluye servicios para permitir a los miembros de equipos dispersos comunicarse, coordinar y administrar procesos, así como colaborar en documentos, modelos y otros entregables de los proyectos. Las soluciones colaborativas están generalmente basadas en redes, y pueden integrarse con soluciones de administración de contenido empresarial o con herramientas de escritorio. Las herramientas colaborativas son también introducidas en la cadena de proveedores y ambientes de manufactura, donde las organizaciones necesitan colaborar y negociar en el diseño de un producto y otras situaciones.

13.3.7 Soporte de Múltiples Tipos de Procesos.

Las grandes organizaciones comúnmente tienen que soportar diferentes tipos de procesos. El problema es si la compañía debe elegir una solución de procesos que se adapte mejor en todas las aplicaciones, o desarrollar múltiples tecnologías y optimizar cada solución. Desafortunadamente, el segundo enfoque garantizara redundancia en las herramientas de modelado y procesadores de procesos, lo que finalmente impactara la línea final e incrementará el costo total de propiedad. A solución óptima es tener una arquitectura completa orientada a servicios y desarrollar los servicios de integración como vayan siendo necesarios. Los vendedores, sin embargo, tienen un vasto interés en sus propias plataformas, y una arquitectura completa orientada a servicios no es todavía una realidad. Las compañías pueden no tener otra alternativa que soportar diferentes plataformas de integración de procesos.

13.4 Especificación de la Implementación de Integración de Procesos.

13.4.1 Introducción.

Esta especificación provee a la implementación una guía para el desarrollo de una solución basada en la integración de procesos. Comúnmente, la especificación de diseño de procesos del Capítulo 9 formará las bases para la implementación.

La integración de procesos representa un estilo específico de integración. Administra la integración de procesos de negocio punto-a-punto, así como los procesos que se expanden a lo largo de las organizaciones. Es apropiado para las iniciativas de mejora de procesos de negocio, automatizar las interacciones entre las entidades organizacionales e implementar soluciones industriales y obligatorias.

Esta sección describe los específicos problemas técnicos que surgen en la implementación y provee un contexto para una implementación específica.

13.4.2 Alcances.

El alcance de una especificación de integración de procesos está limitada por los procesos de negocio que están siendo automatizados e integrados. Puede incluir los procesos de los departamentos o entre departamentos, divisiones, territorios, compañías y clientes o socios del negocio.

13.4.3 Participantes clave.

Esta sección identifica a todos los inversionistas en la implementación, incluyendo a los administradores de negocio que controlan todos o parte de los procesos, los diseñadores y arquitectos del sistema y el equipo de desarrollo que ejecutará la implementación. Debido a que puede haber mucho administradores responsables de partes del proceso, el proceso de mejora continua y la optimización de procesos serán difíciles de alcanzar sin un dueño del proceso o administrador, quien sea responsable de los procesos punto-a-punto. Cualquier otro participante o inversionista debe ser identificado, incluyendo sus roles.

13.4.4 Patrones y Servicios de la Integración de Procesos.

La integración de procesos esta en las primeras etapas de adopción, y los patrones pueden surgir con el tiempo. Esta sección incluye los siguientes patrones:

· Automatización de procesos.
· Monitoreo de Actividades del Negocio (BAM).
· Integración de procesos colaborativos.
Esta sección define los patrones particulares que están siendo utilizados y provee detalles de la configuración de componentes específicos de la implementación.

13.4.4.1 Automatización de Procesos.
La automatización de procesos requiere servicios de integración de las aplicaciones destacadas. La solución puede proveer servicios de integración como adaptadores, o puede integrarse en una solución EAI. Muchas herramientas BPM hacen las dos para proveer flexibilidad en la implementación. Los servicios incluidos e n la automatización de procesos incluyen el modelado de procesos, simulación de procesos, administración de procesos incluyendo soporte para procesos de larga duración, administración de reglas del negocio, soporte a transacciones incluyendo transacciones compensatorias, así como todas los servicios de integración de aplicaciones necesarios. Debido a que es importante la administración de procesos como valioso conocimiento y contenido empresarial, la figura 13-1 incluye un repositorio de procesos. Sin embargo, este puede ser parte de un repositorio existente o solución de administración de contenidos. Se debe notar que la BAM esta en el diagrama porque los paneles de procesos analíticos y administrativos generalmente forman parte de la solución de automatización de procesos. Un buen ejemplo de la integración de procesos es una revisión de procesos de empleados. Este tipo de procesos son difíciles de manejar y requieren integración a traces de una diversidad de fuentes de datos, involucrando a mucha gente, y es generalmente una labor intensiva. La integración de procesos de negocio puede ser comenzada en el momento indicado por las políticas y procedimientos corporativos. La información necesaria es recolectada de una variedad de fuentes y las plantillas e revisión son creadas y enviadas a los administradores apropiados.
Figura 13-1
La tabla de implementación de automatización de procesos (Figura 13-2) especifica la integración de servicios incluidos en la solución de automatización de procesos, junto con los detalles relevantes de la implementación. Se debe personalizar la siguiente tabla para su implementación.
Figura 13-2

13.4.4.2 Monitoreo de Actividades de Negocio (BAM).
Una BAM provee visibilidad en tiempo real a los procesos de negocio y puede ser parte de la solución de administración de procesos o puede ser una solución separada. Debido a que el mercado de BAM es joven y está evolucionando, las soluciones BAM actuales tienen diferentes enfoques y configuraciones. Por ejemplo, algunas soluciones se enfocan en información analítica, monitoreo de datos de los almacenes y envío de alertas cuando ciertos eventos ocurren o surgen condiciones. Algunas están más enfocadas en las herramientas para la construcción grafica de paneles administrativos. Otros están enfocados en el acceso rápido a la información. La futura dirección de las BAM incluye respuestas automatizadas y computación autónoma.
Los servicios básicos provistos por BAM incluyen un panel administrativo con los indicadores claves de funcionamiento más relevantes para roles particulares en la organización, y análisis en tiempo real para presentar en el panel, lo que incluye ya sea la provisión de capacidades de inteligencia del negocio, como monitoreo y agregación de eventos en el almacén de datos o la integración con otras soluciones de inteligencia del negocio. Las soluciones BAM pueden incluir capacidades de integración de información para extraer la información de fuentes de datos analíticas en tiempo real. El actual monitoreo de capacidades puede ser implementado con agentes de aplicaciones, logaritmos de eventos del proceso o puede ser parte de la solución BPM. Una solución BAM puede contener también modelado o desarrollo de capacidades para definir las soluciones BAM, cada una de las cuales es única. Un buen ejemplo del uso de BAM es la administración de todo el procesos de admisión de pacientes en un hospital a través de la descarga e incluso incluyendo el procesos de codificación y pagos. Los hospitales son un ambiente complicado, y al monitorear todos los aspectos del proceso, se pueden tomar acciones para lidiar con cargas de trabajo especialmente pesadas, lidiar con problemas en el proceso de codificación o administrar las cuentas recibidas y procesos de recolección.
La arquitectura de referencia de la Figura 13-3 muestra los servicios básicos que deben ser incluidos en la implementación de BAM con las tecnologías actuales. La arquitectura comúnmente evoluciona conforme el mercado madura.
Figura 13-3
La tabla de implementación (Figura 13-4) especifica todos los servicios de integración provistos por la solución BAM, junto con los detalles relevantes de la implementación. Se debe modificar la tabla para proyectar la implementación.
Figura 13-4

13.4.4.3 Integración de Procesos Colaborativos.
La integración de procesos colaborativos provee una plataforma para integración de trabajo de diferentes miembros del equipo en diferentes localizaciones. Permite a los miembros del equipo el administrar sus propios procesos, comunicarse, coordinarse y colaborar en documentos, modelos y otros entregables del proyecto.
El corazón de la solución colaborativa es el portal de colaboración que provee acceso a toda la información y servicios que soportan el proyecto. Esto incluye artefactos como entregables, notas de reuniones, discusiones, decisiones, etc. Un repositorio del proyecto es importante para administrar esos artefactos. EL repositorio puede ser parte de la plataforma de colaboración o puede integrarse con una solución de administración de contenidos.
El control de la versión con la entrada y salida de servicios son características cruciales para la colaboración. Algunas veces la entrada y salida es parte de la plataforma de colaboración.
Sin embargo, es posible para el portal de colaboraciçon el integrarse con un sistema de administración de contenido o un sistema de control de versión. El segundo es importante para desarrollo de software ya que el código es frecuentemente administrado por un sistema de control de versión. No hay un aquí o allá, un numero de diferentes configuraciones son posibles.
La administración de proyectos también debe ser provista por la plataforma, o puede integrarse con un sistema de gestión de proyectos, como Microsoft Project. EL flujo de trabajo es incluido como parte de la plataforma para administrar procesos colaborativos. La coordinación de procesos es provista por un calendario electrónico y programa de reuniones. Un servicio para facilitar el soporte de tratamiento de discusiones y negociaciones y decisiones de documentos es de gran ayuda también. Debido a que la comunicación de muchos proyectos es realizada por correo electrónico, lo que es particularmente difícil de administrar y alcanzar, la integración de correos electrónicos se está convirtiendo en algo importante. Las plataformas colaborativas deben incluir roles definidos en el nivel de artefactos. Por ejemplo, algunos documentos pueden requerir la entrada de todo el equipo y algunos solo necesitan ser leídos por la mayoría del equipo excepto algunos miembros.
Como es notado previamente, aunque las soluciones de groupware han estado desde mediados de los 80s, están comenzando a proveer mas capacidades de integración conforme evolucionan y se integran con otras soluciones empresariales. La colaboración se está también convirtiendo importante en otros patrones de integración, especialmente en integración B2B, donde los socios necesitan colaborar y negociar en los procesos de negocio, diseños de producto y otros esfuerzos conjuntos. Un buen ejemplo de integración colaborativa es cualquier diseño de procesos que involucra vendedores externos. La industria automotriz ha sido líder en aplicar esta tecnología. Las herramientas colaborativas proveen versiones de control de diseños y rastrea conversaciones, retroalimentación y decisiones.
Como la integración de procesos colaborativos se encuentra más firmemente entrelazada en las organizaciones, la arquitectura es comúnmente evolutiva. La Figura 13-5 es una referencia de la arquitectura basada en una colección de capacidades actualmente disponibles, pero ningún vendedor ofrece todas estas.
Figura 13-5
La tabla de implementación (figura 13-6) especifica todos los servicios de integración provistos en las soluciones de integración colaborativa, junto con los detalles de implementación relevantes. Se debe modificar la tabla para especificar la implementación.
Figura 13-6

13.4.5 Conclusiones y Comentarios.
Esta sección debe proveer cualquier comentario final acerca de la implementación.

13.5 Mejores Prácticas en la Integración de Procesos.

· Hacer un compromiso organizacional para el proceso de mejora continua. La optimización es una disciplina y un viaje, no solo un software de instalación. Aunque tiene el potencial de dar ventaja competitiva, requiere inversión significativa. Las organizaciones que crean una cultura de mejora continua obtendrán los más altos beneficios (pero esto requiere un alto nivel de compromiso).

· Medir el funcionamiento de los procesos. La medición es esencial para la mejora de procesos. El funcionamiento de los procesos puede ser medido en términos de tiempo y/o costo. También puede ser medido en términos de funcionamiento completo en la organización con métricas como rentabilidad, satisfacción del cliente o crecimiento en el mercado. Las herramientas de simulación son de extrema ayuda para calcular las estadísticas de funcionamiento de procesos actuales y hacer análisis what if.

· Premiar la mejora de procesos. No se puede esperar que el comportamiento de los empleados este ligado con la medición de funcionamiento. Para crear un cultura de proceso de mejora continua, se tiene que mejorar el proceso de premiación. De otra manera, habrá pocos incentivos para mantener el cambio continuo.

· Proveer paneles de administración en tiempo real. Poner a los administradores del negocio en el asiento del conductor con paneles personalizados que desplieguen los indicadores claves del funcionamiento y alertas en tiempo real. Proveer a los administradores del negocio con la información que necesitan para administrar proactivamente el negocio. Darles la habilidad de administrar fácilmente y cambiar los procesos y reglas del negocio por las que son responsables.

· Administrar procesos automáticos como componentes reutilizables. Los procesos automatizados pueden ser reutilizables como cualquier componente o interface puede ser reutilizado. Permitiendo a los procesos ser parte de nuevos flujos de trabajo, un negocio puede optimizar rápidamente sus operaciones conforme ocurren cambios o una vista interna es ganada a través del monitoreo de actividades.

13.6 Siguientes Pasos.

La naturaleza de la integración de procesos es que nunca es realizada. La primera implementación es solo un punto de partida que será ajustado y cambiado. El siguiente paso es asegurar que los cambios serán rastreados y administrados para que los procesos sean definidos y documentados.

Adicionalmente, la integración empresarial es un viaje continuo, La infraestructura de integración evolucionara con el tiempo y los componentes de integración de procesos son solo parte de la solución completa. Necesitan ser actualizados para mantenerse en paso con la arquitectura completa. El mapa de integración (Figura 13-7) y el ciclo de vida son los caminos de regreso para comenzar una y otra vez.

Cada nuevo proyecto debe tener sus propios requerimientos. Una implementación puede ser una combinación de diferentes estilos y patrones de integración. El uso de los patrones como guías provistas en este capítulo y en el libro es un punto de inicio. Las decisiones de tecnología disponible puede ser una restricción en la habilidad de implementar una óptima arquitectura. Es importante recordar que los patrones y tecnologías cambiaran y que el proceso de integración es una de las menos desarrolladas formas de integración. Para ver un ejemplo de la arquitectura de referencia de una integración empresarial orientada a servicios que puede ser acomodable en cualquier necesidad de integración, ver el Capítulo 14, Conclusión: Mejores Prácticas para una Integración Empresarial de Negocios.

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 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.


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.

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.