Soluciones Integrales en la Organización EQ

5
Arquitectura de integración técnica

Visión general ejecutiva

La arquitectura de integración técnica representa la construcción de códigos
para la integración de todos los proyectos del negocio.
Es la especificación que todos los proyectos referenciarán al escoger
tecnología de integración para su particular implementación. La arquitectura
incluye el diseño de guía y las restricciones de cómo deben desarrollarse
las aplicaciones.
Por lo tanto, la especificación debe ser profunda para definir todos los
aspectos de la arquitectura de integración, y fácilmente accesible, de modo
que la información pueda encontrarse fácilmente. Mientras que en muchos
casos las descripciones detalladas son necesarias y apropiadas, también
se recomienda el uso de mapas, cuadros y resúmenes para presentar la
información.
Crear una especificación de arquitectura de integración guiará muchas
soluciones de ejecución de TI para asegurar la interoperabilidad y uso
repetido de influencia.
La arquitectura técnica de integración se debe manejar por las necesidades
de negocio. Con el transcurso del tiempo, una organización puede necesitar
uno de cada cosa. Mientras que el negocio actual las necesidades de
promontorio deberían manejar las necesidades de infraestructura y

El ejemplo práctico 6.1 de la Florida: Arquitecturas de integración de

empresa de guía
La complejidad de cualquier gobierno de estado no es a menudo
sobrentendida. Sin embargo, con departamentos múltiples, los presupuestos
grandes, cambios en los presupuestos, nuevas leyes, cambios políticos, y
las prioridades competitivas son unos de los entornos de TI más complejos
que pueden ser imaginados. Aún con el advenimiento de CIO´S de estado,
existe un entorno de TI altamente distribuido en los estados guiando a las
arquitecturas incompatibles, dificultad al dividir información, y duplicación de
esfuerzos.
El estado de la Florida ha sido un líder al organizar la función de TI del
estado y bienes. Ello ha reconocido la necesidad de mejorar el acercamiento
a arquitectura de integración de empresa dentro del estado. Su estrategia
depende en el diseño y el uso repetido de componentes, acoplado a un
acercamiento práctico.

1
 Soluciones Integrales en la Organización EQ
5
Esta guía ha sido para incorporar el acercamiento en cada proyecto
buscando aprobación:
Demuestre la comprensión del campo de problema en el contexto de las
metas del estado. Línea base de lo que el sistema hará y porque ello es
necesario.
➢ Explique los datos. Identifique ubicación de datos, flujos, y metadatos
➢ Explique se los procesos. Cree los modelos de proceso.
➢ Identifique los enlaces de aplicación. Identifique o cree enlaces.
➢ Identifique eventos. Identifique los eventos de negocio que aprietan el
gatillo acciones.
➢ Identifique guiones de transformación de datos. Combine los formatos
de datos entre los sistemas.
➢ Combine el movimiento de información combina flujos de información
entre los sistemas.
➢ Aplique tecnología. Tecnología selecta.
➢ Prueba. Cree una prueba de lo que planea.
➢ Considere ejecución. Especifique las características de ejecución.
➢ Defina el valor. Defina ROI.
➢ Cree los procedimientos de mantenimiento. Identifique los procesos y
procedimientos operacionales.
Por crear esta guía, ellos están proporcionando una estructura para mejorar
cómo los sistemas del estado son organizados y mejorando la habilidad para
integrar y volver a usar los componentes en lo sucesivo. Esto es un paso
clave hacia lograr una arquitectura de integración de empresa.

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

Las ejecuciones, decisiones de arquitectura deberían tomar las necesidades

futuras y adaptabilidad en la cuenta. Deba definir lo siguiente:

El campo de negocio común, para uso repetido atiende que pueda soportar
las aplicaciones múltiples

Campo común, normalizó los servicios técnicos que pueden soportar cada
estilo del integración tal como servicio, información, o proceso oriente

Atienda los niveles que se deben soportar

