Gran parte de las organizaciones están innovando y adoptando soluciones SOA con el objetivo de crear sistemas que puedan ser modificados y configurados rápidamente, para poder proporcionar mayor flexibilidad y adaptabilidad a los cambios del negocio. Para ello, se requieren también cambios organizativos que permitan el acercamiento entre las unidades de negocio y tecnológicas. La realidad es que este intento es costoso y doloroso para una compañía grande; ni mencionar lo que es para una pyme.
Ahora, ¿que es en si SOA? Es un estilo de arquitectura tecnológica que explota los principios de orientación a servicios, con el objetivo de conseguir una relación más estrecha entre los sistemas de negocio y de información que soportan la actividad de una empresa. La orientación a servicios permite a las aplicaciones interactuar entre sí, considerando sus funcionalidades como servicios que pueden ser vistos como “una tarea repetible dentro de un proceso de negocio”. Un servicio es auto-descriptivo, permite su descubrimiento, cumple requisitos de calidad, puede ser gestionado a través de procesos de gobierno (conocido como SOA Governance) y tiene sentido, tanto para el negocio, como para las áreas de IT. De ese modo se obtiene un conjunto de servicios relacionados e integrados que permiten dar soporte a un proceso de negocio construido en SOA.
Para la mayoría, la flexibilidad es el sello distintivo y el principal atractivo de (SOA). En ella, los componentes de aplicaciones se vuelven fácilmente reutilizables y pueden compartirse a través de toda la compañía, así como ensamblarse de forma más flexible. Sin embargo, es esa misma flexibilidad la que se traduce en la impredecibilidad dentro de los Data Centers, una característica incompatible con las tecnologías de gestión de infraestructura tradicionales.
En una arquitectura SOA se hace mucho más difícil, inicialmente, disponer de un mapa claro de las dependencias entre aplicaciones. Por ende, se hace también difícil predecir la carga que pueden llegar a tener los recursos sobre los que corren como consecuencia de la demanda del consumo en las transacciones.
Ahora, hemos dicho que se hace difícil SOA y que puede ser incompatible con la infraestructura tradicional, entonces, si es tan difícil, ¿por qué se está poniendo de moda?. Desde mi punto de vista, SOA no es WebServices ni tampoco BPM. No puede pensarse en SOA solo como el consumo de servicios a través de http o la ejecución de un proceso de negocio. He leído que se suele confundir bastante el concepto, donde BPEL es SOA, WSDL es SOA ó MQ es SOA. Mi definición de SOA se sintetiza en que es una arquitectura, y como toda arquitectura de software, definirá método, objetivos, restricciones, uso de herramientas y permitirá diferentes niveles de visión de los problemas y las soluciones, vistos ambos desde el concepto de servicios.
En referencia a lo expuesto, decir que se hace difícil SOA, es porque se debe entender, que esta debe llevar una definición de Arquitectura al comenzar a utilizarse en cualquier proyecto de software y no debe entenderse solo como la implementación de una herramienta. Los proyectos en los que he participado tienen la problemática de ver solamente los procesos de negocio o la implementación de las herramientas. Y la realidad, es que la brecha entre una cosa y la otra es tan grande (sin pensar en grandes procesos), que hay muchos huecos que quedan sin cubrir. Ahí es donde se hace fundamental entender el concepto de arquitectura, el papel que debe aplicar un arquitecto de software en la implementación de una solución y en los diferentes niveles de visión que debe tener y proveer la arquitectura. Estos niveles de visión deben ser tales, que los usuarios finales entiendan los servicios, de la misma manera que se desarrolla, o que infraestructura monitorea su ejecución operativa.
En conclusión, se hace imprescindible un cambio organizacional y cultural considerable y que los responsables del negocio, los desarrolladores y arquitectos y los equipos de Data Centers colaboren más estrechamente, desde la concepción del problema y las soluciones, sin perder de vista la arquitectura. Es en ese sentido que aparece SOA Governance planteando una visión para enfrentar y llevar adelante la implementación de servicios, funcionando para resolver problemas del negocio actual y fácilmente adaptables a los cambios del negocio. SOA Governance tiene como principal meta alinear el mundo del negocio con el mundo de las Tecnologías de Información para conseguir que ambos sean más efectivos y flexibles. SOA supone que el negocio tiene un diseño que describe cómo funciona, con especial atención a los procesos que realiza y a la estructura organizativa que los posibilita. Ahí es donde se genera la primer diferencia que hace difícil implementar proyectos SOA, ya que el negocio puede tener cierta definición y hasta documentación detallada, pero de seguro no está orientada hacia servicios.
Ese es el primer camino que debe seguirse. Los arquitectos que intervengan en los proyectos SOA, son el nexo para realizar la evangelización necesaria en el negocio sobre el pensamiento, orientado a servicios; y también son el nexo entre las áreas de operaciones para entender las problemáticas de servicios (entendimiento de las problemáticas sincrónicas y asincrónicas como primera medida). Estas problemáticas son entendibles tanto para los responsables del negocio, como para los desarrolladores y los responsables de infraestructura.
Acá es donde la moda deja de ser moda; donde la visibilidad de la comunidad espera una evolución de estas fortalezas, y cree que teniendo herramientas que vayan evolucionando, se generen precedentes de implementación estables y mas seguros; además de poder ser utilizado en cualquier ámbito y que realmente cumpla lo que promete: flexibilidad y adaptación rápida al negocio.
Facundo G. Allegue
Líder de Desarrollo de Huenei SW Factory.
No hay comentarios:
Publicar un comentario