Arquitecturas Orientadas a Servicios

Para ampliar un poco el uso de los ESB utilizados en las arquitecturas SOA. A continuación Ilustrare un par de ejemplos, para que puedan apreciar su alcance:

Arquitectura SOA – Compartiendo archivos de forma segura:

El sistema “A” cada 2 horas deja un archivo con saldos en una unidad de red compartida, el archivo almacenado posee un formato XML y es nombrado con la fecha y hora del sistema. Se deben mover los archivos de saldos generados durante el día, de forma segura al path de red del sistema “B”.

• En el proceso que se desarrolle sobre el ESB se deberá configurar variables como: Servidor, puerto, path, usuario, password de los sistemas “A” y “B”.
• Se deberá configurar la máscara del archivo que se generará en el sistema “A”. Ej: SaldosDDMMYYHHMMSS.xml
• Se deberá configurar la frecuencia de ejecución
• El proceso deberá manejar un LOG de auditoría y manejo de excepciones para su seguimiento.

Arquitectura SOA – Servicios Seguros:

El sistema “A” debe consumir una catalogo de servicios que ofrece el sistema “B”. La información que se compartirá es de carácter sensible, razón por la cual debe protegerse. Cualquier otro sistema de la compañía podrá acceder a consumir los servicios que expone el sistema "B".

• En el proceso que se desarrolle sobre el ESB deberá ser una fachada de los servicios que expone el sistema “B”.
• Los ESB manejan un componente de seguridad el cual puede estar desplegado en el mismo servidor del ESB o en un servidor independiente. Este se deberá encargar de manejar autenticación de los servicios hacia el servidor LDAP. Si la autenticación es correcta le permitirá consultar al consumidor los servicios del sistema "B".
• El componente de seguridad deberá ofrecer los servicios con certificados digitales, para que la información viaje de forma segura.
• El proceso deberá manejar un LOG de auditoría y manejo de excepciones para su seguimiento.

En este link podrás encontrar el stencil de visio, utilizado en los libros de Thomas Erl para representar arquitecturas orientas a Servicios:

http://www.soabooks.com/SOA_Visio_Stencil.zip

Estados de madurez de la Arquitectura Empresarial

En el pos de la relevancia del MO, aprendimos que el punto de partida de una Arquitectura Empresarial es el modelo operativo, el cual nos indica cómo operamos actualmente y cómo deseamos hacerlo en el futuro.

Otro de los pasos dentro de una Arquitectura Empresarial, es evaluar los estados de madurez de la AE, para poder hacerlo existen muchas propuestas en el mercado, aquí les dejo una que proponen en el libro: “Enterprise Architecture as Strategy” de Jeanne W. Ross, Peter Weill, David C. Robertson:

1. Business Silos Architecture

Se hace evidente la presencia sistemas legados y otros que no manejan comunicación entre sí. La integración y estandarización de los procesos de negocio es casi nula. El rol de TI es automatizar lo procesos de negocio, los administradores de negocio diseñan los procesos de negocio y especifican los requerimientos funcionales a TI. Ti desarrolla o compra aplicaciones para cumplir con los requerimientos del negocio.

El estudio que hace el MIT a varias empresas arroja que el 12% se encuentran en este nivel.

Una organización que se encuentre en un nivel de madurez mayor, puede recaer en este cuando su negocio crece rápidamente o cuando se hacen fusiones con otras empresas, es aquí donde la organización debe hacer un gran esfuerzo para volver a cambiar de nivel Business silos.

2. Standardized technology Architecture (Estandarización)

Su principal objetivo es la reducción de costos, lo que significa que si se reducen o simplifican plataformas se disminuye la administración de las mismas.

Con la administración y apoyo de “estándares tecnológicos”, se obtiene:

• Reducción del riesgo
• Reducción del costo al compartir servicios como: Soporte, mantenimiento, compras, confiabilidad, seguridad, desarrollo y entrega a tiempo.
• Reducción del número de software que produce funcionalidad similar
• Se incrementa un acceso compartido a los datos, se introducen bodegas de datos, las transacciones siguen siendo individualmente en cada una de las aplicaciones.
• Se comparte infraestructura y servicios

3. Optimized Core Architecture (Optimización del Nucleo)

Las compañías se mueven de una vista local de datos a una vista empresarial, su principal objetivo estandarizar los datos y los procesos de negocio, más dependiente del modelo operativo, el ROLE de TI es asegurar la reusabilidad de los datos y de la plataforma que soporta los procesos de negocio generalmente en un enfoque y esfuerzo TOP-DOWN. Se analizan requerimientos y capacidades de TI, para estar alineado con el modelo operativo de la organización es aquí donde se evidencian oportunidades y apalancamientos.

4. Business Modularity Architecture (Modularización)

Habilita la agilidad estratégica través de la personalización y reúso de módulos (escancia del negocio). El principal objetivo crear nuevos módulos o re-usarlos para compartirlos transversalmente a las unidades del negocio. Estos servicios deben contar con interfaces estándar para acceder a módulos relacionados con datos, recursos internos y externos. El ROL de TI es proveer vínculos entre los procesos de negocio y las interfaces estándar. También en este nivel se identifican desarrollar y mejorar módulos que extiendan el core del negocio, para poder responder al cambio de condiciones del mercado para ello se usa el reúso de la experiencia en procesos, datos y estandarización tecnológica.