questions

Algunos de vosotros me habéis preguntado cómo como podéis empezar  a implantar SOA en su empresa o en su tesis… lo más común es que me pregunten que libro o páginas puede leer para adquirir los conocimientos necesarios para eso… y la verdad que es una pregunta difícil…

Creo que para empezar, lo más sencillo para hacerse una idea aproximada de lo que tenemos entre manos es hacernos una serie de preguntas. Con la respuesta a estas preguntas podremos hacernos una composición de lugar y poder avanzar en la implantación de SOA.

¿Qué servicio tengo que hacer?

La identificación o “levantamiento” de los servicios es una de las tareas más difíciles e implica sobre todo conocimiento de negocio aunque también es necesario tener unos conceptos (pocos pero muy claros) de SOA.

Los servicios a hacer deben cumplir los siguientes criterios:

  • Tienen sentido para el negocio, es decir, responden a una necesidad concreta de negocio.
  • El servicio tiene que ser modular, tener cohesión (cada servicio se dedica a una cosa) y exponer al consumidor únicamente la información que necesita (bajo acoplamiento)
  • Cada uno de los servicios tiene el interfaz (el contrato con el cliente) claramente definido
  • Tiene que poderse securizar de manera independiente a otros servicios
  • Tiene que ser distribuible. Cada servicio se puede desplegar en una máquina diferente
  • Se debe poder sustituir un servicio por otra implementación sin afectar al resto.
  • Se debe poder invocar cualquier aplicación dentro o fuera de la organización
  • Debe permitir el que se pueda fácilmente construir (componer) un nuevo servicio más complejo a partir de los servicios anteriores.

¿Qué servicios hacer primero?

En la aplicación de SOA es necesario empezar poco a poco y no intentar hacer la adopción de golpe en toda la compañía. Por lo tanto, en respuesta a esta pregunta, los servicios SOA que se acometerán primero serán los que respondan a estos criterios:

  1. Servicios con más potencial de reutilización. Actualmente son los que más veces se han implementado
  2. Conversión a servicio de las lógicas con mayor acoplamiento entre sistemas
  3. Servicios que aporten un gran valor como poca inversión (Quick win)

¿Este servicio es realmente reutilizable?

El gobierno de servicios debe garantizar el cumplimiento de los siguientes requerimientos de negocio:

  • Conectar los activos que ya tenemos
  • Extraer más valor de lo que ya tenemos
  • Extender y evolucionar lo que ya tenemos

Por lo tanto, el gobierno SOA debe dar las pautas necesarias para garantizar la reutilización de servicios como forma de extraer más valor de los activos de la empresa. Estas pautas son las siguientes:

  • Establecer un grano grueso en los servicios. Aunque el “grosor” del grano de los servicios es una medida bastante subjetiva se debe tener a un grano grueso en lugar de servicios de bajo nivel. Hay que tener en cuenta que los servicios deben tener sentido para el negocio y que además se ejecutan en remoto.
  • Establecer un mecanismo que permita conocer exactamente el grado de reutilización de un servicio. Este mecanismo se implementará en el registro de servicios, siendo obligatorio para de alta un servicio, saber a qué otros servicios llama (en el caso de un servicio compuesto.
  • Además se definirán unos logs estándar que permitan contabilizar las llamadas efectivas en tiempo de ejecución a cualquiera de los servicios desplegados en producción.

¿Quién es el responsable del servicio?

Todo servicio deberá tener dos responsables:

  • Un responsable funcional, conocedor de la funcionalidad del servicio, y que será la persona de referencia para obtener información sobre el mismo, solicitar ampliaciones del mismo o nuevas versiones para dar soporte a nueva funcionalidad de negocio.
  • Un responsable técnico que será la persona encargada de resolver los problemas técnicos, de seguridad, de acceso, etc. que se puedan presentar.

Los dos responsables del servicio, que podrán ser la misma persona, estarán identificados de manera nominal en el registro de servicios.

¿Quién va a pagar el coste del desarrollo y el mantenimiento?

El servicio será responsabilidad del departamento que se encarga de ese funcionalidad dentro de la compañía y por lo tanto será este el que debe costear su desarrollo y mantenimiento.

Quiere esto decir que si un servicio de contabilidad lo necesita otro departamento de la empresa, será el departamento de contabilidad el que deba sufragarlo, no el que lo vaya a invocar.

¿Quién usa mi servicio?

Es necesario que podamos saber quién usa un servicio. Esto es necesario para conocer realmente el grado de reutilización de un servicio y sobre todo para poder realizar análisis de impacto. Es decir, poder responder a la pregunta de “¿a quién afecto si falla este servicio?.

Los mecanismos son:

  • En el registro de servicios se indicará para cada servicio que otros servicios utiliza
  • En el log de los servicios ser genera una traza con la identidad del usuario que invoca al servicio. Este log se podrá explotar posteriormente para obtener informes y estadísticas de uso.

El servicio que necesito ¿Ya existe?

El registro de servicios contendrá los metadatos necesarios para que un analista pueda buscar y encontrar un servicio ya existente. Los metadatos son los siguientes:

  • Módulo funcional al que pertenece el servicio
  • Tipo de servicio: de núcleo, técnico, compuesto, flujo de integración, compuesto
  • Listado con las entidades de negocio con las que trabaja. Por ejemplo: clientes, tarjetas, créditos…
  • Nombre de las operaciones que contiene el servicio

¿Qué roles intervienen?

Los roles implicados son los siguientes:

  • Arquitecto de servicios
    Rol con una versión global de toda la empresa. Debe conocer la orientación a servicios y también tener un conocimiento funcional. Debe velar porque los servicios tengan una coherencia a lo largo de toda la empresa (por encima de los departamentos), de que sean realmente reutilizablesy que no se vuelvan implementar dos veces o más.
  • Analista de servicio
    Analista funcional que además de los skills clásicos de análisis, suma los principios de orientación a servicios en el análisis funcional
  • Analista técnico
    Realiza el diseño técnico de la solución, teniendo en cuenta la tecnología, la arquitectura y framework específicos y los principios de diseño SOA
  • Responsable de esquema de datos
    Responsable de velar por la integridad y coherencia del modelo de datos usado en los contratos de los servicios.
  • Responsable funcional del servicio
  • Responsable técnico del servicio

Creo que una vez tengamos claras estas respuestas, estaremos en una mejor posición para abordar el proyecto de implantación de SOA.

Anuncios