1. FACULTAD DE ADMINISTRACIÓN
LICENCIATURA EN SISTEMAS COMPUTACIONALES
ADMINISTRATIVOS
DR. CARLOS ARTURO TORRES GASTELÚ
SOLUCIONES INTEGRALES EN LAS ORGANIZACIONES
“INTEGRACIÓN DE ARQUITECTURA TÉCNICAquot;
FUENTE: GOLD-BERNSTEIN & RUH
EQUIPO # 6
AGUILAR PALACIOS LIZBETH
RIVERA OCHOA JULIETA FARINA
ROMERO VELÁZQUEZ YORELI
801-S
H. VERACRUZ, VER., 25 DE MARZO DEL 2009.

2. VISIÓN GENERAL DE EJECUTIVO
La integración Arquitectura Técnica de la empresa representa los códigos de construcción
para todos los proyectos de integración. Es la especificación de que todos los proyectos de
integración de referencia la hora de elegir la tecnología para su aplicación. La arquitectura
y el diseño incluye orientación restricciones sobre cómo deben desarrollarse las
aplicaciones.
Por lo tanto, la especificación debe ser minuciosa para definir todos los aspectos de la
arquitectura de integración, y de fácil acceso, de modo que la información puede ser
fácilmente encontrada y entendida. Si bien en muchos casos las descripciones detalladas
son necesarias y adecuadas, también recomendamos el uso de gráficos y tablas resumen
para presentar la información. Cada una de las arquitecturas de la solución presentada en la
Parte III de este libro se basa en la especificación de esta arquitectura, y es un subconjunto
de esta especificación. Creación de una Arquitectura de Integración de Especificaciones
guiará muchas aplicaciones de soluciones de TI para garantizar la operatividad entre
palanca y la reutilización. Por ejemplo, el Estado de Florida ha creado un conjunto de
directrices para la integración de la arquitectura, se describe en el Estudio de caso 6.1
(Estado de la Oficina de Tecnología del Estado de Florida de 2003).
La Arquitectura Técnica de Integración debe ser impulsada por los requerimientos del
negocio. Con el tiempo, una gran organización puede necesitar de un todo. Si bien las
necesidades empresariales actuales deben conducir y las necesidades de infraestructura.
6.1 ESTUDIO DE CASO
ESTADO DE LA FLORIDA: LA INTEGRACIÓN DE LA EMPRESA
RECTORES ARQUITECTURAS
La complejidad de cualquier gobierno estatal a menudo no es entendida por aquellos en el
exterior. Sin embargo, con múltiples departamentos, grandes presupuestos, los cambios en
los presupuestos, nuevas leyes, cambios en los políticos, y otras prioridades, es uno de los
más complejos entornos de TI que se puede imaginar. Incluso con el advenimiento del
estado Clos, todavía hay un entorno de TI altamente distribuido en los estados para
arquitecturas incompatibles, dificultad en el intercambio de información, y la duplicación
de esfuerzos.
El Estado de Florida ha sido un líder en la organización de las funciones del Estado y los
activos de TI. Se ha reconocido la necesidad de mejorar el enfoque de la arquitectura de
integración de la empresa dentro del estado. Su estrategia se basa en patrones de diseño y
reutilización de componentes, junto con un enfoque práctico.

3. Se ha dado orientación para incorporar el enfoque en la búsqueda de aprobación de
cualquier proyecto:
• Demostrar la comprensión del problema de dominio en el contexto de los objetivos
del Estado. Línea de base de lo que el sistema se hace y por qué es necesario.
• Compruebe el sentido de los datos. Identificar la localización de datos, flujos, y los
metadatos.
• Hacer sentido de los procesos. Crear modelos de procesos.
• Identificar las interfaces de la aplicación. Identificar o crear interfaces.
• Identificar los eventos. Identificar eventos de negocios que activan las acciones.
• Identificar escenarios de transformación de datos. Mapa de los formatos de datos
entre sistemas.
• Mapa Mapa circulación de información entre sistemas de información.
• Aplicar la tecnología. Seleccione la tecnología,
• Test. Crear un plan de prueba.
• Considerar el desempeño. Especificar las características de rendimiento.
• Definir el valor. Definir el retorno de la inversión.
• Crear los procedimientos de mantenimiento. Identificar los procesos operativos y
procedimientos.
Mediante la creación de esta guía, que proporcionan una estructura para mejorar el estado
de cómo están organizados los sistemas y la mejora de la capacidad de integrar y reutilizar
los componentes en el futuro. Este es un paso clave hacia la consecución de una
arquitectura de integración de la empresa.
Implementaciones, la arquitectura debe tomar decisiones y la adaptabilidad de las
necesidades futuras en cuenta. Debe definir los siguientes:
• común, reutilizables empresa los servicios de dominio que puede soportar múltiples
aplicaciones
• común, normalizado de los servicios técnicos que puedan apoyar cualquier estilo de
integración, tales como servicio, información o proceso orientada.
• los niveles de servicio que debe ser apoyado
• Un marco de seguridad basado en un articulado claramente en toda la empresa
política de seguridad
• Centrarse en la capacidad de apalancamiento existente (herencia) los sistemas de
información y sistema de productos comerciales empaquetados para ofrecer una
porción significativa de la funcionalidad de la aplicación.
En algunos casos, la arquitectura técnica esfuerzo se centrará en reducir el número de
despedidos tecnologías. La actual arquitectura de integración de la evaluación (capítulo 5),
prevé una gran cantidad de información para impulsar la arquitectura decisiones.

