Implementación de una visión de arquitectura Experiencias y Resultados

1. Andrés Camilo Bustamante Analista de Arquitectura Gerencia de Desarrollo andrbube@suramericana.com.co Suramericana de Seguros S.A. Implementación de una visión de arquitecturaExperiencias y Resultados

2. Agenda • Visión Inicial • Proceso de conformación del equipo • Experiencias y productos • Arquitectura Inicial • Plataforma de Publicación de Servicios • Logros • Preguntas y Respuestas

3. Visión Inicial • Problemática • Respuestas rápidas a requerimientos del negocio • Ofrecer disponibilidad de soluciones de negocio en cualquier momento, desde cualquier lugar • Aprovechar relaciones de gran valor para el negocio con clientes, socios y proveedores • Facilitar la automatización de procesos de negocio complejos • Proveer seguridad y confiabilidad en las transacciones de negocio • Soportar un gran número de usuarios dificil de medir y que puede crecer a gran velocidad

4. Visión Inicial • Reto • Construir aplicaciones con prácticas de diseño e infraestructura lo suficientemente robustas que nos brinden: • Velocidad (de desarrollo y de ejecución) • Disponibilidad • Confiabilidad • Proyección • Seguridad • Calidad en nuestros productos

5. Visión Inicial • Objetivo General • Definir una Arquitectura eficiente para la construcción de aplicaciones basada en plataformas abiertas y escalables sobre la cual se implementará toda la estrategia de desarrollo informático a largo plazo.

6. Visión Inicial • Objetivos Específicos • Definir las especificaciones: Arquitectura de aplicaciones, de integración y de datos. • Definir la infraestructura: Estándares tecnológicos, plataformas y herramientas. • Definir el esquema de gobierno: políticas y normas, mejores prácticas, esquemas de coordinación y reporte.

7. Agenda • Visión Inicial • Proceso de conformación del equipo • Experiencias y productos • Arquitectura Inicial • Plataforma de Publicación de Servicios • Logros • Preguntas y Respuesta

8. Proceso de Conformación del Equipo

9. Especificaciones • Arquitectura ( Diseño ) • Aplicaciones • Técnica • Modelo de Integración • Modelo de Información • Modelo de Interfaces Gobierno • Coordinación y reporte • Políticas y normativas • Mejores prácticas (Patrones, Frameworks) • Publicación y Documentación Infraestructura • Estándares tecnológicos • Plataforma de integración y Servidor de Aplicaciones • Herramientas y esquemas de administración Proceso de conformación del equipo Equipo de Arquitectura

10. Proceso de conformación del equipo • Iniciativa gerencial • Necesidad evidente en todos los equipos • Definición de perfil de arquitecto • Habilidades • Responsabiliddes • Finalidades • Entorno • Formulación de proyectos

11. Proceso de conformación del equipo • Definición de perfil de arquitecto - Habilidades • Las principales habilidades se deben concentrar en el análisis y diseño de sistemas. • Debe conocer y dominar todos los elementos de la infraestructura tecnológica que tiene a su disposición. • Se debe concentrar en la optimización y reutilización de todos estos elementos de infraestructura en los desarrollos de software de la organización. • Para ello su principal herramienta de trabajo es el uso de patrones de software (patrones de diseño y arquitectura). Estos patrones de diseño se pueden definir como las mejores prácticas que son reconocidas y que buscan solucionar un problema recurrente.

12. Proceso de conformación del equipo • Definición de perfil de arquitecto - Responsabilidades • Definición y desarrollo del marco de referencia técnico dentro del cual se logran satisfacer las necesidades de negocio • Diseño y reutilización de todos los elementos que conforman la arquitectura • Proveer las bases técnicas y administrativas para el diseño y la implementación de sistemas • Soportar el procesos de análisis en los proyectos para mantener una consistencia entre los requisitos y la arquitectura

13. Proceso de conformación del equipo • Definición de perfil de arquitecto - Finalidades • Análisis y diseños de sistemas (evaluaciones de arquitectura) • Soporte técnico y metodológico • Evaluación e implantación de nuevas tecnologías (investigación) • Definición y administración de toda lógica no funcional • Definición y evaluación de esquemas de integración

14. Proceso de conformación del equipo • Entorno • El cargo se desarrolla internamente en la Gerencia de Desarrollo informático. Es un puente entre las áreas técnicas y las áreas de desarrollo informático, brindando un soporte en lo relacionado con toda la infraestructura que soportan las aplicaciones (software de la compañía)

15. Gerencia de Desarrollo Gerencia Técnica Coordinación Políticas Proyecto Proyecto Cambio en Producción Gerencia de Proyecto Gerencia de Proyecto Gerencia de Proyecto Grupo de Integración Grupo de Integración Grupo de Integración Proceso de conformación del equipo Vicepresidencia Administrativa Visión EQUIPO DE ARQUITECTURA Apoyo metodológico Directrices

