En mi anterior entrada, traté el preámbulo de lo que constituye el Manifiesto SOA. Siguiendo con esta tema, traigo a colación los dos primeros principios del manifiesto. Como se puede ver, no hacen referencia a conceptos técnicos, sino que inciden en el impacto que tiene la adopción de SOA en la empresa:

Respetar la estructura de la organización

Este principio hace mención a que la adopción de la orientación a servicios y por ende, SOA, no debe ser una iniciativa de T.I. (es decir, una cosa de los técnicos) si no que debe ser de negocio. A fin de cuentas, SOA no debe tratar de tecnología sino del diseño de los servicios de negocio y como el negocio puede beneficiarse de su uso.
No sé el grado de adopción que tiene este principio en la práctica, pero me temo que no mucho. Para esto sería  necesario que el área de negocio se familiarice con conceptos tales como el contrato de los servicios, la interoperabilidad de los mismos, bajo acoplamiento, etc. Otra cosa distinta, es que la adopción de una orientación a servicios (y una arquitectura SOA en definitiva) sea liderada por el área de TI pero con el apoyo expreso de la dirección de la organización, que debe hacer lo necesario para implantar este cambio cultural en la empresa.

Reconocer que SOA requiere cambios a todos los niveles

Centrándonos exclusivamente en el área de T.I. de la empresa es innegable que es necesario un cambio profundo en todos los departamentos. Como se ha comentado anteriormente, SOA es ante todo un paradigma de diseño (orientado a servicios), por lo tanto, es necesario adaptar la metodología de desarrollo de proyectos a esta realidad, en primer lugar, y después que ésta se transmita a los roles implicados (Jefe de proyecto, Analista Funcional, Analista técnico y programador).

Por supuesto a nivel de infraestructura también tiene un cambio profundo, ya que la adopción de una solución técnica concreta seguramente conllevará la adquisión de Middleware como pueden ser el Enterprise Service Bus, Process Server, UDDI, etc. etc. El equipo encargado de su explotación necesita saber manejar este sofware para garantizar su escalabilidad y disponibilidad.

En último término se hace imprescindible, la puesta en práctica de un gobierno SOA que debe proporcionar los mecanismos de control, procedimientos y métodos para garantizar el orden en un “ecosistema” de servicios de negocio. Con el tiempo, a medida que se implante la orientación a servicios, la reutilización de éstos complicará este control ya que los nuevos servicios estarán formados por composición de otros servicios más sencillos, que se llaman entre sí, y que cada uno de ellos debe tener un propietario que se encargue de su mantenimiento y evolución, que se hace necesario un análisis de impacto cuando se modifique un servicio, que debe hacerse una gestión de la demanda, controlar si es necesario realizar un nuevo servicio o se puede reutilizar uno ya existente, etc., etc.

Sin el gobierno, indudablemente aparecerá el caos, y es que citando el famoso eslogan publicitario, en SOA “la potencia sin control, no sirve de nada”.

Comparte este artículo…

Anuncios