Un marco de seguridad comprensivo basado en una norma de actuación

sobre seguridad claramente a todo lo ancho de la empresa articulada

Foco en la habilidad para especular existente (herencia) en sistemas de

información y comercializar los productos de sistema empaquetados para
2
 Soluciones Integrales en la Organización EQ
5
proporcionar una porción significativa de la funcionalidad de aplicación.

En algunos casos, el esfuerzo de arquitectura técnica se enfocará en reducir

el número de las tecnologías redundantes.

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

Como manifieste sobre, la arquitectura técnica de integración proporciona
los códigos de edificio para la infraestructura de integración. La adherencia
de proyecto a nivel a esta arquitectura asegura que existen consistencia,
reutilización, y el beneficio económico a la organización para inversiones en
la tecnología de integración.

Introducción
Esta especificación representa la especificación de arquitectura de
integración técnica de empresa. Este documento estará acostumbrado a
guiar todas las decisiones y diseños relacionados con la integración en la
organización. Define el alcance de la arquitectura de integración, los
vendedores y tecnologías, y normas de empresa preferidos. Al crear la
introducción, bosqueje todos los lectores de decisiones a todo lo ancho de
la empresa del documento deber tener conciencia de, y llamar la atención
sobre apéndices, tal como referencian los reglamentos y normas de
gobernanza

Arquitectura de integración técnica

Alcance

Defina el alcance de la arquitectura de integración. Deba dirigir si es a todo

lo ancho de la empresa o limite a cierta organización o clase de
aplicaciones. Otras áreas para dirigir incluyen tipos de la integración (datos,
aplicación, o proceso), cualesquiera limitaciones y razones para las
limitaciones. El alcance debe describir también lo que tipos de aplicaciones
externas están cubiertos, incluyendo si una aplicación fuera del alcance de
la empresa es un candidato para unirse a las aplicaciones de empresa. Esto
será el caso si la organización tiene cada aprovisionamiento encadene o las
iniciativas de comercio electrónico planearon.

Seleccione a los participantes

Defina la audiencia y los depositarios de una apuesta principales. La
audiencia debería incluir todos los miembros de la organización de TI; sin
embargo, ello debe listar explícitamente los papeles o títulos específicos
3
 Soluciones Integrales en la Organización EQ
5
que es aplicar la integración en la ejecución normal de sus trabajos. Los
depositarios de una apuesta principales deberían incluir los poderes
ejecutivos de TI y esos responsables para mantener el documento.

Necesidades de arquitectura de integración

Esta sección depende en las necesidades de negocio, así como la
evaluación actual de integración. Las necesidades de arquitectura de la
sección de integración incluyen necesidades para los tipos de los servicios y
tecnologías de integración que serán parte de la infraestructura y define lo
que los servicios deben utilizar para los tipos diferentes de aplicaciones, las
aplicaciones que necesitan ser integradas, y los tipos o estilos de la
integración que estará usado a través de la empresa.

Tipos de integración
La organización necesita comenzar esta especificación por identificar los
tipos de integración que necesita ser sostenida. Ayuda para definir las
necesidades conocidas para este tipo de la integración para determinar el
alcance de la inversión. Por ejemplo, si existe varias aplicaciones que
requieren proceso integración, entonces la organización debería considerar
una licencia de empresa para una solución de BPM.

Servicios y tecnologías de integración

La arquitectura de integración es comprendida de varias integraciones
diferentes, y estos servicios se pueden poner en práctica con diferentes
tecnologías
Antes que dejar la arquitectura de guía de selección de producto, la
arquitectura debe ser basada sobre un marco que abarca todos los aspectos
de integración necesaria para esa organización. La arquitectura se
construye entonces usando existente o nuevos productos. Además, la
arquitectura es construida en los principios de la organización y no de los
productos escogidos. 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 tipos diferentes de integración, y las tecnologías
que pueden estar acostumbrados a poner en práctica el servicio.
Las tecnologías diferentes ponen en práctica el mismo servicio siempre no
significa la redundancia si las tecnologías dan el mismo servicio a los tipos
diferentes de aplicaciones.