4. 6.2 Integración de la Arquitectura Técnica de Especificaciones
Como se señaló anteriormente, la técnica proporciona la arquitectura de integración de los
códigos de construcción para la integración de infraestructura. Proyecto a nivel de la
adhesión a esta arquitectura garantiza que haya coherencia, la reutilización, y el beneficio
económico a la organización para las inversiones en tecnología de integración. Esta
adhesión se puede lograr a través del diseño de evaluación, como se explica en la sección
de Arquitectura de Gobierno Capítulo 4. Véase el Apéndice D de la especificación
completa plantilla.
6.2.1 Introducción
Esta especificación representa la arquitectura de integración de la empresa especificación
técnica. Este documento se utilizará para orientar todas las decisiones y diseños
relacionados con la integración en la organización. Se define el alcance de la integración de
la arquitectura, los proveedores preferidos y las tecnologías, las normas y de la empresa. Al
crear la introducción, el esquema de toda la empresa todas las decisiones de los lectores el
documento debe ser consciente de, y llamar la atención sobre apéndices, como se
referencias y normas de gobernanza.
6.2.2 Ámbito de aplicación
Definir el alcance de la arquitectura de integración. Se debe abordar si se trata de toda la
empresa o limitarse a una determinada organización o clase de aplicaciones. Otras áreas
para hacer frente a determinados tipos de integración (datos, aplicación o proceso), las
limitaciones y las razones de las limitaciones. El alcance también deben indicar qué tipos
de aplicaciones externas están cubiertas, incluida la de si la solicitud fuera del ámbito de la
empresa es un candidato para la conexión a aplicaciones empresariales. Este será el caso si
la organización tiene la cadena de suministro o comercio electrónico iniciativas previstas.
6.2.3 Los participantes clave
Definir el público y los principales interesados. El público debe incluir a todos los
miembros de la organización de TI, sin embargo, debe explícitamente lista los títulos o
funciones específicas que se aplicarán a la integración en la ejecución normal de sus
puestos de trabajo. Los principales interesados deben incluir la TI y los ejecutivos
responsables de mantener el documento.
6.2.4 Requisitos de la Arquitectura de Integración
Esta sección se basa en las necesidades capturadas en el capítulo 2, así como la integración
en curso de evaluación. La integración Arquitectura Requisitos sección incluye los
requisitos para los tipos de servicios de integración y tecnologías que serán parte de la

5. infraestructura y los servicios que se define lo que debe utilizarse para los diferentes tipos
de aplicaciones, las aplicaciones que necesitan ser integrados entre sí, y los tipos o estilos
de la integración que se utilizarán en toda la empresa.
6.2.4.1 Tipos de Integración
La organización debe comenzar esta especificación mediante la identificación de los tipos
de la integración que necesitan apoyo (véase la Figura 6-1). Los datos de la estrategia de
negocio y los requisitos recogidos en el capítulo 2 y en el Capítulo 3, junto con la
evaluación que se describe en el capítulo 5 guías de esta actividad. Ayuda a definir los
requisitos conocidos para este tipo de integración a fin de determinar el alcance de la
inversión. Por ejemplo, si hay una serie de aplicaciones que requieren proceso de
integración y, a continuación, la organización debería considerar la posibilidad de una
empresa una licencia para la solución de BPM.
6.2.4.2 Integración de Servicios y Tecnologías
Como se señaló anteriormente, la arquitectura de integración está compuesta por una serie
de servicios de integración, y estos servicios pueden ser implementados con diferentes.
Aplicación interna Conectividad simple, aplicaciones que requieran este
requisitos de integración enrutamiento inteligente, la nivel de integración
traducción y la transformación,
la aplicación de interfaces /
adaptadores
Legado requisitos de Mainframe, la costumbre o las aplicaciones que requieran este
integración aplicaciones de la ERP. nivel de integración
Clientes, socios, EDI, la costumbre o servicios aplicaciones que requieran este
proveedores (B2B), los B2B nivel de integración.
requisitos de integración
Compuesto de los requisitos Aplicaciones compuestas, SOA. aplicaciones que requieran este
de integración novedad nivel de integración
Portal de integración de Portal Integrado aplicaciones que requieran este
requisitos nivel de integración
la formación de los Lote, en tiempo real, aplicaciones que requieran este
requisitos de integración volúmenes, programación, nivel de integración
información estructurada y no
estructurada

6. Proceso de integración de BPM, BAM, y aplicaciones de aplicaciones que requieran este
requisitos flujo de trabajo nivel de integración
Figura 6-1 Tipos de Integración
Tecnologías. En lugar de dejar que la unidad de selección de productos de arquitectura, la
arquitectura debe basarse en un marco que engloba todos los aspectos necesarios para la
integración de esa organización. La arquitectura se construye con existentes o nuevos
productos. Además, la arquitectura está construida sobre los principios de la organización y
no de los productos seleccionados. Por ejemplo, las empresas de embarcarse en el camino
de SOA pueden definir su arquitectura como una serie de servicios. Figura 6-2 muestra los
diferentes tipos de servicios de integración, y las tecnologías que pueden utilizarse para
ejecutar el servicio. Como se señala más adelante, puede haber un número de tecnologías
utilizadas para poner en marcha un servicio, debido a las diferentes tecnologías son
adecuadas para los diferentes tipos de aplicaciones. Distintas tecnologías de aplicación el
mismo servicio no siempre significa la redundancia en caso de las tecnologías entregar el
mismo servicio a los diferentes tipos de aplicaciones.
Figura 5-3 (página 81), que fue construido durante la evaluación de la arquitectura actual y
muestra los productos existentes en la organización, se utiliza como base para determinar si
el proveedor preferido o la tecnología que está instalado actualmente.

