Los 10 errores más frecuentes implantando una estrategia SOA

por

Lograr el éxito en la implantación de una estrategia SOA es difícil, no nos engañemos. Aunque tengamos todos los conceptos claros, seamos unos expertos en BPM, contemos con profesionales de alto nivel y experiencia, y todo esté listo en nuestra mente para ponernos a ello, es sumamente fácil descarrilar la estrategia. Hay que alinear muchos planetas para lograrlo, y como sabéis los planetas no se mueven deprisa precisamente (relatividad aparte).

La experiencia siempre es buena consejera, así que vamos a echar mano de ella y dedicaremos esta entrada a listar algunos errores que considero más probables durante la implantación de una estrategia SOA en una organización.

Los 10 errores mas frecuentes implantando una estrategia SOA

 

Seguro que vosotros también tenéis alguna experiencia de la que podemos aprender todos, así que os invito a que uséis los comentarios para opinar o aportar lo que creáis oportuno.

Vamos allá.

 

Considerarlo una tecnología.

Si estáis pensando algo parecido a “oh no! lo va a decir otra vez!”, es señal de que estáis siguiendo mis anteriores entradas con atención (de lo cual me alegro). Es cierto, no me canso de repetir que SOA no es una tecnología. Se trata de un error común, que conduce a la frustración, a la decepción al no ver por ninguna parte todas las maravillas que promete SOA. Y se extiende la idea de que SOA es humo… y no termina de despegar… y así nos va…

Cuando se enfoca a nivel estratégico y organizacional, SOA empieza bien. Si no, empieza herido, y cuanto más cerca de la tecnología se enfoque, más mortal será esa herida.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 1: considerar SOA como una tecnologia

 

Desatender la tecnología

Anda! ¿Y ahora esto? ¿Nos aclaramos o qué?

Calma… una cosa es que SOA no sea una tecnología, y otra cosa es que se quede en un plano teórico. La puesta en marcha de SOA naturalmente necesita en algún momento de una implementación tecnológica para traer todos sus beneficios a la realidad.

El riesgo está ahora en pensar que la implementación de los servicios SOA puede ser sencilla, o pensar que puede relajarse la auditoría permanente del cumplimiento de la normativa de interoperabilidad o cualquier otra política dictada desde la gobernanza SOA.

En este sentido hay que mantener el músculo de la abstracción bien atento, incluso en la construcción de los servicios. Los propios componentes de las orquestaciones deberían ser encapsulados y reutilizables, se debe perseguir la obtención de una especie de “caja de lego”, con cuyas piezas poder montar infinidad de construcciones, infinidad de servicios.

Si no lo hacemos así, corremos el riesgo de tener el acoplamiento en casa, dentro del propio catálogo de servicios. Una idea ciertamente aterradora. Y toda la agilidad que queremos ganar fuera del catálogo, gracias al catálogo, la perdemos dentro de él… Lo cual a la larga supondrá un lastre creciente para toda la estrategia y su degradación.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 2: desatender la capa tecnologica

 

No implicar a los grupos de interés adecuados

Como estrategia en TIC, SOA tiene que implicar a mucha gente, de distintos perfiles, con distintos intereses y grados de responsabilidad dentro de la organización. Es imprescindible que todos esos grupos de interés sean correctamente identificados e implicados con la estrategia.

De nada sirve que los equipos de desarrollo y sus jefes de proyecto estén por la labor, si sus responsables no establecen objetivos alineados con la estrategia. Del mismo modo, si los responsables de la organización tienen asimilada la estrategia pero los responsables de ponerla en marcha proyecto a proyecto no siguen las directrices y la filosofía que plantea la gobernanza SOA, de poco sirve.

En este asunto debe salir a relucir la diplomacia, la sensibilidad hacia los distintos perfiles y trayectorias de los responsables implicados en cada nivel, para trabajar la alineación de todos ellos con la nueva estrategia, sin verse obligados, sino participando en ella, manteniendo su ámbito de control y supervisión. Hay que saber mostrar a cada perfil la visión de SOA que mejor encaja con sus intereses. Y naturalmente esta labor corresponde a la gobernanza SOA.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 3: grupos de interes

 

Buscar resultados globales demasiado pronto

Implantar una estrategia SOA en una organización implica una cierta inversión. Y como en toda inversión, es legítimo querer ver un retorno de dicha inversión. Y este es uno de los puntos más oscuros y escurridizos de SOA.

El retorno de la inversión de una estrategia SOA no es ni inmediato ni totalmente económico. Siempre se traduce en ahorro de costes colaterales, en importantes ahorros como:

  • proyectos más cortos, gracias a la reutilización de servicios y la eliminación de redundancia de requerimientos,
  • mantenimiento más económico, al tener un mapa de sistemas desacoplado y reducirse por tanto el impacto de cualquier cambio,
  • seguramente ahorro en la red de comunicaciones, al eliminar el tráfico masivo de información que requería toda la capacidad de la red.