4
Soluciones Integrales en la Organización EQ
5

5
Soluciones Integrales en la Organización EQ
5

6
Soluciones Integrales en la Organización EQ
5

7
 Soluciones Integrales en la Organización EQ
5

Descripción de arquitectura de integración

La descripción de arquitectura contiene dos vistas diferentes: la vista
conceptual y la vista de desarrollo:
La vista conceptual proporciona la pintura grande de la infraestructura
de integración de empresa y los tipos de servicios que se proveerá.
La vista de desarrollo contiene información pertinente a
desarrolladores que utilizarán la arquitectura.

8
 Soluciones Integrales en la Organización EQ
5
Vista conceptual
La arquitectura conceptual es propuesta dando a la pintura grande de la
arquitectura de integración. No existe ninguna vía derecha o una vía para
desarrollar este diagrama. Es un dibujo conceptual. Necesita transportar
todos los componentes de la infraestructura, cómo correlacionan, y cómo se
relacionan con otros componentes de la empresa en realidad; puede existir
las vistas conceptuales múltiples para ilustrar una variedad de puntos en la
arquitectura.
La arquitectura conceptual debería incluir los tipos de aplicaciones o
sistemas que se unirá usando la arquitectura de integración, lo que las
tecnologías son usadas para integración, cómo la arquitectura técnica se
usará por portales y en la red corporativa y conectividad externa así como
cómo el intermedio de usuarios con las aplicaciones resultantes. La
arquitectura conceptual debe ser un diagrama que puede estar
acostumbrado a explicar la arquitectura a ambos directivos y personal. Ello
lo puede estar dando satisfacción al personal técnicamente profundo, pero
puede estar acostumbrado a explicar así los usuarios de negocio cómo la
infraestructura es usada.

Vista de desarrollo
La vista de desarrollo es una descripción de cómo y cuando cada una de las
herramientas y enlaces diferentes están acostumbrado a guiar el equipo de
desarrollo utilizando la arquitectura de integración.
Muchas herramientas y acercamientos diferentes podrían ser empleadas por
desarrolladores para usar la arquitectura. Para todos y cada aspecto de la
arquitectura de integración debe existir una descripción de cómo un
desarrollador puede utilizar los servicios de integración en una aplicación.
Esto incluiría los lenguajes soporte y la manera en que los servicios y
capacidades son accedidos, las herramientas para desarrollar todas las
integraciones, y herramientas para configuración y administración. También
las interfaces normalizadas disponibles por el uso se deben definir.

9
 Soluciones Integrales en la Organización EQ
5

Perfil de normas
Esta sección específica toda las normas que han sido adoptadas por la
organización que es pertinente a la arquitectura de integración. La
especificación completa debe incluir también una política de gobierno que
define cómo sumisión a normas será manejado, y el proceso y orientaciones
para aprobar soluciones que no cumplen con normas. Las normas
arquitecturales que están comenzando a aparecer puede que tengan un
impacto más grande en lo sucesivo en una arquitectura de integración de
empresa.

10
Soluciones Integrales en la Organización EQ
5

11
Soluciones Integrales en la Organización EQ
5

12
 Soluciones Integrales en la Organización EQ
5

Ejemplo práctico 6.2

Modele maneje arquitectura: Mejorar cómo integración es realizada

La anca de manejo de objeto se ha embarcado sobre la creación de normas

relacionada con el modelo de manejo de la arquitectura (MDA). Esta actividad ha
sido manejada por un deseo para proteger la inversión de software integrando lo
que ha sido construido con lo que construirá. La meta es la especificación de una
arquitectura que podría estar durante los próximos veinte años. El proceso es
realizado para desarrollar los modelos de los sistemas para ser fabricado que sea
probable y se pueda simular. Una vez que el modelo es validado, código es
generado en el entorno de objetivo que integran las aplicaciones de herencia y de
los productos de estante con el código generado.
El proceso para desarrollar una aplicación MDA es:
Desarrolle un modelo de plataforma independiente que describa la
funcionalidad y comportamiento.

