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)

Problemas y desafíos de la arquitectura de software

Las siguientes figuras son obtenidas de fuentes de prestigio y reconocimiento en la industria TI, y evidencian un problema general dentro de la industria del desarrollo de software:

Arquitectura de la aplicación Java EE PetStore

Fuente: Originalmente de http://sun.java.com, pero obtenida de www.theserverside.com

Arquitectura de servidor de mensajería Sun Java CommunicationSuite

Fuente: http://www.oracle.com
 

Arquitectura del Microframework .Net

Fuente: http://msdn.microsoft.com

La documentación de los sistemas de software generalmente incluyen una sección denominada “arquitectura del sistema”, la cual presenta una serie de diagramas similares a los expuestos.

Si bien a primera vista estos diagramas parecieran ser una buena guía para entender el sistema, una observación más cuidadosa permite constatar que todos ellos se caracterizan por:

·         la utilización de texto descriptivo y la utilización de diagramas de cajas y líneas

·         tener muy baja precisión, y ser más bien informales.

·         apelar a la intuición y pericia técnica del lector.

El uso de estos diagramas, hacen que en general la arquitectura de software sea considerado por muchos una “vista de alto nivel” del sistema, muchas veces abstracta e inherentemente imprecisa. Esto hace que las definiciones de  arquitectura sean sólo un punto de partida, y estén muy lejos de cumplir el rol de su análogo en la industria de la construcción.

De ahí que la ya no tan incipiente disciplina de arquitectura de software, tenga como sus grandes desafíos establecer los lineamientos teóricos y prácticos para que la arquitectura de software sea utilizada como un artefacto de ingeniería, basada en principios claros y no en definiciones ad-hoc, capaz de contribuir a (i) la comunicación entre las diferentes partes involucradas y (ii) la reducción del riesgo en el desarrollo mediante la captura precisa de las principales decisiones técnicas.

Otro gran desafío de la disciplina es la de permitir la construcción de sistemas con una base arquitectónica sólida e intelectualmente manejable. Como objetivos relacionados, se busca que los sistemas:

·         Puedan ser construidos en función de una composición de partes

·         Adhieran a la arquitectura definida para su construcción, manifestando en consecuencia las propiedades deseadas para ellos.

·         Utilicen crecientes grados de arquitecturas de integración estándares

·         Sean documentados de manera que la organización que los crea pueda reutilizar el conocimiento arquitectónico

·         Reducir los costos de producción de sistemas a gran escala mediante la definición de líneas de productos.

Fuentes:

• Notas del Curso de Arquitectura de Software, dictado por los Profesores David Garlan y Anthony Lattanze, en el programa de Master en Ingeniería de Software de la Universidad de Carnegie Mellon.
• www.theserverside.com
• www.oracle.com
• msdn.microsoft.com

Exploraciones de factibilidad técnica para SOA: consideraciones metodológicas.

La mayoría de las organizaciones, en sus etapas tempranas de adopción de SOA, se ven en la necesidad de tomar decisiones que determinarán de manera crítica el curso que seguirá la iniciativa en el futuro. Muchas de las decisiones a nivel de arquitectura tomadas durante esta etapa, conllevan el riesgo de imponer fuertes penalidades en caso de ser incorrectas. Es aquí donde se produce la mayor cantidad de errores tales como: adquisiciones innecesarias, lock in innecesario con proveedores de tecnología, elaboración de arquitecturas demasiado complejas para la realidad organizacional, incorporación de metodologías incorrectas y formación de estructuras organizacionales erróneas e ineficaces.

La mitigación de estos riesgos requiere de muchos elementos. Uno que me interesa mencionar tiene relación con el post previo respecto a la realización de las pruebas de factibilidad técnica: La adecuada planificación y realización de ellas puede tener beneficios extra en cuanto a la reducción del riesgo de cometer uno o más de los errores mencionados (y otros no mencionados). En particular, la selección de un escenario pequeño, pero que tenga funcionalidad que permita cubrir de punta a punta de todas las capas del stack de solución SOA, tiene la virtud de permitir a las organizaciones obtener información suficiente para recalibrar el alcance y complejidad de su iniciativa SOA, en caso de ser necesario.

