CapíTulo 6

Arquitectura de Integración Técnica 1

Capítulo 6.

Arquitectura de Integración
Técnica.

6.1 Revisión ejecutiva.

La Arquitectura de Integración Técnica representa
los códigos de construcciones de la empresa para
todos los proyectos de integración. Es en la
especificación donde todos los proyectos
referencian cuándo se elegirán las tecnologías de
integración para su implementación particular. La
arquitectura incluye una guía y restricciones
diseñadas en cómo deben ser desarrolladas las
aplicaciones.

Por lo tanto, la especificación debe ser tanto de la
definición de todos los aspectos de la arquitectura
de integración, así como fácil de acceder, para que
la información pueda ser fácilmente encontrada y
entendida. Mientras en michos casos las
descripciones detalladas son necesarias y
apropiadas, nosotros recomendamos el uso de
mapas de resumen y tablas para presentar la
información. Cada una de las arquitecturas de
solución presentadas en la Parte III de este libro,
están basadas en esta especificación de
arquitectura, y es un subconjunto de esta
especificación. El crear una Especificación de
Arquitectura de Integración guiará a muchas
soluciones de implementación de TI para asegurar
la interoperabilidad y conducirlas a la reutilización.
Por ejemplo, en Estado de Florida ha creado una
serie de lineamientos para su arquitectura de
integración, descritos en el Caso de estudio 6.1
(Oficina del Estado de la Tecnología de Florida
2003).

La Arquitectura de Integración Técnica deberá ser
Integración Empresarial


conducida por los requerimientos del negocio. Con el tiempo, una gran
organización necesitará uno de cada uno. Mientras las necesidades de los
negocios actuales deberán conducir los requerimientos de infraestructura e
implementaciones, las decisiones de arquitectura deberán tomar en cuenta
futuros requerimientos y adaptabilidad. Deberá definir lo siguiente:

Comunes y reutilizables servicios de área de negocios que puedan
soportar múltiples aplicaciones.
Comunes y estandarizados servicios técnicos que puedan adoptar
cualquier estilo de integración ya sea de servicio, información u
orientada procesos.
Niveles de servicios deben ser soportados.
Una estructura de seguridad comprensible basada en políticas de
seguridad claramente articuladas a lo largo de la empresa.
Enfoque en la habilidad de conducir los sistemas existentes y productos
comerciales de sistemas empacados, para proveer una significante
porción de funcionalidad a las aplicaciones.

En algunos casos, el esfuerzo en la arquitectura técnica se enfocará en reducir
el número de tecnologías redundantes. La Evaluación Actual de la Arquitectura
de Integración (Capítulo 5) provee un buen manejo de la información que
llevará a tomar decisiones de arquitectura.



Caso 6.1
Estado de Florida: Guiando la Arquitectura de Integración Empresarial.
La complejidad de cualquier gobierno de estado no es generalmente
entendido por aquellos que se encuentra afuera. No obstante, con múltiples
departamentos, grandes presupuestos, cambios en el presupuesto, nuevas
leyes, cambios en políticos, y prioridades de competencia; es uno de los
ambientes de TI más complejos que puede ser imaginado. Aun con la
llegada de CIOs de estado, hay un gran ambiente de distribución en los
estados, conduciendo a arquitecturas incompatibles, dificultad de compartir
información y duplicación de esfuerzos.
El Estado de Florida ha sido líder en organizar las funciones y
características de las TI del estado. Se ha reconocido la necesidad de
mejorar el enfoque a la arquitectura de integración empresarial dentro del
estado. Su estrategia reside en los patrones de diseño y componentes de
reutilización, junto con un enfoque práctico. La guía ha sido dada para
incorporar el siguiente enfoque a cualquier proyecto en que se busque
aprobación:

Demostrar en entendimiento del dominio del problema en el
contexto de las metas del estado. Línea basa de lo que hará el
sistema y porque es necesario.
Dar sentido a los datos. Identificar localización de datos, flujos y
metadatos.
Dar sentido a los procesos. Crear modelo de procesos.
Identificar las interfaces de aplicaciones .Identificar o crear
interfaces.
Identificar eventos. Identificar los eventos del negocio que accionen
otras acciones.
Identificar escenarios de transformación de datos. Planear
formatos de datos entre sistemas.
Mapa da información de movimiento. Mapa de la información
que fluye por estos sistemas.
Aplicar Tecnología. Seleccionar Tecnología
Pruebas. Crear plan de pruebas
Considerar actuación. Características específicas de funcionalidad.
Definir el valor. Define el ROI
Crear procedimientos de mantenimiento. Identificar procesos y
procedimientos operacionales.

