Problemas en la adopción de SOA: Transición inadecuada de roles

Un error común al incorporar SOA en una organización, es no sopesar adecuadamente lo que implica esta transición a nivel de las competencias técnicas y conceptuales de su personal; usualmente, las organizaciones simplemente ponen la palabra “SOA” al lado derecho del actual rol cumplido por la persona.  Por ejemplo, un “analista” pasa a ser “analista SOA”, un “arquitecto” pasa a ser “arquitecto SOA”, etc. Se asume una transición transparente y oportuna, subestimando fuertemente el esfuerzo, tiempo y conocimientos requeridos para ser competente en cada uno de estos nuevos roles.

 A modo de ejemplo, un arquitecto especialista en sistemas de arquitecturas tradicionales, va a requerir de mucho tiempo y esfuerzo para poder hacer la transición a sistemas orientados a servicios, debido a cambios en: (i) el tipo y cantidad de tecnologías nuevas involucradas, (ii) el tipo de abstracción con el que se  trabaja, (iii) los principios y fundamentos conceptuales que norman la construcción de aplicaciones.

Respecto al primer punto, se debe considerar que los estándares creados para la construcción de aplicaciones durante la primera y sobre todo durante la segunda generación en SOA son muchos. Si en la primera generación de SOA, bastaba con saber WSDL, SOAP, XSD/XML  y opcionalmente UDDI, en la segunda generación aparece un conjunto relevante de estándares WS-* (que hoy superan los 20). Además, en ambientes donde se requiere de interoperar con múltiples entidades externas, el conocer los perfiles WS-I es altamente recomendable.

Si bien no se requiere que un arquitecto conozca en detalle cada uno de los estándares SOA, debe conocer lo suficiente como para poder razonar a nivel arquitectónico en torno a ellos (por lo menos en torno a los más usados, como WS-BPEL, WS-Policy, WS-Security, etc.). La carencia de estos conocimientos probablemente lleve a una subutilización del middleware que se adquiera para la iniciativa SOA, o a la implementación redundante de mecanismos ya abordados por las especificaciones. Personalmente, me ha tocado ver varias implementaciones pobres y redundantes de funcionalidades ya provistas por componentes de middleware.

Una segunda arista de este problema es que el arquitecto debe conocer las características de varios  componentes de middleware que generalmente se asocian a las implementaciones de SOA, como por ejemplo: buses de servicios, motores de reglas, motores de orquestación, gestores de políticas de servicios Web, registros de servicios, etc. Este conocimiento no sólo es necesario para el adecuado uso de las piezas de middleware, también se necesita para proteger a la organización del constante bombardeo publicitario que los grandes productores de software han montado en torno a ellos, y que lleva a gran cantidad de organizaciones a comprar productos que no necesitan.

Respecto al segundo punto, los cambios también son relevantes: El arquitecto debe adquirir conocimientos que le permitan identificar servicios que tengan relevancia y trazabilidad a nivel de negocio, lo que implica un mayor conocimiento e internalización de los objetivos y guías centrales del negocio de la organización. Además, las implementaciones SOA modernas generalmente buscan la automatización de procesos de negocio, y no se limitan a soportar tareas puntuales, requiriendo que el arquitecto entienda estos procesos y sepa plasmarlos en el sistema mediante orquestaciones y coreografías de servicios.

Por último, el tercer punto es el que, en mi opinión, lleva de manera más subrepticia al fracaso de la iniciativa SOA en el logro de sus objetivos de mediano y largo plazo. La internalización de los principios y conceptos asociados a SOA es un proceso de lenta maduración, y es clave para que los sistemas manifiesten los atributos de calidad derivados del paradigma arquitectónico. Los saltos dados de una organización al paradigma SOA, sin una adecuada transición de sus arquitectos, pueden llevar a una proliferación de sistemas que: (i) usen tecnología (middleware y estándares) SOA y (ii) estén adecuadamente alineados con los objetivos del negocio, pero (iii) que se hayan concebido sólo en base a principios de otros paradigmas (orientación a objetos, a eventos, funcional, etc.). El desempeño de los sistemas así concebidos probablemente será peor al de su contraparte más simple, y no necesariamente manifestará las características deseables de un sistema orientado a servicios, lo que inevitablemente levantará cuestionamientos acerca de por qué se optó por una arquitectura tan compleja, cuando existía una forma más sencilla de hacer las cosas.

Referencias:

• SOA Governance: Achieving and Sustaining Business and IT Agility
• SOA Principles of Service Design
• Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)