Sin embargo, el éxito las pruebas será fuertemente afectado por las metodologías utilizadas para su desarrollo. En este aspecto, resulta ideal que el equipo a cargo de ellas tenga adecuadamente internalizados los cambios metodológicos a nivel de desarrollo que se desprenden del cambio de paradigma. A modo de ejemplo, si una organización tradicionalmente a usado el Proceso de Desarrollo Rational (RUP) para desarrollo de aplicaciones multicapas, el equipo de pruebas de factibilidad técnica debiera estar familiarizado, por ejemplo, con su extensión SOMA (Service Oriented Modeling and Architecture) para desarrollar aplicaciones SOA (incluso a nivel de notación, el equipo a cargo de las pruebas debiera conocer el perfil de UML soaML).

Si el equipo cuenta el conocimiento de metodologías “actualizadas” para el desarrollo en SOA, se pueden aprovechar estos ejercicios de factibilidad técnica para revisar que tan idónea es la metodología de desarrollo seleccionada, y realizar correcciones antes de institucionalizarla para desarrollos de mayor escala. Sin embargo, esto se debe hacer con sumo cuidado, ya que una “sobrecarga metodológica” podría poner en riesgo los objetivos principales de las pruebas de factibilidad técnica.

En caso de que el equipo no cuente con los conocimientos metodológicos adecuados, se está frente a un problema que podría poner en riesgo el éxito de las pruebas, situación que debe ser remediada incluso antes de iniciarlas.

Referencias:

1. SOA Governance: Achieving and Sustaining Business and IT Agility
2. Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA
3. Service oriented architecture Modeling Language (SoaML)

Instalación de Websphere en Ubuntu atascada en el script importConfigArchive

Debido a que Ubuntu tiene enlazado el shell sh a /bin/dash, en vez de a /bin/bash, la instalación del servidor de aplicaciones Websphere se queda atascada al ejecutar el script importConfigArchive durante la creación de un perfil.

Esto se puede corregir de la siguiente manera:

sudo -i
cd /bin
unlink sh
ln -s /bin/bash sh

Una vez ejecutados estos comandos, la instalación y posterior creación del perfil concluyen sin problemas.
Aunque obviamente no es recomendable reenlazar scripts provistos por el sistema operativo, no he visto efectos secundarios.
Esto se probó en Ubuntu 11.10 para un servidor Websphere 8.x

Fuentes:
http://www.pingudownunder.com/2009/09/10/getting-websphere-application-7-installed-on-ubuntu-9-04/

Exploraciones de factibilidad técnica al comienzo de una iniciativa SOA

Para mitigar los riesgos inherentes a un cambio de paradigma, y sobretodo uno como SOA que podría tener un impacto en toda la organización, resulta altamente recomendable realizar una exploración de factibilidad técnica las durante fases tempranas de la iniciativa. Esta es una práctica generalmente realizada cuando la tecnología es poco conocida o no se ha probado previamente, y existe un grado de complejidad que no permite incorporarla en un plan de proyecto sobre la base de conjeturas o analogías.

Las exploraciones de factibilidad técnica generalmente se materializan a través de una serie de pruebas de conceptos. Estas exploraciones debieran ser identificadas y acotadas en su alcance durante las fases iniciales del proyecto, ejecutadas, para luego utilizar sus salidas y resultados para obtener un adecuado conocimiento de la complejidad tecnológica, las complicaciones de implementar un servicio en ella y para refinar las decisiones de arquitectura y diseño. Este entendimiento extra es un gran apoyo para la adecuada asignación de recursos (tiempo, personal, pericia) conmensurable a la complejidad de la implementación de servicios.

En mi experiencia, si la organización tiene como política externalizar el desarrollo de sus aplicaciones, entonces resulta altamente conveniente externalizar la realización de estas pruebas de concepto, solicitando a potenciales proveedores que realicen ejercicios en la tecnología dada, o muestren implementaciones echas por ellos donde se demuestre que han utilizado exitosamente la tecnología. La razón detrás de esto, es que muchas veces las empresas desarrolladoras presentan propuestas donde aseguran contar con los conocimientos necesarios para realizar el proyecto, pero una vez adjudicado, se evidencian severas faltas de pericia en herramientas claves, lo que puede ser agravado por la indisponibilidad de expertos reales en el país e incluso en el continente.

Independiente de si el desarrollo es interno o externalizado, un enfoque que parece ser altamente efectivo en la reducción de riesgos es la utilización de las fases del Proceso Unificado Rational (RUP) de IBM, donde en su fase de elaboración (en la que aún no se invierte más del 30% del presupuesto), se implementan uno o más requerimientos que aseguren que todas las decisiones tecnológicas son factibles. Cualquier problema detectado en esta actividad, que pueden ir desde la detección de la falta de competencias técnicas en el personal disponible hasta incompatibilidades entre los productos de middleware escogidos (incluso si son de un mismo proveedor), implica una alerta roja que debe llevar a una reflexión sobre la conveniencia de continuar el proyecto en esas condiciones, o realizar cambios a los planes y la estrategia de desarrollo.

