Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

SOA desde el Bottom Up - El Mejor Enfoque para la Arquitectura Orientada a Servicios La actitud general de las organizaciones de negocio hacia Service Oriented Architecture, o SOA,

ha cambiado significativamente sobre el curso de la existencia del término. Cuando SOA hizo su

primera aparición como una palabra de moda en los pasados 2000, el entusiasmo para el nuevo

modelo alcanzó rápidamente un punto culminante. Las compañías con grandes problemas de

infraestructura estuvieron tan seguras que SOA era el arreglo que ellos habían estado esperando

para lo cual estaban dispuestos a gastar millones de dólares en masivas iniciativas SOA top-down

con largas líneas de tiempo confusas de ROI.

Por el 2009, las cosas cambiaron. La Arquitectura Orientada a Servicios no fue más la reina de la

fiesta, por decir lo menos. La vasta mayoría de iniciativas SOA de radicales top-down que ha sido

lanzada con tales altas expectativas fallaron miserablemente, dejando las compañías millones de

dólares tirados y años atrás las mejoras arquitecturales. Algunos estudios estiman que tan sólo el

20% de las iniciativas SOA lanzadas en la cima de la popularidad del modelo fueron aún

completamente realizadas. La reacción negativa hacia SOA fue inmediata y fuerte que un analista

de la industria llegó tan lejos como para publicar una maqueta necrológica para SOA en su blog en

enero del 2009.

¿Por qué SOA aún es importante?

A la vista de tanto fracaso, la reacción es tal vez comprensible. Sin embargo, no podría estar más

fuera de lugar. Lejos de estar muerta, SOA es más relevante que nunca.

Los mismos problemas de infraestructura que existieron en los pasados 2000 siguen afectando a

las compañías de hoy, y con el clima económico demandante de hoy, aún más agilidad de las

empresas que quieren estar a la vanguardia de la industria, encontrar una forma para implementar

SOA es crucial. Mientras tanto, estas compañías que no administraron por completo sus iniciativas

SOA - Bechtel siendo el ejemplo más frecuentemente mencionado - vieron exactamente el

increíble ROI que fue prometido en el inicio del proceso.

De esto, podemos concluir una cosa: el enfoque de dejar todo top-down a SOA tiene la culpa por el

fracaso percibido del modelo, no la misma SOA.

En este artículo, vamos a echar un vistazo a algunas de las razones por las cuales estos esfuerzos

top-down anteriores de SOA fallaron, y cómo los frameworks de integración open source como

Mule ESB están haciendo el santo grial de SOA una realidad para muchas organizaciones, usando

un nuevo modelo de adopción de SOA bottom-up.

Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

Una breve historia de SOA Top-Down

A lo que los CIOs se enfrentaron fue con la tarea de administrar infraestructuras altamente

complejas, los beneficios ofrecidos por la Arquitectura Orientada a Servicios sonaron como un

sueño hecho realidad - los costos decrementarían, la productividad de los desarrolladores y del

negocio incrementaría, y la compañía estaría preparada para un futuro ágil.

El gran cambio introducido por el modelo SOA fueron arquitecturas diseñadas alrededor de

servicios, más que de aplicaciones. El concepto de servicios - pequeñas piezas independientes de

software que ejecutaban una sola tarea para cualquier programa que las invocara - fue nada

nuevo, habiendo estado en uso en las infraestructuras empresariales desde los 1980s. Lo que

SOA trajo a la tabla fue alcance de uso vastamente incrementado para estas pequeñas unidades

de funcionalidad.

El Modelo SOA Top Down

En este momento, las infraestructuras empresariales estuvieron llegando a ser cada vez más

inchadas y pesadas. Los nuevos servicios de negocio o automatización necesitan generalmente

que hubiéramos estado desarrollando nuevo software en casa. Estos nuevos programas

frecuentemente duplicaron funcionalidades que ya existía en otros programas internos.

Por ejemplo, si muchos programas requirieran checar información crediticia, cada programa

duplicaría todo el código requerido para ejecutar la verificación crediticia (o en el peor de los casos,

usar al mismo tiempo una diferente implementación). Cada programa nuevo representaba una

base de código adicional para los cuales los equipos de TI de las compañías serían responsables

para soportar, así como una sobrecarga adicional de la red. En otros casos, la complejidad de la

