Lectura 8 capitulo 6 GOLD-BERNSTEIN & RUSH

Technical Integration Architecture

INTRODUCCIÓN

La arquitectura técnica de la integración representa la construcción de códigos para todos los proyectos de integración. Es la especificación a la cual todos los proyectos harán referencia cuando se elija una tecnología de integración para su particular implementación. La arquitectura incluye guías y restricciones de diseño en el como las aplicaciones deben ser desarrolladas.
Por lo tanto, la especificación debe ser cuidadosa al definir todos los aspectos de la arquitectura de integración, y fácilmente accesible, de manera que la información pueda ser fácilmente encontrada y entendida. Mientras en muchos casos descripciones detalladas son necesarias y apropiadas, se recomienda el uso de gráficos sumarios y tablas para representar información. Crear una especificación de la arquitectura de integración guiara muchas soluciones de implementación de TI, para asegurar la interoperabilidad y la reutilización.

Arquitectura técnica de la integración

Caso de Estudio 6.1
La complejidad de cualquier gobierno generalmente no es entendida por aquellos que están en el exterior. Sin embargo con múltiples departamentos, grandes presupuestos, cambios en los presupuestos nuevas leyes, cambios en las políticas y prioridades competitivas es uno de los mas complejos ambientes de TI que se puedan imaginar. Incluso con la llegada de los CIOs hay aun un alto ambiente de TI distribuido en los estados dirigidos por arquitecturas incompatibles, que difícilmente comparten información y duplican esfuerzos.
El estado de florida ha sido líder en la organización de las funciones de TI y de activos. Ha reconocido la necesidad de mejorar el aproximamiento a la arquitectura de integración empresarial dentro del estado. Su estrategia de basa en designar patrones y reutilización de componentes acoplándolas con la práctica. Esta guía ha sido dada para incorporar la aproximación de muchos proyectos buscando la aproximación:
Demostrar entendimiento del dominio del problema en el contexto de las metas del estado. Línea base de lo que el sistema hará y porque es necesario.
Darle sentido a los datos. Identificar la localización de los datos, flujos y meta datos.
Darle sentido a los procesos, crear modelos de procesos
Identificar interfaces de aplicación. Identificar o crear interfaces.
Identificar eventos. Identificar eventos del negocio que disparan acciones.
Identificar escenarios de transformación de datos. Mapas de formatos de datos entre sistemas
Mapas de movimiento de información mapas de flujo de información entre sistemas.
Aplicar tecnología. Seleccionar tecnología
Prueba. Crear un plan de prueba
Considerar el rendimiento. Especificar características de rendimiento
Definir el valor. Definir la recuperación de la inversión
Crear procesos de mantenimiento. Identificar procesos operacionales y procedimientos.

6.2 Especificación técnica de la arquitectura de integración

Como se declaro anteriormente, la arquitectura técnica de integración provee de códigos de construcción para la infraestructura de integración. El nivel de proyecto adhiere aseguradores de que hay consistencia, reusabilidad y un beneficio económico para la organización en invertir en tecnologías de integración. Esta adherencia puede ser completada a través de revisiones de diseño.

6.2.1 Introducción
Esta especificación representa la especificación de la arquitectura técnica de integración para la empresa. Este documento será usado para guiar todas las decisiones y diseños relacionados a la integración en la organización. Define los alcances de la arquitectura de integración, vendedores y tecnologías preferidas, y estándares empresariales.

6.2.2 Alcance
Definir el alcance de la arquitectura de integración. Debe añadir si es una empresa grande o limitada para una organización para cierta organización o ciertas clases de aplicación. Otras áreas a incluir son el tipo de integración (datos, aplicaciones o procesos), cualquier limitación o razones de limitación. El alcance debe describir también que tipo de aplicaciones externas serán cubiertas incluyendo si una aplicación fuera del alcance de la empresa es candidata para conectarse con las aplicaciones de la empresa. Este será el caso si la empresa tiene cualquier cadena de o iniciativas de comercio electrónico planeada.

