Your SlideShare is downloading. ×
FACULTAD DE ADMINISTRACIÓN


 LICENCIATURA EN SISTEMAS COMPUTACIONALES
             ADMINISTRATIVOS


     DR. CARLOS ARTU...
VISIÓN GENERAL DE EJECUTIVO

La integración Arquitectura Técnica de la empresa representa los códigos de construcción
para...
Se ha dado orientación para incorporar el enfoque en la búsqueda de aprobación de
cualquier proyecto:

   •   Demostrar la...
6.2 Integración de la Arquitectura Técnica de Especificaciones


Como se señaló anteriormente, la técnica proporciona la a...
infraestructura y los servicios que se define lo que debe utilizarse para los diferentes tipos
de aplicaciones, las aplica...
Proceso de integración de BPM, BAM, y aplicaciones de aplicaciones que requieran este
requisitos                  flujo de...
Integración Tecnología      de Uso recomendado                    Preferencia           Actualmente
de servicios integraci...
móvil              móviles   de   información nombre del
                                común y las reglas de producto
  ...
6.2.5 Descripción de la Arquitectura de Integración


Descripción de la Arquitectura contiene dos vistas diferentes: el co...
integración de todos los servicios que pueden ser parte de la Arquitectura Técnica de
Integración.
El diagrama debe ir aco...
6.2.6 Normas de Perfil


En esta sección se especifican todas las normas que han sido adoptadas por la organización
que so...
Soporte de idiomas                        <Lista de cómo cada uno de los idiomas es
                                      ...
6.2 ESTUDIO DE CASO


        ARQUITECTURA DIRIGIDA POR MODELOS: ¿CÓMO MEJORAR LA
                              INTEGRACIÓ...
4.2.7 Requisitos de nivel de servicio


Requerimientos de nivel de servicio incluye la disponibilidad, integridad y servic...
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...
• de inicio, cierre y reinicie
• Solución de problemas y el nivel de apoyo al mantenimiento del código y el uso de
herrami...
6.2.5 Usabilidad


Usabilidad se refiere a la facilidad con cada tipo de usuario utilizará el sistema. Definición
de todos...
necesario para que todo el proceso para completar, pueda ser medido en segundos, minutos,
horas o días. Número de usuarios...
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...
6.2.8 Seguridad


La seguridad es un tipo de servicio a nivel de exigencia, pero es un tema tan importante y
un tema altam...
Usabilidad            Desarrolladores,
                      analistas, diseñadores,
                      directores     ...
Confiden       No
                            Autenticación    Autorización Auditoría
                                    ...
6.2.8.2 Autorización


Determinar qué niveles de autorización de operaciones de un usuario o proceso está
autorizado a rea...
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 nece...
La confidencialidad se refiere al nivel de intimidad que requiere una transmisión.
Confidencialidad se aplica en general a...
Tipo de No reputación                    Tipo de Aplicación
No reputación sesiones de comunicaciones Simple integración de...
Disponibilidad                           Back-up y planes de recuperación, redundancia
                                   ...
Todas las limitaciones y directrices específicas para los arquitectos, diseñadores,
desarrolladores y definido en este mom...
• Hacer la arquitectura de un documento de especificación. Debe ser consultado para cada
nuevo proyecto de integración y r...
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 al...
Persistencia              Sistemas de almacenamiento, recuperación y
                          capacidades de reproducción...
Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion
Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion
Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion
Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion
Upcoming SlideShare
Loading in...5
×

Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion

724

Published on

Published in: Business, Travel
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
724
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion"

  1. 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. 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. 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. 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. 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. 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.
  7. 7. 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
  8. 8. 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.)
  9. 9. 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
  10. 10. 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.)
  11. 11. 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).
  12. 12. 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
  13. 13. 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.
  14. 14. 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.
  15. 15. 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
  16. 16. • 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
  17. 17. 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
  18. 18. 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
  19. 19. 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.
  20. 20. 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
  21. 21. 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
  22. 22. 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.
  23. 23. 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
  24. 24. 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
  25. 25. 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.
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. • 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).
  30. 30. 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
  31. 31. Persistencia Sistemas de almacenamiento, recuperación y capacidades de reproducción, los instrumentos analíticos Servicios de directorio Servidor de directorio, herramientas administrativas.

×