Al crear esta guía, se están proveyendo las estructuras para mejora como el
estado de los sistemas es ordenado y el mejoramiento de la habilidad de
integrar y reutilizar los componentes en el futuro. Esta es un paso clave
hacia el logro de una arquitectura de integración empresarial.



6.2 Especificación de Arquitectura Técnica.

Como se menciono anteriormente, la Arquitectura de Integración Técnica
provee los códigos de construcción de la infraestructura de integración. Las
adiciones a nivel proyecto a ésta arquitectura asegura que habrá consistencia,
reusabilidad, y beneficio económico a la organización por las inversiones en
tecnologías de integración. Esta adición puede ser alcanzada a través del
diseño de revisiones, como se explica en el Gobierno de la Arquitectura
(Capítulo 4).

6.1.2 Introducción

Esta especificación representa la especificación de la arquitectura de
integración técnica empresarial. Este documento será usado para guiar
todas las decisiones y diseños relacionados con la integración, dentro de
la organización, Esta define el alcance de la arquitectura de integración,
tecnologías y vendedores preferidos y estándares empresariales.
Cuando se crea la introducción, hay que resaltarles a los usuarios todas
las decisiones en las que los lectores del documento deberán prestar
atención.

6.2.2 Alcance

Define el alcance de la arquitectura de integración. Debe ser dirigida ya
sea a toda la empresa o limitada a cierta organización o clase de
aplicaciones. Otras áreas que agregar incluyen los tipos de integración:
datos, aplicaciones o procesos), cualquier limitación y razones de las
limitaciones. El alcance deberá describir que tipo de aplicaciones
externas son cubiertas, incluyendo ya sea que una aplicación fuera del
alcance de la empresa es candidata para conectarse con aplicaciones
empresariales. Esto será el casa si la organización tiene cualquier
iniciativa de cadena de pedidos o comercio electrónico planeada.

6.2.3 Participantes Clave.

Define la audiencia e inversionistas principales. La audiencia debe incluir
a todos los miembros de la organización de TI; sin embargo, esto
debería enlistar explícitamente los roles específicos que son para
aplicar la integración en la ejecución normal de sus trabajos. Los
inversionistas principales deben incluir a los ejecutivos de TI y aquellos
responsables de mantener el documento.

6.2.4 Requerimientos de Arquitectura de Integración.



Esta sección esta dentro de los requerimientos del negocio capturados
en el Capítulo 2, así como en la evaluación de integración actual. La
sección de Requerimientos de la Arquitectura de Integración incluye los
requerimientos para los tipos de servicios y tecnologías que serán parte
de la infraestructura y definen para que deben ser utilizados para
diferentes tipos de aplicaciones, las aplicaciones que necesitan ser
integradas entre sí, y los tipos o estilos de integración que serán
utilizadas a lo largo de la empresa.

6.2.4.1 Tipos de Integración

La organización necesita comenzar esta especificación
identificando los tipos de integración que serán necesitadas para
ser soportada (ver Figura 6-1). Los datos de la estrategia de
negocios y requerimientos acumulados en el Capítulo 2 y 3 junto
con la evaluación actual descrita en el Capítulo 5, guían esta
actividad. Esto ayuda a definir los requerimientos conocidos para
este tipo de integración para determinar el alcance del a inversión.
Por ejemplo, si hay un número de aplicaciones que requieren
integración de procesos, entonces la organización deberá
considerar una licencia empresarial para una solución BPM.

6.2.4.2 Servicios y Tecnologías de Integración.



