Mi propio manifiesto SOA (SOA IMHO)
En una entrada reciente acerca de SOA, realicé una reflexión acerca de las diferentes concepciones que se han aportado acerca de este concepto y la controversia generada al respecto. Me gustaría incidir en el hecho de que se trata de mi interpretación humilde y subjetiva acerca de SOA, por lo cual no pretendo despreciar opiniones en otra dirección ni mucho menos... En la diversidad radica la auténtica riqueza.
Como ya apunté en dicho post, mi definición para SOA es:
"Una arquitectura débilmente acoplada diseñada para resolver las necesidades de los procesos de negocio (BPM) de una empresa"
A primera vista, esta definición puede parecer demasiado simple: ¿dónde están SOAP, WSDL, servicios web, WS-* y los demás estándares asociados a este concepto? En realidad, una arquitectura orientada a servicios no precisa del uso de estos estándares para ser considerada como tal, y no debemos confundir arquitecturas con tecnologías, planos con hormigón…En el pasado, las arquitecturas débilmente acopladas se basaban en otras tecnologías como por ejemplo CORBA y DCOM; así como diversos enfoques basados en el intercambio de documentos, tales como EDI, para lograr integración B2B. Muchas de estas tecnologías ocupan todavía hoy un amplio sector de mercado, y están siendo complementadas, en algunos casos, y reemplazadas progresivamente, en otros tantos, por el uso de otras nuevas.Pienso que la definición aportada es válida puesto que refleja la verdadera motivación de SOA: Satisfacer las necesidades de una empresa, lo cual no se puede garantizar mediante el uso de unas tecnologías u otras, sino mediante el uso apropiado de cualquiera de ellas.
Hablando en términos más concretos, la arquitectura orientada a servicios de una empresa puede que sólo se parezca a la de otra empresa en el hecho de que aglutine unos cuantos servicios, sin entrar a comparar las tecnologías en que estén implementados respectivamente. Es probable que haya una serie de servicios comunes, de propósito similar, entre ambas arquitecturas (por ejemplo, servicios de autenticación y login de usuarios); no obstante, por lo demás es muy probable que ambas arquitecturas no tengan prácticamente nada en común, más allá de la motivación para la que fueron diseñadas (satisfacer necesidades de negocio).
Muchos analistas confunden los términos “arquitectura orientada a servicios” e “implementación orientada a servicios”. Este hecho añade confusión al debate y difumina el verdadero significado de los conceptos relacionados con SOA. Esto puede llevar a resultados nefastos a nivel empresarial.Confundir arquitectura con implementación genera resultados caóticos. Es por ello que, a menudo, me escandaliza ver artículos que tratan de explicar el concepto de SOA y derivan en un tutorial sobre cómo implementar servicios web y proporcionan guías de buenas prácticas de programación… Esta es una de las causas fundamentales por las que SOA es un concepto tan críptico hoy en día… Los esfuerzos para promover el uso de arquitecturas débilmente acopladas se centran en el ¿cómo? , no en el ¿qué? (contraposición de cuestiones a la que prometo dedicar una entrada en el futuro cercano, bueno, quizá medio... :-P)Como ya comentábamos, los conceptos asociados a SOA no son nuevos, muchos de ellos son evoluciones de ideas que fueron introducidas previamente por CORBA, DCOM, DCE y otras… Pero, a diferencia de estas iniciativas previas, la promesa clave de SOA es posibilitar la optimización de procesos de negocio a través de la interoperabilidad entre estándares abiertos.A pesar de que dichos estándares son importantes, no debemos olvidar que no son el concepto clave de SOA… Los estándares no definen una arquitectura, y una arquitectura no conduce unívocamente a una implementación concreta…
"Al fin y al cabo, será la implementación válida de una arquitectura bien diseñada la que generará beneficios de negocio, no la arquitectura en sí misma."
SOA es un enfoque arquitectural para la creación de sistemas construidos a partir de servicios independientes, autónomos. Con SOA, la integración entre dichos sistemas se diseña “a priori” frente al concepto tradicional en el cual la integración se construía “a posteriori”. Es por ello que la solución final tiende a ser un conjunto de servicios integrados, desarrollados en diferentes lenguajes, alojados en un conjunto heterogéneo de arquitecturas, en las cuales exista una gran variedad de modelos de seguridad, procesos de negocio…
A pesar de que este concepto pueda sonar complejo, insisto en que no se trata de algo tan novedoso, mucha gente coincide en afirmar que el concepto de SOA es la evolución lógica de experiencias asociadas con el diseño y desarrollo de sistemas distribuidos basados en tecnologías disponibles desde hace tiempo. Muchos de los conceptos asociados con SOA, como por ejemplo los servicios, el descubrimiento y el late binding ya existían en tiempos de CORBA y DCOM. De forma parecida, muchos principios de diseño de servicios comparten conceptos como la encapsulación, abstracción y definición de interfaces claros con la filosofía de orientación a objetos.
¿Significa el revuelo ocasionado por SOA y los servicios que las tecnologías de la información no estaban orientadas a servicios en el pasado? Realmente, NO, no significa eso… Sin la aplicación de dichos principios, el diseño e implementación de dichos sistemas habría sido inabordable.No obstante, hay un factor clave, determinante en el contexto empresarial que SOA aborda de una forma más efectiva que las filosofías anteriores: la capacidad de reacción al cambio. Si las tecnologías no son capaces de reaccionar y readaptarse a las necesidades y oportunidades empresariales de manera rápida, estas tecnologías serán percibidas como un freno y no como un factor optimizador de estos procesos.SOA se compromete a posibilitar una respuesta mucho más rápida por parte de estas tecnologías ante condiciones de mercado variables. Sin embargo, SOA es una filosofía arquitectural, y por ello no siempre resultará un concepto viable desde el punto de vista de su implementación sobre un determinado proceso de negocio. Cada organización puede tener diferentes requerimientos y expectativas para SOA debido a la gran variedad de necesidades de negocio y objetivos. Este hecho es una de las razones por las que describir SOA es un reto. SOA, como cualquier otra iniciativa, debe proporcionar un valor añadido para la organización. De lo contrario, no merece la pena ni sentarse a hablar sobre su posible adopción… La mejor forma para asegurarse de que la inversión en SOA proporcionará un retorno de la inversión favorable para una empresa es conseguir alinear los conceptos de SOA con los procesos de negocio claves para cada organización.
A pesar de esta obviedad, sigue existiendo mucha confusión en torno a SOA, algo sobre lo que espero aportar un poco más de luz en próximas entradas.