Combine el modelo a la tecnología de soporte intermedio de objetivo y

cree un modelo de la plataforma específico.

Genere código del modelo de plataforma específica para el

despliegue.
Por este acercamiento, los sistemas que se basan pesadamente sobre la
integración se pueden desarrollar rápidamente y más fácil hoy. Además, el
OMG lo imagina las herramientas de MDA para desarrolle se para el
contrario diseñando para generar modelos de los sistemas existentes para
uso en nuevas aplicaciones. Además, será fácil de generar puntales de
refuerzo entre las aplicaciones ambos dentro de y a través de la empresa
por dividir el moderno de plataforma independiente de ferrocarriles elevados
entre organizaciones que necesita integrar a otros sistemas.
Necesidades de servicio a nivel
Las necesidades de servicio a nivel incluyen disponibilidad, integridad y servicio de
entrega, escalabilidad, capacidad de mantenimiento, manejabilidad, valor práctico,
y ejecución. Transacción, persistencia, y los servicios directivos también pueden
ser requeridos para soportar el nivel necesario del servicio.

13
 Soluciones Integrales en la Organización EQ
5
Estas necesidades pueden ser derivadas de la aplicación a la sección de
necesidades o se pueden imponer por la organización basada en sobre
necesidades del negocio.
Cada sección puede la mayoría probablemente necesita derrumbar las
necesidades para la aplicación así como tipo o trecho de la integración. Estas
necesidades son propuestas para una guía para el diseño y ejecución de la
arquitectura de integración. Muchas de estas necesidades estarán a un nivel alto y
no a un nivel detallado que ocurrir con el diseño de aplicación. Las necesidades de
aplicación específicas pueden necesitar ajustes a la especificación de alto nivel. Es
importante que la organización trate la arquitectura de integración de empresa
como un proceso progresivo antes que un producto terminado.

Disponibilidad
Esta sección captura las necesidades de disponibilidad, tal como cuando la
integración tendrá lugar (tiempo real), expectaciones en el acceso al
servicio, y cualesquiera métricas específicas que la arquitectura de
integración necesita acercarse. Existen dos tipos de las métricas para ser
definido con respecto a la disponibilidad: disponibilidad de sistema y
disponibilidad de la integración. Las medidas de disponibilidad de sistema
típicas están trabajando disponibilidad de hora, normalmente definido como
8 horas por día, 5 días por semana (8 x 5), o la disponibilidad constante,
definido como 24 horas diarias, los 7 días por semana (24 x 7).
Disponibilidad de la integración puede ser definida como tiempo real u otro,
tal como periódico o lote. Este métrico define cuando la información que ha
sido integrada es el provecho capaz para el uso.
Integridad y servicio de entrega
La integridad de transmisión es asegurada por la transmisión atienda tal como
entrega avalada, una vez y único una vez entrega, y los almacenes de mensajes
persistentes. La integridad de la información los procesos que son dependientes de
la validez de la traducción y el proceso de transformación, y el proceso de la
información por el sistema de objetivo. Este métrico pueda ser medido y evaluado
por error, y se relacionan con ambas calidad y coste del sistema.
Escalabilidad
La escalabilidad es un factor grande en la capacidad planear y comprar. Las
necesidades de escalabilidad deben ser definidas para las necesidades
estimadas de la organización en ambos a corto plazo y el más tiempo
término. Las necesidades de escalabilidad se pueden definir por los
parámetros siguientes:
14
 Soluciones Integrales en la Organización EQ
5
➢ Cantidad de la información para pasarse
➢ La transacción evalúa (tiempo / volumen)