Como se mostro anteriormente, la arquitectura de integración esta
comprimida en un numero de diferentes servicios de integración, y
estos servicios pueden ser implementados con diferentes
tecnologías. En vez de dejar que la selección de productos
dirigiera la arquitectura, la arquitectura debe ser basada en una
estructura que abarque todos los aspectos de la integración
necesarios para esa organización. La arquitectura es entonces
construida utilizando productos existentes o nuevos. Además, la
arquitectura es construida con los principios de la organización y
no de los productos seleccionados. Por ejemplo, las compañías
que se embarcan en el camino de SOA pueden definir su
arquitectura como una serie de servicios. La Figura 6-2 muestra
los diferentes tipos de servicios de integración, y las tecnologías
que pueden ser utilizadas para implementar un servicio, porque
diferentes tecnologías se acoplan a diferentes tipos de
aplicaciones. Diferentes tecnologías que implementen el mismo
servicio no siempre significa redundancia si la tecnologías
entregan el mismo servicio a diferentes tipos de aplicaciones.

La Figura 5-3 del Capítulo 5, que fue construida durante la
evaluación de la arquitectura actual y muestra los productos
existentes en la organización, es utilizada como base para
determinar si los vendedores o tecnologías preferidas están
actualmente instalados.



6.2.5 Descripción de la Arquitectura de Integración.

La Descripción de la Arquitectura contiene dos vistas diferentes: la vista
conceptual y la de desarrollo. La vista conceptual provee un panorama
general de la infraestructura de integración empresarial y los tipos de
servicios que serán proveídos. La vista de desarrollo contiene
información relevante para los desarrolladores que utilizarán la
arquitectura. En la Parte III de éste libro se describen los patrones
específicos de la integración y como utilizan los servicios de la
Arquitectura de Integración Técnica.

6.2.5.1 Vista Conceptual.



La arquitectura conceptual intenta dar un panorama general de la
arquitectura de integración. No hay forma correcta o incorrecta de
desarrollar este diagrama. Es un dibujo conceptual que necesita
comunicar todos los componentes de la empresa. De hecho,
puede haber múltiples vistas conceptuales para ilustrar una
variedad de puntos en la arquitectura.

La arquitectura conceptual debe incluir los tipos de aplicaciones o
sistemas que conectarán utilizando la arquitectura de integración,
qué tecnologías son usadas para la integración, cómo será
utilizada la arquitectura técnica por los portales y en la red
corporativa y conectividad externa, así como la forma en que
interactuarán los usuarios con las aplicaciones resultantes. La
arquitectura conceptual deberá ser un diagrama que puede ser
utilizado para explicar la arquitectura tanto a los administradores,
como al personal. No estará satisfaciendo al personal técnico
profundo, pero puede ser usado para explicar a los usuarios del
negocio cómo la infraestructura es utilizada.

La Parte III del libro contiene patrones y diagramas
arquitectónicos de referencia para diferentes soluciones de
integración. Sin embargo, grandes compañías suelen tener una
combinación de requerimientos de integración. Abajo hay dos
ejemplos de diagramas. La figura 6-3 representa una vista
simplificada de la estratificación de los servicios de integración
ofrecidos. La figura 6-4 representa una vista alternativa a todos
los servicios de la integración que pueden ser parte de la
Arquitectura de Integración Técnica.

El diagrama debe ser acompañado por una descripción general
de la arquitectura conceptual, descripciones de cada componente
y relaciones entre ellos.

6.2.5.2 Vista de Desarrollo.

La vista de desarrollo es una descripción de cómo y cuando son
usadas cada una de las diferentes herramientas e interfaces, para
guiar al equipo de desarrollo, utilizando la arquitectura de
integración. Una arquitectura de integración es puesta para
ayudar a los desarrolladores en el rápido desarrollo de nuevas
aplicaciones que requieren integración pesada. Muchas
herramientas y enfoques diferentes pueden ser empleados por
los desarrolladores para utilizar la arquitectura. Para cada uno de
los aspectos de la arquitectura de integración debe haber una
descripción de cómo el desarrollador va a utilizar los servicios de
integración en una aplicación. Esto debería incluir los lenguajes
soportados y la forma en que los servicios y capacidades son


accedidos, herramientas para el desarrollo de cualquier
integración, y herramientas para la configuración y administración
de éstos. También interfaces estándar disponibles para su uso
deben ser definidas (ver Figura 6-5).



6.2.6 Perfil de Estándares.

Esta sección específica todos los estándares que han sido adoptados
por la organización que son relevantes para la arquitectura de
integración. La especificación completa debe incluir las políticas de
gobierno que definen como será manejado el cumplimiento de los
estándares, y el proceso y guía para aprobar las soluciones que no