8. Integración Tecnología de Uso recomendado Preferencia Actualmente
de servicios integración Vendedor / instalados?
Tecnología
Procesos de BP IV Modelado, ejecución y Nombre del Si o No
integración gestión de procesos proveedor, el
empresariales integrados nombre del
producto
BAM Seguimiento en tiempo real Nombre del Si o No
de los procesos y guión ¬ proveedor, el
juntas; puede ser parte de nombre del
la herramienta BAM producto
B2B B2B servidores Utilizados para la Nombre del Si o No
integración integración con socios y proveedor, el
proveedores, construir nombre del
comunidad on-line. Se producto
integra con aplicaciones de
back-end a través de
adaptadores o servidores
EAI
EDI Utilizado para los grandes Nombre del Si o No
socios, las soluciones EDI. proveedor, el
Usado con VAN nombre del
producto
XML Utilizados para el envío de Nombre del Si o No
mensajes a los socios a proveedor, el
través de Internet nombre del
producto
Servidores web Utilizarse como una Nombre del Si o No
interfaz proveedor, el
nombre del
producto
Integración Servidores de Entrega de información a Nombre del Si o No
móvil integración diferentes dispositivos proveedor, el

9. móvil móviles de información nombre del
común y las reglas de producto
negocio
Seguridad La integración Integra diferentes sistemas Nombre del Si o No
integración de servidores de de seguridad proveedor, el
seguridad nombre del
producto
Figura 6-2 (cont.)

11. 6.2.5 Descripción de la Arquitectura de Integración
Descripción de la Arquitectura contiene dos vistas diferentes: el conceptual y el desarrollo
opinión. La vista conceptual proporciona el panorama general de la empresa de integración
de infraestructura y los tipos de servicios que serán prestados. La visión de desarrollo
contiene información de interés para los desarrolladores que utilizan la arquitectura. En la
parte III de este libro se describen las pautas específicas de integración y cómo utilizar los
servicios de integración de la Arquitectura Técnica.
6.2.5.1 Visión conceptual
La arquitectura conceptual se destina a dar el panorama de la arquitectura de integración.
No hay manera correcta o una forma de desarrollar este esquema. Se trata de un dibujo
conceptual. Es necesario transmitir todos los componentes de la infraestructura, cómo se
interrelacionan, y cómo se relacionan con los otros componentes de la empresa. De hecho,
puede haber varios puntos de vista conceptual para ilustrar una serie de desmayos en la
arquitectura.
La arquitectura conceptual debe incluir los tipos de aplicaciones o sistemas que conectarse
a través de la integración de arquitectura, ¿qué tecnologías se utilizan para la integración, la
forma en que la arquitectura técnica será utilizada por los portales y en la red corporativa y
conectividad externa, así como cómo los usuarios interactúan con los las aplicaciones
resultantes. La arquitectura conceptual debe ser un diagrama que se puede utilizar para
explicar la arquitectura a la gestión y el personal. No va a ser satisfactorio para el personal
técnico profundo, pero puede ser usado para explicar los 10 usuarios de negocios la forma
en que la infraestructura se utiliza.
La parte III del libro contiene las pautas y los diagramas de arquitectura de referencia para
diferentes soluciones de integración. Sin embargo, las grandes empresas pueden tener una
combinación de requisitos de integración. A continuación se presentan dos ejemplos de
diagramas. Figura 6-3 representa una visión simplificada de la superposición de servicios
de integración ofrecidos. Figura 6-4 (página 99) representa una visión alternativa de la

12. integración de todos los servicios que pueden ser parte de la Arquitectura Técnica de
Integración.
El diagrama debe ir acompañada de una descripción general de los planos de arquitectura,
las descripciones de cada uno de los componentes y las relaciones entre cada uno.
6.2.5.2 Visión de Desarrollo
La visión de desarrollo es una descripción de cómo y cuándo cada una de las diferentes
herramientas e interfaces se utiliza para guiar el equipo de desarrollo utilizando la
arquitectura de integración. Una arquitectura de integración puesto en marcha para apoyar a
los desarrolladores en el rápido desarrollo de nuevas aplicaciones que requieren gran
integración. Diferentes herramientas y enfoques podrían ser empleadas por los
desarrolladores a usar la arquitectura. Para todos y cada uno de los aspectos de la
arquitectura de integración no debe ser una descripción de cómo un desarrollador puede
utilizar los servicios de integración en una aplicación. Esto incluiría las lenguas apoyo y la
manera en que los servicios son accesibles y las capacidades, herramientas para el
desarrollo de cualquier integraciones y herramientas para configuración y administración.
También las interfaces estándar disponibles para su uso debe ser definido. (Ver la Figura
6-5, página 100.)

13. 6.2.6 Normas de Perfil
En esta sección se especifican todas las normas que han sido adoptadas por la organización
que son relevantes para la integración de la arquitectura. La especificación completa debe
incluir también una política de gobierno que define la forma de cumplimiento de las normas
será gestionado, y el proceso y las directrices para la aprobación de soluciones que no
cumplen con las normas. La mayoría de estas normas se refieren a las interfaces, formatos,
mecanismos o las comunicaciones. Normas arquitectónicas están empezando a parecer que
puede tener un impacto mayor en el futuro sobre una arquitectura de integración de la
empresa. Una norma fundamental que hay que vigilar es la Arquitectura Dirigida por
Modelos (MDA) de la norma objeto del Grupo de Gestión. 6.2 Estudio de caso describe las
actividades de MDA (Soley ª).
Tipos de normas que se abordarán en el pliego de condiciones se enumeran en Figura 6-6,
(página 100).