➢ Número de aplicaciones para integrarse

➢ Las conexiones de usuario final simultáneas

Estas necesidades determinan el tipo de arquitectura así como las

tecnologías escogidos para la ejecución.

Capacidad de mantenimiento y manejabilidad

Capacidad de mantenimiento y manejabilidad se refiere a las
características operacionales de la arquitectura. Esta parte de la
especificación define los servicios específicos que exija.
También define todas las necesidades para integrar con el entorno
operacional existente. En último lugar, identifica todas las limitaciones de
Capacidad de mantenimiento relacionados, tales como aplicaciones que
están emigrando a las plataformas diferentes, o esté siendo cambiado.
Capacidad de mantenimiento y necesidades de manejo se pueda morar
por los servicios siguientes:
➢ Controlando y alertando
➢ Arranque, paro del trabajo, y comience de nuevo
➢ Localizador de problemas y nivel del apoyo
➢ Capacidad de mantenimiento de código y uso de herramientas:
instalación y manejando la liberación de actualizaciones y habilidad
a reducción de precios al nivel original por resolución gubernamental
➢ Programación
➢ Integración con las herramientas existentes

Después de determinar necesidades se recomienda asignar un

requerimiento de manejabilidad desertando la o cada aplicación o
proyecto pueden hacer esto. Esta clasificación proporciona un resumen
mire las necesidades de manejabilidad de caída. La clasificación
siguiente se puede usar:
➢ Nivel 1. Arranque, paro del trabajo y comience de nuevo,
localizando, fijando la hora de remoto instalación
➢ Nivel 2. Nivel 1 más las actualizaciones y reducciones de precios al
nivel original por resolución gubernamental, integró depósito de
15
 Soluciones Integrales en la Organización EQ
5
aplicación
➢ Nivel 3. Nivel 2 más supervisión en tiempo real y alarmas, la
integración completa de las herramientas de desarrollo y de manejo

Valor práctico

La responsabilidad se refiere a cómo fácilmente cada tipo del usuario usará

el sistema. Definiendo todos los tipos de los usuarios de sistema,
conjuntamente con el tipo de acceso y valor práctico ellos exigen, ayude a
determinar herramientas y necesidades de aplicación. La figura 6-7
proporciona una plantilla para determinar las necesidades de valor práctico.
Esta mesa puede ser modificada o expandida según sea necesario.

Ejecución
Las necesidades de ejecución definen el nivel de atienda la infraestructura
necesita proporcionar para soportar los usuarios, procesos, y transacciones
de negocio. Las necesidades de ejecución son también usadas en la vista
de planificación de capacidad de varios tipos diferentes de medidas pueden
incluirse en por necesidades de rendimiento. El tiempo de respuesta es el
tiempo estimado o aceptable para usuarios o aplicaciones para esperar a
una respuesta del sistema. (véase la figura 6-8 ).

16
 Soluciones Integrales en la Organización EQ
5

El rendimiento es la cantidad de la información que se puede enviar

completamente el sistema dentro de cierta cantidad del tiempo. Puede ser
medido en el número de transacciones o volumen de los datos.
El tiempo de inversión es la cantidad del tiempo toma para el proceso entero
para completar.
En poder ser medido en los segundos, minutos, horas, o días. Número de
usuarios simultáneos determina el número de conexiones o sesiones vivas
el sistema debe soportar. Número de aplicaciones unidas se refiere al
número de las aplicaciones integradas que pudo enviar o recibir la
información por el sistema.

Servicios de transacción
Los servicios de transacción incluyen el apoyo de transacción distribuido y
la sumisión de transacción estándar de XA. Esta información determina
cómo transacciones serán manejadas y cómo la integridad de transacción
se mantendrá. Esta sección también define necesidades para apoyar
industria y las normas reguladoras tales como RossanettaNet, HIPAA, u
otras transacciones de industria estándar.

