SOA para humanos. De la competencia a la cooperación

Las Arquitecturas Orientadas a Servicios y los proveedores con productos casi mágicos para implementarlas, proponen un nuevo paradigma para agilizar la automatización de procesos de negocio. Sin embargo, existe una letra chiquita en estas promesas que normalmente los proveedores de soluciones no hacemos énfasis hasta después de recibir la orden de compra: Implementar SOA en una organización requiere de un cambio cultural profundo y radical. Hasta la fecha, no he visto una “suite integrada” de soluciones SOA que provea una solución mágica a este problema, no hay una licencia de software que resuelva el problema de SOA para los humanos. Las organizaciones deben tener claro que SOA implica antes que nada un cambio organiza- cional, requiriendo una estrategia centrada en las personas antes que en la infraestructura.

A continuación comparto cinco estrategias que pueden ayudarles a asegurar que su organización contemple el factor humano en su adopción de SOA y aumentar las probabilidades de éxito:

1.- Liderazgo y Consenso: El lider de una estrategia de SOA requiere de poder crear un ambiente donde las decisiones se toman por consenso. La única manera de que una organización cambie es que todos sean escuchados, sus preocupaciones sean atendidas y se logren acuerdos donde nadie salga perdiendo. El mayor reto de SOA es pasar de una organización competitiva a una organización cooperativa. El establecer métricas que promuevan la cooperación y no la competencia entre áreas, el reconocimiento a la labor de equipo y un sistema efectivo de toma decisiones consensuado es un primer paso ineludible hacia SOA.

2.- Establecer un Lenguaje Común: El concepto de SOA no tiene estandares, cada proveedor da su versión particular de SOA en el cual mágicamente su producto cumple con todas las expectativas. Esto es increiblemente dañino para una organización, ya que dentro de la misma empresa, dependiendo del proveedor favorito de cada grupo de sistemas, se entenderá SOA como cosas fundamentalmente distintas. Antes de iniciar un proyecto de adopción de SOA debemos definir y divulgar lo que significa SOA para nuestra organización, y los beneficios particulares que buscamos. Lograr que todos hablen el mismo idioma es indispensable para una toma de decisiones en consenso.

3.- Diseñar nuestra propia receta: No existen recetas secretas para SOA. Cada organización tiene retos de negocio, cultura e historia distintas. Se tiene que aceptar que ningun proveedor va a poder darle un SOA “llave en mano” por que no hay otra organización igual a la suya en este sentido. La metodologia de Factores Criticos de Exito (Rockart) está más vigente que nunca al ser una estrategia basada en consenso y en la recopilación de la inteligencia colectiva para planear de forma adecuada. El definir a traves de una sesión formal de factores criticos de éxito, que contemple contextos humanos, organizacionales, tecnológicos, y administrativos es una buena manera de garantizar que se cubren todos los aspectos de una estrategia de cambio hacia SOA.

4.- El negocio antes que la arquitectura: El principal motivo de fracaso en los proyectos de TI es muy claro: el beneficio esperado por el negocio nunca llega. Más que centrarnos en si contamos con una arquitectura con todas las “capacidades”, debemos de centrarnos en un enfoque donde primero entregamos el resultado que las personas de negocio esperan y después nos preocupamos por la arquitectura técnica. Sé que va en contra de todo lo que los “profesionales” de sistemas les decimos, pero la realidad es que si entregamos primero el resultado de negocio sera mas fácil que nos den tiempo y dinero para hacer la arquitectura soñada. En SOA esto quiere decir, primero analizamos los procesos más importantes para el negocio y hacemos lo mínimo indispensable para entregar mejoras en ellos. Nada más.

5 .- La disciplina en el diseño: Existe una multitud de “conectores” y “componentes” que prometen facilitar todo. Sin embargo SOA es antes que nada una disciplina de diseño. Como toda disciplina son los humanos quienes la practican, no el producto de software. Un buen equipo de SOA entiende a todos los niveles que preservar el estilo de diseño es indispensable para obtener los beneficios. Se acabaron los “hacks” y mejoras propietarias. Todo diseño debe de obedecer los principios de diseño de SOA, los arquitectos y desarrolladores deben de practicar esta disciplina. Un comite guía puede ser de gran ayuda para asegurar que esta disciplina se aprenda y se regule.

6.- El valor de aprender: La cultura de hacerlo bien y a la primera no aplica enteramente para SOA. Somos humanos, estamos aprendiendo globalmente como cambiar hacia SOA. Habrá cosas que nos pareceran buena idea en un principio y con el paso del tiempo mostrarán que no lo son. Debemos estar abiertos a rediseñar o refactorizar. Es mejor aceptar de antemano que tendremos que variar el diseño y trabajemos de acuerdo a esto. Con SOA necesitamos iterar y protegernos de los cambios, pero más que nada necesitamos promover la experimentación y el consenso. Nada peor para paralizar SOA que desarrolladores temerosos a “exponerse” con sus compañeros porque no se imaginaron todo bien a la primera. SOA fue pensado para el cambio, aprovechémoslo.

Al final, lo que es indispensable considerar en la implementación de SOA en una organización es cómo lograr el cambio que se requiere para que los beneficios de esta arquitectura den resultado y no nos vaya a pasar que dentro de 10 años tengamos que cambiar a otra bala de plata, porque simplemente hicimos lo mismo que toda la vida, pero ahora con estandares de SOA. Buena suerte.