15. Soporte de idiomas <Lista de cómo cada uno de los idiomas es
compatible. Describir la forma de acceso>
Integración de herramientas de definición <Lista de las herramientas empleadas para
crear y gestionar una definición de
integración
Integración de herramientas de apoyo <Lista de las Herramientas utilizadas para
apoyar la gestión y configuración de
integraciones>
Interfaces abiertas Cualquier lista de interfaces abiertas que se
pueden utilizar independientemente de los
idiomas o las herramientas de desarrollo
Figura 6-5 Ver Tabla de Desarrollo
Industria o la tecnología estándar para cada
Protocolos de comunicación tipo de comunicación
Ejemplo: RosettaNet, JMS, etc
Estándar de la industria o la tecnología para
cada tipo de aplicación
Ejemplo: los servicios Web para x tipos de
Interfaces de la aplicación
aplicaciones, empaquetado y adaptadores
para el tipo de aplicaciones. JCA para z tipo
de aplicaciones
Norma de la industria o la tecnología para
cada uno tipo de mensaje
Formatos de mensaje Ejemplo: XML para la mayoría de los tipos
de mes ¬ sabios. Para las transacciones EDI
con grandes socios. etc
Estándar de la industria y la tecnología
Modelos de procesos Ejemplo: Estandarizar en una herramienta de
modelado o de una norma como la BPEL
Normas para diferentes tipos de
metadatos
Metadatos Ejemplo: los metadatos acerca de las
interfaces, servicios Web, transformación de
datos, etc
Figura 6-6 Integración Normas

16. 6.2 ESTUDIO DE CASO
ARQUITECTURA DIRIGIDA POR MODELOS: ¿CÓMO MEJORAR LA
INTEGRACIÓN SE LOGRA
El objeto del Grupo de Gestión se ha embarcado en la creación de las normas relacionadas
con la Arquitectura Dirigida por Modelos (MDA). Esta actividad fue impulsado por un
deseo de proteger las inversiones de software mediante la integración de lo que se ha
construido con lo que van a construir. El objetivo es la especificación de una arquitectura
que puede durar los próximos veinte años. Desarrollo se logra mediante el desarrollo de
modelos de los sistemas que se construirán son comprobables y que puede ser simulado.
Una vez que el modelo es validado, el código se genera en el entorno de destino, que
integra las aplicaciones heredadas y fuera de la plataforma de productos con código
generado.
El proceso para el desarrollo de una aplicación de MDA es el siguiente:
1. Desarrollar una plataforma independiente del modelo que describe la funcionalidad y
comportamiento.
2. Mapa de la modelo a la tecnología middleware objetivo crear una plataforma y modelo
específico.
3. Generar el código de la plataforma modelo para el despliegue.
A través de este enfoque, los sistemas que están muy basados en la integración se pueden
desarrollar más rápidos y más fáciles que es típico de hoy. Además, los OMG se prevé que
a través de la MDA se desarrollarán herramientas para la ingeniería inversa, para generar
modelos de los sistemas existentes para su uso en nuevas aplicaciones. Además, será más
fácil de generar puentes entre aplicaciones tanto dentro como en toda la empresa,
compartiendo la plataforma independiente modelos entre las organizaciones que necesitan
integrar a otros sistemas.

17. 4.2.7 Requisitos de nivel de servicio
Requerimientos de nivel de servicio incluye la disponibilidad, integridad y servicio,
escalabilidad, mantenimiento, gestión, facilidad de uso, y el rendimiento. Transacción, la
persistencia, y servicios de directorio también puede ser necesaria para apoyar el necesario
nivel de servicio. Estos requisitos pueden ser derivados de los requisitos de las aplicaciones
de la sección, o bien ser establecidos por la organización basada en las necesidades de la
empresa.
Cada sección es muy probable necesidad de romper los requisitos de solicitud, así como el
tipo o espacio de integración. Estos requisitos están destinados a ser una guía para el diseño
y la aplicación de la arquitectura de integración. Muchos de estos requisitos serán de alto
nivel y no a un nivel detallado que se producirán con la aplicación de diseño. Necesidades
específicas de las aplicaciones pueden requerir ajustes a la especificación de alto nivel. Es
importante que la organización de tratar la integración de la empresa La arquitectura como
un proceso continúo en lugar de un producto terminado.
6.2.7.1 Disponibilidad
Esta sección recoge los requisitos de disponibilidad, por ejemplo, cuando la integración se
llevará a cabo (en tiempo real o por lotes), las expectativas sobre el acceso al servicio, así
como los parámetros que la arquitectura de integración de las necesidades a satisfacer. Hay
dos tipos de parámetros que se definan con respecto a la disponibilidad: la disponibilidad
del sistema y disponibilidad de la integración. Típico sistema de mediciones de la
disponibilidad de horas de trabajo son la disponibilidad, por lo general se define como 8
horas por día, 5 días a la semana (8 X 5), o la disponibilidad de tiempo completo, definido
como 24 horas al día, 7 días a la semana (24 X 7). Disponibilidad de la integración puede
ser definida como tiempo real o de otro tipo, tales como periódicos o lote. Este parámetro
define cuando la información que se ha integrado está disponible para su uso.

