Your SlideShare is downloading. ×
Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sio2009 Eq6 L8 Tem Gold Bernstein & Ruh Cap6 Integracion

375
views

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
375
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Equipo 6: Aguilar Palacios Lizbeth Rivera Ochoa Julieta Farina Romero Velázquez Yoreli INTEGRACIÓN DE ARQUITECTURA TÉCNICA
  • 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 todos los proyectos de integración a 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.
  • 3. Visión general de ejecutivo
    • 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.
  • 4. Visión general de ejecutivo
    • 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.
  • 5. ESTUDIO DE CASO
    • ESTADO DE LA FLORIDA:
    • LA INTEGRACIÓN DE LA EMPRESA RECTORES ARQUITECTURAS
  • 6. ESTUDIO DE CASO: ESTADO DE LA FLORIDA
    • 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. Se ha dado orientación para incorporar el enfoque en la búsqueda de aprobación de cualquier proyecto.
  • 7. ESTUDIO DE CASO: ESTADO DE LA FLORIDA
    • 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 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.
  • 8. ESTUDIO DE CASO: ESTADO DE LA FLORIDA
    • 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.
  • 9. ESTUDIO DE CASO: ESTADO DE LA FLORIDA
    • Implementaciones, la arquitectura debe tomar decisiones y la adaptabilidad de las necesidades futuras en cuenta. Debe definir los siguientes:
    •  
    • Los servicios reutilizables de la empresa de dominio que puede soportar múltiples aplicaciones.
    • Servicios técnicos normalizados 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.
  • 10. Integración de la Arquitectura Técnica de Especificaciones
    • Representa la arquitectura de integración de la empresa especificación técnica.
    • Se define el alcance de la integración de la arquitectura, los proveedores preferidos y las tecnologías, las normas y de la empresa.
  • 11. Á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 debe 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.
  • 12. 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.
  • 13. Requisitos de la Arquitectura de Integración
    • Los requisitos para la integración de la Arquitectura incluye los requisitos para los tipos de servicios de integración y tecnologías que serán parte de la 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.
  • 14. 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 (Figura 6-1). Los datos de la estrategia de negocio y los requisitos recogidos, junto con la evaluación de las 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.
  • 15. 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 tecnologías.
  • 16.  
  • 17.
    • 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.
    • 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.
  • 18. Integración de Servicios y Tecnologías
    • 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.
  • 19.  
  • 20. Integración de servicios Tecnología de integración Uso recomendado Preferencia Vendedor / Tecnología Actualmente instalados? Procesos de integración BP IV Modelado, ejecución y gestión de procesos empresariales integrados Nombre del proveedor, el nombre del producto Si o No BAM Seguimiento en tiempo real de los procesos y guión ¬ juntas; puede ser parte de la herramienta BAM Nombre del proveedor, el nombre del producto Si o No B2B integración B2B servidores Utilizados para la integración con socios y proveedores, construir comunidad on-line. Se integra con aplicaciones de back-end a través de adaptadores o servidores EAI Nombre del proveedor, el nombre del producto Si o No EDI Utilizado para los grandes socios, las soluciones EDI. Usado con VAN Nombre del proveedor, el nombre del producto Si o No XML Utilizados para el envío de mensajes a los socios a través de Internet Nombre del proveedor, el nombre del producto Si o No Servidores web Utilizarse como una interfaz Nombre del proveedor, el nombre del producto Si o No Integración móvil Servidores de integración móvil Entrega de información a diferentes dispositivos móviles de información común y las reglas de negocio Nombre del proveedor, el nombre del producto Si o No Seguridad integración La integración de servidores de seguridad Integra diferentes sistemas de seguridad Nombre del proveedor, el nombre del producto Si o No
  • 21. 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.
  • 22. conceptual Ver
    • 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.
  • 23.
    • 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 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.
  • 24.  
  • 25.  
  • 26. Visión del 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.
  • 27. 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
  • 28. Normas de Perfil
    • Las normas que han sido adoptadas por la organización que son relevantes para la integración de la arquitectura.
    • 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 de la siguiente manera.
  • 29. Integración de las normas Protocolos de comunicación Industria o la tecnología estándar para cada tipo de comunicación Ejemplo: RosettaNet, JMS, etc Interfaces de la aplicación Estándar de la industria o la tecnología para cada tipo de aplicación Ejemplo: los servicios Web para x tipos de aplicaciones, empaquetado y adaptadores para el tipo de aplicaciones. JCA para z tipo de aplicaciones Formatos de mensaje Norma de la industria o la tecnología para cada uno tipo de mensaje Ejemplo: XML para la mayoría de los tipos de mes sabios. Para las transacciones EDI con grandes socios. etc Modelos de procesos Estándar de la industria y la tecnología Ejemplo: Estandarizar en una herramienta de modelado o de una norma como la BPEL Metadatos Normas para diferentes tipos de metadatos Ejemplo: los metadatos acerca de las interfaces, servicios Web, transformación de datos, etc
  • 30. 6.2 Estudio de Caso
    • Arquitectura Dirigida por Modelos: ¿Cómo se logra Mejorar la integración)
    • 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.
  • 31. 6.2 Estudio de Caso
    • 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 puede desarrollar más rápido y más fácil 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.
  • 32. 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.
    • 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.
    • Estos requisitos están destinados a ser una guía para el diseño y la aplicación de la arquitectura de integración
    • 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.
  • 33. 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.
  • 34. Tipo de aplicación o Nombre Nombre de la aplicación Nombre de la aplicación Disponibilidad Tiempo real o por lotes; 8x5 o 24x7 Integridad y servicio de entrega Garantizada, una vez y sólo una vez; mensaje tiendas Escalabilidad Conexiones, lugares transacciones, los volúmenes de datos Mantenimiento y gestión Nivel 1, Nivel 2, Nivel 3 Usabilidad Desarrolladores, analistas, diseñadores, directores de LOB, otros usuarios de negocios, gerentes operativos El rendimiento Tiempo de respuesta, rendimiento, simultánea usuarios. Servicios de transacción transacciones 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 directorio información acerca de todos los componentes de la infraestructura de integración> ...
  • 35. 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, pero es más eficaz si se puede definirse específicamente.
  • 36. Cuadro de Seguridad Autenticación Autorización Auditoría Confidencialidad No repudiació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 ■ ■ ■ ■ ■
  • 37. Visión de Capacidad de Planificación
    • Esta sección (Figura 6-14),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.
  • 38. 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 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
  • 39. Limitaciones del diseño y de Orientación
    • 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.
  • 40. 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.
  • 41. Mejores Prácticas en la Integración de Arquitectura Técnica
    • 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.
    • Á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 saboteado.
    • 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.
  • 42. 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 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).
  • 43.  

×