Mi ruta personal hacia la CMDB

Han pasado ya muchos años desde la primera vez que me tocó participar en un proyecto de definición de CMDB en algún cliente. Desde entonces he tropezado con los errores más comunes, los he cometido, he aprendido, he rectificado y más o menos he ido saliendo airoso de cada uno de ellos; pero con cada tropiezo he añadido una piedra más a la mochila de la experiencia así que nunca dos proyectos son iguales.

Al principio, el foco estaba en el descubrimiento y en “rellenar” la CMDB . Aquí entraron las herramientas de descubrimiento automático (en nada parecidas a las que hay hoy en día!) y aprendimos que no todo lo que hay en la CMDB se puede inventariar de forma automatizada; pero los proyectos de CMDB (y ojo, que digo “proyecto de CMDB y no proyecto de Gestión de Configuraciones ni nada parecido) nacían como efecto secundario después de que un cliente tuviese una herramienta de descubrimiento (empezaba con algo tan simple como un NNM y terminaba con verdaderos monstruos como HP Radia)

Luego apareció la necesidad de la taxonomía: era necesario poner orden en todos esos EC ’s que inundaban las bases de datos, así que comenzamos a filosofar sobre ámbito, profundidad, metamodelo… hacía falta dejar claro qué entraba y qué no entraba en la CMDB y cuando entraba, qué información tenía que mantener.

Más tarde, a medida que pasaban los años empezó a ser necesario el discutir al respecto del concepto del Ciclo de Vida del EC (mucho antes de ITIL® V3 y su ciclo del vida del servicio!): los ECs son como los seres vivos: nacen, crecen, se multiplican y mueren… ¿cuál debía ser el ciclo de vida adecuado a cada cliente?.

No pasó casi nada de tiempo para que la combinación de taxonomía y ciclo de vida diese un resultado inmediato: no podemos tener un único ciclo de vida; cada tipo de EC, o cada familia de ellos puede tener un ciclo de vida diferente y se hace necesario definirlos para facilitar los automatismos, la implementación de estos ciclos de vida en las herramientas e incluso para establecer las responsabilidades de los diferentes equipos en los diferentes momentos del ciclo de vida.

El ciclo de vida del EC dentro de la CMDB nos lleva directamente a reflexionar sobre el proceso de Gestión de Configuraciones: quién hace qué, porqué, para qué, cómo y con qué dentro de cada uno de los ciclos de vida de los diferentes elementos, además de cómo controlamos, monitorizamos y gestionamos que eso se cumpla.

Más adelante, cuando ya habían pasado años y años, los clientes comenzaron a ser cada vez más maduros y surgió la gran pregunta, aquella que tenía que haber aparecido el primer día: ¿Vale la pena? y en cada cliente diferente, la respuesta tenía que ser diferente: en unos casos no valía la pena (el esfuerzo requerido no iba a aportar mucho más de lo que ya tenían) mientras que en otros clientes resulta que sí que valía la pena. Todo depende de cuál sea el resultado esperado, las necesidades, la situación actual (no sólo en términos de información, sino en términos de personal, de comunicación, de cohesión de los procesos) y el esfuerzo (y coste) requerido.

Y ya últimamente, lo que estoy encontrando y me lleva a reflexiones cada vez más interesantes con los clientes es qué perfil debe tener el/las personas responsables de mantener todo esto “en solfa”. Estoy plenamente convencido de que a nada que el entorno sea un poco grande (más de 400 usuarios, por ejemplo) esto es un trabajo a jornada completa que debe desempeñar una persona con carácter… con el suficiente carácter como para dejarle claro a cualquiera que “se salte la CMDB a la torera” que eso no se puede hacer así.

Así que ya ves, en mi ruta personal he ido “escalando” en madurez al tiempo que iba aprendiendo un poquito en cada sitio y otro poquito de cada libro que leía y ahora, desde la media distancia puedo ver que el camino se ha de hacer al revés, planteando las siguientes preguntas:

1. ¿Para qué servirá el trabajo de Gestión de Configuraciones que vamos a realizar?
2. ¿Vale la pena hacerlo?
3. ¿Quién será el/la/los/las responsables de la gestión?
4. ¿Qué información queremos gestionar?
5. ¿Qué ciclo de vida tiene cada tipo de EC y qué información se gestiona en cada etapa?
6. ¿Qué actividades debemos hacer para responder a que (4 y 5) sean coherentes?
7. ¿Qué herramientas necesito en cada etapa?

Lo mas probable es que no todas preguntas tengan respuesta en un primer momento, pero de lo que estoy seguro es de que aparecerán más tarde o más temprano.