Pero el retorno de la inversión vendrá también de:

  • agilidad para reaccionar con rapidez a la competencia o a nuevas demandas y retos para el negocio, al reducir el time-to-market,
  • escalabilidad, para crecer sin impactar al resto de la organización,
  • flexibilidad, al poder cambiar un sistema por otro sin impactar al resto gracias al desacoplamiento del mapa de sistemas: basta con que el nuevo sistema publique y consuma los mismos servicios,
  • capacidad para intercambiar información mediante los servicios estándar, favoreciendo movimientos estratégicos empresariales (fusiones, acuerdos, etc),
  • optimización de los procesos de negocio, gracias al análisis de los procesos existentes y a la detección de patrones, eventos, reglas, etc.

Y todos estos beneficios son (además de extremadamente complejos de estimar y calcular) lentos en aparecer, como lenta es la implantación de una estrategia SOA. Cualquier otro enfoque no es realista.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 4: resultados a corto plazo

 

Proliferación de servicios (demasiada granularidad): baja reusabilidad

Este problema es más probable cuando estamos extrayendo servicios de abajo arriba (aproximación bottom-up). Es fácil en este caso identificar los componentes software y soluciones de integración ya realizadas en modo espagueti en el mapa de sistemas existente, y resulta muy inmediato incorporar tal cual, o simplemente con una capa de estándar, los mismos casos de uso como servicios SOA en el catálogo.

Aunque este puede ser un primer paso válido para minimizar impactos en los sistemas existentes en su cambio de orientación hacia SOA, no deben quedarse ahí. Es necesario preparar y cumplir una hoja de ruta para analizar todo el proceso afectado por esos servicios de bajo nivel para obtener unos servicios SOA con el nivel de abstracción correcto, que terminen por cambiar de verdad la orientación de esos sistemas y dotar a la organización de verdaderos servicios SOA estandar reutilizables.

En una aproximación top-down, analizando los procesos de negocio es importante buscar no sólo procesos más o menos atómicos que se repiten para incluirlos en el catálogo de servicios, sino sobre todo patrones de eventos, flujo y procesos que se repitan. Estos servicios compuestos suelen dotar de mucha más potencia, agilidad y capacidad al catálogo de servicios SOA de la organización.

Tanto en un enfoque como en el otro, un nivel de granularidad demasiado alto implica un índice de reutilización muy bajo, perdiéndose capacidad de ahorro, homogeneidad en el mapa de sistemas y complicando enormemente el mantenimiento del catálogo.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 5: baja reusabilidad

 

Exceso de abstracción (granularidad insuficiente): demasiada reusabilidad

Más probable en aproximaciones top-down, se trata del caso opuesto al anterior. Cuando nos quedamos a un nivel de abstracción tan alto que prácticamente se reutiliza siempre. Hay que tener cuidado con estos casos, que pueden parecer un éxito ante tanta reutilización.

Se plantea un problema ante las posibles necesidades de evolución que surjan. Creo que se entenderá mejor con un ejemplo. Imaginemos tres procesos de negocio, procesoA, procesoB y procesoC. Los tres incluyen en su flujo un evento inicial que se llama igual, digamos notificarEvento. Ante esta similitud podemos pensar en crear un único servicio de negocio, notificarEventoProceso, que sería consumido por todos los sistemas que necesitan conocer que se ha producido ese evento en alguno de los tres procesos (A, B y C).

Hasta aquí parece que hemos hecho algo muy bueno. Con un solo servicio estamos resolviendo una necesidad presente en varios sistemas de información.

Pero pensemos en una cosa: realmente los procesos procesoA, procesoB y procesoC son distintos. Aunque los tres incluyen un evento llamado notificarEvento, son procesos diferentes. ¿Qué ocurre si uno de esos procesos cambia, evoluciona o es sustituido por otro?. Pues que nuestro servicio notificarEventoProceso deberá ser modificado y los sistemas de información afectados por el cambio serían todos los que usan el servicio, no únicamente los afectados por el proceso de negocio que ha cambiado.

Normalmente en estos casos se debe vencer la tentación de crear un servicio para todos los procesos que coinciden en eventos con el mismo nombre. Lo importante en un evento no es su nombre, sino el evento en sí. Y si son eventos distintos, aunque tengan el mismo nombre, deben desencadenar servicios distintos. En nuestro ejemplo sería mejor crear tres servicios: notificarEventoProcesoA, notificarEventoProcesoB y notificarEventoProcesoC.