6.2.3 Participantes Clave
Para definir la audiencia hay que incluir a todos los miembros de TI de la organización. Sin embargo se debe de especificar explícitamente los papeles y los títulos que son aplicados en la ejecución normal de su trabajo

6.2.4 Requerimientos de arquitectura de integración
Esta sección se basa en los requerimientos del negocio, así como las evaluaciones de integración reciente. La sección de requerimientos de arquitectura de integración incluye los tipos de de servicios para la integración y las tecnologías que serán parte de la infraestructura de integración y define que servicios deben ser utilizados para diferentes tipos de aplicaciones, la aplicación que debe ser integrada con cada otra y los tipos o estilos de integración que serán usados a través de la empresa.

6.2.5 Tipos de integración
La organización necesita comenzar esta especificación para identificar los tipos de integración que necesitan ser apoyados o soportados (ver la figura 6-1) los datos de la estrategia del negocio y los requerimientos recolectados, junto con las evaluaciones actuales. Ayuda a definir los requerimientos conocidos para este tipo de integración para determinar el alcance de la inversión. Por ejemplo si hay un número de aplicaciones que requieren integración de procesos, entonces la empresa deberá considerar una licencia empresarial para una solución BPM.

6.2.6 Servicios de integración y tecnologías
Según lo observado previamente la arquitectura de integración esta comprometida con un numero de diferentes de servicios de integración y estos servicios pueden ser implementados con diferentes tecnologías. Mejor dicho, que al dejar la selección del producto en manos de la arquitectura una arquitectura debe basarse en un marco que abarque todos los aspectos de integración necesarios para la integración. La arquitectura es construida entonces usando existentes o nuevos productos. Además la arquitectura es construida bajo los principios de la organización y no de los productos seleccionados. Por ejemplo compañías que se embarcan en el camino de SOA pueden definir su arquitectura como una serie de servicios (ver figura 6-2) representa los diferentes tipos de servicios de integración y las tecnologías que pueden ser usadas para la implementación del servicio. Según se observa a continuación puede haber un numero de tecnologías que pueden ser usadas para implementar un servicios porque diferentes tecnologías son convenientes para diferentes tipos de aplicaciones. La implementación de diferentes tecnologías en un servicio no siempre significa redundancia si se reparten las tecnologías en el mismo servicio para diferentes tipos de aplicaciones.

En la figura 6-3, la cual fue construida durante la evaluación de la arquitectura actual y muestra los productos existentes en la organización, es usada como base para determinar si la tecnología o el vendedor preferido esta actualmente instalado.

6.2.5.1 Vista Conceptual
La arquitectura conceptual intenta dar el panorama general de la arquitectura de la integración. No existe el camino correcto o el camino recto para desarrollar este diagrama. Se necesita transportar todos los componentes de la empresa. De hecho, hay múltiples vistas conceptuales para ilustrar una variedad de puntos en la arquitectura.
La arquitectura conceptual puede incluir los tipos de aplicaciones o sistemas que se conectarán usando la arquitectura de la integración, qué tecnologías son usadas para la integración, como la arquitectura técnica será usada por portales y en la red corporativa y la conectividad externa, así mismo, el cómo los usuarios interactúan con las aplicaciones resultantes. La arquitectura conceptual debe ser un diagrama que pueda usarse para explicar la arquitectura de ambos, tanto de la gerencia como del personal. No debe satisfacer al personal profundamente involucrado técnicamente, pero pude ser usado para explicar a los usuarios del negocio cómo la infraestructura es usada.
Las grandes compañías tienen probablemente una combinación de requerimientos de integración. Abajo hay dos ejemplos de diagramas. La figura 6-3 representa una vista simplificada de etiquetado de los servicios de integración ofrecidos.
La figura 6-4 representa una vista alternativa de todos los servicios de integración que pueden ser parte de la Arquitectura de Integración Técnica.El diagrama debe ser acompañado por una descripción total de la arquitectura conceptual, descripciones de cada componente y la relación entre cada uno.

