board-755792_640

Cuando uno echa la vista a atrás y ve todo el conjunto de un proyecto de adopción de SOA en la empresa, no puede dejar de sorprenderse de la cantidad de reglas, tareas, normativas y procedimientos que son necesarios para poner un poco de orden en la cosa, un poco de gobierno… gobierno SOA.

Y es que hay multitud de cosas que hacemos en el gobierno de las que muchas veces no somos conscientes que hacemos, otras por desgracia, directamente no se hacen o se ignoran…

La teoría del bueno de Thomas Erl, en su libro de gobierno SOA, dice algo  más bien obvio sobre la definición de gobierno:

es el acto de gobernar o administrar algo

… y también algo menos obvio pero igualmente cierto sobre el gobierno TI:

responsable de organizar, dirigir y guiar la creación y evolución de activos y recursos IT.

Hasta aquí bien, creo que todos teníamos la idea intuitiva de lo que es el gobierno de las tecnologías de la información. Sin embargo, en el caso de SOA, es necesario ir un poco más allá para hablar del gobierno SOA o la gobernanza SOA (como se traduce a veces). Y lo primero es hablar de los bloques o ladrillos con los que se construye este gobierno SOA. Son cuatro:

  1. Preceptos: definen las reglas que gobiernan la toma de decisiones.
    Estos preceptos definen los objetivos (responsabilidades, quien tiene la autoridad y las metas a conseguir), las políticas que entre otras cosas establece las restricciones a aplicar y las consecuencias que pueden tener la toma de decisiones.
    Se basan en estándares, de obligado cumplimiento, que contemplan las tecnologías, procesos, acciones y métricas a emplear.
    Por último, tenemos las guías que no son ogligatorias pero indican cuales son las recomendaciones y buenas prácticas a emplear.
  2. procesos: que coordinan las actividades de toma de decisiones en base a los preceptos e involucrando a la gente teniendo en cuenta los roles que desempeñan en la adopción de SOA.
    Muchos de ellos son diseñados para apoyar y asegurar el cumplimiento de los preceptos (en forma de revisiones formales)
  3. Roles (personas): que son las que toman decisiones, son dueños de los preceptos y procesos y también son dirigidos o guiados por la aplicación por el gobierno.
  4. Métricas: es lo que tenemos para medir el cumplimiento de los preceptos.

Lo curioso es que si echamos un vistazo a los proceptos y procesos que se recogen en el libro, en mayor o menor medida, seguramente estaremos cumplido muchos de ellos.  Sin embargo, otros por desgracia, ni siquiera seremos conscientes de que existen y de que los necesitamos.

Por poner unos cuantos ejemplos, el gobierno SOA habla de estos procesos:

  1. Cómo se accede y quién puede hacerlo al registro de servicios
  2. Cómo se verifica que la información que se aporta cuando se registra un servicio es suficiente y de calidad
  3. Como se hace el descubrimiento de un servicio en el registro
  4. Como un usuario realiza una petición para la reutilización de un servicio existente
  5. Cómo este mismo usuario tiene que pedir la modificación de un servicio existente para que se adapte a sus necesidades
  6. Cómo se versiona un servicio
  7. Cómo se retira un servicio

En definitiva, en el proyecto de adopción de SOA es muy conveniente echar un vistazo a estos procesos que otros ya han identificado anteriormente y aprovechar este conocimiento en nuestro provecho. No basta con que actuemos por intución.

Por desgracia la adopción de SOA es muy compleja y necesitamos un poco de “orden”… y lo mejor sin duda, es hacer “explícito” en forma de procesos, preceptos y normativas lo que muchas veces hacemos de manera “implícita”.

Anuncios