Otro problema adicional es el que provoca en la monitorizacion del negocio. Las herramientas de monitorización hacen seguimiento y conteo de una serie de indicadores que se distribuyen a lo largo del catálogo de servicios, para medir la cantidad o la frecuencia de ciertos eventos, duración de ciertos procesos de negocio, etc. Si distintos flujos, eventos y procesos, se “resuelven” con un mismo servicio abstracto, ¿qué monitorizamos ahí?. Habría que meterse en la lógica del servicio para hacer monitorizaciones dependientes de dicha lógica, o dependientes de ciertos datos transmitidos en los procesos.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 6: excesiva reusabilidad

 

Mal uso de los estándares

Decir “yo uso estándares” no implica que se usen correctamente. Decir que al usar estándares estamos cumpliendo con esa premisa SOA no es del todo cierto: hay que usarlos bien.

En esto quisiera comentar dos cuestiones. Por un lado, la definición de un estándar es como un molde, como la definición de una clase si preferís la analogía con la orientación a objetos. Un estándar define por defecto todo lo necesario para resolver un determinado escenario donde ese estándar es aplicable. Pero es importante darse cuenta que su definición es por defecto, es decir, se parte de ella para llegar a una implementación propia del estándar, haciéndolo plenamente operativo en la organización y caso concreto en que se está usando.

Requiere por tanto un importante esfuerzo de análisis del negocio en general y de la organización en particular, para saber dónde se puede usar el estándar tal cual se propone (por defecto), y dónde se debe sustituir lo que el estándar propone por valores concretos de la propia organización. De esta manera se crea una especie de instancia del estándar, se saca una implementación de aquel molde, que es plenamente funcional y operativa en la realidad de esta organización que lo está implementando. Este ejercicio suele acarrear otras ventajas importantes para la gestión de la información por parte de la organización, ya que permite recopilar y unificar toda la semántica de negocio de la organización, asegurando de esta manera la interoperabilidad semántica dentro y fuera de la misma.

Por otro lado, hay que ser muy precisos en la implementación del estándar. La ambigüedad es un enemigo muy escurridizo, y es muy fácil caer en ella aun estando razonablemente seguros de no estar siendo en absoluto ambiguos. El ejemplo más típico que siempre menciono cuando hablo de este asunto está basado en un caso real que me ocurrió en el trabajo. Definir en un nodo de un esquema de un servicio que ahí se debe informar el “identificador del profesional” puede parecer bastante preciso. Pero luego descubres que para unos equipos el profesional se identificaba con un id local, para otros se identificaba con un código nacional, para otros se identificaba con su usuario corporativo, para otros con su dirección de correo… Naturalmente hubo que modificar la definición de aquel servicio para indicar expresamente y con absoluta precisión que en aquel nodo debía ir el identificador del profesional que consiste en el código nacional de identificación.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 7: mal uso de los estandares

 

Abuso de la sincronía

El escenario de espagueti casi siempre incluye una buena cantidad de servicios web propietarios publicados por distintos sistemas de información, para recibir invocaciones de tipo consulta-respuesta. Estos servicios son naturalmente síncronos.

Como hemos comentado en anteriores entradas, tenemos dos aproximaciones posibles para identificar servicios SOA: de arriba abajo (top-down) partiendo del análisis de procesos de negocio, y de abajo arriba (bottom-up) partiendo del mapa de sistemas existente y las soluciones de integración en marcha. Este último enfoque significa analizar el mapa de espagueti y descubrir en él los servicios SOA.

El abuso de la sincronía suele venir de trasladar con demasiada identidad aquellos servicios web de consulta al catálogo de servicios SOA, arrastrando así una sincronía entre los sistemas que necesitan esa información y el sistema que provee dicha información. Este es el camino más rápido, el menos traumático, y el menos costoso… a corto plazo. Porque en realidad, los sistemas permanecen acoplados entre sí, y por tanto hemos avanzado poco.

En estos casos se puede admitir esta inclusión de servicios síncronos si utilizamos patrones SOA conocidos especialmente indicados para estos enfoques de abajo arriba, como el patrón de fachada. Este patrón sugiere que el servicio propietario se mantenga tal cual, pero que ningún sistema lo invoque directamente. En su lugar deben invocar un servicio estándar en la capa de middleware que oculte al servicio original, que sea el único punto que lo invoque y desacople de esta manera a los sistemas de información implicados. Este tipo de patrones suelen ser útiles como paso inicial en una hoja de ruta que desemboque en un cambio completo de planteamiento hacia una orientación a eventos, donde el sistema que publicaba el servicio a la espera de consultas termine invocando a un servicio asíncrono para notificar un evento, y los sistemas que invocaban al servicio inicial de consulta terminen suscritos a ese servicio para recibir la información asociada. La asincronía propia de una orientación a eventos introduce un desacoplamiento ideal entre los sistemas participantes, y este es el escenario que hay que buscar.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 8: abuso de mensajeria sincrona

 

