1. 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.

2. 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.

3. 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

4. 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

5. 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.

6. 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.