Servicios de persistencia
A menudo es necesario para persistir o almacenar datos para el uso futuro
durante un proceso de integración. La persistencia es requerida por mejore
la fiabilidad al recobrarme de una falta. Sea capaz de comenzar de nuevo un
sistema suspendido sin perder ningún en progreso integraciones son el más
básico uso de un servicio de persistencia.
Otros tipos de usos para los datos persistidos incluyen habilidad de la
reducción de precios al nivel original por resolución gubernamental
cualesquiera acciones, ejecutan exámenes de cuentas de la actividad, o

17
 Soluciones Integrales en la Organización EQ
5
usan los reunidos para analizar la actividad en la infraestructura. Esta
sección define los requerimientos para proporcionar el almacenamiento de
los datos de integración e información de estado durante y después de cada
uso de la infraestructura de integración.

Servicios directivos
Se convierte en una práctica mejor en los sistemas distribuidos modernos
para proporcionar la habilidad para los servicios directivos.
Pueden proporcionar transparencia de ubicación por permitir aplicaciones al
"hallazgo" otras aplicaciones para la integración. Esto reduce la necesidad
de codificar información fuerte de una ubicación en la aplicación, y aumente
la adaptabilidad porque un cambio de ubicación no podría requerir cambios
en otras aplicaciones. Además, los directivos pueden estar acostumbrados a
almacenar información de configuración sobre recursos o usuarios que se
puede usar por cada aplicación o proceso de integración.
Finalmente, el directivo puede estar acostumbrado a almacenar información
de seguridad. Este uso se examinará en el detalle más cercano en la
sección en la seguridad.
En esta sección, se define las necesidades para los servicios directivos.
Esto incluye la habilidad para registrar cada "componente" del sistema
incluyendo servidores, enlaces, servicio, esquemas, u otros tipos de la
información.
La figura 6-9 es un ejemplo de una disposición simple para un directorio que
puede existir. Los campos forzosos son el nombre y ubicación. El tipo y
descripción son útiles en un sistema operacional. Otros campos podrían ser
añadidos para los componentes específicos.

18
 Soluciones Integrales en la Organización EQ
5

Atienda la mesa sumaria de nivel

El servicio nivela la mesa sumaria (Figura 6-10) es útil para mostrar un

acuerdo que provea de puerta la vista de necesidades de servicio a nivel.

19
 Soluciones Integrales en la Organización EQ
5

Seguridad
La seguridad es un tipo de requerimiento de servicio a nivel, pero es tal
tema importante y un tema altamente especializado que se negocia con
separadamente. La especificación debería empezar por resumiendo las
necesidades a nivel superior de seguridad por los categorías o tipos de
aplicaciones que estará utilizando la arquitectura. Esto se puede hacer en
una manera general como se muestra en la figura 6-11.

20
 Soluciones Integrales en la Organización EQ
5

Autenticación
Los servicios de autenticación confirman la identidad de un usuario. Una
especificación detallada de la autorización atiende necesidades incluya lo
siguiente:
➢ Lista de tipos de usuario. Los tipos de usuario deberían ser
correlativos los tipos de aplicaciones o atienden un grupo accedería.
Los ejemplos incluyen: diseñadores, programadores, gerentes, la
línea de los usuarios, clientes, y socios de negocio.
➢ Nivel de la autenticación para cada tipo de usuario o papel. Niveles
del autentificación puede incluir: contraseña, contraseña con
codificación de público/clave privada, certificado digital, y
estadísticas de datos biológicos.
➢ Si la entrada en el sistema unitaria se soportar. La lógica unitaria
define si la autenticación se puede ejecutar definitivamente
aplicaciones y servicios. Esto requiere un directorio centralizado
para todos los servicios.
➢ Definición de cómo cuentas de usuario maneje los asuntos. Las
cuentas de usuario deben ser constantemente creado y actualice
basado en los cambios que ocurren en la empresa. Es importante
tener un proceso formal definido en cómo esta información será
mantenido sea sincrónico.
21
 Soluciones Integrales en la Organización EQ