construcción de nuevas aplicaciones hechas en casa resultarían en caros contratos de trabajo

exteriores que podrían no integrarse sin problemas con otros programas existentes.

SOA ayudó a resolver estos problemas cambiando la práctica de desarrollo de las aplicaciones

internas hacia la creación de componentes reutilizables llamados servicios.

Primero, la compañía haría un mapeo comprensivo de las funcionalidades reales de que ellos

necesitaban de su infraestructura - ¿cuáles fueron las tareas que todos estos programas

personalizados habían estado creando para automatizar es primer lugar? ¿cómo se relacionan?

¿qué clases de formatos de datos y protocolos tendrían que interoperar?

A continuación, la compañía determinaría cómo cada una de estas funcionalidades podría ser

expresada no como una simple aplicación, sino como una colección de servicios. Por ejemplo, un

sistema de ordenamiento no sería un pensamiento de una sola pieza funcional, sino como una

combinación lógica de servicios de manejo de tarjetas de crédito, servicios de mantenimiento de

inventario, servicios de datos de los clientes, y más. Desde esta evaluación, la organización sería

capaz de identificar aquellos servicios que fueron comunes a toda aplicación, y construirlos en tal

forma que el mismo servicio sería reutilizable en todas las aplicaciones.

Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

Una vez que los servicios han sido creados, las diferentes aplicaciones que la compañía ha estado

usando antes podrían ser recreadas con mínimo código duplicado usando estas partes comunes.

Como una pieza adicional del plan, cualesquiera funcionalidades específicas a las nuevas

aplicaciones también habrían sido creadas como nuevos servicios, y hacerlas disponibles para

reutilización por cualesquiera aplicaciones posteriores que podrían requerirlas.

SOA crearía un ecosistema de componentes activamente actualizados de lógica de negocio, que

podría ser rápidamente ligado con mínima cantidad de código nuevo para crear programas ad-hoc

para manejar algunas necesidades de negocio, no importa cuán específicos.

Las cosas se vuelven amargas- ¿Por qué SOA Top Down no

funciona?

Mientras este audaz plan para implementar SOA se veía genial en papeles, cuando las compañías

intentaron ponerlo en acción, se encontraron rápidamente con dificultades. La mayoría de los

problemas fueron causados por conjuntos similares de suposiciones ingenuas sobre el

comportamiento organizacional que estuvo incluido en cada plan de adopción top-down.

Para comprender que estuvo mal, vamos a ver algunas de las erráticas ideas que causaron que

muchas de las iniciativas top-down de SOA fallaran.

Juicio de SOA Top Down: El "Equipo de Adopción" de SOA selecciona y compra un producto

propietario de Governance de SOA. Los equipos de desarrollo aprenderán entonces y usarán este

producto, para re-diseñar todos los sistemas existentes y para diseñar proyectos futuros.

Por qué no funciona: El gasto masivo combinado con la carencia de inversión en desarrolladores

y el encierro de los proveedores es una receta para el desastre.

En el modelo de SOA top-down, las compañías frecuentemente buscaron pasar la compleja tarea

de adopción de SOA a un sólo equipo. Entonces este equipo sería responsable para manejar todos

los aspectos de la adopción. En los días cuando SOA fue la palabra de moda más caliente de

todas, estos departamentos estuvieron bajo la dura presión de poner en lugar una SOA tan pronto

como fuera posible, y los proveedores de SOA estuvieron más que felices de aprovecharse de los

temores. Como resultado del primer paso en el proceso SOA para muchas compañías fue la

compra multimillonaria de un Framework de Governance de SOA.

Hay tres problemas con este enfoque. Primero, virtualmente garantiza el encierro de los

proveedores. Mientras el encierro de los proveedores es a veces tolerado por las compañías en los

productos servidores de aplicación, donde el ciclo de interoperabilidad es bastante cerrado,

absolutamente no tiene lugar en una arquitectura de integración. Es completamente difícil hacer

predicciones exactas sobre cómo tus necesidades pueden cambiar en el futuro sin tener que

hacer un compromiso multimillonario a la guía de una sola compañía. SOA es sobre lo que TU

Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

organización necesita - no a lo que un proveedor dice que necesitas. No olvides que tus

necesidades no son sólo una lista de sistemas que necesitan trabajar juntos - tu solución necesita

hacer las cosas más fáciles para tus desarrolladores y usuarios también.