16. Procesos de Conformación • Conformación actual: • Un ejecutivo de arquitectura • Tres analistas de arquitectura • Un DA (Data Administrator) • Un practicante • Fuerte relación con la Gerencia Técnica • Administración de la plataforma de Bases de Datos • Administración de la plataforma Web • Application Server J2EE • Plataforma Microsoft • Soporte para la gerencia de desarrollo

17. Agenda • Visión Inicial • Proceso de conformación del equipo • Experiencias y productos • Arquitectura Inicial • Plataforma de Publicación de Servicios • Logros • Preguntas y Respuesta

18. Experiencias y Productos Service Oriented Architecture – SOA Plataforma de Publicación de Servicios

19. Experiencias y Productos • Definción de modelo de arquitectura general y un modelo de arquitectura de aplicaciones: • SOA • MVC • Lógica no funcional para el desarrollo de aplicaciones • Oracle Application Server 10g • Oracle Database 10g • Microsoft .NET Framework • Definición de modelo de gobierno • Especificación de normas, estándares y técnicas • Definición de herramientas de desarrollo • Jdeveloper, Enterprise Architect, REM, CVS • Definición de metodología de desarrollo

20. Propuesta Inicial de Arquitectura Directorio de Componentes Servicios Servicios de Autenticación y Autorización Servicios de Manipulación de inconsistencias

21. Persistencia • Almacenar y recuperar instancias de objetos del negocio • Solucionar la impedancia entre el modelo objetual y el relacional • Acceso a repositorios de datos heterogéneos

22. Persistencia

23. Archivos XML Persistencia • En este nivel se almacena la información permanente de la aplicación. Estos datos pueden almacenarse en un modelo de datos relacional, un servidor NDS, colas de mensajes, archivos texto o XML, o cualquier otro mecanismo de almacenamiento permanente. Repositorio De Datos Oracle MQ

24. Persistencia

25. Persistencia • Manipulación y consulta de datos • Operaciones permitidas por cada tipo de repositorio • No tiene inteligencia de negocio • Entrega de datos a través de XML • Encapsula la complejidad de acceso a cada repositorio • Para su implementación se aplicarán los patrones DAO y Factory que facilitan el desacople entre el nivel de Repositorio y el de Persistencia

26. Persistencia

27. Persistencia • Recuperar instancias de objetos del negocio en los repositorios de datos • Almacenar instancias de objetos del negocio en los repositorios de datos • Saber cómo construir objetos del negocio a partir del XML obtenido de la capa inferior de Acceso a Datos • Saber cómo almacenar un objeto del negocio utilizando el componente DAO adecuado • Utilizar el Cache de objetos para mejorar el rendimiento y la escalabilidad de los sistemas

28. Persistencia

29. Persistencia • Responsabilidades • Mantener en memoria principal información utilizada frecuentemente por las aplicaciones • Ofrecer esquemas de vencimiento de cache • Restricciones • Los objetos en este nivel deben estar relacionados a entidades cuyos cambios en el tiempo sean mínimos, por ejemplo ciudades y parámetros de aplicación • Los objetos en el modelo de cache no debe permitir actualizaciones o entradas diferentes a las existentes en el repositorio de datos.

30. Persistencia • Espejismos • Con la capa de persistencia se solucionarán todos los problemas de acceso a datos de las aplicaciones (Framework de Persistencia, Framework de mapeo Objeto Relacional) • El cache será una buena solución para mejorar el rendimiento de las aplicaciones • Realidades • Mucha de la lógica de negocio está implementada en procedimientos almacenados que deben ser reutilizados por todo el software de la compañía • Las bases de datos corporativas son accedidas por muchos sistemas diferentes, por lo que el a menudo el uso de cache no resulta factible

31. Persistencia • Productos • Conjuntos de mejores prácticas para el acceso a datos • Bind Variables, patrón DAO, patron Factory, DTO • Framework liviano de persistencia “casero” • Utilidades que aceleran el desarrollo e implementan buenas prácticas. Por ejemplo: Liberación adecuada de recursos (conexiones), uso adecuado de fechas, etc. • Evaluación de Frameworks de Persistencia • Evaluación de productos como BC4J, TopLink, Hibernate

32. Propuesta Inicial de Arquitectura

33. Componentes de Negocio • Los componentes del negocio son unidades de software autónomas capaces de realizar operaciones puntuales. La unión de varios componentes del negocio en una operación conforma un servicio. • En esta capa, los programadores también cuentan con un Framework unificado de utilidades, desarrolladas tanto por proveedores como internamente.

34. Componentes de Negocio

35. Componentes de Negocio • Uno de los objetivos de crear una arquitectura base para la construcción de aplicaciones es poder reutilizar la funcionalidad existente. El nivel de Componentes de Aplicación se crea para facilitar la reutilización. Aquí se crearan unidades atómicas de software, es decir, programas con funcionalidad puntual y sin dependencias ni prerrequisitos de procesamiento. En este nivel se encontrará gran parte del core del negocio. La combinación de esta unidades de software conformarán los servicios.