cumplan con estándares. Muchos de éstos estándares están
relacionados a las interfaces, formatos o mecanismos de comunicación.
Los estándares arquitectónicos están comenzando a aparecer y pueden
tener un gran impacto en el futuro en la arquitectura de integración
empresarial. Un estándar clave que hay que observar es le Arquitectura
Dirigida a Modelos (Model Driven Arquitecture MDA), estándar del
Object Management Group. En el Caso de estudio 6.2 se describen las
actividades de MDA (Soley n.d.).

Los tipos de estándares que deben ser incluidos en la especificación
están enlistados en la Figura 6-6.



Caso 6.2
Arquitectura Dirigida a Modelos: Mejorando cómo es lograda la
Integración.

El Object Management Group se ha embarcado en la creación de
estándares relacionados al MDA. Esta actividad fue dirigida por el deseo de
proteger las inversiones de software, garantizando lo que se había
construido con lo que se iba a construir. La meta es la especificación de una
arquitectura que pude durar los siguientes 20 años. El desarrollo es
alcanzado por los modelos de desarrollo de los sistemas que se construyen
y que son probables y pueden simularse. Una vez que el modelo es
validado, el código se genera en el ambiente del proyecto que integra las
aplicaciones de he rancia y los productos pendientes con código generado.
El proceso de desarrollar una aplicación MDA es el siguiente:

1. Desarrollar un modelo de plataforma independiente que describa las
funciones y comportamiento.
2. Trazar el modelo en la tecnología middleware objetivo y crear un
modelo especifico de plataforma.
3. General el código desde el modelo específico de plataforma para el
desarrollo.

A través de este enfoque, los sistemas están fuertemente basados en
integración que puede ser desarrollada más rápido y fácilmente que hoy en
día. Adicionalmente, la OMG visiona que a través de MDA, serán
desarrolladas herramientas para ingeniería inversa, y generar modelos de
sistemas existentes para su uso en nuevas aplicaciones. Además, será más
fácil generar puentes entre las aplicaciones tanto dentro como a través de la
empresa, mediante la compartición de modelos de plataforma
independientes entre las organizaciones que necesiten integrar otros
sistemas.

6.2.7 Requerimientos a Nivel de Servicios.

Los requerimientos a nivel de servicios incluyen disponibilidad, integridad
y servicio de entrega, escalabilidad, mantenimiento, administración,
usabilidad y funcionamiento. Los servicios de transacción, persistencia y
directorio pueden ser requeridos para soportar el nivel necesario del
servicio. Estos requerimientos pueden derivarse de la sección de
requerimientos de las aplicaciones o pueden ser impuestos por la
organización basados en las necesidades del negocio.

Cada sección necesitará romper con los requerimientos de las
aplicaciones, así como categorizar y abarcar la integración. Se intenta


que estos requerimientos sean una guía para el diseño y la
implementación de la arquitectura de integración. Muchos de estos
requerimientos estarán en un alto nivel y no a un nivel detallado que
ocurrirá con el diseño de las aplicaciones. Los requerimientos
específicos de las aplicaciones pueden necesitar ajustes para las
especificaciones de alto nivel. Es importante que la organización trate a
la Arquitectura de Integración empresarial como un proceso continuo en
lugar de un producto terminado.

6.2.7.1 Disponibilidad

Esta sección captura los requerimientos de disponibilidad, como
cuándo tendrá lugar la integración, expectaciones del acceso al
servicio, y métricas específicas que la arquitectura de integración
debe cumplir. Hay dos tipos de meticas que deben ser definidas
en cuando a la disponibilidad: Disponibilidad del sistema y
disponibilidad de integración. Las medidas de una disponibilidad
de sistema típica están trabajando disponibilidad por hora,
generalmente definidas como 8 horas al día, 5 días a la semana
(8 x 5), o de tiempo completo, definidas como 24 horas al día, 7
días a la semana (24 x 7). LA disponibilidad de integración puede
ser definida en tiempo real o de otra forma, como periódica o
agrupando tareas. Esta métrica define cuándo la información que
ha sido integrada está disponible para su uso.

6.2.7.2 Servicio de Integridad y Entrega.