18. 6.2.7.2 La integridad y la entrega de servicios
La integridad de la información integrada se basa en la integridad de la transmisión, así
como la integridad de la información que está siendo procesado. Transmisión integridad
está garantizada por los servicios de transmisión, tales como la entrega garantizada, una vez
y sólo una vez la entrega, y la persistencia de mensaje tiendas. La integridad de los
procesos de información depende de la validez de la traducción y el proceso de
transformación, así como el tratamiento de la información por el sistema de destino. Este
parámetro puede ser medido en los índices de error, y se refiere tanto a la calidad y el costo
del sistema.
6.2.7.3 Escalabilidad
La escalabilidad es un gran factor de la capacidad de planificación y compra. La
escalabilidad de los requisitos debe ser definidos para las necesidades previstas de la
organización tanto en el corto plazo y largo plazo. Requisitos de escalabilidad puede ser
definido por los siguientes parámetros:
• Cantidad de la información se transmita a
• Tasas de transacción (tiempo / volumen)
• Número de solicitudes que deben integrarse
• Conexiones simultáneas de usuarios finales
6.2.7.4 mantenimiento y administración
Mantenimiento y la capacidad de gestión se refieren a las características operativas de la
arquitectura. Esta parte de la especificación define los servicios específicos requeridos.
También definir los requisitos para integrarse con el entorno operativo actual, por último,
identificar todas las limitaciones de mantenimiento, tales como aplicaciones Abt están
migrando a plataformas diferentes, o se están quot;sunsettedquot;.
Mantenimiento y gestión de requisitos pueden ser definidos por los siguientes servicios:
• Vigilancia y alerta

19. • de inicio, cierre y reinicie
• Solución de problemas y el nivel de apoyo al mantenimiento del código y el uso de
herramientas
• Instalación y gestión de liberación de las actualizaciones y la capacidad de revertir la
• Sheduling
• Integración con las herramientas existentes
Después de determinar los requisitos, se recomienda que se resuman a los efectos de la
planificación empresarial. Asignación de un requisito de calificación de gestión a cada
solicitud o proyecto puede hacer esto. Esta calificación se presenta un resumen de la
opinión de todos los requisitos de gestión. La siguiente clasificación se puede utilizar:
œ Nivel 1. De inicio, cierre y reinicie, la solución de problemas, la programación de
instalación remota
€ Nivel 2. Nivel 1, más actualizaciones y rollbacks, integrada de la aplicación del
repositorio
f Nivel 3. Nivel 2 y seguimiento en tiempo real y alertas, la plena integración y desarrollo
de herramientas de gestión

20. 6.2.5 Usabilidad
Usabilidad se refiere a la facilidad con cada tipo de usuario utilizará el sistema. Definición
de todos los tipos de usuarios de la red, junto con el tipo de acceso y facilidad de uso que
necesitan, las herramientas y ayuda a determinar las necesidades de las aplicaciones. Figura
6-7 (página 104) ofrece un plantilla para determinar los requisitos de usabilidad. Este
cuadro puede ser modificado o ampliado según se requiera.
Tipo de Usuario Requisitos de usabilidad
Desarrolladores <J2EE,. NET, servicios J2EE y / o. NET programación, interfaces de
Web, legado, la integración se especializan programación de servicios Web>
Analista Modelado de la interfaz
Diseñador Modelado y configuración de la interfaz
Línea de los directores de empresa Portal basado en navegador o el tablero de
instrumentos, en tiempo real de alertas
Otros asuntos de usuario Basada en navegador del portal, alertas en tiempo
real
Gerentes operativos Interfaz con herramientas de gestión, la interfaz
de portal de la situación operacional, en tiempo
real de alertas
Figura 6 -7 Usabilidad Tabla Requisito
6.2.7.6 Rendimiento
Requisitos de desempeño definir el nivel de servicio de las necesidades de infraestructura
para prestar apoyo a los usuarios de negocios, procesos y operaciones. Requisitos de
desempeño se utilizan también en la capacidad de planificación de vista (véase la Figura
6-8).
Un número de diferentes tipos de mediciones pueden incluirse en los requisitos de
rendimiento. Tiempo de respuesta es la esperada o aceptable para el tiempo Usuarios o
aplicaciones a la espera de una respuesta del sistema. Puede ser medido; en el sub-segundos
(tiempo real), minutos, horas o días. El rendimiento es Ac cantidad de información que se
pueden enviar a través del sistema dentro de una cierta cantidad de tiempo. Puede medirse
en número de transacciones o del volumen de datos. El tiempo es la cantidad de tiempo

