BAQUIA

Construyendo SOA por la vía rápida

A lo largo de las últimas semanas he seguido con interés la polémica generada en torno al post de Anne Thomas Manes titulado SOA ha muerto; larga vida a los servicios . En este post el autor reflexiona sobre el dudoso éxito que han tenido las iniciativas de implantación de SOA (Service-Oriented Architecture) en las organizaciones afirmando, no sin cierto afán de protagonismo, la defunción prematura de este paradigma tecnológico.

Como suele ocurrir en estos casos de titulares polémicos, el contenido del post matiza bastante el titular y finalmente uno acaba preguntándose, a tenor del número de reacciones provocadas, si realmente era necesario armar tanto revuelo. Finalmente, y según el autor, lo que definitivamente ha muerto no es la orientación a servicios como arquitectura o conjunto de buenas prácticas, sino más bien el paquete comercial de solución SOA que han tratado de imponer los grandes fabricantes e integradores de software.

¿SOA ha muerto?…

Es verdad que en los últimos meses ha empezado a evidenciarse una corriente critica hacia SOA basada en las insatisfacciones y en las promesas no cumplidas (no hay que olvidar que los mayores beneficios esperados de la aplicación de SOA son la reducción de costes y la agilidad organizativa). Estas expectativas generadas no casan bien con la sensación, que parece se está imponiendo, de que SOA implica proyectos más caros, más largos y con peores resultados. Todo apunta además a que esta corriente crítica se irá agudizando conforme las consecuencias de la depresión económica se hagan más palpables.

En mi opinión, se ha generado una gran confusión identificando a las suites de productos SOA con la propia implantación de, genéricamente, arquitecturas orientadas a servicios. Obviamente, esta identificación se ha fomentado, con grandes dosis de evangelización, desde los grandes fabricantes e integradores para hacer caja. Se ha vendido y promocionado la idea de que SOA es un producto que puedes comprar (aunque te pueda costar varios años implantar).

El mensaje repetido machaconamente es que si quieres implantar SOA necesitas: un proveedor de servicios, un registro, un ESB, un motor de reglas de negocio, gestor de eventos, monitorización, BPEL, SOA governance, y además llevar a cabo toda una reingeniería de procesos y un cambio cultural sin precedentes en tu organización. Todo ello poniendo en práctica un snack de tecnologías emergentes que casi nadie domina, mucho más en los últimos años en los que ha habido una notable carencia de profesionales en el sector de las TI.

Por otro lado, se produce una circunstancia cuanto menos paradójica. La adopción de SOA, tal como ha sido planteada mayoritariamente en el mercado, se traduce en un viaje iniciático hacia la madurez tecnológica que comenzaría con la definición de procesos de negocio, continuaría con la identificación e implementación de web services, y tras unos cuantos pasos más, que podrían significar años, se aterrizaría en SOA governance. En resumidas cuentas, durante equis años, los proyectos de TI de una compañía se centrarían en la consecución de un roadmap de hitos basados en objetivos tecnológicos y no directamente en objetivos de negocio. Sinceramente, creo que es indispensable hacer una reflexión sobre los riesgos que introduce una decisión de estas características, más aún teniendo en cuenta la coyuntura económica en la que nos encontramos.

…¿O sigue vivo?

Bajo mi punto de vista, SOA sigue vivo. En realidad, siempre lo ha estado desde que alguien se preguntó cómo podía reutilizar su código encapsulándolo en un componente y presentándolo al mundo a través de una interfaz bien definida. SOA no es un conjunto de tecnologías concretas. SOA no emerge automáticamente de la implantación de web services, BPEL o un ESB. Es perfectamente posible diseñar una solución de software compuesta principalmente de web services y no estar aplicando SOA en absoluto. Y lo contrario también es posible (un buen ejemplo de ello sería las soluciones basadas en servicios OSGi o SCA).

Lo fundamental es diseñar soluciones de software alineadas con el estatus de madurez tecnológica de la organización y totalmente centradas en sus objetivos de negocio (¿es que es admisible a día de hoy diseñar software bajo otros supuestos que no sean los mencionados?). Si de paso, y las circunstancias lo permiten, es posible aplicar determinados aspectos de SOA, a través de la elección de ciertas tecnologías y/o enfoques metodológicos, bienvenido sea. Frente al todo o nada de las estrategias top-down, una cuidada gestión de la calidad y de la configuración, una potente estrategia de testing, y una mejora continua de los sistemas hará posible que de un enfoque bottom-up emerjan las buenas prácticas de SOA.

En mi opinión, para aplicar SOA no hay mejor receta que empezar a hacerlo, sin complejos pero minimizando los riesgos y sobre todo persiguiendo resultados de negocio tangibles en el corto plazo. Por ejemplo, para minimizar los riesgos de tener que realizar una gran inversión inicial, es posible optar por una combinación de productos open source, como pueden ser Apache ServiceMix o Apache CXF, e ir de la mano de un partner tecnológico de confianza que ponga el acento en la consecución de los objetivos de negocio y no en vender una predeterminada suite de productos.

Definitivamente, es urgente volver a pensar en SOA a partir de sus orígenes como aplicación de buenas prácticas en desarrollo de software, y olvidarnos de SOA como producto comercial empaquetado. Sólo de esta manera, y en combinación con la puesta en práctica de metodologías ágiles de desarrollo, es posible hacer realidad la promesa del software reutilizable y ligero que responde ágilmente a los retos de negocio concretos de las organizaciones.


Compartir en :


Noticias relacionadas




Comentarios