6.2.5.2 Vista Desarrollada
La vista desarrollada es una descripción de cómo y cuándo cada una de las diferentes herramientas es usada para guiar al equipo de desarrollo utilizando la arquitectura de integración. Una arquitectura de integración es puesta en lugar como apoyo a los desarrolladores en el rápido desarrollo de nuevas aplicación que requieren integración pesada. Muchas diferentes herramientas y accesos pueden ser empleados por desarrolladores para usar la arquitectura. Para cada aspecto de la arquitectura de la integración debe haber una descripción de cómo un desarrollador puede utilizar los servicios en una aplicación. Esto debe incluir los lenguajes apoyados y la manera que los servicios y capacidades son accesadas, herramientas para desarrollar cualquier integración y herramientas para configuración y administración. También interfaces estándares disponibles para su uso deben ser definidas. Ver Figura 6-5.

6.2.6 Perfiles Estándares
Esta sección especifica todos los estándares que tienen que ser adoptados por la organización que son relevantes a la arquitectura de integración. La especificación completa debe incluir también una póliza de la dirección que define cómo cumplir a los estándares que serán manejados, y el proceso y los lineamientos para soluciones aprobadas que no obedezcan a los estándares. La mayoría de estos estándares están relacionados a interfaces, formatos o mecanismos de comunicación. Los estándares de arquitectura están empezando a aparecer, y pueden tener un gran impacto en el futuro en una arquitectura de integración empresarial. Una clave estándar que observar es el Modelo de Arquitectura Impulsada (MDA); estándar del Grupo de Gestión de Objetos. El caso de estudio 6.2 describe las actividades de MDA. Los tipos de estándares a ser direccionados en las especificaciones están listados en la figura 6-6.

Caso de estudio 6.2
Modelo de Arquitectura Impulsada: Mejorando el cómo la integración es llevada a cabo.
El Grupo de Gestión de Objetos se ha embarcado en la creación de estándares relacionados al Modelo de Arquitectura Impulsada. Esta actividad fue impulsada por el deseo de proteger la inversión de software mediante la integración de lo que se ha construido con lo que construirá. La meta es la especificación de una arquitectura que pueda durar por los siguientes veinte años. El desarrollo es llevado a cabo, mediante modelos desarrollados de los sistemas a ser construidos que son probados y pueden ser simulados. Una vez que el modelo es validado, el código es generado en el ambiente deseado que integra las aplicaciones de herencia y productos fuera de mostrador con el código generado.
El proceso para desarrollar una aplicación MDA es:
1.Desarrollar un modelo de plataforma independiente que describe las funcionalidades y comportamientos.
2.Mapear el modelo teniendo como objetivo tecnología middleware y crear una plataforma de modelo especifico. (Middleware es un software de computadora que conecta componentes de software o aplicaciones para que puedan intercambiar datos entre éstas. Es utilizado a menudo para soportar aplicaciones distribuidas. Esto incluye servidores web, servidores de aplicaciones, sistemas de gestión de contenido y herramientas similares. Middleware es especialmente esencial para tecnologías como XML, SOAP, servicios web y arquitecturas orientadas a servicios.)
3.Generar código del modelo de plataforma específica para despliegue.
A través de este enfoque, los sistemas que son grandemente basados sobre la integración pueden ser desarrollados más rápida y fácilmente de lo normal hoy en día. Además, la OMG tiene la visión de que a través de MDA se desarrollaran herramientas para la ingeniería inversa, para generar modelos de sistemas existentes para el uso en nuevas aplicaciones. Además, deberá ser más fácil generar puentes entre ambas aplicaciones internas y a través de la empresa mediante el hecho de compartir los modelos de plataforma independiente entre las organizaciones que necesitan integrar a otros sistemas.

