Una de las primeras cosas que hay que hacer (y que lamentablemente no se hace en muchas ocasiones) cuando empezamos con SOA, incluso antes de hacer ningún servicio, es organizar la gestión de estos servicios, lo que se conoce como SOA Governance o Gobernanza SOA (quizás mal traducido al español como “gobierno SOA” aunque para la RAE parece que es lo mismo).

La verdad es que no he podido encontrar una definición de Gobierno SOA que sea breve y fácilmente entendible. Si me permitís la maldad, todos estos temas relacionados con la metodología suelen ser bastante farragosos. Yendo al grano, está claro que este tema daría para varias entradas en el blog. Con casi total seguridad lo abordaré próximamente, pero quiero que al menos en esta primera entrada de este tema, sirva para plasmar una definición que podamos manejar todos a modo de introducción.

¿qué es y que hace el gobierno SOA? Es un organismo dentro de la empresa que:

  • produce las políticas, procedimientos (procesos) necesarios para controlar el desarrollo, despliegue y gestión de los servicios.
  • Una vez desplegado y puesto en producción debe definir y hacer que se apliquen los mecanismos de monitorizacion y supervisión que garanticen su correcto funcionamiento, tanto a nivel funcional (control de los errores de negocio) como a nivel técnico (tiempos de respuesta, errores técnicos, reintentos, escalabilidad, etc.)
  • Debe focalizarse en el ciclo de vida completo del servicio, desde el origen (se detecta la necesidad del mismo) hasta su fin (cuando es retirado de producción).
  • Toda estas políticas, normativas, procesos deber divulgados, comprobar que se aplican y tenerlos constantemente actualizados.

Todo esto en la práctica se puede traducir en las siguientes acciones que deben ser aplicadas por comité encargado del gobierno SOA:

  1. Asegurarse de que los servicios que se identifican y construyen pueden ser consumidos por el resto de la organización.
    La inercia en la empresa será hacer las lógicas de negocio o los servicios que necesita nuestra aplicación porque así se ha hecho toda la vida. Debemos tener una amplitud de miras que nos permita generalizar esta lógica para que pueda ser usada por el resto de aplicaciones de la organización o incluso nuestros socios.
  2. Que el mismo servicio no se implemente n veces.
    Para esto es muy necesario una herramienta que actúe de registro en tiempo de diseño para que los analistas puedan buscar, con criterios de negocio, si ya existe la funcionalidad que necesitan.
  3. Acordar un lenguaje COMUN para lo servicios.
    Esto es, los datos o campos que son parámetros de entrada/salida de los servicios estén bien definidos, no se repitan. En resumen, que la estructura Cliente exista una vez y se use en todos los servicios que necesiten la información de un cliente y no se cree una nueva estructura para cada servicio. Sin ir más lejos, esta es la forma normal de trabajar con las tablas de bases de datos. En la mayoría de la empresas, existe un grupo de Modelo de Datos que vela por esto mismo sólo que en lugar de tratar con esquemas XSD lo hacen con columnas de las tablas.

Comparte esta entrada…

Share

Anuncios