Referencias:

SOA Governance: Achieving and Sustaining Business and IT Agility

Determinación del alcance de una iniciativa SOA

Los proyectos con una inadecuada definición de alcance son altamente propensos a tener problemas, y dejar a más de una parte interesada disconforme. Los proyectos en SOA obviamente no son la excepción.

Sin embargo, iniciativa de transformación a SOA se caracteriza por requerir un alineamiento más notorio con los objetivos del negocio, ya que dada la magnitud y complejidad de estas iniciativas se requiere de un patrocino ejecutivo que se mantenga indeleble.

Para lograr una definición precisa del alcance, y conducente a los objetivos de la iniciativa SOA, se puede utilizar una técnica denominada “modelado servicio-objetivo”, la cual utiliza los objetivos del negocio para la definición y restricción del alcance. Muy en resumen, esta técnica se centra en identificar los objetivos de negocio, articulándolos de manera precisa, luego priorizándolos y finalmente obteniendo un acuerdo consensuado, respaldado por la firma de cada uno de los terceros relevantes de la iniciativa. Luego estos objetivos son utilizados para determinar cuales servicios y aplicaciones están dentro del alcance de la transformación organizacional, dejando sólo a aquellos donde se puede establecer una traza directa hacia la realización de los objetivos de negocio priorizados que la organización tiene más interés en lograr.

Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility

Estandarización de estructuras de datos para la adopción de SOA

Dentro de los múltiples factores que deben ser abordados para lograr una adecuada adopción de SOA dentro de una organización, uno de los más relevantes y que debe ser abordado tempranamente es el de la estandarización de sus estructuras de datos. Una organización que posee un modelo de datos común está en muy buen pie para lograr buenos niveles de reutilización y flexibilidad organizacional.

Sin embargo, es muy probable que la existencia de un modelo de datos común y transversal sea más la excepción que la regla, y que la mayor parte de las organizaciones de gran tamaño tengan bases de datos con esquemas redundantes. También puede que la documentación de los modelos de datos no esté disponible, o sea propietaria. Por último, es muy probable que el grado de acoplamiento, o dependencia estructural, entre las aplicaciones de software y sus respectivos modelos de datos sea tan alto que haga imposible su modificación a un costo razonable. Debido a todo lo anterior, una iniciativa de adopción de SOA debe tomar la estandarización de datos desde otro ángulo, buscando la estandarización de las estructuras a nivel de mensajería. Como paso concreto, la organización debiera instaurar mecanismos para estandarizar y gobernar todos sus esquemas XML.

Antes de empezar a realizar un levantamiento de todas las estructuras de datos relevantes, y de comenzar generar un modelo de datos común para toda la organización, se debe investigar si existen modelos estándares aportados por la industria para el dominio concreto del negocio (por ejemplo, modelos para la industria de seguros, naviera, financiera, etc.,) o para un dominio transversal, como por ejemplo el de recursos humanos. Existen organizaciones como OASIS (www.oasis-open.org) que se dedican a la creación de estándares abiertos, y cuentan con sitios tales como www.xml.org enfocados en áreas específicas de negocios.

De existir tales modelos, debe privilegiarse su uso, pues facilitará la interoperación con organizaciones externas y la integración entre sistemas internos. Un modelo levantado sin esta consideración muy probablemente requerirá de transformaciones para interoperar fuera del ámbito en que fue concebido, lo que llevará a múltiples problemas que pueden ser evitados, como mayores costos de hardware y middleware, y perdidas de desempeño en las aplicaciones que requieran de tales transformaciones.

En caso de adoptar la estrategia de adoptar modelos estandarizados para una industria o negocio específico, se deben tomar acciones para mitigar el riesgo de que, debido al tamaño y la complejidad que muchas veces tienen estos modelos, los proyectos SOA se vean inesperadamente impactados en su avance. La adopción de esta estrategia es una apuesta al largo plazo, que fácilmente puede poner en peligro un proyecto con plazos y presupuesto limitados, y que tenga un acercamiento ingenuo en torno al esfuerzo que implica adoptar estos modelos.

Referencias:
SOA Governance: Achieving and Sustaining Business and IT Agility