6.2.7 Requerimientos de Niveles de Servicio
Los requerimientos de niveles de servicio incluyen disponibilidad, integridad y entrega de servicios, escalabilidad, mantenimiento, gestión, usabilidad y desempeño. Transacción, persistencia y servicios de directorio pueden también requerir el soporte necesario del nivel de servicio. Estos requerimientos pueden ser derivados de la sección de requerimientos de la aplicación o pueden ser impuestos por la organización basada en las necesidades del negocio.
Cada sección deberá probablemente necesitar romper los requerimientos de aplicación así como un tipo de alcance de integración. Estos requerimientos intentan ser una guía para el diseño e implementación e la arquitectura de integración. Muchos de estos requerimientos deberán estar a un nivel alto y no como un nivel detallado que ocurrirá con el diseño de la aplicación. Los requerimientos de aplicaciones específicas pueden necesitar ajustes a las especificaciones de alto nivel. Es importante que la organización trate a la Arquitectura de Integración Empresarial como un proceso diario más que un producto terminado.

6.2.7.1 Disponibilidad
Esta sección captura los requerimientos de disponibilidad, tales como cuándo tomara lugar la integración (tiempo real o por partidas), expectativas en el acceso al servicio, y cualesquiera de las métricas especificas que la arquitectura de integración necesita conocer. Hay dos tipos de métricas a ser definidas con respecto a la disponibilidad: disponibilidad de sistema y de integración. Típicas medidas de disponibilidad de sistema están trabajando por hora disponibles, usualmente definido de 8 horas por día, 5 días por semana (8x5), o tiempo completo de disponible, definido como 24 horas por día, 7 días por semana (24x7). La disponibilidad de la integración puede ser definida como tiempo real u otra, tal como periódicos o por partidas. Esta métrica define cuando la información que tiene que ser integrada esta disponible para su uso.

6.2.7.2 Integridad y Servicios de Entrega
La integridad de información integrada descansa en la integridad de la transmisión así como la integridad de la información es procesada. La integridad de transmisión es asegurada por servicios de transmisión tales como la entrega garantizada, una y solo una entrega, y persistentes mensajes almacenados. La integridad de la información de procesos es dependiente de la validez de la traducción y transformación del proceso, y el procesamiento de la información por el sistema. Esta métrica puede ser medida en porcentajes de error, y relacionando a ambos la calidad y costo del sistema.

6.2.7.3 Escalabilidad
La escalabilidad es un factor importante en la capacidad de planear y comprar. Los requerimientos de escalabilidad deben ser definidos por las necesidades esperadas de la organización a corto y largo plazo. Los requerimientos de escalabilidad deben ser definidos por los siguientes parámetros.
· La cantidad de información a ser pasada.
· Porcentajes de transacción (tiempo/volumen).
· Número de aplicación a ser integrada.
· Conexiones de usuarios finales simultáneos.
Estos requerimientos determinan el tipo de arquitectura así como las tecnologías seleccionadas para la implementación.

6.2.7.4 Mantenimiento y Gestión
El mantenimiento y gestión se refiere 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 a integrar con el ambiente operacional existente. Finalmente, identifica todo lo relacionado al mantenimiento de los límites, tales como aplicaciones que están migrando a diferentes plataformas, o están quedando obsoletas.
Los requerimientos de mantenimiento y la gestión pueden ser definidas por los siguientes servicios:
· Monitoreo y alerta.
· Inicio, apagado y reinicio.
· Solución de problemas y nivel de soporte.
· Mantenimiento de código y herramientas de uso.
· Instalación y gestión de liberación de actualizaciones y capacidad de rollback (operación que devuelve a la base de datos a algún estado previo).
· Calendarización.
· Integración con herramientas existentes.
Después de determina los requerimientos, recomendamos resumirlos para el propósito de planeación de la empresa. La asignación de una calificación de requerimiento de gestión para cada aplicación o proyecto puede hacer esto. Esta calificación provee una vista en forma de resumen de todos los requerimientos de gestión. La siguiente calificación puede ser usada:
· Nivel 1. Inicio, apagado y reinicio, solución de problemas, agenda de instalación remota.
· Nivel 2. El nivel 1 más actualizaciones y rollbacks, repositorio de aplicación integrada.
· Nivel 3. El nivel 2 más monitoreo en tiempo real y alertas, integración completa de desarrollo y gestión de herramientas.