Síndrome de Estocolmo

Durante la implantación de una estrategia SOA hay que desarrollar una importante habilidad para cambiar de registro en función de la audiencia. Esta característica, que podría ser recomendable en muchas situaciones, aquí es imprescindible. Hay que sintonizar adecuadamente con nuestro interlocutor para orientarle adecuadamente en el cambio de mentalidad que se necesita para entender, asimilar y aplicar la filosofía de una estrategia SOA.

Lo mismo nos encontramos frente al máximo responsable del departamento de IT de la organización, que nos encontramos frente a los expertos funcionales de esta o aquella área funcional, o ante un gerente de un proveedor externo, o  los jefes de proyecto de la organización, o el responsable de gestión del cambio, o el de sistemas, etc, etc.

Tengamos claro que todos y cada uno de estos actores van a presentar resistencia al cambio. Unos más, otros menos, pero todos van a resistirse. Incluso los que digan estar totalmente convencidos y apuesten sinceramente por la estrategia, arrastrarán prácticas, costumbres, formas de hacer las cosas, que vienen usando durante muchos años y que, en principio, tenderán a mantener (comprensiblemente o interesadamente).

Para los arquitectos SOA (o consultores SOA, analistas SOA, desarrolladores SOA, etc), resultará muchas veces complicado mantenerse recto en el camino correcto marcado por la estrategia. Podemos encontrarnos sin dificultad aceptando propuestas poco alineadas con la estrategia, o consintiendo prácticas que ponen en peligro la ejecución de una determinada hoja de ruta para lograr una orientación a servicios correcta, etc, etc.

A estas situaciones nos referimos aquí cuando hablamos del síndrome de Estocolmo del consultor SOA. Es fundamental no caer en intereses ajenos a la estrategia, no ceder a propuestas no alineadas con la estrategia, que suelen venir acompañadas de una cierta presión por parte de los equipos que las plantean. Para ello hay que acudir a la oficina de gobernanza SOA siempre que se tengan dudas o se identifique un riesgo en este sentido. Este grupo debe tener suficiente capacidad decisoria o suficiente alcance a la dirección de TIC de la organización como para encarrilar adecuadamente esas situaciones, o elevarlas para que se encarrilen desde la dirección.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 9: sindrome de Estocolmo

 

Ausencia de Gobernanza o débil Gobernanza

Creo que a lo largo de otras entradas y en esta misma han salido ejemplos muy claros de problemas y riesgos cuya solución pasa por una oficina de gobernanza SOA fuerte y constante.

Y es que la gobernanza es el principal motor de la estrategia SOA, por lo que su ausencia haría inviable la estrategia, y su debilidad haría tremendamente difícil una resolución de conflictos y riesgos potenciales que permitan avanzar adecuadamente con la estrategia.

Cuando esto ocurre, aparecen por ejemplo sistemas de información que no terminan de evolucionar a SOA. Sistemas que no terminan de publicar servicios claramente identificados, o que no terminan de consumirlos. Aparecen áreas funcionales completas que parecen ajenas a la estrategia, y que continúan lanzando proyectos y nuevos sistemas de información como si la estrategia SOA no fuera con ellos. Esto supone un doble problema, porque por un lado se retrasa la expansión de la estrategia y la posibilidad de publicar más servicios de negocio de esas áreas, y por otro lado mientras se está luchando con la estrategia contra el escenario tipo espagueti, ese mismo escenario sigue creciendo allá donde la estrategia no consigue llegar, ahondando los problemas que se pretende corregir, retrasando los beneficios de la estrategia SOA y amenazando a su credibilidad ante la ausencia o retraso en los resultados prometidos.

Por esto es absolutamente vital entender bien lo que es la gobernanza SOA y el papel determinante que tiene. Y entender bien que cuanto más arriba cale la gobernanza en la pirámide de la organización, más posibilidades de éxito tendrá la implantación de una estrategia SOA.

Los 10 errores mas comunes implantando una estrategia SOA, error numero 10: Gobernanza debil

 

Termino esta larga entrada con este enlace. Se trata de un informe de Gartner (existen otros por ahí) sobre errores comunes en SOA. Entre nuestra experiencia y lo que la gente de Gartner comenta creo que podéis tener una idea bastante completa de donde están las principales amenazas en el camino de implantar una estrategia SOA en una organización.

 

De nuevo os animo a usar los comentarios aquí abajo para compartir vuestras experiencias, opiniones, sugerencias, etc.

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This