SOA y Requerimientos de Negocio

Una arquitectura SOA es una estructura compleja que provee comunicación y facilita la interacción de los distintos servicios y componentes que componen un sistema. Una vez que la arquitectura de comunicación está definida, por ejemplo a través de un service bus, el paso siguiente es definir qué servicios hay que implementar.

Puede existir en este punto una lucha de intereses. Algunos sectores querrán priorizar servicios técnicos, como manejo de contención de recursos o seguridad y permisos, contemplando autenticación y autorización. Sin embargo, según la referencia [1] es crítico comenzar identificando los servicios de negocio. Es decir, identificar y establecer los requerimientos y los servicios que los implementan. Para tal fin se proponen tres etapas: identificar los servicios, relevar sus requerimientos, y finalmente, documentarlos.

Etapa 1: Identificar los servicios de negocio

En este punto es importante detectar servicios que cumplan las siguientes características: que tengan poca interacción con otros y que sean relevantes, de manera de poder observar con mayor claridad el retorno de inversión en los mismos.

Existen dos grandes aproximaciones a la identificación de servicios: un enfoque TOP-DOWN y un enfoque BOTTOM UP. En el primero se recomienda empezar por casos de uso de negocio de alto nivel o flujos de procesos de negocio que ya existan en la organización. Los mismos funcionarán como punto de partida para lograr descomponer funcionalidad de alto nivel en subsistemas. Ayuda a este proceso de descomposición empezar con casos de uso que no generen mucha controversia entre los involucrados, de manera de no perder el foco del proceso. En pocas palabras, se busca definir a cada proceso como un servicio, tratando de observar los riesgos y debilidades en cada paso. Luego, cada servicio se va a su vez descomponiendo en servicios de menor complejidad.

En un esquema BOTTOM UP se parte desde las aplicaciones, tratando de identificar las áreas o sistemas que están inmediatamente a su cargo. Funciona casi como un proceso de ingeniería reversa, yendo del código propiamente dicho de las aplicaciones, hasta obtener casos de uso de alto nivel.

Respecto a cuál de las estrategias es mejor, es un viejo debate dentro de la comunidad. La realidad es que ambos funcionan bajo determinadas restricciones, por lo que es importante conocer ambas y reconocer cual se adapta mejor al contexto actual.

Etapa 2: Capturar requerimientos de negocio

En la referencia [1] se describe un esquema para determinar los requerimientos de negocio relativos a servicios, dentro de una arquitectura SOA. El esquema funciona como un checklist que debe ser revisado para que no se escape ningún requerimiento. El primer ítem en el checklist es accesibilidad: ¿cómo el usuario encuentra y accede al servicio?

Luego sigue funcionalidad: ¿que está aportando este servicio para ser un proceso crítico del sistema? ¿Qué problema está resolviendo? El tercer punto es interacción: definir cómo y cuándo se comunica el servicio con otros, y cómo será accedido. El cuarto punto es información: ¿qué datos de entrada y salida necesita el servicio? Finalmente, el quinto lugar se concentra en el proceso: ¿cómo se relacionan las acciones y los eventos del servicio?

Un punto interesante a tener en cuenta dentro del mundo SOA es que no siempre se conocen por anticipado todos los potenciales usuarios del servicio. En este caso, los stakeholders deberán describir lo que ellos esperan del servicio. El output de esta etapa se validará con los usuarios finales que se conozcan. Intentarlo con todos es inviable.

Etapa 3: Documentación

Los requerimientos de negocio relevados deben ser documentados cuidadosamente. Esto tiene un importante aspecto en la trazabilidad de los mismos, y tener siempre claro en todo momento qué servicio se está correspondiendo con qué requerimiento. Existen muchas opciones y herramientas para formalizar la especificación de requerimientos. La más conocida es a través de casos de uso. Los casos de uso encajan también perfectamente con una propuesta SOA, por lo que los mismos constituyen una opción solida a la hora de dejar documentado los requerimientos de los procesos de negocio.

Referencias:

[1] http://www.ibm.com/developerworks/library/ar-soareq2/index.html