Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

El mejor enfoque para una arquitectura orientada a servicios

  • Be the first to comment

  • Be the first to like this

El mejor enfoque para una arquitectura orientada a servicios

  1. 1. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicoSOA desde el Bottom Up - El Mejor Enfoquepara la Arquitectura Orientada a ServiciosLa 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 suprimera aparición como una palabra de moda en los pasados 2000, el entusiasmo para el nuevomodelo alcanzó rápidamente un punto culminante. Las compañías con grandes problemas deinfraestructura estuvieron tan seguras que SOA era el arreglo que ellos habían estado esperandopara lo cual estaban dispuestos a gastar millones de dólares en masivas iniciativas SOA top-downcon 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 lafiesta, por decir lo menos. La vasta mayoría de iniciativas SOA de radicales top-down que ha sidolanzada con tales altas expectativas fallaron miserablemente, dejando las compañías millones dedólares tirados y años atrás las mejoras arquitecturales. Algunos estudios estiman que tan sólo el20% de las iniciativas SOA lanzadas en la cima de la popularidad del modelo fueron aúncompletamente realizadas. La reacción negativa hacia SOA fue inmediata y fuerte que un analistade la industria llegó tan lejos como para publicar una maqueta necrológica para SOA en su blog enenero 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ásfuera 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 alas compañías de hoy, y con el clima económico demandante de hoy, aún más agilidad de lasempresas que quieren estar a la vanguardia de la industria, encontrar una forma para implementarSOA es crucial. Mientras tanto, estas compañías que no administraron por completo sus iniciativasSOA - Bechtel siendo el ejemplo más frecuentemente mencionado - vieron exactamente elincreí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 elfracaso 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 esfuerzostop-down anteriores de SOA fallaron, y cómo los frameworks de integración open source comoMule ESB están haciendo el santo grial de SOA una realidad para muchas organizaciones, usandoun nuevo modelo de adopción de SOA bottom-up.
  2. 2. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicoUna breve historia de SOA Top-DownA lo que los CIOs se enfrentaron fue con la tarea de administrar infraestructuras altamentecomplejas, los beneficios ofrecidos por la Arquitectura Orientada a Servicios sonaron como unsueño hecho realidad - los costos decrementarían, la productividad de los desarrolladores y delnegocio 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 deservicios, más que de aplicaciones. El concepto de servicios - pequeñas piezas independientes desoftware que ejecutaban una sola tarea para cualquier programa que las invocara - fue nadanuevo, habiendo estado en uso en las infraestructuras empresariales desde los 1980s. Lo queSOA trajo a la tabla fue alcance de uso vastamente incrementado para estas pequeñas unidadesde funcionalidad.El Modelo SOA Top DownEn este momento, las infraestructuras empresariales estuvieron llegando a ser cada vez másinchadas y pesadas. Los nuevos servicios de negocio o automatización necesitan generalmenteque hubiéramos estado desarrollando nuevo software en casa. Estos nuevos programasfrecuentemente duplicaron funcionalidades que ya existía en otros programas internos.Por ejemplo, si muchos programas requirieran checar información crediticia, cada programaduplicarí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 unabase de código adicional para los cuales los equipos de TI de las compañías serían responsablespara soportar, así como una sobrecarga adicional de la red. En otros casos, la complejidad de laconstrucción de nuevas aplicaciones hechas en casa resultarían en caros contratos de trabajoexteriores 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 aplicacionesinternas hacia la creación de componentes reutilizables llamados servicios.Primero, la compañía haría un mapeo comprensivo de las funcionalidades reales de que ellosnecesitaban de su infraestructura - ¿cuáles fueron las tareas que todos estos programaspersonalizados 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 serexpresada no como una simple aplicación, sino como una colección de servicios. Por ejemplo, unsistema de ordenamiento no sería un pensamiento de una sola pieza funcional, sino como unacombinación lógica de servicios de manejo de tarjetas de crédito, servicios de mantenimiento deinventario, servicios de datos de los clientes, y más. Desde esta evaluación, la organización seríacapaz de identificar aquellos servicios que fueron comunes a toda aplicación, y construirlos en talforma que el mismo servicio sería reutilizable en todas las aplicaciones.
  3. 3. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicoUna vez que los servicios han sido creados, las diferentes aplicaciones que la compañía ha estadousando 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 nuevasaplicaciones también habrían sido creadas como nuevos servicios, y hacerlas disponibles parareutilización por cualesquiera aplicaciones posteriores que podrían requerirlas.SOA crearía un ecosistema de componentes activamente actualizados de lógica de negocio, quepodría ser rápidamente ligado con mínima cantidad de código nuevo para crear programas ad-hocpara manejar algunas necesidades de negocio, no importa cuán específicos.Las cosas se vuelven amargas- ¿Por qué SOA Top Down nofunciona?Mientras este audaz plan para implementar SOA se veía genial en papeles, cuando las compañíasintentaron ponerlo en acción, se encontraron rápidamente con dificultades. La mayoría de losproblemas fueron causados por conjuntos similares de suposiciones ingenuas sobre elcomportamiento 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 quemuchas de las iniciativas top-down de SOA fallaran.Juicio de SOA Top Down: El "Equipo de Adopción" de SOA selecciona y compra un productopropietario de Governance de SOA. Los equipos de desarrollo aprenderán entonces y usarán esteproducto, 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 desarrolladoresy 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 tareade adopción de SOA a un sólo equipo. Entonces este equipo sería responsable para manejar todoslos aspectos de la adopción. En los días cuando SOA fue la palabra de moda más caliente detodas, estos departamentos estuvieron bajo la dura presión de poner en lugar una SOA tan prontocomo fuera posible, y los proveedores de SOA estuvieron más que felices de aprovecharse de lostemores. Como resultado del primer paso en el proceso SOA para muchas compañías fue lacompra multimillonaria de un Framework de Governance de SOA.Hay tres problemas con este enfoque. Primero, virtualmente garantiza el encierro de losproveedores. Mientras el encierro de los proveedores es a veces tolerado por las compañías en losproductos 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 hacerpredicciones exactas sobre cómo tus necesidades pueden cambiar en el futuro sin tener quehacer un compromiso multimillonario a la guía de una sola compañía. SOA es sobre lo que TU
  4. 4. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicoorganización necesita - no a lo que un proveedor dice que necesitas. No olvides que tusnecesidades no son sólo una lista de sistemas que necesitan trabajar juntos - tu solución necesitahacer 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 deldesarrollador. Tu equipo de desarrollo no se sienta a esperar la oportunidad para implementar SOApor ti - de hecho, en adición a su carga de trabajo regular, ellos también probablemente se hanmantenido ocupados poniéndose día a día apagando los fuegos que ya afectan tu red. El esfuerzorequerido para cambiar a un nuevo modelo no es tan trivial por su cuenta. Cuando se combina conun mandato superior para usar una nueva herramienta simplemente debido a que eso es lo que lacompañía ha comprado, la tarea puede llegar a ser insuperable. Sólo algunos bugs o defectos dediseño en la herramienta SOA pueden ser suficientes para hacer que un atareado equipo dedesarrollo esté menos entusiasmado sobre el proyecto completo.Finalmente, vamos a hablar sobre el dinero. SOA es una gran oportunidad. Haciendo unainversión inicial completa en un sólo producto es una forma segura de poner en modo pánico a tuorganización completa, cuando aquello que necesitas es un plan ordenado, claro, que puedasimplementar de forma incremental, con mucha de la entrada de todas las armas de tuorganizació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 tusequipos.Juicio de SOA Top Down SOA: SOA significa un paradigma de cambio a toda la empresa, y elesfuerzo de todos confía en el de los demás. Así, el cambio completo debe suceder de formasimultánea.Por qué no funciona: La mayoría de las organizaciones no tienen los recursos para dejar todo yenfocarse en SOA. SOA que cae del cielo son castillos en el aire - no es una adopción incrementalbien planeada.Cuando se trata con una tarea tan complicada como implementar SOA, la cantidad de cambios quenecesitan 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 sincomprender nuestro modelo SOA. Sólo hay una forma de que este catch 22 - el dejar todo, quitar yremplazar el modelo SOA, donde todo, desde los procesos de desarrollo hasta hardware escambiado de forma simultánea.¿El problema? Este enfoque es estáticamente probado que falla. Para la mayoría de lasorganizaciones, 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. 5. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicode usuarios de Mule. Los buenos desarrolladores comprenden el valor del desarrollo orientado aservicios.Las tecnologías de ESB Open-source tales como Mule le permiten a los desarrolladores seguirmejores prácticas para SOA sin un modelo de gobierno pesado, construyendo interfaces RESTfulque pueden ser reutilizadas de forma correcta, y se integrarán sin problemas con cualquier modelode gobierno SOA como la empresa avance. A veces, un nuevo Web Service no es aún lo quenecesitas - si ya tienes en su lugar una solución bien diseñada, simplemente usa componentesMule para conectarlos rápidamente al resto de tu arquitectura, y pasar a una zona donde eldesembolso inicial asociado con la construcción de un nuevo servicio obtenga un mayor margen devalor a tu organización. Empieza a evangelizar a tus equipos hoy, consigue engancharlos, y luegogradualmente introduce un gobierno SOA ligero, inteligente a un ritmo que coincida con losrecursos reales de tus desarrolladores disponibles.Juicio de SOA Top Down: El Repositorio de Servicios SOA le ahorra tiempo a los desarrolladoresproporcionándoles componentes reutilizables. Eso es el por qué los equipos deben manteneractualizada 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 losdesarrolladores hacia abajo con tareas tediosas (manuales). Tu solución SOA debe automatizar lacatalogació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 devalor es el desarrollo más rápido, la facilidad de administración, y menos tiempo haciendo el trabajotedioso de integración. Eso es el porqué es un caso de disonancia cognitiva grave de hacer a tusdesarrolladores responsables para mantener actualizado tu repositorio - estás básicamentediciéndoles que lleguen a ser más productivos y menos aburridos en el trabajo haciendo talachaadicional 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 algunasmaravillosas herramientas que permiten SOA bottom-up - cosas como clases Java con metadatosque llenan automáticamente el repositorio con información de los servicios, o integración REST delrepositorio, 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 formaque las tecnologías SOA continúen madurando o los verdaderos puntos débiles salgan a lasuperficie, preparando para el futuro tu arquitectura y estén continuamente mejorando tu ROI.
  6. 6. Java Developers Mexico https://www.facebook.com/JavaDevelopersMexicoJuicio de SOA Top Down: La clave para una SOA exitosa es un cambio cultural organizacionalhacia las decisiones de arquitectos "virtuosos".Por qué no funciona: La clave para una SOA exitosa es un plan hecho de un conjunto de metasalcanzables, claras, con beneficios bien definidos.Sí, "virtuoso" fue realmente una palabra que fue usada por los defensores de SOA top-down paradescribir el proceso de adopción. La idea fue que SOA era para sentirnos bien, que todos laadoptarí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 deSOA dejando a tu equipo en la oscuridad. SOA no se trata de ideología. Se trata de hacer lascosas en la forma más simple y eficiente. Los equipos están motivados por objetivos de desarrolloalcanzables, claros, que han sido probados, con beneficios claramente definidos. Abandonar elrollo publicitario suave de SOA top-down, y mostrarle a tus equipos cómo los simples cambios sonla forma en que ellos piensan sobre el desarrollo resultará en una mayor productividad.SOA Bottom-Up - Un Modelo de Adopción de SOA querealmente funcionaDespués de más de 10 años de esfuerzos fallidos de SOA, está claro que la filosofía top-downtradicional de SOA está anticuada y obsoleta – un nuevo enfoque es necesario para que lasorganizaciones 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 pormayor; sobre implementar herramientas pragmáticas a nivel de grupo de trabajo más queagobiarlos 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 sourcede integración que simplemente funciona. Herramientas open source y ligeras como Mule ESBcambian 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 unamanera bottom-up. De hecho, Mule es tan sencillo que hemos visto a algunos desarrolladoresimplementar desarrollo orientado a servicios y seguir principios SOA sin saber (o tomar cuidado) deque ellos de hecho están haciendo, SOA.No se necesitan vendedores de SOA viniendo a llamar a la puerta lanzando SOA, y no necesitasjustificar grandes gastos de licencias y entrenamientos de software propietario (sin mencionar elnuevo hardware o sistemas de desarrollo actualizado que podrían ser requeridos para ejecutar lapila de proveedores típica). Reconoce un problema (o una oportunidad), descubre cómo otrosestán actualmente construyendo soluciones similares, y empieza a aprender que herramientasdisponibles se ajustan mejor a tu proyecto.

×