Esto nos trae al segundo problema con la adopción del modelo top-down - adopción del

desarrollador. Tu equipo de desarrollo no se sienta a esperar la oportunidad para implementar SOA

por ti - de hecho, en adición a su carga de trabajo regular, ellos también probablemente se han

mantenido ocupados poniéndose día a día apagando los fuegos que ya afectan tu red. El esfuerzo

requerido para cambiar a un nuevo modelo no es tan trivial por su cuenta. Cuando se combina con

un mandato superior para usar una nueva herramienta simplemente debido a que eso es lo que la

compañía ha comprado, la tarea puede llegar a ser insuperable. Sólo algunos bugs o defectos de

diseño en la herramienta SOA pueden ser suficientes para hacer que un atareado equipo de

desarrollo esté menos entusiasmado sobre el proyecto completo.

Finalmente, vamos a hablar sobre el dinero. SOA es una gran oportunidad. Haciendo una

inversión inicial completa en un sólo producto es una forma segura de poner en modo pánico a tu

organización completa, cuando aquello que necesitas es un plan ordenado, claro, que puedas

implementar de forma incremental, con mucha de la entrada de todas las armas de tu

organización. Esto te permite asegurar que cada parte trabaja perfectamente - integración,

servicios, mejores prácticas, adopción - sin interrumpir tus operaciones diarias o sobrecargar a tus

equipos.

Juicio de SOA Top Down SOA: SOA significa un paradigma de cambio a toda la empresa, y el

esfuerzo de todos confía en el de los demás. Así, el cambio completo debe suceder de forma

simultánea.

Por qué no funciona: La mayoría de las organizaciones no tienen los recursos para dejar todo y

enfocarse en SOA. SOA que cae del cielo son castillos en el aire - no es una adopción incremental

bien planeada.

Cuando se trata con una tarea tan complicada como implementar SOA, la cantidad de cambios que

necesitan hacerse pueden ser intimidantes. Es tentador pensar de la situación como un "catch 22" -

no podemos empezar a usar SOA sin escribir los servicios, y no podemos escribir los servicios sin

comprender nuestro modelo SOA. Sólo hay una forma de que este catch 22 - el dejar todo, quitar y

remplazar el modelo SOA, donde todo, desde los procesos de desarrollo hasta hardware es

cambiado de forma simultánea.

¿El problema? Este enfoque es estáticamente probado que falla. Para la mayoría de las

organizaciones, elegir este modelo es una forma segura de matar tus planes de SOA.

Afortunadamente, SOA no es tanto de lo que un Catch 22 se parece. Desde una perspectiva top-

down, SOA puede parecer como una iniciativa irreductiblemente compleja. Pero desde el bottom-

up, SOA es una proposición sensible, manejable. Hemos visto esto una y otra vez en la comunidad

Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

de usuarios de Mule. Los buenos desarrolladores comprenden el valor del desarrollo orientado a

servicios.

Las tecnologías de ESB Open-source tales como Mule le permiten a los desarrolladores seguir

mejores prácticas para SOA sin un modelo de gobierno pesado, construyendo interfaces RESTful

que pueden ser reutilizadas de forma correcta, y se integrarán sin problemas con cualquier modelo

de gobierno SOA como la empresa avance. A veces, un nuevo Web Service no es aún lo que

necesitas - si ya tienes en su lugar una solución bien diseñada, simplemente usa componentes

Mule para conectarlos rápidamente al resto de tu arquitectura, y pasar a una zona donde el

desembolso inicial asociado con la construcción de un nuevo servicio obtenga un mayor margen de

valor a tu organización. Empieza a evangelizar a tus equipos hoy, consigue engancharlos, y luego

gradualmente introduce un gobierno SOA ligero, inteligente a un ritmo que coincida con los

recursos reales de tus desarrolladores disponibles.

Juicio de SOA Top Down: El Repositorio de Servicios SOA le ahorra tiempo a los desarrolladores

proporcionándoles componentes reutilizables. Eso es el por qué los equipos deben mantener

actualizada toda la información en el repositorio.

Por qué no funciona: El punto de SOA es hacer el desarrollo más fácil, no cargar a los

desarrolladores hacia abajo con tareas tediosas (manuales). Tu solución SOA debe automatizar la

catalogación de los servicios.

Al igual que muchas suposiciones hechas por los defensores de SOA top-down, este enfoque está