36. Componentes de Negocio Reglas de Construcción de Unidades de Software Atomicidad Acoplamiento débil entre componentes Orientación hacia Procesos Construcción con base en estándares Reutilización de Funcionalidad

37. Componentes de Negocio

38. Componentes de Negocio En este nivel se encontrará un conjunto de utilidades que faciliten el desarrollo de componentes de negocio. La construcción de este nivel se implementa bajo un patrón Fachada

39. Componentes de Negocio • Espejismos • Los componentes de negocio siempre utilizarán el framework centralizado sin tener que hacer invocaciones directas de utilidades de terceros, de esta forma los cambios en estas utilidades no afectarán la estabilidad de los componentes de negocio • Facilita la capacitación de los desarrolladores en las utilidades disponibles. • El diseño es más claro y fácil de entender • Se reduce considerablemente el tiempo de diseño de las aplicaciones • Permite la convivencia de diferentes versiones de las utilidades

40. Componentes de Negocio • Realidades • El esfuerazo necesario para mantener la fachada actualizada es muy grande, por lo que se convierte en un cuello de botella para el proceso de desarrollo. • Se debe proveer un conjunto de frameworks estándar de la compañía de manera que sea posible su mantenimient y que contenga las utilidades más importantes • Cada proveedor tiene gran parte de su propiedad intelectual en frameworks que aceleran el desarrollo. Estos frameworks deben ser mantenidos por el propio proveedor y en lo posible no deben ser compartidos entre aplicaciones. Cada aplicación tiene su propia versión.

41. Propuesta Inicial de Arquitectura Directorio de Componentes Servicios

42. Servicios • Los servicios son componentes que, a través de las llamadas a componentes del negocio en un orden específico, orquestan las funciones para ejecutar procesos. • Los objetivos de los servicios son facilitar la composición de aplicaciones, reutilizar funcionalidades existentes y mantener disponibles las soluciones del negocio en cualquier momento y desde cualquier lugar Servicios

43. Servicios Reglas de Construcción de Servicios • Encapsulamiento: La lógica de servicios debe ser accedida sólo a través de una interfaz pública bien definida. • Acoplamiento débil: Su ejecución no depende de la interacción con componentes externos • Construcción con base en componentes: Los servicios son una combinación de componentes de negocio. Su lógica de procesamiento se debe limitar a instanciar los componentes y a tomar decisiones simples dependiendo de los resultados de los métodos invocados.

44. Servicios Reglas de Construcción de Servicios 4. Enfoque en procesos: La combinación de los componentes utilizados por un servicio debe representar un proceso. 5. Orientación a uso en la red: Un servicio debe tener una interfaz accesible desde la red. Para nuestra tecnología los servicios deben exponerse como componentes límite. En el momento de adquirir la infraestructura adecuada, los servicios podrán exponerse como EJBs, WebServices, etc.

45. Servicios Reglas de Construcción de Servicios 6. Reutilización: Los servicios deben ser diseñados para ser reutilizables, evitando la duplicidad de implementación de la misma lógica. 7. Construcción con base en estándares: Disminuye el tiempo de mantenimiento y hace mas fácil la capacitación en su funcionamiento, además fortalece la reutilización.

46. Servicios • Espejismos • El desarrollo de aplicaciones orientadas a servicios es más fácil pues se reutilizan los servicios existentes • Debido a que los servicios son sólo una combinación de componentes, las modificaciones se hacen en forma rápida y sencilla • Se tiene claramente ubicado en que parte de la aplicación se encuentran los procesos de negocio

47. Servicios • Realidades • El desarrollo de aplicaciones a partir de servicios requiere un cambio del proceso de desarrollo, pues hay que pensar en servicios y no solamente en funciones específicas del sistema • Mientras no cambie la especificación de la interfaz y su semántica, cualquier cambio en los servicios será transparente para los consumidores. Si hay un cambio en alguno de estos dos aspectos se hace necesaria la verificación de TODOS los consumidores de los servicios • Durante el ciclo de desarrollo y pruebas el ambiente de ejecución debe ser MUY estable pues una aplicación depende de servicios por fuera de su dominio

48. Propuesta Inicial de Arquitectura Servicios de Autenticación y Autorización

49. Servicios de Autenticación y Autorización • Reto • Los servicios deben ser publicados y consumidos entre aplicaciones con sistemas de seguridad heterogeneos • Objetivo • Los servicios de autenticación y autorización deben facilitar la labor del desarrollador implementando una solución estándar reutilizable

50. Servicios de Autenticación y Autorización Sistema de Seguridad X Sistema de Seguridad Y Consumidor A Consumidor B Consumidor C Servicio Autenticación Autorización