21. necesario para que todo el proceso para completar, pueda ser medido en segundos, minutos,
horas o días. Número de usuarios simultáneos determina el número de conexiones en vivo o
sesiones el sistema de apoyo. Número de aplicaciones conectadas refiere al número de
aplicaciones integradas que pueden enviar o recibir información a través del sistema.
Tiempo de respuesta En tiempo real, minutos, horas, días
Rendimiento Número de transacciones, los volúmenes de datos
El tiempo de Segundos, minutos, horas, días
Número de usuarios simultáneos Subtotales por tipos de usuarios definidos en la
usabilidad
Número de aplicaciones conectadas Nombre de todas las aplicaciones que se integrarán
Servicios de transacciones
Servicios de transacciones distribuidas de transacción incluyen el apoyo y el cumplimiento
de transacciones XA estándar. Esta información determina cómo se gestionará las
operaciones y la forma en la integridad transaccional se mantendrá. Esta sección también
define los requisitos para el apoyo a la industria y las normas reglamentarias, tales como
RosettaNet, HIPAA, u otras transacciones estándar de la industria.
6.2. 7.8 Persistencia de Servicios
A menudo es necesario persistir o almacenar datos para su uso en el futuro durante un
proceso de integración. La persistencia es necesaria para mejorar la fiabilidad cuando se
estaba recuperando de un dure. Ser capaz de reiniciar un sistema fracasado, sin perder en
cualquier proceso de integración es el uso más básico de una persistencia sen-hielo. Sin
embargo, hay numerosos • (sus usos para este tipo de servicio. Otros tipos de usos de los
datos persistentes incluyen la capacidad de revertir cualquier acción, realizar auditorías de
la actividad, o utilizar el 4ata recogidos para analizar la actividad en la infraestructura. En
esta sección se definen aneats los requisitos para proporcionar el almacenamiento de datos

22. y la integración de información de estado durante y después de cualquier uso de la
infraestructura de integración.
6.2.7.9 Servicios de directorio
Se ha convertido en una buena práctica en los modernos sistemas distribuidos para
proporcionar la capacidad de los servicios de directorio. Directorios proporcionar varias
capacidades fundamentales para la infraestructura. Que pueden proporcionar la ubicación
de transparencia al permitir a aplicaciones de quot;encontrarquot; otras aplicaciones para la
integración. Esto reduce la necesidad de codificar la información de localización en la
aplicación, y aumenta la capacidad de adaptación debido a que un cambio de ubicación no
exigiría cambios en otras aplicaciones. Además, los directorios se pueden utilizar para
almacenar información de configuración de los recursos o los usuarios que puedan ser
utilizados por cualquier aplicación o proceso de integración.
Por último, un directorio puede ser usado para almacenar la información de seguridad. Este
uso será examinado con más detalle en la sección sobre seguridad.
En esta sección, definir los requisitos para servicios de directorio. Esto incluye la capacidad
para registrar cualquier quot;componentequot; del sistema, incluidos servidores, interfaces de
servicio, esquemas, u otros tipos de información.
Figura 6-9 es un ejemplo de una sencilla configuración de un directorio que puedan existir.
Los campos obligatorios son el nombre y la ubicación. El tipo y la descripción son útiles en
un sistema que funcione. Otros campos pueden ser añadidos para componentes específicos.
6.2.7.10 Cuadro Resumen de nivel de servicio
El Cuadro Resumen de nivel de servicio (Figura 6-10) es útil para mostrar una vista global
de requerimientos de nivel de servicio.

23. 6.2.8 Seguridad
La seguridad es un tipo de servicio a nivel de exigencia, pero es un tema tan importante y
un tema altamente especializado que es tratado por separado. La especificación debe
comenzar con un resumen de la parte superior de seguridad a nivel de las necesidades por
las categorías o tipos de aplicaciones que serán la utilización de la arquitectura. Esto puede
hacerse de manera general como se muestra en la Figura 6-11 (página 108), pero es más
eficaz si se puede definirse específicamente.
Nombre Tipo de Ubicación Descripción Otros campos
componente componente de
Nombre Nombre Ubicación Descripción <valor>
componente componente
Nombre Nombre Ubicación Descripción <valor>
componente componente
Figura 6-9 Cuadro de servicios de directorio
Tipo de aplicación o Nombre de la Nombre de la
Nombre aplicación aplicación
Disponibilidad Tiempo real o por lotes;
8x5 o 24x7
Integridad y servicio Garantizada, una vez y
de entrega sólo una vez; mensaje
tiendas
Escalabilidad Conexiones, lugares
transacciones, los
volúmenes de datos
Mantenimiento y Nivel 1, Nivel 2, Nivel
gestión 3

24. Usabilidad Desarrolladores,
analistas, diseñadores,
directores de LOB,
otros usuarios de
negocios, gerentes
operativos
1 El rendimiento Tiempo de respuesta,
rendimiento,
simultánea usuarios.
Servicios de Transacciones ...
transacción distribuidas, compatible
con XA, HIPAA, otros
Persistencia Almacenamiento de ...
datos e integración de
información para la
recuperación,
reproducción y análisis
Servicios de información acerca de ...
directorio todos los componentes
de la infraestructura de
integración>
Figura 6-10 Cuadro Resumen de nivel de servicio

25. Confiden No
Autenticación Autorización Auditoría
cialidad Reputación
Datos Internos ■
Los datos de los Asociados ■ ■ ■
Datos del cliente ■ ■ ■ ■
Aplicación interna ■ ■
Aplicación de los socios ■ ■ ■
Datos de los asociados ■ ■ ■ ■ ■
Procesos internos
Procesos de los asociados ■ - ■ ■
Procesos de los clientes ■ ■ ■ ■ ■
Figura 6 - 11 Cuadro de Seguridad
6.2.8.1 Autenticación
Servicios de autenticación de confirmar la identidad de un usuario. Una definición detallada
de los requisitos de autorización de servicio incluye lo siguiente:
• Lista de los tipos de usuarios. Tipos de usuarios que se correlacionan con los tipos de
aplicaciones o servicios de un grupo de acceso. Los ejemplos incluyen: los diseñadores,
programadores, administradores, usuarios de línea de negocio, clientes y socios.
• Nivel de autenticación para cada tipo de usuario o función. Los niveles de autenticación
pueden incluir: la contraseña, con contraseña pública / clave privada de encriptación,
certificado digital, y datos biométricos.
• Si unitario contará con el apoyo de acceso. Unitario si se define la lógica de autenticación
se puede realizar una vez por todas las aplicaciones y servicios. Esto requiere un directorio
centralizado para todos los servicios.
• Definición de cuentas de usuario cómo se gestionará. Cuentas de usuario debe ser creado
y constantemente actualizada sobre la base de los cambios que ocurren en el negocio. Es
importante tener un proceso formal definido sobre cómo esta información se mantendrá
sincronizada.

26. 6.2.8.2 Autorización
Determinar qué niveles de autorización de operaciones de un usuario o proceso está
autorizado a realizar en un conjunto de datos o dentro de una aplicación. En esta sección se
definen las categorías de autorización, sobre la base de aplicación y / o sensibilidad de los
datos (ver Figura 6-12). Autorización se define generalmente en una matriz CRUD que
define los derechos para crear, leer, actualizar o eliminar información.
6.2.8.3 Seguridad Perimetral
En esta sección se debe abordar la manera en que la arquitectura de integración de trabajo
con la seguridad del perímetro y los tipos o categorías de integración que será necesaria
para utilizar el perímetro de seguridad. Perímetro de seguridad es la combinación de
servidores de seguridad, cifrado, autenticación de los servicios, y la arquitectura utilizada
para proteger a la empresa desde el mundo exterior. La configuración del perímetro de
seguridad se dicta el diseño de la arquitectura de integración de lo que se refiere a uso
externo.
6.2.8.4 Auditoría
En esta sección se definen las categorías de la auditoría basado en el tipo de aplicación y la
sensibilidad de los datos procesados. Categorías básicas de la auditoría son:
• Nivel 0. Mantener ninguna información
En los casos en que no hay preocupación acerca de las interacciones a causa de otros
factores relacionados con la confianza, Nivel 0 se puede utilizar, y no se realizó la
auditoría.
• Nivel 1. Mantener la información sobre el tipo de interacción y de los participantes
En los casos en que los detalles no son necesarios y sólo el conocimiento de que una
interacción se ha llevado a cabo es necesario, Nivel 1 sería aplicable. Esto sería utilizado en

27. los casos en que un retroceso no es posible o necesario, pero sólo el hecho de que se llevó a
cabo una interacción es necesario.
Aplicación 1 Aplicación 2 Aplicación 3 Aplicación 4
Rol de usuario # <C. R. U. D> <R, U> <R. U> <R>
1
Rol de usuario # <R> <C, R, U. D> <R. U> <R. U>
2
Rol de usuario # <R> <R> <C, R. U, D> <R>
3
Rol de usuario # <R> <R, U> <R. U> <C. R, U. D>
4
Figura 6 - 12 Solicitud de autorización de la tabla
• Nivel 2. Mantener únicamente las instrucciones para cada interacción
Nivel 2 se utiliza para examinar los tipos de interacciones que se han producido y observa
conductas raras o comprobar que se produjo una interacción. Esto puede ser utilizado para
verificar que un empleado ha efectuado una operación no autorizada en el sistema y
disponer de la información para revertir la acción.
• Nivel 3. Mantener un conjunto completo de información en cada interacción
El nivel 3 se utiliza en los casos en que las interacciones son muy sensibles y la prueba de
la interacción o la necesidad de cada auditoría es necesaria la interacción. Auditoría
completa puede ser necesario en los casos de importantes operaciones financieras, por
ejemplo.
Rendimiento y las necesidades de recursos son las ventajas de hacer una distinción entre
cada nivel. En caso contrario, si el rendimiento y los recursos son gratis, entonces el nivel
cuatro que siempre se han de aplicar. En muchos casos, esto puede no ser viable.
6.2.8.5 Confidencialidad

28. La confidencialidad se refiere al nivel de intimidad que requiere una transmisión.
Confidencialidad se aplica en general al nivel de cifrado que se aplica. Sin embargo,
también podría reflejarse en el camino de comunicación que se utiliza. Por ejemplo, si un
alto grado de confidencialidad es necesario, la interacción puede ser dirigida a un costo más
elevado línea dedicada en lugar de seguir un camino que utiliza una conexión a Internet. En
términos generales, cuando el uso de la codificación, mayor es el nivel de confidencialidad,
el más lento el tiempo de respuesta. Sin embargo, al examinar los canales de comunicación,
el mayor grado de confidencialidad, la más cara de las comunicaciones. Rendimiento, costo
y seguridad son a menudo compensaciones.
6.2.8.6 No reputación
No reputación es sumamente importante para las operaciones B2B. Se asegura de que una
petición o una orden no pueden ser repudiadas más tarde. No reputación servicios son
necesarios para garantizar la validez y ejecutabilidad de los contratos electrónicos. La
especificación debe definir el nivel de servicio requerido No reputación, y que los tipos y
categorías de las aplicaciones lo requieran (Figura 6-13). Tipos de No reputación incluyen:
• No reputación sesiones de comunicaciones. Los criterios de valoración en la
comunicación período de sesiones, como una sesión de SSL, el intercambio de fichas que
les identifique de forma exclusiva. Este tipo de No reputación confirma que se llevó a cabo
una sesión, pero No validar la información específica que se intercambió en la sesión, ya
que no obligar a la sesión permanente a los contenidos el iniciador o el destinatario.
• No reputación servicios de middleware. Interacciones entre los servicios de middleware
incluir un signo que valida la autenticidad del servicio. Interacciones están bien y con
marca de tiempo registrado. Este tipo de No reputación valida una interacción que se llevó
a cabo, pero no específica que se intercambió información en la interacción.
• No reputación transacciones. La operación se acompaña con una muestra que valida su
autenticidad y la operación es el tiempo-sellado y conectado. Este tipo de No reputación
valida que la operación se llevó a cabo, pero no lo fue procesado de datos específicos en la
transacción.

29. Tipo de No reputación Tipo de Aplicación
No reputación sesiones de comunicaciones Simple integración de las aplicaciones o el
intercambio de datos entre aplicaciones.
No reputación servicios middleware Integraciones que son las interacciones con
una infraestructura de middleware.
No reputación transacciones Procesamiento de transacciones.
No reputación aplicación de medidas Complejos procesos de negocio
consistentes transacciones múltiples
Figura 6 – 13 Cuadro de Nonrepudiation
No reputación aplicación consta de múltiples acciones de las transacciones. El usuario final
de la intención de tomar la acción se registra, la solicitud única son las acciones e
irrefutable trazabilidad para el usuario, y las acciones están bien con marca de tiempo y de
forma segura conectado. Esto confirma que los participantes la intención de participar en la
acción, valida su identidad irrefutable, irrefutablemente se asocia el tiempo de la acción con
esta información, y proporciona no reputación que todo el proceso se completó.
6.2.9 Capacidad de Planificación de Ver
Esta sección (Figura 6-14, página 112) especifica el diseño de criterios para alcanzar los
requisitos de las aplicaciones se definen en la sección de nivel de servicio. El objetivo es
definir la forma en todos los requerimientos de nivel de servicio se sufragarán incluyendo
tecnologías, políticas y procedimientos.
Requerimientos Enfoque de diseño

30. Disponibilidad Back-up y planes de recuperación, redundancia
plan de conmutación por error, el desastre del
sitio, etc
Tiempo de respuesta Ancho de banda de red, acceso de alta velocidad,
acceso localizados, optimizado las interacciones
humanas, la aplicación de optimización de
rendimiento, optimización de bases de datos
Rendimiento Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
capacidad de almacenamiento.
Los tiempos de Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
alertas en tiempo real
Número de usuarios Conexión de la gestión, el almacenamiento en
caché, la localización de acceso redundante a
través de las tiendas, la optimización de las
interacciones humanas, el rendimiento de las
aplicaciones, optimización de bases de datos
Número de aplicaciones conectadas Punto a punto de integración, servidor de
integración, integración de los servidores
distribuidos
Servicios de transacción operación de seguimiento, servicios de
transacciones dentro de la aplicación, otros
Persistencia Sistemas de almacenamiento, recuperación y
capacidades de reproducción, los instrumentos
analíticos
Servicios de directorio Servidor de directorio, herramientas
administrativas
Figura 6 - 14 Capacidad de Planificación de la tabla
4.2.10 Limitaciones del diseño y de Orientación

31. Todas las limitaciones y directrices específicas para los arquitectos, diseñadores,
desarrolladores y definido en este momento. Este es un tema que es ilimitado. Sin embargo
las áreas a considerar en la fijación de limitaciones y la orientación son
• Conozca las limitaciones de rendimiento.
• Formateo de datos directrices.
• Limitaciones en el registro de metadatos y definiciones.
• Preferencia en el uso de diferentes tipos de interfaces.
• Casos de implementación de seguridad.
• Desviaciones permitido la integración de la arquitectura.
Esta sección será muy probablemente muy limitado al principio, pero como el uso de la
arquitectura lleva a una mejor comprensión y conocimiento de lo que funciona o no, que
crecerá más de la cal.
6.2.11 Conclusiones y comentarios
La sección final de la Arquitectura de Integración de Especificaciones resume cualquier
aspecto o las decisiones relativas a la arquitectura de integración. Estos pueden incluir sin
resolver soluciones a necesidades específicas. Esto podría ser un buen lugar para el
ejecutivo de administración de TI para proporcionar orientación sobre las expectativas de la
integración de la arquitectura, la manera en que afectan a la organización, y lo que se espera
del personal. Por último, podría incluir la discusión sobre dónde va la arquitectura en el
futuro.
6.3 Buenas Prácticas en la Integración de Arquitectura Técnica

32. • Hacer la arquitectura de un documento de especificación. Debe ser consultado para cada
nuevo proyecto de integración y revisar periódicamente, o cuando sea necesario.
• No hervir el océano primera vez a cabo. Ámbito de aplicación inicial de la arquitectura de
integración de definición del proyecto a la última no más de dos a tres meses.
• Asegúrese de que todas las partes interesadas han de entrada a la definición y revisión de
la especificación de arquitectura. En caso contrario, la arquitectura puede ser saboteada.
• Plan a nivel mundial, la aplicación a nivel local.
• Diseño para su reutilización.
• Medida y gestión de la reutilización.
• Implementar la calidad de las cifras para justificar las inversiones en infraestructura.
6.4 Próximos pasos
La Arquitectura Técnica de Integración proporciona el marco para la elección de
infraestructura de tecnologías de las soluciones examinadas en la Parte III del libro.
Aquellos que buscan implementar soluciones tácticas será la tentación para ir allí
inmediatamente. Sin embargo, las compañías que deseen maximizar la agilidad
empresarial, la reutilización y retorno de la inversión, se desea completar la integración de
la empresa Archi ¬ arquitectura mediante la definición de la Arquitectura de Integración de
Servicios (Capítulo 7), Arquitectura de Información de Integración (capítulo 8), el Proceso
de Integración y Arquitectura (capítulo 9).

34. 6.2.9 Capacidad de Planificación de Ver
Esta sección (Figura 6-14, página 112) especifica el diseño de criterios para alcanzar los
requisitos de las aplicaciones se definen en la sección de nivel de servicio. El objetivo es
definir la forma en todos los requerimientos de nivel de servicio se sufragarán incluyendo
tecnologías, políticas y procedimientos.
Requerimientos Enfoque de diseño
Disponibilidad Back-up y planes de recuperación, redundancia
plan de conmutación por error, el desastre del
sitio, etc
Tiempo de respuesta Red de banda ancha, acceso de alta velocidad,
acceso localizados, optimizado las interacciones
humanas, la aplicación de optimización de
rendimiento, optimización de bases de datos
Rendimiento Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
capacidad de almacenamiento
Los tiempos de Ancho de banda de red, acceso de alta velocidad,
el rendimiento de las aplicaciones de
optimización, optimización de bases de datos,
alertas en tiempo real
Número de usuarios Conexión de gestión, el almacenamiento en
caché, la localización de acceso redundante a
través de las tiendas, la optimización de las
interacciones humanas, el rendimiento de las
aplicaciones, optimización de bases de datos
Número de aplicaciones conectadas Punto a punto de integración, servidor de
integración, la integración de servidores
distribuidos
Servicios de transacción operación de seguimiento, servicios de
transacciones dentro de la aplicación, otros

35. Persistencia Sistemas de almacenamiento, recuperación y
capacidades de reproducción, los instrumentos
analíticos
Servicios de directorio Servidor de directorio, herramientas
administrativas.