basado en la idea que los desarrolladores son un recurso, no equipos de profesionales expertos.

Piensa del cambio a SOA como una venta que estás haciendo a tu compañía. La proposición de

valor es el desarrollo más rápido, la facilidad de administración, y menos tiempo haciendo el trabajo

tedioso de integración. Eso es el porqué es un caso de disonancia cognitiva grave de hacer a tus

desarrolladores responsables para mantener actualizado tu repositorio - estás básicamente

diciéndoles que lleguen a ser más productivos y menos aburridos en el trabajo haciendo talacha

adicional aburrida.

Un buen modelo de Gobierno SOA siempre hace las cosas más fáciles y reduce complejidad.

Usando componentes open source de Mule, nuestros usuarios han construido algunas

maravillosas herramientas que permiten SOA bottom-up - cosas como clases Java con metadatos

que llenan automáticamente el repositorio con información de los servicios, o integración REST del

repositorio, colocando todos los servicios directamente en frente de los desarrolladores.

Cuando es combinado con un enfoque que no requiere millones de dólares como su primer paso,

esto significa que puedes agregar herramientas adicionales que reducen la complejidad de forma

que las tecnologías SOA continúen madurando o los verdaderos puntos débiles salgan a la

superficie, preparando para el futuro tu arquitectura y estén continuamente mejorando tu ROI.

Java Developers Mexico https://www.facebook.com/JavaDevelopersMexico

Juicio de SOA Top Down: La clave para una SOA exitosa es un cambio cultural organizacional

hacia las decisiones de arquitectos "virtuosos".

Por qué no funciona: La clave para una SOA exitosa es un plan hecho de un conjunto de metas

alcanzables, claras, con beneficios bien definidos.

Sí, "virtuoso" fue realmente una palabra que fue usada por los defensores de SOA top-down para

describir el proceso de adopción. La idea fue que SOA era para sentirnos bien, que todos la

adoptarían no sólo como una tecnología ahorradora de tiempo sino como una ideología.

Esta es una buena forma de pensar, pero también es una buena forma de hundir tus esfuerzos de

SOA dejando a tu equipo en la oscuridad. SOA no se trata de ideología. Se trata de hacer las

cosas en la forma más simple y eficiente. Los equipos están motivados por objetivos de desarrollo

alcanzables, claros, que han sido probados, con beneficios claramente definidos. Abandonar el

rollo publicitario suave de SOA top-down, y mostrarle a tus equipos cómo los simples cambios son

la forma en que ellos piensan sobre el desarrollo resultará en una mayor productividad.

SOA Bottom-Up - Un Modelo de Adopción de SOA que

realmente funciona Después de más de 10 años de esfuerzos fallidos de SOA, está claro que la filosofía top-down

tradicional de SOA está anticuada y obsoleta – un nuevo enfoque es necesario para que las

organizaciones de hoy vean el valor real.

El foco debe ser en hacer las cosas más fáciles para todos, no se trata de arquitecturas virtuosas;

sobre mejorar las estructuras organizacionales existentes y procesos más que reingeniería al por

mayor; sobre implementar herramientas pragmáticas a nivel de grupo de trabajo más que

agobiarlos con herramientas de governance inchadas de multi-millones de dólares.

Mule ESB, el ESB open source más ampliamente usado del mundo, es un framework open source

de integración que simplemente funciona. Herramientas open source y ligeras como Mule ESB

cambian completamente la ecuación de costo, así como el patrón de adopción de SOA,

permitiéndoles a los equipos de desarrollo implementar proyectos habilitados por SOA en una

manera bottom-up. De hecho, Mule es tan sencillo que hemos visto a algunos desarrolladores

implementar desarrollo orientado a servicios y seguir principios SOA sin saber (o tomar cuidado) de

que ellos de hecho están haciendo, SOA.

No se necesitan vendedores de SOA viniendo a llamar a la puerta lanzando SOA, y no necesitas

justificar grandes gastos de licencias y entrenamientos de software propietario (sin mencionar el

nuevo hardware o sistemas de desarrollo actualizado que podrían ser requeridos para ejecutar la

pila de proveedores típica). Reconoce un problema (o una oportunidad), descubre cómo otros

están actualmente construyendo soluciones similares, y empieza a aprender que herramientas

disponibles se ajustan mejor a tu proyecto.