En el número de Mayo de la revista Computer World en Ecuador, me hicieron una entrevista sobre «Pensando en SOA». Fue un intercambio muy cordial de preguntas/respuestas que reproduzco a continuación. Espero que os sea interesante:
¿Cuáles son las aplicaciones de SOA en una organización y qué infraestructura necesitan?
Las aplicaciones de SOA son muy variadas ya que en realidad trata de una nueva forma de diseñar el software. Una nueva forma de pensar que se enfoca en el desacoplamiento de los servicios (los pequeños programas que hacen algo con sentido para el negocio). Mediante este desacoplamiento, es decir, al no depender unos de otros, podemos cambiar uno por otro y combinarlos con facilidad para crear nuevos servicios de valor añadido para el negocio.
En realidad SOA no es una tecnología que se pueda comprar, es un estilo de diseño como lo son el paradigma de la programación estructurada o de la orientación a objetos. Sin embargo, para llevarla la realidad, es necesario disponer de un Middleware o un conjunto de herramientas software. Lo más habitual es tener un bus empresarial o enterprise service bus, que hace de intermediario entre consumidores y proveedores de servicios.
A esto habría que añadir al menos un registro que sirva de listado de los servicios disponibles en la empresa, para poder reutilizarlos en tiempo de diseño y también para localizarlos en tiempo de ejecución (un consumidor no debe conocer la localización física de la máquina donde se ejecuta el servicio)
¿Están las empresas en la region Andina trabajando con este tipo de arquitectura, cómo ve el escenario en Ecuador?
Mi impresión es que todavía no se ha adoptado SOA todavía en ninguna empresa, al menos de manera general. Sí que hay algunas de ellas, las más punteras, que ya están desarrollando el proyecto de adopción de SOA. Es un proceso lento, porque implica deshacer los verdaderos «espaguetis» en los que sean convertido sus aplicaciones core de negocio.
Sin embargo, sí que he apreciado un verdadero interés en todo lo relacionado con SOA. Se ve en esta forma de diseñar software la solución a los problemas actuales de falta de flexibilidad y evolución en las soluciones software de la empresa: la búsqueda sobre todo de la multicanalidad y la reutilización de activos software, también el ahorro de costes y de tiempo en poner una solución de negocio en el mercado.
¿Qué tipo de organizaciones son las que mayormente podrían necesitar una implementación de este tipo?
No hay un tipo especial de organización al que se dirija SOA especialmente. Sin embargo, por supuesto, se obtendrá un mayor beneficio cuanto más heterogéneo y más acoplado sea el conjunto de aplicaciones que tenga la empresa. En una compañia mediana o grande conviven decenas de aplicaciones de muy diferente tecnología y año de de construcción.
A lo largo del tiempo vamos aplicando parches para integrar estas aplicaciones que no fueron diseñadas para actuar en conjunto si no como islas o silos independientes. Esto produce una verdadera asfixia a la organización, ya que no puede evolucionar y responder a los retos del mercado porque su informática ya no da más de sí. Está tan enmarañada que no es posible ya crear nada nuevo sin romper algo de lo ya existente.
También es común que la misma lógica de negocio, esté repetida 3 o 4 veces. Hemos pagado más de una vez por hacer lo mismo y seguimos gastando varias veces también su mantenimiento. Esto no es sostenible, tenemos que dedicar el prosupuesto a crear nuevos productos para la empresa y darle más valor. Ahí es también donde SOA nos puede ayudar, mediante el principio de la reutilizacion: haremos un servicio una vez (y sólo una) y lo reutilizaremos donde se necesite. Es en este escenario donde de verdad SOA nos muestra todo su potencial.
¿Cuáles son los beneficios para una organización?
Son muchos, pero por resumir, podemos decir que gracias a la reutilización de servicios tendremos un ahorro de costos en el desarrollo y mantenimiento del software de la empresa. Además, debido a la capacidad de crear nuevos servicios combinando los ya existentes podremos reducir el tiempo en que podemos poner la solución de negocio en el mercado. Con esto además, conseguimos ser más flexibles en la construcción del software para responder a las necesidades de negocio.
Además, podemos convertir las lógicas de las aplicaciones antiguas (legacy) en servicios que pueden ser reutilizados por la organización, extrayendo más valor de lo que ya teníamos.
¿Cuánto tiempo puede llevarle a una organización una implementación de este tipo?
Esto varía mucho dependiendo de la organización y de la extensión que queremos dar a la adopción de SOA. Hay que tener en cuenta que SOA conlleva un cambio en la mentalidad y la forma de actuar dentro de la organización, es posible además que conlleve cambios organizacionales. Además, suele coincidir en el mismo momento de la adopción de SOA, que haya que acometer en la empresa un cambio en la metodología de desarrollo, en los productos Middleware que tengamos instalados, en las herramientas de desarrollo, etc. ya que normalmente es necesario usar una tecnología que no usábamos antes en la empresa. Todo ello, además, suele ser acompañado con la reestructuración o refactorización de las aplicaciones core de la compañía, en su adaptación para convertir en servicios lo que antes eran únicamente lógicas de negocio no reutilizables. Por todo ello, la adopción de SOA suele ser a medio o largo plazo, desde unos cuantos meses hasta dos o tres años en una gran organización como puede ser un banco.
¿A cuánto puede ascender la inversion de una arquitectura como esta?
Dependiendo del tiempo y de los productos Middleware que se adquieran, puede ser una inversión considerable. En el caso de los productos, es posible adoptar algunos de ellos de manera gratuita (open source). Sin embargo, en el caso de grandes empresas como pueda ser un banco, casi siempre se decantan por los productos de grandes fabricantes como IBM o Oracle. Si tenemos esto en cuenta, para este último caso y teniendo en cuenta que el proyecto puede durar un par de años, el coste se puede elevar a varios millones de dólares.
Este tipo de arquitectura tiene alguna relación con BPM, explique.
En un entorno para el negocio enormemente cambiante debido a la cada vez más fuerte competencia en un mundo globalizado, clientes cada vez más exigentes, cambios normativos y legales, etc., la velocidad para poner una aplicación en el mercado llega a ser crítica (el llamado time to market). Por otra parte, en ocasiones, las empresas no tienen sus procesos de negocio correctamente definidos, por lo que no pueden ser gestionados ni optimizados correctamente. No se tienen métricas del negocio en tiempo real que proporcione información a los analistas de negocio para poder tomar decisiones casi inmediatamente. Si a ello unimos que las aplicaciones tradicionales son poco flexibles y casi siempre limitadas al ámbito de un área concreta de la organización, tenemos la foto completa de una situación a la que se puede poner remedio con la combinación de dos conceptos muy complementarios: BPM y SOA.
BPM es una metodología empresarial para la gestión de procesos mediante su automatización (mediante herramientas informáticas). Su objetivo es modelar, integrar, monitorizar y optimizar los procesos de negocio de la organización. De tal manera que obliga a las empresas a pensar en el proceso como elemento central.
Por otra parte, SOA permite la implementación de nuevos procesos de negocio y la modificación de los actuales en menos tiempo y con menos coste, ayudando a rentabilizar la inversión ya hecha en software al integrar aplicaciones cerradas, antiguas y otros servicios de otras áreas de negocio (u otras organizaciones). Al hacer corresponder un servicio SOA con un concepto de negocio, minimiza la “brecha” entre las áreas de negocio y T.I., pudiendo de esta manera hablar un lenguaje común.
Está claro que BPM y SOA se complementan y no se debería acometer una sin la otra (al menos no BPM sin SOA). Con la aplicación de los dos, la organización puede adaptarse rápidamente al mercado obteniendo una ventaja competitiva.
En resumen:
- BPM y SOA, son binomio ganador y van mejor juntos
- SOA es la infraestructura que necesita BPM
- SOA sin BPM sólo permite diseñar y construir un conjunto de servicios
- BPM sin SOA requeriría un desarrollo de código ad-hoc para cada integración con otros sistemas
- Juntos “orquestan a las personas y los servicios en un proceso de negocio”
Blog de Andrés Hevia 
02/07/2013 at 23:45
Muy de acuerdo como siempre en muchas cosas de las que dices, pero muy en desacuerdo en otras, no se puede tener todo 🙂 .
Para hacer SOA no hace falta un Middleware , ayuda , pero no es imprescindible , y se que tu lo sabes pero tus lectores no y es muy importante que todo el mundo tenga claro este concepto y no dejarnos “embaucar” por proveedores
Recomiendo este video que es de hace tiempo pero que sigue teniendo vigencia a día de hoy.
http://www.infoq.com/presentations/webber-guerilla-soa
Es más discutible cuando se habla en términos de beneficio de SOA para la empresa , todo el mundo se centra en la reutilización y en el alineamiento con el negocio, sin llegar a discutir su valor , la experiencia me ha demostrado que el gran valor de SOA no son estos, sino la flexibilidad ante el cambio.
Siempre me gusto la frase “The thing about SOA is to break whatever your system is into easier to change things which often translates into smallr simplr .”
Esta frase «SOA sin BPM sólo permite diseñar y construir un conjunto de servicios» comentada asi , tiene un tono peyorativo y en realidad no tiene porque serlo , la empresas españolas no estan orientada a procesos , estan orientadas a departamentos y esto hace que las aplicaciones y/o servicios asi lo estan , si no hay procesos BPM pierde su valor , pero el tener servicios ya en si mismo tiene un gran valor, justamente por lo comentado anteriormente.
03/07/2013 at 08:23
Estoy muy de acuerdo contigo con lo de no dejarnos «embaucar» por los proveedores. Normalmente los arquitectos SOA que asesoran a una empresa son de la misma compañía que fabrica el sotfware, dejando en entredicho su imparcialidad al ser juez y parte en los productos que recomiendan.
Y creo que uno de los problemas que tenemos es que, en muchas ocasiones, «matamos moscas a cañonazos» como decimos en España. Para las necesidades de muchas empresas no es necesario comprar una cara suite de integración (como la de IBM, Oracle u otras), ya que les sobra con una solución open source más sencilla y más fácil de implementar. Por lo tanto, creo que sí hace falta un Middleware, pero entendido en sentido amplio, ni siquiera hace falta que sea un ESB… podría ser por ejemplo una solución como Spring Integration o Apache Camel.
En cuanto a lo de BPM, creo que si una empresa tiene cientos de servicios, se queda un poco coja, si no tiene un «hilo conductor» que haga que esos servicios actúen de manera coordinada. Este sería el papel que tendría el BPM, coordinar estos cientos de servicios orientados a ejecutar un proceso de negocio de la compañía.
Y sí, si creo que los servicios deben responder a necesidades de negocio, como toda la informática al final y al cabo.
En fin, un gran debate, que enriquece el post. Muchas gracias por tu aportación.
04/07/2013 at 01:20
Siguiendo con el tema de BPM , estando de acuerdo en lo que dices , no deja de ser una posición muy idealista , una covergencia a SOA no deja de ser un cambio radical en lo organizativo y en lo tecnológico. Si a este cambio le añades la orientación a procesos , bufff.
Las empresas y las personas que las componen no aceptamos los cambios con facilidad , asi que paso a paso.
Cuando hablamos de BPM , estamos hablando de procesos de larga duración, y estos a dia de hoy ya se esta haciendo de alguna manera menos elegante , por ejemplo en los «micro worflow» de las aplicaciones o aprendiendose los usuarios las transacciones que tiene que llamar para que ejecutar dicho proceso.
Con una aproximacion menos «idealista» , estos workflows pueden seguir en los front-end y estos son los que orquestan las diferentes llamadas a los servicios.
Tener tu organización orientada a servicios ya de por si es una ventaja , como hemos hablado en terminos de organizacion , reutilizacion y flexibilidad.
Digamos , aplicar una orientación a procesos (BPM) con SOA da más valor , si , es necesario e imprescidible , no.
04/07/2013 at 08:26
Evidentemente cada empresa es un mundo, y cada una de ellas tendrá que trazar su plan para la adopción de SOA y BPM. Se puede ir mediante pasos intermedios como los que comentas de los microflows de los frontales o con un proceso BPM real…
Sin embargo, tal como yo lo veo, hay que tener un par de cosas en cuenta:
1.- Podemos decir que todas las empresas tienen procesos de negocio. Es la forma en al que llevan a cabo su negocio: venden un producto, fabrican uno, contratan con un proveedor o cumplen con el fisco… aunque estos procesos se hagan a mano y en papel, son procesos de negocio al fin y al cabo. Dependerá de la inversión y el tiempo que se necesite (y si compensa desde el punto de vista de negocio), pero una evolución natural es informatizar estos procesos (o sea el BPM).
2.- si estos «procesos» se implementan en los frontales, no seremos multicanal. ¿que pasará cuando se implemente el «proceso» en el frontal de una web de la intranet y después queremos que nuestros clientes accedan desde su móvil? no podremos reutilizar el «proceso», cosa que sí podríamos perfectamente mediante un solución BPM recubierta de servicios web por ejemplo
En fin, un debate interesante…
04/07/2013 at 23:34
En cuanto a lo primero es cierto, pero cuantas empresas conoces que se sepan sus procesos trasversales , no las cadenas de valor que eso las saben todas o mas les vale, me refiero a los procesos detallados esos que nosotros tenemos , como IT ,que implementar , muy pocos , cuantas han hecho proyectos de re ingeniería de procesos , muchas , resultados , muy discutibles. Si eso falla , ya podrá existir una tecnología madurisìma que no conseguirás nada.
En cuanto a lo segundo siento decirte que eso que dices es falso, ya que la tecnología aporta a día de hoy soluciones tecnológicas , como el responsive web design que permitiría hacer una solución multicana y multidispositivo con un mismo frontal. Eso como ejemplo, y en el peor de los casos solo tendrías que implementar un frontal por dispositivo , en el caso de soluciones nativas, ya que la lógica esta en servicios. Lo cual muchas empresas lo firmarían dado la situación actual.
No es que le quiera quitar valor al BPM , que lo tiene , pero de verdad pasó a paso.
05/07/2013 at 08:24
Creo que lo que estamos hablando sobre BPM es cuestión de matices y de la percepción de cada uno.
Sin embargo, sobre lo de implementar procesos en los frontales, por muy responsive design que sean, no puedo estar de acuerdo. Creo que ese ese un concepto equivocado, un frontal NO puede tener lógica de integración.
Y en lugar de soltar aquí un rollo teórico voy a citar simplemente casos reales en los que la lógica de integración, implementada en el frontal no es reutilizables:
1.- Invocación desde una aplicación móvil nativa –> no se pueden usar pantallas HTML
2.- Invocación desde un partner (un banco) en un modelo B2B –> el banco no va a usar nuestras pantallas
3.- Invocación desde un batch –> no tiene pantallas
4.- Invocación desde una aplicación de escritorio hecha en Visual Basic 6 –> no puede usar HTML
5.- Invocación desde un producto CRM –> no puede usar HTML
En todos estos casos, no podemos reaprovechar la lógica de integración que hayamos puesto en el frontal. De ahí que esta lógica de integración deba implementarse mediante servicios complejos y desplegarse en una capa intermedia de integración (el bus) que pueda ser invocada desde cualquier punto de la empresa, sea cual sea la tecnología con la que está implementada.
05/07/2013 at 19:50
Los procesos de negocio , son procesos trasversales a los departamentos y suelen cubrirse , en la actualidad con diferentes aplicativos.
No existe en España , cultura de gestionar los procesos de manera trasversal , las empresas son jerárquicas y eso es cultural. Eso no se va a cambiar ni con un BPM , ni con los workflwos de los 90 ( BPM no deja de ser un reconceptualización de los mismo).
Si estamos de acuerdo hasta aquí seguimos.
Nadie ha dicho que la logica de procesos este en los frontales, hemos dicho que los usuarios tiene “micro worflow” , que suelen ser una sucesión de pantallas/tareas que desgraciadamente a día de hoy son parte o tareas de un proceso mucho mas largo.
Si lo llevamos a lo tecnológico, ¿quién gestiona la sucesión de pasos en una aplicación MVC tradicional tipo struts o spring MVC? el propio Framework.
Nuevo punto de ruptura, ¿estamos de acuerdo?, si es así seguimos.
Con la llegada del paradigma orientado a servicios muchas cosas han o están cambiado, los frameworks MVC tienen a ser sustituidos por llamadas a servicios desde los frontales , habitualmente Rest+json.
Hay quienes dicen que struts , spring se mantiene y son estos los que se encargan de invocar a servicios , nuevamente quien gestiona la sucesión de pantallas struts , pero olvidemos este caso y centremos en el anterior
Digo pantallas porque una tarea de un procesos pueden ser una o mas pantallas , esta desde leugo en el mundo BPM es una discusión muy interesante.
Quien determina la pantalla siguiente o tarea siguiente, un BPM ¿podría ser?, habitualmente el servicio que recibe la petición del frontal que genero la llamada.
Frontal servicio Frontal , que esto se puede mejorar con un BPM vuelvo a decir que no lo discuto.
Nuevo punto de ruptura, buscando consenso.
Tu argumento “NO puede tener lógica de integración” es algo que comparto plenamente contigo.
A partir de aquí todo lo que dices deja de tener valor porque estamos de acuerdo. Entiendo que quieras que el lector se posicione de tu parte mezclando conceptos dispares y no centrando el discurso en un caso concreto que poder discutir
1.- Invocación desde una aplicación móvil nativa –> no se pueden usar pantallas HTML
En ambos casos , con un BPM o sin un BPM , las pantalla deberán ser construidas , y efectivamente la sucesión pantalla nativa – servicio – pantalla nativa , será igual que antes. La reutilización será a nivel de servicios, nunca desde luego a nivel de front-end
2.- Invocación desde un partner (un banco) en un modelo B2B –> el banco no va a usar nuestras pantallas
Si y no, tu no utilizas paypal , quien gestiona el flujo , tu empresa o paypal. Pero pongamonos en el caso que planteas, que además es cierto en la mayoria de los casos, este proceso que planteas tiene interacción humana si o no , si es que no, lo habitual por otro parte, ya no tiene sentido hablar de BPM , tecnológicas como BPEL o alguna otra por ejemplo , orientadas a lo tecnológico podrían orquestar la interacción de pasos a realizar.
Estamos de acuerdo que BPEL y BPM no es lo mismo ¿no?
3.Invocación desde un batch –> no tiene pantallas
No será que estamos confundiendo BPM con tecnología como BPEL , la orquestación de un batch es algo tecnológico. Eso quieres resolverlo que BPM ¿? Umm , suena raro , no me veo definiendo en un proceso las cadenas de un batch . Se mezcla lo tecnológico con lo funcional
4.- Invocación desde una aplicación de escritorio hecha en Visual Basic 6 –> no puede usar HTML
Veo que vienes del mundo Microsoft , interesante ,
Efectivamente el problema se repite como en el punto 1 aplicación nativa , y se repetiría para una aplicación en powerbuilder , delphi o etc etc , .
5.- Invocación desde un producto CRM –> no puede usar HTML
Este caso es mas interesante, los ERP son casos duros de pelar en las orientaciones a servicios , porque los procesos los tienen embebidos en su ERP , no es tan sencillo , y desde luego ninguna empresa te va a comprar que el proceso no este embebido en el mismo. El único que se aleja de esta concepción es SAP , el cual recomiendo de cómo hace su orientación a servicios.
09/07/2013 at 13:14
Hola:
Como dices estamos de acuerdo en algunas cosas, sin embargo en otras no.
Sin extenderme mucho, creo que lo que dices se mezclan cosas entre los frontales, bpm, servicios, etc. Y creo que lo mejor es remitirnos a la arquitectura de referencia SOA de IBM (http://pensandoensoa.com/2011/10/16/arquitectura-soa-de-referencia-de-ibm/)
1.- Los MVC se deben dedicar a ejecutar flujos de navegación, es decir, una secuencia de pantallas para resolver algo
2.- La relación entre BPM y los frontales es a través del inicio del proceso (a veces no hay pantallas) y las tareas manuales. Cuando se encuentra una tarea manual, es cuando el usuario accede al flujo de pantallas para resolver esa tarea. Cuando la resuelve, el flujo se acaba y desaparece. Claro que esta tarea manual se podría hacer de varias maneras (por ejemplo respondiendo a un SMS en el móvil del usuario), ya que el BPM no sabe nada de frontends.
En definitiva, hay una línea clara de separación entre la capa de clientes, de la capa de integración (servicios + procesos), de la capa de backends, y no debemos mezclarlos.
Saludos
26/04/2018 at 17:11
Hola Estimado, gusto en saludarle,
Quisiera que por favor me ayudara con un test de preguntas técnicas frecuentes en SOA, ya que leyendo su post me pareció bastante interesante ahondar un poco más en el tema.
Gracias de antemano,
Saludos.
29/04/2018 at 11:13
Hola. ¿A qué te refieres exactamente? ¿A un examen de certificación?