Sobre la Gobernanza en una estrategia SOA

por

Cuando en alguna ocasión me han preguntado por el principal factor clave de éxito de una estrategia SOA, mi respuesta siempre ha sido rápida: la Gobernanza.

Y la mayoría de las veces he percibido en el gesto (o ausencia de gestos) de mi interlocutor la sensación de que acababa de lanzarle uno de esos términos que parecen vacíos de contenido o una de esas palabrotas que están de moda y se usan sin saber realmente de qué se trata.

Y me preocupa que esa idea esté tan extendida, porque además no es tan difícil encontrar por internet muy buenas explicaciones de lo que es y de su importancia.

De entrada os recomiendo encarecidamente este enlace. Por mi parte voy a poner aquí mi granito de arena, a ver si entre todos empezamos a usar este término correctamente y sobre todo sabiendo de su importancia.

Hemos dicho ya algunas veces que SOA se centra sobre todo en cómo hacer las cosas, y no tanto en con qué herramientas. Pero ocuparse de cómo hacer las cosas requiere necesariamente establecer qué cosas hay que hacer, y cuáles no. Establecer el orden en que se hacen, el momento en que se hacen, y por fin, la manera en que se hacen.

La estrategia SOA solo podra alcanzar su potencial mediante una Gobernanza eficaz

En una primera aproximación muy simplificada ya estamos acercándonos al concepto de Gobernanza. Se trata de toda la definición de qué se hace, qué no se hace, cuándo se hace, quién lo hace, y cómo se hace. Y esta acción debe ser constante, y debe estar muy presente en todo momento en los Comités de Gestión de Cambios, Comités de Seguimiento, Comités Directores, etc, etc. Debe dar soporte a las decisiones de los departamentos TIC.

Su importancia se hace evidente si pensamos en las consecuencias de su ausencia o deficiencia, viene muy bien explicado en el enlace que os puse antes:

  • alguien decide publicar un servicio que considera interesante hacer disponible a terceros. Nadie le dice cómo debe hacerlo, así que define el servicio como cree que es mejor para la utilidad que piensa que puede tener. Puede que utilice como criterio el tenerlo rápidamente publicado, o que sea compatible con la tecnología que está usando, etc.
  • independientemente de que ese servicio lo use alguien o no (de hecho no lo sabe con precisión), un buen día tiene que apagarlo, o incluso simplemente cambiarlo. Quizá porque replataforman su sistema, quizá porque hay un cambio de alcance, quizá porque el equipo que hay detrás de ese sistema cambia y el equipo entrante no sabe que ese servicio existe o qué otros sistemas lo pueden estar usando.
  • un número indeterminado de sistemas empiezan a fallar. Habían apoyado algunas de sus funcionalidades en ese servicio que encontraron publicado, y ahora tienen problemas.

El desastre como podéis imaginar es importante, y la recuperación del desastre es otro desastre igualmente importante. Algunos podéis pensar que aquí lo que ha faltado es coordinación. Y no andaríais equivocados, ha faltado mucha coordinación por supuesto, pero no solo eso. Ha faltado mucho más, empezando por una estrategia. La mera existencia de una estrategia (la que sea) ya es un paso adelante en cualquier escenario IT. Una frase que me impactó mientras me preparaba para la certificación en BPMN decía algo tan obvio pero tan importante como esto: “una estrategia permite alinear los esfuerzos para alcanzar los objetivos“. Parece evidente ¿verdad?. Pues pensadlo bien, seguro que encontráis ejemplos en vuestra experiencia donde sorprendentemente no hay una clara estrategia definida (y si la hay, no se nota, lo cual tiene el mismo efecto).

Hablando de interoperabilidad, la existencia de una estrategia es una necesidad básica imprescindible. Y SOA como estrategia trae todo lo demás que hace falta para que esa estrategia sea óptima. Y ese “todo lo demás” define y conforma la Gobernanza SOA:

 

  • Normativa de interoperabilidad, definiendo con precisión de qué manera deben encararse los requerimientos de interoperabilidad en los proyectos IT de la organización, cuál es el enfoque, qué deben tener en cuenta los distintos sistemas de información para encajar en un escenario SOA que permita reducir costes y agilizar los procesos. Qué prácticas están prohibidas, qué prácticas están recomendadas pero no obligadas y cuáles son de obligado cumplimiento.
  • Ciclo de vida de los servicios, procedimientos, metodologías adaptadas a una estrategia SOA, plantillas de obligado uso, políticas de seguridad, de gestión de errores, etc.
  • Indicadores a medir y auditar para asegurar que se sigue la normativa establecida, planes de prueba de obligado cumplimiento, etc. Traza de todos los servicios publicados, sistemas proveedores y consumidores de los servicios, sus versiones, su estado, etc, etc.

Estaréis pensando que todo esto es necesario en cualquier caso, no solo en una estrategia SOA. Bien, a lo mejor estáis usando una estrategia SOA y no lo sabéis. Lo dudo, pero entendería que pensarais que no estoy descubriendo el fuego ni inventando la rueda, es totalmente cierto. Os recuerdo lo que os decía al principio de este blog: cuando enumeras las buenas prácticas que promueve una estrategia SOA resultan sorprendentemente obvias, pero también sorprendentemente ausentes… al menos con el enfoque adecuado en un escenario de interoperabilidad que pretenda ser viable, sostenible, escalable y económicamente rentable. Aquí está la diferencia.

Cuando veamos los patrones anti-SOA tendremos ocasión de ver ejemplos claros, pero aun teniendo en cuenta todo lo que acabamos de comentar, es posible que estemos haciendo un mal uso de estas buenas prácticas. Intentaremos concretarlo en futuras entradas, para evitar el efecto “por supuesto”. Sí, acabo de inventarme esto: con lo de efecto “por supuesto” me refiero a esas veces en que alguien explica algo, y termina preguntando “¿lo habéis entendido?”, y todo el mundo asiente con un “por supuesto”. Después todos se van felices a sus puestos, y luego ocurre algo que deja demostrado demasiado tarde que de aquella charla quedaron tantas interpretaciones como personas presentes. Y ninguna acertada. Las actas ayudan a evitar esto, pero hasta en eso hay que hacerlo bien, porque un acta mal hecha no sirve para nada. Volveremos a esto en futuras entradas.

Retomando la Gobernanza, dejadme insistir una vez más en que se trata de un proceso indispensablemente continuo, ininterrumpido, que cíclicamente debe ser capaz de autorevisarse y actualizarse conforme el contexto, el avance, y el grado de madurez de la organización van evolucionando. Aquí tenéis una propuesta basada en el trabajo de Open Group que muestra este ciclo sin fin:

La Gobernanza en una estrategia SOA es un ciclo continuo de definicion, planificacion, implementacion y monitorizacion

La necesidad de esa regulación constante, en continua revisión y seguimiento, la necesidad de esa vigilancia de su cumplimiento, y atención a esto: la necesidad de asegurar un correcto enfoque en cuanto a abstracción, granularidad y orientación a los procesos de negocio (qué debe ser un servicio y qué no debe ser un servicio), implican la necesidad de formar un equipo de alto nivel estratégico, con un enfoque óptimo tanto del negocio como de la mentalidad SOA, que sea un equipo de toma de decisiones vinculantes para todos los proyectos, que implemente la estrategia asegurando la coordinación y perfecta orientación de todos los proyectos IT implicados en escenarios de interoperabilidad. En los enlaces que os he pasado en esta entrada lo llaman “Centro de Excelencia” y no me parece mal nombre, porque eso es justo lo que debe hacer: garantizar la excelencia en la ejecución de la estrategia SOA.

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