6.2.7.5 Usabilidad
La usabilidad se refiere a cuan fácil cada tipo de usuario usará el sistema. Definiendo todos los tipos de usuarios del sistema, también con el tipo de acceso y usabilidad que ellos requieren, ayuda a determinar las herramientas y requerimientos de aplicaciones. La figura 6-7 proporciona una plantilla para determinar los requerimientos de usabilidad. Esta tabla puede ser modificada o expandida si es necesario.

6.2.7.6 Desempeño Los requerimientos de desempeño definen el nivel de servicio que la infraestructura necesita proporcionar para dar soporte a los usuarios de negocios, procesos y transacciones. Los requerimientos de desempeño son usados también en la capacidad de la vista de la planeación. (Ver Figura 6-8).
Un número de diferentes tipos de mediciones pueden ser incluidas en los requerimientos de desempeño. El tiempo de respuesta es el esperado o el tiempo es aceptable para los usuarios o las aplicaciones en espera de una respuesta del sistema. Puede ser medida en sub-segundos o segundos (tiempo real), minutos, horas o días. Tomando en cuenta esto, es la cantidad de información que puede ser enviada a través del sistema interno en una cierta cantidad de tiempo. Puede ser medido en número de transacciones o volumen de datos. El tiempo de vuelta completa es la cantidad de tiempo que toma al proceso entero completarse. Puede ser medido en segundos, minutos, horas, o días. El número de simultáneos usuarios 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 podrían mandar o recibir información a través del sistema.

6.2.7.7 Servicios de Transacción
Estos servicios incluyen soporte a transacciones distribuidas y el estándar XA de conformidad de transacción. Esta información determina cómo las transacciones serán gestionadas y cómo la integridad transaccional será mantenida. Esta sección también define los requerimientos para el soportar la industria y estándares regulatorios tales como RossettaNet, HIPAA, u otras transacciones de estándares de industrias.

6.2.7.8 Servicios persistentes
A menudo es necesario que persistan o se almacenen datos para el futuro uso durante un proceso de integración. La persistencia es requerida para mejorar la fiabilidad cuando exista una recuperación de una falla. Siendo capaz de reiniciar una falla de sistema sin perder nada en los procesos de integración es el uso más básico de un servicio de persistencia. Sin embargo, hay otros numerosos usuarios para este tipo de servicio. Otros tipos de usos para mantener datos incluyen la habilidad de retornar a un estado previo cualquier acción, realizar auditorias de actividad, o usar la colección de datos para analizar actividades en la infraestructura. Esta sección define los requerimientos de proporción de almacén de los datos de integración y el estado de la información durante y después de cualquier uso de la infraestructura de integración.

6.2.7.9 Servicios de guía
Se ha convertido en una mejor práctica en los sistemas distribuidos modernos para proporcionar habilidad para los servicios de guía. Las guías proporcionan bastantes capacidades fundamentales para la infraestructura. Pueden proveer de transparencia de lugar mediante el alojo de aplicaciones para “encontrar” otras aplicaciones para la integración. Esto reduce la necesidad de codificar fuertemente la información del lugar en la aplicación y aumenta la capacidad de adaptación porque un cambio de locación puede no requerir cambios en otras aplicaciones. Además, las guías pueden ser usadas para almacenar información de configuración en recursos o usuarios que pueden ser usados por cualquier aplicación o proceso de integración. Finalmente, una guía puede ser usada para almacenar información de seguridad. Este uso será examinado a detalle en la sección de seguridad.
En esta sección, se define los requerimientos para los servicios de la guía. 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 configuración de una guía 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 agregados para componentes específicos.

6.2.7.10 Tabla de resumen de nivel de servicios
Esta tabla nos es útil para mostrar una imagen de los requerimientos del nivel de servicios.

6.2.8 Seguridad
La seguridad es un requerimiento de nivel de servicios, pero es un tópico muy especializado que debe ser abordado por separado. La especificación debe comenzar resumiendo por separado los requerimientos de seguridad de alto nivel en categorías o tipos de aplicación que serán utilizados en la arquitectura. Esto puede ser realizado de una manera general, pero es más efectivo si puede ser específicamente definido.