La integridad de información integrada se resta de la integridad de
la transmisión, así como de la integridad de la información que
esta siendo procesada. La integridad de transmisión es asegurada
pro servicios de transmisión como entrega garantizada, entrega
en una y sólo una vez, y almacén de mensajes persistentes. La
integridad de los procesos de información es dependiente de la
validez de los procesos de traducción y transformación, y del
procesamiento de la información por el sistema objetivo. Estas
métricas pueden ser medidas en índice de errores, y se
relacionan tanto con la calidad como con el costo del sistema.

6.2.7.3 Escalabilidad.

La escalabilidad es un gran factor en la capacidad de planear y
adquirir. Los requerimientos de escalabilidad deben ser definidos
para las necesidades esperadas en la organización, a corto y
largo plazo. Los requerimientos de escalabilidad pueden ser
definidos por los siguientes parámetros:

Cantidad de información que será pasada.


Tasa de transacciones (tiempo/volumen).
Numero de aplicaciones que serán integradas.
Conexiones simultáneas y de usuario final.
Estos requerimientos determinan el tipo de arquitectura así como
las tecnologías seleccionadas para la implementación.
6.2.7.4 Mantenimiento y Administración.
El mantenimiento y administración se refieren a las características
operacionales de la arquitectura. Esta parte de la especificación
define los servicios específicos requeridos. También, define
cualquier requerimiento para integrarlos en el ambiente
operacional existente. Finalmente, identificar todas las
limitaciones relacionadas con el mantenimiento, como las
aplicaciones que están migrando a otras plataformas.
Los requerimientos de mantenimiento y administración pueden ser
definidos por los siguientes servicios:

Monitoreo y alerta.
Inicio, Apagado y Reinicio.
Solución de problemas y nivel de soporte.
Mantenimiento del código y uso de herramientas.
Instalación y administración de publicación de
actualizaciones y habilidad para deshacer acciones.
Programación de horarios.
Integración con herramientas existentes.
Después de determinar los requerimientos, se recomienda hacer
un resumen de éstos con propósito de la planeación empresarial.
Asignar un porcentaje a requerimientos de administración en cada
aplicación o proyecto puede servir para eso. Este porcentaje
provee una revisión de todos los requerimientos de
administración. El siguiente índice puede ser utilizado:

Nivel 1. Inicio, Apagado, Reinicio, Solución de problemas,
programación de la instalación remota.
Nivel 2. Nivel 1 más actualizaciones y deshacer acciones,
repositorio de aplicaciones integradas.
Nivel 3. Nivel 2 más monitoreo y alertas en tiempo real,
integración completa de las herramientas de desarrollo y
administración.
6.2.7.5 Usabilidad.
La usabilidad se refiere a que tal fácil cada uno de los usuarios
utilizará el sistema. Definir todos los tipos de usuarios del sistema,
junto con el tipo de acceso y usabilidad que requieren, ayuda a


determinar las herramientas y requerimientos de las aplicaciones.
La Figura 6-7 provee una plantilla para determinar los
requerimientos de usabilidad. Esta tabla puede ser modificada o
expandida si es necesario.

6.2.7.6 Funcionamiento.
Los requerimientos de funcionamiento definen el nivel de servicio
que necesita proveer la infraestructura para soportar a los
usuarios del negocio, procesos y transacciones. Los
requerimientos de funcionamiento son utilizados también en la
planeación de la vista de capacidades (ver Figura 6-8).
Un número de diferentes tipos de medidas pueden estar incluidas
en los requerimientos de funcionamiento. El tiempo de respuesta
es el tiempo esperado o aceptado por los usuarios o aplicaciones
para esperar por la respuesta del sistema. Puede ser medido en
milésimas de segundo o segundos (tiempo real), minutos, horas o
días. El punto de cruce es la cantidad de información que puede
ser enviada a través del sistema en una cierra cantidad de tiempo.
Puede ser medida en el número de transacciones o volumen de
datos. El tiempo de regreso es la cantidad de tiempo que de toma
a todo el proceso completarse. Puede ser medido en segundos,
minutos, horas o días. El número de usuarios simultáneos
determina el número de conexiones en vivo o sesiones que el
sistema debe soportar. El número de aplicaciones conectadas se
refiere al número de aplicaciones integradas que pueden enviar o
recibir información a través del sistema.