5

Autorización
Los niveles de autorización determinan las operaciones que un usuario o
proceso son autorizados para ejecutarse en un conjunto de los datos o
dentro de una aplicación. (Véase la figura 6-12). La autorización es
normalmente morada en una matriz de CRUD que define se endereza
para crear, leer, actualizar, o borrar información.

Seguridad de perímetro
La seguridad de perímetro es la combinación de cortafuegos, codificación,
servicios de autenticación, y arquitectura acostumbró a proteger la empresa
del mundo exterior.
La configuración de la seguridad de perímetro dictará el diseño de la
arquitectura de integración como se relaciona con el uso externo.

Auditoría
Esta sección define categorías para revisar basada en el tipo de aplicación y
la sensibilidad de los datos andando en una procesión. Categorías básicas
de la auditoría son:
➢ Nivel 0. No mantenga ninguna información
En casos donde allí no está ninguna preocupación sobre las
interacciones debido a otros factores relacionada con fie de,
nivel 0 puede ser usado, y ninguna auditoría podría ser
ejecutada.
➢ Nivel 1. Mantenga información en el tipo de la interacción y participantes
22
 Soluciones Integrales en la Organización EQ
5
En casos donde los detalles no son requeridos y sólo el
conocimiento que una interacción ha tomado lugar es requerido,
nivel 1 podría ser aplicable. Esto podría usado en los casos
donde una reducción de precios al nivel original por resolución
gubernamental no es factible o necesaria, pero sólo el hecho
que una interacción tuvo lugar se exige.

➢ Nivel 2. Mantenga las instrucciones solas para cada interacción

El nivel 2 está acostumbrado a examinar los tipos de interacciones
que ha ocurrido y busca comportamiento impar o verifique que una
interacción ocurrió. Esto puede estar acostumbrado a verificar que
un empleado tenga ejecute un desautorizado la operación en el
sistema y tenga la información a reducción de precios al nivel
original por resolución gubernamental la acción.
➢ Nivel 3. Mantenga un conjunto completo de la información sobre cada
interacción
El nivel 3 es usado en casos donde las interacciones son
extremadamente sensitivas y prueba de la interacción o el necesite
revisar enteramente cada interacción es requerido. El examen de
cuentas completo puede ser requerido en caso de las
transacciones financieras significativas, por ejemplo.
Las necesidades de ejecución y de recurso son las compensaciones al
hacer un distinción entre cada nivel. De otra manera, si ejecución y recursos
eran libremente, entonces nivel cuatro se podría aplicarse siempre. En
muchos casos, esto no puede ser factible.

Confidencialidad
La confidencialidad se refiere al nivel del retiro que una transmisión exige.
Contra la confidencialidad normalmente aplica al nivel de la codificación que
es aplicado. Sin embargo, ello también pudo ser reflejado en los camino de
comunicaciones que se usa. Por ejemplo, si un alto grado de la
confidencialidad es requerido, entonces la interacción pudo ser orientada en
un coste más alto dedicado alinee se antes que seguir un camino que usa
una conexión en Internet. Hablando en términos generales, al usar
codificación, los más altos el nivel de confidencialidad, los lentos el tiempo
de respuesta. Sin embargo, cuando considerando canales de comunicación,
el grado más alto de la confidencialidad, más costoso seran las
comunicaciones. Ejecución, coste, y seguridad son a menudo las
compensaciones.

23
 Soluciones Integrales en la Organización EQ
5

Ninguna repudiación
Ninguna repudiación es extremadamente importante para las transacciones
de B2B. Asegura que una solicitud o una orden no se pueden repudiar
luego. Ningunos servicios repudiaciones son requeridos para asegurar la
validez y fuerza ejecutiva de contratos electrónicos. La especificación
debería definir el nivel de ninguna repudiación atienda requiera, y que tipos
y categorías de aplicaciones lo requieren (Figure 6-13).