6.2.8.1 Autentificación
Estos servicios confirman la identidad de un usuario. Una detallada especificación de servicio de autorización de usuario requiere lo siguiente:
· Lista de tipos de usuario: los tipos de usuario deben relacionarse con los tipos de aplicaciones o servicios a los que podría acceder un grupo. Los ejemplos incluyen: diseñadores, programadores, administradores, usuarios, clientes y socios.

· Nivel de autentificación para cada nivel o rol. Los niveles de autentificación pueden incluir: password, password con clave pública o privada, certificado digital y biometrías.

· Definir como serán usadas las cuentas: las cuentas de los usuarios deben cambiar según se dan cambios en la organización del negocio. Es importante tener un proceso formal que defina como esta información será sincronizada.

6.2.8.2 Autorización
Los niveles de autorización determinan las operaciones a las que un usuario o proceso esta autorizado a llevar a cabo dentro de una aplicación. Esta sección define categorías de autorización, basadas en la aplicación o la sensibilidad de los datos. La autorización es generalmente retratada en una matriz que define los derechos de crear, leer, actualizar, o borrar información.

6.2.8.3 Perímetro de seguridad
Esta sección debe mostrar como la arquitectura de integración trabajara como un perímetro de seguridad y los tipos o categorías de integración que son requeridas para usar las funciones de seguridad del perímetro. El perímetro de seguridad es la combinación de firewalls, encriptación, servicios de autentificación y la arquitectura utilizada para proteger a la organización del mundo exterior. La configuración del perímetro de seguridad dictara el diseño de arquitectura de integración en cuanto a como se relaciona con el exterior.

6.2.8.4 Auditoria

Esta sección define las categorías de auditoria basadas en el tipo de aplicaciones y la sensibilidad de los datos manejados. Las categorías básicas de auditoria son:
· Nivel 0. Sin preservación de información
En casos donde debe preocupar la interacción de datos, sino otros factores. El nivel 0 puede ser usado, y no será llevada a cabo una auditoria.
· Nivel 1. Preservación de información según tipo de interacción y participantes
En casos donde los detalles no son requeridos y solo el conocer que una interacción se dio es requerido, puede utilizarse el nivel 1. Este puede ser usado en instancias donde un rollback no es factible o necesario, sino solo el hecho de que la interacción se realizo es requerido.
· Nivel 2. Preservar solo instrucciones para cada interacción
El nivel 2 es utilizado para examinar los tipos de interacción que han ocurrido y para buscar por algún comportamiento extraño o verificar que una interacción ocurrió. Esto puede ser usado para verificar que un empleado ha incurrido en alguna operación en el sistema a la que no esta autorizado, y poder llevar a cabo un rollback de esa acción.
· Nivel 3. Preservar un set completo de información de cada interacción
El nivel 3 es utilizado en casos donde las interacciones son extremadamente sensibles y cada prueba de la interacción es necesaria para poder auditar cada interacción requerida. Una completa auditoria puede ser requerida en casos de importantes transacciones financieras, por ejemplo.
Los requerimientos y comportamiento son los parámetros para poder diferenciar entre niveles de auditoria. De otro modo si el comportamiento y los recursos fueran libres, entonces el nivel cuatro pudiera ser aplicado. En muchas instancias esto no es factible.

6.2.8.5 Confidencialidad
Se refiere a los niveles de privacidad que una transmisión requiere. La confidencialidad generalmente aplica al nivel de encriptación que se utiliza. También, puede reflejar en como los canales de comunicación son utilizados. Por ejemplo si un alto grado de confidencialidad es requerido, entonces la interacción pudiera ser dirigida a una línea de alto costo, en vez de utilizar la señal de internet normal. Hablando en forma general, cuando se utiliza la encriptación, en cuanto mayor es el nivel de confidencialidad, menor es el tiempo de respuesta. Además, cuando se consideran los canales de comunicación, mientras mayor es el grado de confidencialidad, mas caras son las comunicaciones. Desempeño, costos y seguridad son a menudo intercambiables.