6.2.7.7 Servicios de Transacciones.
Los servicios de transacciones incluyen soporte a transacciones
distribuidas y estándar de cumplimiento de transacciones XA.
Esta información determina cómo serán administradas las
transacciones y cómo se mantendrá la integridad de éstas. Esta
sección también define los requerimientos para soportar los
estándares regulatorios y de la industria, como RosettaNet,
HIPAA, u otros estándares de transacciones de la industria.
6.2.7.8 Servicios de Persistencia.
Regularmente es necesario persistir o almacenar datos para su
uso futuro en un proceso de integración. LA persistencia es
requerida para mejorar la confiabilidad cuando se recupera de
alguna falla. El ser capaz de reiniciar un sistema con fallas sin
perder ningún proceso de integración es el uso más básico del
servicio de persistencia. Sin embargo, hay un número de otros
usos para éste tipo de servicio. Otros tipos de usos para los datos
persistentes incluye la habilidad de deshacer cualquier acción,
realizar auditorías de una actividad, o utilizar los datos
recolectados para analizar actividades en la infraestructura. Esta
sección define los requerimientos para proveer almacenamiento
de datos de la integración y es estado de dicha información
durante y después de cualquier uso de la infraestructura de
integración.
6.2.7.9 Servicios de Directorio.
Se ha convertido en mejor práctica en los sistemas distribuidos
modernos el proveer la habilidad de los servicios de directorio.
Los directorios proveen varias capacidades fundamentales para la
infraestructura. Pueden proveer transparencia en la locación,
permitiendo a las aplicaciones el encontrar a otras aplicaciones
para la integración. Esto reduce la necesidad de código duro de
localización de información en las aplicaciones e incrementa la


adaptabilidad porque un cambio de lugar no requerirá cambios en
otras aplicaciones. Adicionalmente, los directorios pueden ser
utilizados para almacenar información de configuración de
recursos o usuarios que pueden ser utilizados por cualquier
aplicación o proceso de integración. Finalmente, un directorio
puede ser utilizado para almacenar información de seguridad.
Este uso será examinado a mayor detalle en la sección de
seguridad.
En esta sección, se definen los requerimientos para servicios de
directorios. Esto incluye la habilidad de registrar cualquier
componente del sistema, incluyendo servidores, interfaces,
servicios, esquemas u otros tipos de información.
La Figura 6-9 es un ejemplo de una simple determinación de un
directorio que puede existir. Los campos obligatorios son el
nombre y la localización. El tipo y descripción son útiles en un
sistema operacional. Otros campos pueden ser añadidos para
componentes específicos.

6.2.7.10 Tabla Sumaria a Nivel Servicios.
La Tabla Sumaria a Nivel Servicios (figura 6-10) es de utilidad
para desplegar una vista agregada de los requerimientos a nivel
de servicios.



6.2.8 Seguridad

La seguridad es un tipo de requerimiento a nivel servicios, pero es un
tema tan importante y altamente especializado que se trata por
separado. La especificación debe comenzar con un resumen del nivel
más alto de requerimientos de seguridad por categorías o tipos de
aplicaciones que estarán utilizando la arquitectura. Esto puede ser
realizado de manera general como se muestra en la Figura 6-11, pero es
más efectivo si se puede definir específicamente.

6.2.8.1 Autentificación.

Los servicios de autentificación confitan la identidad del
usuario. Una especificación detallada de los requerimientos del
servicio de autentificación, incluye lo siguiente:

Lista de tipos de usuarios. Los tipos de usuario deberán
relacionarse con el tipo de aplicaciones o servicios que el
grupo accederá. Algunos ejemplos son: diseñadores,
programadores, administradores, usuarios de línea de
negocios, clientes y socios.



Nivel de autentificación para cada tipo o rol de usuario.
Los niveles de autentificación pueden incluir: contraseña,
contraseña con encriptación pública o privada, certificado
digital y biométricas.

Si solamente se soportara acceso unitario. La lógica
unitaria define si la autentificación puede ser realizada una
vez para todas las aplicaciones y servicios. Esto requiere un
directorio centralizado de todos los servicios.

Definición de cómo serán manejadas las cuentas de
usuario. Las cuentas de usuario deben ser constantemente
creadas y actualizadas basadas en los cambios que ocurren
en el negocio. Es importante tener procesos definidos
formales de cómo se sincronizará esta información.