Ningún tipo de repudiación incluye:

➢ Ninguna repudiación de sesiones de comunicaciones. Los puntos finales

en la sesión de comunicación, tal como una sesión de SSL, cambian
símbolos que singularmente los identificaron no valide que la información
específica ha sido cambiada en la sesión, como no ata permanentemente
los contenidos de sesión al creador o el receptor.
➢ Ninguna repudiación de servicios de soporte intermedio. Interacciones
entre servicios de soporte intermedio, incluyen un símbolo que valida la
autenticidad del servicio. Las interacciones son con seguridad de tiempo
sellado y entrado. Este tipo de ningún repudiación valida que una
interacción tuvo lugar, pero no ese específico información es sido
cambiada en la interacción.
➢ Ninguna repudiación de transacciones. La transacción es acompañada
con un simbólico que valide su autenticidad y la transacción es de tiempo
sellado y entre. Este tipo de ninguna repudiación valida que una
transacción tuvo lugar, pero no lo que los datos específicos son sido
24
 Soluciones Integrales en la Organización EQ
5
andados en una procesión en la transacción.

Esta sección (figura 6-14 , página 112) especifica los acercamientos de

diseño para lograr las necesidades de aplicación definidas en la sección a
nivel de servicio. La meta es definir cómo todo de servicio a nivel
necesidades serán acercadas incluyendo tecnologías, políticas, y
procedimientos, limitaciones de diseño y guía.

25
 Soluciones Integrales en la Organización EQ
5

Esta es un área
de tema
abierta que es
ilimitada.
Sin embargo ciertas áreas para considerar en la colocación de limitaciones
y la guía son
➢ Las limitaciones de ejecución conocidas
➢ Orientaciones de formato para los datos
➢ Limitaciones en las definiciones de metadatos y preferencia de registro
en el uso de tipos diferentes de enlaces
➢ Casos especiales de las ejecuciones de seguridad
➢ Desviaciones permitieron de la arquitectura de integración

26
 Soluciones Integrales en la Organización EQ
5

Conclusiones y comentarios
La sección final de la especificación de arquitectura de integración resume
todos los asuntos particulares o decisiones con respecto a la arquitectura de
integración. Éstas pueden incluir las soluciones no resuelto a las
necesidades específicas. Esto podría ser un lugar bueno para el manejo de
TI ejecutivo para proporcionar guía en las expectaciones de la arquitectura
de integración, cómo impactará la organización, y lo que es estimado del
personal. En último lugar, podría incluir discusión en donde la arquitectura
está yendo en lo sucesivo.

Las mejores prácticas en la arquitectura de integración técnica

Haga la especificación de arquitectura un documento vivo. Debe ser la
consulta para proyectar cada nueva integración y revisó periódicamente o
siempre que exija.
El alcance de la arquitectura inicial de integración, la definición del proyecto
para último no más que de dos a tres meses. Asegúrese todos los
depositarios de una apuesta tienen entrada a la definición y repase la
especificación de la arquitectura. De otra manera, la arquitectura quizá sea
saboteada. Planee mundialmente, el instrumento localmente. Diseño para el
uso repetido. Medida y uso repetido de manejo. Ponga en práctica las
métricas de calidad para justificar las inversiones de infraestructura.

Pasos próximos
La arquitectura técnica de integración proporciona el marco para escoger las
tecnologías de infraestructura para las soluciones discutidas en la parte III
del libro. Ésos mirando a poner en práctica las soluciones tácticas será
tentar al salto allí inmediatamente. Sin embargo, las compañías desean
aumentar al máximo agilidad de negocio, vuelva a usar, y retorne en
inversión, desee completar la integración de la arquitectura de la empresa
por definir la arquitectura de integración de servicio (Cap 7), arquitectura de
integración de información (Cap 8), y la arquitectura de integración de
proceso (Cap 9).

27