Búsqueda de Servicio de TI: Cómo Elegir el Socio Ideal

Los proyectos de software suelen contar con un equipo con diferentes roles, como los ejemplos listados a continuación:

• Gerente Comercial;
• Gerente de Proyectos;
• Analista de Negocios;
• Analista de Sistemas;
• Arquitecto de Software;
• Desarrollador de Sistemas;
• Analista de Pruebas;
• Gestor de Configuración;
• Analista de Calidad;
• Gestor de Medición y Análisis;
• Entre varios otros que podrían ser citados aquí.

Es un hecho que cualquiera de estos roles, aun sin tener responsabilidad directa sobre el asunto, ya ha tenido algún contacto con el concepto de SOA (Service Oriented Architecture). Esta arquitectura ha sido aprobada, vislumbrada y referenciada siempre que se proyecta una solución, ya sea nueva o en evolución.

¿Cuál es la propuesta?

La propuesta de solucionar de forma madura y estable problemas como integración, reusabilidad, desacoplamiento y escalabilidad, entre varios otros, es muy atractiva tanto desde el punto de vista técnico como funcional; sin embargo, exige un estudio profundo sobre su arquitectura y, principalmente, del entorno en el que la misma será implementada, ya que al final se debe entregar una composición de servicios que no serán más que funcionalidades ya existentes, pero reorganizadas de manera que respeten los estándares de la arquitectura (SOA) implementada, compartiendo funcionalidades comunes entre las diversas soluciones específicas de cada área del negocio.

Durante la implementación de esta arquitectura, que está orientada a servicios, se debe dedicar precisamente un tiempo considerable a la identificación de estos servicios, con el fin de alcanzar el beneficio efectivo propuesto por SOA.

Entre las diversas técnicas y teorías de identificación de servicios, me gustaría exponer un pequeño conjunto de buenas prácticas, o bien consideraciones a tener en cuenta durante la ejecución de esta actividad. Estas sugerencias fueron compiladas a partir de los trabajos realizados en diferentes clientes y con necesidades variadas.

Principio de simplicidade

Del mismo modo que en las definiciones de cualquier solución, siempre que algo se vuelve complejo, la probabilidad de que estemos siguiendo un camino incorrecto es alta. En la identificación de servicios en SOA esta filosofía también es válida; es decir, no existen reglas de identificación infalibles ni que atiendan a todos los casos, por lo que resulta muy interesante partir de una visión simplificada y trabajar con el hecho de que las reglas de identificación se modificarán conforme a la evolución y maduración de los trabajos.

Una forma práctica de comenzar es respondiendo a preguntas como:

• ¿Qué soluciones de negocio ya están integradas hoy en día?
• ¿El proyecto está dispuesto a modificar parte de las soluciones involucradas para adecuarse a SOA, o las implementaciones deberán ser siempre externas a la solución, trabajando en conjunto para integrarse a la plataforma definida?
• ¿Existirán integraciones externas al negocio (internet por ejemplo)?
• ¿Existe documentación de Requisitos Funcionales de cada producto involucrado? Esto es muy importante para la etapa de definición de responsabilidades.
• ¿Ya existe algún mapeo entre las unidades de negocio?
• ¿Cómo organizaremos los servicios identificados? Existen estándares para la documentación y el registro de servicios, y el registro de los mismos depende de la herramienta elegida como bus (es, bus). Es importante empezar de forma organizada para evitar revisiones excesivas posteriormente.

Tener en mente el negocio

La identificación de servicios depende directamente del análisis de la representación del negocio en forma de sistema. Por lo tanto, es mucho más importante tener buenos conocimientos sobre el modelo de datos de cada solución involucrada en la integración que conocimientos de implementación técnica de la solución en cuestión. Por este motivo, esta etapa debe realizarse siempre en conjunto con alguien que posea el conocimiento de los requisitos funcionales y del modelo de datos de la solución, ya que en este contexto se encuentra la información más útil para definir cuántos servicios hay, cuáles son, dónde están o dónde se ubicarán los servicios identificados. Resulta entonces bastante obvio, pero no se puede dejar de mencionar, que un modelado de negocio (BPM) se aplica perfectamente como material de referencia para la identificación de servicios.