6.2.8.6 No repudio
La no cancelación es importantísima en las relaciones B2B. Esto asegura que una petición o alguna orden no serán canceladas en un futuro. Servicios de no cancelación son requeridos para asegurar la validez y formalidad de los contratos electrónicos. Las especificaciones deben definir los niveles del servicio de no cancelación requerido, y que tipos y categorías de aplicaciones requiere. Los tipos de no cancelación incluyen:
· Sesiones de comunicación no cancelables
Los puntos finales en la sesión de comunicación, como en una sesión SSL, intercambian fragmentos únicos que las identifican. Este tipo de no cancelación hacer constar que una reunión se llevo a cabo, pero no valida la información especifica que se intercambio en la sesión. Así como no conecta permanentemente los contenidos de la sesión con quien los emitió, dentro del recipiente.
· Transacciones no cancelables
La transacción es acompañada de un fragmento de información que valida la autenticidad de la operación y aparte tiene una marca de tiempo y una identificación. Este tipo de no cancelación valida que una transacción se lleve a cabo, pero no especifica el tipo de información que fue procesada en la transacción.
· Operaciones de aplicaciones consistentes en múltiples transacciones sin cancelación
En este tipo las transacciones son directamente rastreables hasta el usuario final, teniendo marca de tiempo e identificación. Esto valida que los participantes trataron de llevar a cabo la acción, irrefutablemente validando su identidad, y relacionando el tiempo de la acción con la información utilizada, y provee la no cancelación durante todo el proceso.

6.2.9 Panorama de capacidad de planeación
Esta sección especifica el diseño que se aproxima a lograr los requerimientos de la aplicación definidos en los niveles de seguridad. La meta es definir como todos los niveles de requerimientos se integraran, incluyendo las tecnologías, pólizas y procedimientos.

6.2.10 Diseño de restricciones guías de acción
Todas las restricciones y guías para arquitectos, diseñadores y desarrolladores deben ser especificados. Este es un tópico abierto en un área que no tiene fronteras. Sin embargo, muchas aéreas a considerar en la implementación de restricciones y guías:
· Conocer las limitantes de desempeño
· Formación de guías para los datos
· Restricciones en definición de metadatos y registros
· Preferencias en uso de distintos tipos de interfaces
· Casos especiales de implementación de seguridad
· Desviaciones permitidas por la arquitectura de la integración
Esta sección será muy limitada en un principio, pero el uso de la arquitectura lleva a un mejor entendimiento y conocimiento de que es lo que sirve y lo que no sirve, y va creciendo con el tiempo.

6.2.11 Conclusiones y comentarios
La sección final de especificaciones de arquitectura de integración resume todos los asuntos particulares o decisiones concernientes a la arquitectura de integración. Esto puede incluir soluciones no resueltas para problemas específicos. Esto puede ser un buen lugar para que el manejo ejecutivo de la TI pueda proveer una guía o expectaciones de arquitectura de integración y como impactara esto a la organización, así como lo esperado por parte del personal. Finalmente puede incluir una discusión acerca de a donde se dirige la arquitectura en el futuro.

6.3 Las mejores practicas en la arquitectura de integración técnica
· hacer de las especificaciones de arquitectura, un documento real
· visualizar que las definiciones del primer proyecto de arquitectura de integración sea llevado a cabo en unos tres meses
· planear globalmente, implementar localmente
· diseñar para reutilización
· reutilizar medidas y manejo
· implementar métricas de calidad para justificar inversiones de infraestructura

CONCLUSIÓN

La arquitectura técnica de integración debe ser inducida por los requerimientos del negocio. En un cierto plazo, una organización grande tal vez necesite una. Mientras que las necesidades de los negocios mas recientes deben manejar los requerimientos de infraestructura e implementación, la decisión de la arquitectura debe tomar en cuenta los requerimientos futuros y la adaptabilidad.
En algunos casos el esfuerzo de arquitectura técnica se enfocará en reducir el número de tecnología redundante. La actual evaluación de arquitectura de integración proporciona un gran manejo de información que manejará decisiones de arquitectura.