6.2.8.2 Autorización.

Los niveles de autorización determinan qué usuarios o
procesos están permitidos para realizar o utilizar una serie de
datos en una aplicación. Esta sección define categorías para
autorización, basadas en la aplicación o sensibilidad de los
datos. (ver Figura 6-12). LA autorización es generalmente
definida en una matriz CRUD que define los derechos de
Crear, Leer, Actualizar o Borrar información.

6.2.8.3 Perímetro de Seguridad.

Esta sección también integra cómo la arquitectura de
integración funcionará con un perímetro de seguridad y los
tipos o categorías de integración que serán requeridos para
utilizar en las características del perímetro de seguridad. Éste
es la combinación de cortafuegos, encriptación, servicios de


autentificación, y arquitectura utilizada para proteger la
empresa del mundo externo. La configuración del perímetro
de seguridad indicará el diseño de la arquitectura de
integración en relación con su uso externo.

6.2.8.4 Auditoría.

Esta sección define las categorías de auditorio basadas en el
tipo de aplicación y sensibilidad e los datos que están siendo
procesados. Las categorías básicas de la auditoría son:

Nivel 0. Mantener nada de información. En casos
donde no hay preocupación por la interacción porque hay
otros factores relacionados en los que se puede confiar, el
Nivel O puede ser utilizado y ninguna auditoria será
realizada.
Nivel 1. Mantener información en el tipo de interacción
y participantes. En casos donde los detalles no son
requeridos y solo el conocimiento de que una interacción
se ha llevado a cabo es requerido, el Nivel 1 sería
aplicable. Este puede ser utilizado en instancias donde no
es factible o necesario el deshacer una acción, pero solo
el hecho de que la actividad se realizó es requerido.
Nivel 2. Mantener solo las instrucciones para cada
interacción. El Nivel 2 es utilizado para examinar los
tipos de interacciones que han ocurrido y ver
comportamientos extraños o verificar que una interacción
ha ocurrido. Esto puede ser utilizado para verificar que un
empleado ha realizado una operación no autorizada en el
sistema y tiene la información para deshacer la acción.
Nivel 3. Mantener un conjunto completo de
información en cada interacción. El Nivel 3 es usado en
casos donde las interacciones son extremadamente
sensibles y probar la interacción o la completa auditoria
de cada interacción son requeridas. La completa auditoria
puede ser requerida en casos de transacciones
financieras significativas.

La función y los requerimientos de recursos son los puntos
clave entre hacer una distinción de cada nivel. De otra forma,
si el funcionamiento y los recursos fueran gratuitos el nivel 4
sería aplicado siempre. En muchas instancias, esto puede no
ser factible.

6.2.8.5 Confidencialidad.



La confidencialidad se refiere al nivel de privacidad que
requiere una transmisión. La confidencialidad usualmente
aplica al nivel de encriptación que es aplicado. Sin embargo,
también puede ser reflejado en al camino de comunicaciones
utilizado. Por ejemplo, si un alto nivel de confidencialidad es
requerido, la interacción podría ser direccionada a una line
dedicada de alto costo en vez de seguir un camino que utiliza
conexión a Internet. Generalmente, cuando se utiliza la
encriptación, el mayor nivel de confidencialidad, más lento es
el tiempo de respuesta, No obstante, cuando se consideran
los canales de comunicación, si se tiene mayor nivel de
confidencialidad, más caras las comunicaciones.
Funcionamiento, costo y seguridad son los puntos decisivos.

6.2.8.6 No cancelación.

La No Cancelación es muy importante en las transacciones
B2B. Asegura que los pedidos en una orden no pueden ser
regresados después. Los servicios de No Cancelación son
requeridos para asegurar la validez y fortaleza de los
contratos electrónicos. La especificación debe definir el nivel
de servicio de No Cancelación requerido, y cuales tipos y
categorías de aplicaciones requiere (Figura 6-13). Los tipos
de No Cancelación incluyen:

Sesiones de Comunicación de No Cancelación. Los
puntos finales de la sesión de comunicación, como las
sesiones SSl, intercambio de señales que los identifiquen
únicamente. Este tipo de No Cancelaciones validan que la
sesión tuvo lugar, pero no validan que información
específica fue intercambiada en la sesión, como hace eso,
no vincula permanentemente los contenidos de la sesión
con el origen o el receptor.
Servicios Middleware de No Cancelación. Las
interacciones entre servicios middleware incluyen señales
que validan la autenticidad del servicio. Las interacciones
son aseguradas en lapsos de tiempo e iniciadas. Este tipo
valida que la interacción tuvo lugar, pero no que
información específica fue intercambiada en la
interacción.
Transacciones de No Cancelación. Las transacciones
están acompañadas con señales que validan la
autenticidad y la transacción es marcada en el tiempo y el
inicio. Este tipo valida que hubo transacción pero no que
se procesó información específica.
Acciones de aplicaciones No Canceladas resultado de
muchas transacciones. Los usuarios finales intentan


tomar que la acción es grabada, las acciones de la
aplicación con únicas e irrefutablemente rastreadas por el
usuario, y las acciones son aseguradas en tiempo e inicio.
Esto valida que los participantes intenten completar la
acción, valida sus identidades, asocia el tiempo de la
acción con esta información y provee indicadores de que
el proceso fue completado.

6.2.9 Vista de Capacidad de Planeación.

Esta sección (Figura 6-14) especifica los enfoques de diseño para
alcanzar los requerimientos de las aplicaciones definidos en la sección
de Nivel de Servicios. La meta es definir cómo todos los requerimientos
a nivel de servicios se encontraran, incluyendo tecnologías, políticas y
procedimientos.

6.2.10 Diseño de Restricciones y Guías.

Todas las restricciones y guías específicas para arquitectos, diseñadores
y desarrolladores deben ser definidas en este punto. Este es un tema
abierto que no tiene límites. Sin embargo, algunas áreas en las que hay
que considerar el establecimiento de restricciones y áreas son:

Limitaciones de funcionalidad comicidad.
Formatos de guías de datos.
Restricciones en definiciones y registro de metadatos.
Preferencias de uso de diferentes tipos de interfaces.
Casos especiales de implementaciones de seguridad.
Desviaciones permitidas por la arquitectura de integración.



Esta sección es generalmente muy limitada al principio, pero conforme
se usa la arquitectura, lleva a un mejor entendimiento y conocimiento de
lo que funciona y no funciona y va a crecer con el tiempo.



6.2.11 Conclusiones y Comentarios.

La sección final de la Especificación de la Arquitectura de Integración
resume cualquier problema en particular o decisiones con respecto a la
arquitectura de integración. Estas pueden incluir las soluciones no
resultas para requerimientos específicos. Esto puede ser una buen lugar
para que los ejecutivos de administración de TI provean una quía sobre
las expectativas de la arquitectura de integración, cómo impactará a la
organización y qué se espera del personal. Finalmente, puede incluir una
discusión de hacia dónde va la arquitectura en el futuro.

6.3 Mejores Prácticas.

Hacer de la especificación de la arquitectura un documento vivo. Debe
ser consultado para cada nuevo proyecto de integración y revisado
periódicamente, o cuando se requiera.
No evaporar el océano en la primera vez. El alcance del primer proyecto
de definición de la arquitectura de integración no debe ser mayor a 2 o 3
meses.
Asegurarse que los inversionistas tienen entradas en la definición y
revisión de la especificación de la arquitectura. De otra manera, la
arquitectura puede ser saboteada.
Planear global, implementar local.
Diseñar para la reutilización.
Medir y administrar la reutilización.
Implementar métricas de calidad para justificar la infraestructura de las
inversiones.

6.4 Siguientes Pasos.

La Arquitectura de Integración Técnica provee un marco para elegir la
infraestructura de tecnologías para las soluciones discutidas en la Parte III del
libro. Aquellos que buscan implementar soluciones tácticas pueden saltar a esa
parte inmediatamente. Sin embargo, las compañías que busquen maximizar la
agilidad del negocio, reutilización y retorno de las inversiones, deberán
completar la Arquitectura de Integración empresarial mediante la definición de
la Arquitectura de Integración de Servicios (Capítulo 7), Arquitectura de
Integración de Información (Capítulo 8) y Arquitectura de Integración de
Procesos (Capitulo 9).


CapíTulo 6

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CapíTulo 6

Similar to CapíTulo 6 (20)

CapíTulo 6