Para entender mejor esta asociación entre servicios y requisitos funcionales, se puede trabajar como si los sistemas fueran personas y los servicios fueran tareas realizadas por estas personas, donde cada persona debe tener responsabilidad sobre un conjunto determinado de información y, por consecuencia, realizar tareas solicitadas por otras personas, manteniendo la información que está bajo su responsabilidad.

Imitar los conceptos de DDD (Domain Driven Design)

Aprovechando el gancho de asociación entre negocio, personas y responsabilidades sobre la información, sugiero firmemente el reaprovechamiento de los conceptos definidos por los proyectos orientados al dominio.

Estos conceptos establecen que un sistema debe construirse definiendo el dominio de la información que está bajo su responsabilidad y aislando por completo el acceso a dicha información. De este modo, todo acceso a esta información solo puede ser realizado por el sistema definido; por lo tanto, ninguna información es obtenida, alterada o eliminada si no es a través de las funciones disponibles en el sistema que domina el conocimiento de cómo mantener tal información. La principal característica de los proyectos que siguen estos conceptos es que, incluso los módulos dentro de un mismo sistema deben implementar esta división de responsabilidad por dominio de información. La siguiente imagen demuestra de manera sencilla esta separación de responsabilidades por dominio de información.

Al observar la imagen anterior, se puede identificar fácilmente la existencia de un candidato a servicio, que en este caso es el servicio que mantiene la información de los clientes. La utilización de conceptos como DDD no es muy común ni se implementa de manera completa, por lo que son pocos los sistemas que ofrecen una identificación de servicios tan simple y directa; sin embargo, podemos llevar el aprendizaje de los conceptos de DDD para observar los sistemas existentes en nuestros entornos, con el fin de separar qué dominio de datos comprende y mantiene cada uno, y a partir de ahí asignar responsabilidades y comenzar a identificar nuestros servicios.

Atribución de responsabilidades

Bajo mi punto de vista, la tarea más importante en el proceso de identificación de servicios es la atribución de responsabilidades a cada uno de los sistemas involucrados. Esto se debe a que, a partir del momento en que se identifica que un sistema es responsable de determinada información, se vuelve evidente la necesidad de ofrecer servicios a otros sistemas que hagan uso de esta información. Dentro de la misma etapa de atribución de responsabilidades, se puede hacer la separación entre la información que se utiliza únicamente como complemento del modelo interno del sistema y la información que debe compartirse entre los demás modelos pertenecientes a otros dominios.

En resumen, un flujo simplificado para la identificación de servicios podría ser:

Conclusión

Los servicios se pueden identificar de manera simplificada, ya que la información necesaria para su identificación ya existe y solo debe ser analizada. Independientemente de la estrategia adoptada (siguiendo la teoría, definiendo una personalizada o aprendiendo sobre la marcha), este trabajo debe tomarse en serio, ya que es el responsable de hacer un uso correcto de la estructura de integración mediante servicios; es decir, no tiene ningún sentido contar con un bus de servicios óptimo en términos técnicos, pero utilizado de manera incorrecta, con servicios mal definidos o mal aprovechados.

La identificación de servicios siempre debe ser realizada por un equipo y no por una persona en específico, ya que requiere conocimientos variados (técnicos, analíticos y de negocio). Los servicios identificados sufren una evolución continua, conforme a la maduración de las soluciones que los componen y al crecimiento del negocio que representan. Incluso basándose en una lista de pasos, es necesario estudiar cada situación para descubrir necesidades específicas que puedan exigir una estrategia diferenciada.

Es importante recordar además que esta es solo una sugerencia para iniciar los trabajos de identificación de servicios e implementación de una arquitectura orientada a servicios. Si entramos en detalles, descubriremos que existen reglas o normas para la segregación de servicios, o incluso para la definición de los contratos disponibles en cada servicio. Vale la pena señalar que los resultados obtenidos, tales como la calidad y el reuso de la unidad de servicio entre otras aplicaciones, vuelven a las unidades de negocio (servicios) interoperables y más flexibles, adaptándose de forma más ágil a los cambios del negocio.

Inicie con un proyecto que ofrezca menos riesgo, realice todo el estudio de la unidad de negocio e impleméntela. Al finalizar, extraiga las lecciones aprendidas y aumente la complejidad en la implementación del concepto.

SOA – Service Oriented Architecture