gente tomando apuntes

Después de varios meses o años implantando SOA, es necesario hacer una revisión de lo que estamos haciendo. Por supuesto no es necesario esperar tanto tiempo para hacerlo, más bien es recomendable hacerlo cada poco tiempo (quizás no más de dos meses). Pero si no hemos hecho una revisión de la aplicación de SOA en la empresa hasta ahora es cuando menos preocupante. SOA implica la mediación de determinados parámetros que son vitales para constatar el éxito o el fracaso de su implantación. ¿Cómo podemos saber si SOA tiene éxito si no sabemos, por ejemplo, cual es el grado de reutilización de los servicios?.

El objetivo de esta revisión es ver primero donde hemos llegado y después hacia donde vamos. Es bastante común en un proyecto de gran envergadura los desvíos y cambios de rumbo respecto al previamente trazado. Debemos tener claro hacia donde vamos, pero antes, hay que ver donde estamos y si estamos en el camino correcto para llegar al objetivo.

Nos vemos en la situación de que ya tenemos decenas, o incluso cientos de servicios construidos, hemos implantado la reutilización de los servicios, la multicanalidad, del desacoplamiento y otros tantos principios de SOA… pero ¿seguro que los hemos implantado? Es hora de hacer una revisión.

Veo en esta entrada un guión interesante para realizar esta revisión del proyecto SOA, lo que llama el “SOA Portfolio Review”. Entre los objetivos de esta revisión están el determinar si la metodología, los límites de los contratos están bien definidos y además asegurar que hemos llegado el mínimo de redundancia, duplicación de servicios mientras maximizamos la reutilización de los mismos.

Sobre los contratos y el impacto sobre el consumo y orquestación de los servicios

¿Qué tenemos que revisar? Entre otras cosas (pongo en cursiva los puntos originales y en normal mis comentarios al respecto):

  • Acoplamiento entre el diseño del servicio, su descripción y la lógica de negocio para determinar la agilidad, el coste de desarrollo y mantenimiento
    Según el principio de Abstracción, el servicio debe ser una caja negra para el consumidor, que ve únicamente el contrato del mismo. Por lo tanto no puede estar acoplado el servicio con su diseño e implementación
  • Guías de diseño de los servicios, definición del contrato y políticas asociadas
    ¿Estás guías son conocidas y entendidas en la empresa? ¿son realmente útiles? ¿se están usando?
  • Consumo esperado y combinación de los servicios
    Si los servicios no se reutilización, mediante su invocación por diferentes consumidores o mediante su combinación para crear servicios de más alto nivel, SOA es un fracaso. ¿Estamos fracasando entonces? no lo sabremos si no medimos el grado de reutilización.
  • Proceso usado por los desarrolladores para descubrir, acceder, evaluar e integrar los servicios.
    Para reutilizar un servicio, lo primero que debemos conocer es este servicio ya existe y se ajusta a nuestras necesidades. Para ello, necesitamos poder “descubrirlo”, es decir, realizar una consulta con determinados criterios en una herramienta que nos localice el servicio que necesitamos (ver El papel fundamental del registro de servicios en este blog).
  • Cómo el equipo construye y despliega artefactos y como el equipo desarrolla servicios.
    ¿Cómo se están desarrollando los servicios? ¿se cumple con la normativa de desarrollo? ¿se están alcanzando los objetivos de productividad fijados? Si no tenemos respuesta a esas preguntas estamos en un aprieto.

Esta revisión debe determinar:

  1. ¿Permite el diseño conseguir las metas de modularidad, configuración y flexibilidad? Hay que tener en cuenta los principios de desacoplamiento, abstracción, granularidad, interoperabilidad y separación de cometidos.
    Claro que lo primero que tenemos que saber es cómo vamos a medir esto. ¿Cómo sabemos si un servicio o conjunto de servicios son modulares?. Una forma de saberlo serían las relaciones con el resto de servicios… por supuesto no puede haber referencias circulares o sea, las dependencias deberían ir siempre en un sólo sentido: A depende de B, y B de C pero no a su vez C de A…
  2. Pueden los consumidores descubrir realmente los servicios relevantes, y pueden los consumidores entender fácilmente como los servicios corresponden con los requerimientos funcionales y no funcionales.
    Un elemento vital en la implantación de SOA es el catálogo de servicios utilizable por los “humanos” en tiempo de diseño.

Los entregables en la evaluación

En esta revisión que estamos haciendo, deberíamos generar unos documentos o entregables que dejen constancia tanto de la situación actual como de las recomendaciones o líneas a seguir para mantenernos en el camino correcto al objetivo.

En esta revisión se debería utlilizar mucha de la documentación que debemos tener ya realizada para la implantación de SOA en la empresa. El objetivo es hacer hacer una revisión crítica de los mismos para ver su grado de aplicación y sobre todo recoger métricas sobre la marcha de SOA en la compañía.

Entre esta documentación, está la siguiente:

  • Modelos de diseño
    • Casos de uso de alto nivel, requerimientos, y descripciones para los servicios existentes y futuros
    • Procesos de negocio implantados en BPM
    • Modelos de servicio y descripciones de los interfaces
    • Artefactos de revisión de código y artefactos maven generados durante la implementación
  • Practicas del desarrollo de la gobernanta
    • Guías de diseño de los servicios
    • Herramientas y frameworks de desarrollo
    • Procesos de implementación de servicios
    • Guías para administración, monitorización, seguridad, etc.
  • Políticas de tiempo de ejecución
    • Políticas de seguridad
    • SLA (Acuerdos de nivel de servicio)
    • Estructura organizacional de la empresa
  • Mapa de portafolio de servicios
    • Aplicaciones / proyectos
    • Servicios / APIs
    • Capacidades de negocio y dominio de negocio
    • Uso
  • Revisión del portafolio SOA
    • Estrategias
    • Gobernanza SOA
    • Estándares a utilizar
    • Procesos de desarrollo
Anuncios