Hola a todos de nuevo.

Esta vez voy a escribir sobre un tema que creo que está en boca de todos, la famosa CMDB.

Creo que el primero de los puntos que se debieran tratar, es, ¿que es una CMDB?

La CMDB es un concepto que introduce (buenas prácticas)ITIL/ISO20000 para facilitar la gestión de los servicios IT, y desde mi punto de vista consiste en alguna(s) herramienta(s) que permita(n) mantener los elementos de configuración importantes para un servicio. Del mismo modo, debe poder mantener ciertas relaciones entre los elementos de configuración, ya que en las organizaciones actuales, no suelen existir elementos aislados, sino que todos ellos se complementan y apoyan para proporcionar uno o varios servicios.

Por lo tanto y tomando como base la «definición» dada, una CMDB podría ser una hoja de cálculo en la que el responsable correspondiente tiene anotadas aquellas máquinas que son importantes para el servicio A, y las relaciones que entre ellas existen. Dada esta información, es muy posible, que el responsable, ante un cambio en uno de los elementos que tiene anotados en la hoja de cálculo, pueda levantar la voz de alarma a su jefe, indicando que ese objeto(CI) proporciona el servicio A y que se tenga en cuenta a la hora de realizar la actualización.

Con respecto a este pequeño comentario de introducción, que no deja de ser mi visión de la herramienta, es lógico deducir que cada organización tendrá que definir que elementos considera o no importantes para la CMDB y que información asociada es la que deben incluir. Este punto que parece obvio es uno de los mayores inconvenientes a la hora de desarrollar la herramienta, pues parte del alcance y definición de la misma, es propia para cada organización, y por lo tanto no se puede generalizar.

Ahora, ¿que es un elemento de configuración o CI (Configuration Item)?. Bueno, al margen de lo que ITIL comenta como CI, realmente y desde mi punto de vista un CI es cualquier elemento que se encuentra en la organización y que es importante controlar para proporcionar un servicio. Los CI‘s pueden ser físicos (un servidor), lógicos (un sistema operativo instalado en el servidor) o conceptuales (el servicio que proporciona el servidor). Es importante reseñar que los CI’s tienen atributos que contienen información relevante del elemento desde el punto de vista del servicio y además tienen cierto carácter dinámico, pues deben tener un estado (en producción, planificado, retirado, etc). Ya por último solo me queda indicar que el CI es el elemento mínimo de la CMDB, que no es mas que un conjunto de CI’s relacionados e importantes de cara a 1 o n servicios.

El objetivo de una CMDB, desde mi punto de vista es proporcionar información sobre la infraestructura TI importante de cara al servicio.

Existen multitud de fuentes de información donde se pueden encontrar múltiples objetivos asignados a la CMDB, personalmente, creo que todos ellos no corresponden a la propia CMDB, sino a procesos (o función) de orden superior, que serían los encargados de alimentar, actualizar y explotar la información que aquí se encuentra almacenada a través de los medios/cauces adecuados.

Basándome en mi conocimiento actual, los errores mas frecuentes a la hora de abordar un proyecto de este tipo son:

1. Imposibilidad por parte del proveedor de definir el detalle (¿que información contiene un elemento de configuración?) y el alcance (¿que consideramos un elemento de configuración?) de la CMDB por diversos motivos, entre otros caben destacar, debilidad frente al cliente, inexistencia de fuentes de datos oficiales en la organización, inexistencia de mapa de servicios, inexistencia de información sobre infraestructuras, reticencia de los empleados a proporcionar información, el uso del término SI en el cliente de forma demasiado habitual, en fin, y muuuuuchos mas elementos de este estilo, que no favorecen para nada la marcha del proyecto.
2. Confusión entre CMDB e inventario. La CMDB no es un inventario, no se aborda este desarrollo para proporcionar solución al inventario actual. Recordemos que la CMDB solo contiene elementos de configuración necesarios o importantes para proporcionar un servicio, absolutamente nada mas. La mayor parte de las ocasiones, en el cliente se confunde el concepto, y realmente lo que se intenta abordar es la implementación de un inventario que solucione las debilidades y carencias del actual. Normalmente este punto también es causa de bastantes desastres en este tipo de proyectos.
3. No consiste en centralizar datos. Muchas de las organizaciones que comienzan en este mundo, aprovechan el concepto de CMDB y el concepto de federación de información, para dirigir el proyecto hacia una centralización de datos. Nada mas lejos de la realidad. La CMDB debe ser capaz de obtener información de fuentes externas a la misma, para poblar ciertos atributos de sus elementos de configuración, en el caso de requerirse, pero para nada se habla en las mejores prácticas ITIL de la centralización de información. Ese es otro tipo de proyecto que debe ser abordado por otro tipo de perfiles.
4. Predisposición a la compra de herramientas por parte de las organizaciones. Personalmente me considero una persona eminentemente práctica, cuando abordo un proyecto siempre verifico que no existan herramientas en el mercado que pueden cubrir los requerimientos, y la mayor parte de las veces prefiero la compra de las mismas, antes que meterme en un desarrollo en el que sabes cuando entras, pero ni cuando sales ni a que coste. En este caso, soy de la opinión de que merece la pena el desarrollo de herramientas adaptadas a la organización. Se pongan como se pongan Gartner y compañia, en el mercado actual no existen herramientas que cubran el 60% de la casuistica actual. Existe la posibilidad también de comprar varias herramientas e intentar la integración, pero realmente, suele ser mayor el esfuerzo de integración que el que hubiese supuesto el desarrollo directo.

Los pasos que considero de necesario cumplimiento para abordar un proyecto de este tipo son:

1. Petición al cliente del catálogo de servicios. Como ya se ha comentado, la CMDB tiene como el mas importante objetivo controlar elementos que afectan al servicio. Si el cliente no es capaz de generar un mapa por lo menos de los servicios mas importantes de su organización, directamente recomiendo cancelar el proyecto.
2. Del catálogo de servicios seleccionar aquellos con los que comenzar el proyecto. Mi recomendación es que sean o 1 o como mucho 2. Al lector puede parecerle poco, abordar un proyecto así, con tan poco alcance, pero personalmente creo que hasta que la herramienta no se encuentra en funcionamiento, ninguno seremos capaces de imaginar la carga de trabajo que supone mantener funcional la CMDB por cada uno de los servicios, así que la recomendación es simple, poco a poco. Por otro lado, la base tecnológica es la misma, sean 2 o 100 servicios los implementados en la CMDB, por lo tanto el esfuerzo realizado para los primeros servicios es completamente válido para los sucesivos. En cambio, si la base tecnológica es mala, a la hora de la ampliación, posiblemente al equipo de proyecto se le caiga el mundo encima.
3. Definición de alcance y profundidad de la base de datos de configuración o CMDB. En este punto también suele traer bastante controversia en el cliente. De forma habitual, ni siquiera el propio cliente logra llegar a un resultado satisfactorio en este punto. Lo que para un área podria ser suficiente, para otra es informacion incompleta, y para otra es totalmente distinto a lo que habian pensado. En fin, este punto, que al lector podria parecerle un poco obvio, realmente es causa de la mayor parte de las cancelaciones en este tipo de proyectos. Personalmente opino que tanto el alcance como la profundidad de los elementos de configuracion en nuestra CMDB puede ir creciendo a medida que la Organización lo hace con la explotacion de la herramienta. Si partimos de mucha profundidad/alcance, podemos encontrarnos en un proceso infinito de definición de CIs, que es lo que esta pasando en mas organizaciones de las que nos creemos. Por lo tanto, si en un tiempo razonable no se logra llegar a ningun acuerdo con el cliente/organización, recomiendo la cancelación del proyecto.
4. Implementacion/compra de CMDB. En el caso de la compra, pues es simple, dejémonos de cuestiones politicas y seamos profesionales señores. En el caso de que la herramienta valorada cumpla el 80% de la funcionalidad requerida, pensemos en la compra y por supuesto, pensemos en el desarrollo posterior y valoremos. En el caso del desarrollo de la herramienta, hagamos realmente un buen analisis y seamos conscientes de los recursos necesarios para abordar un proyecto tan importante con una calidad, coste y tiempos razonables. En el caso de que no estemos dispuestos a desarrollar absolutamente nada, olvidemos el proyecto, por que como he comentado antes, el producto a fecha de hoy no existe.
5. Este punto ya es el ultimo a considerar, pues a partir de aqui, el proceso es el mismo que para cualquier desarrollo de sotfware actual. Simplemente continuemos el desarrollo, planificando trabajo junto a la organizacion, planificando las pruebas unitarias y de integración y por ultimo, pasado este maravilloso proyecto a explotación.
6. Para futuros proyectos, en el caso de que seamos de las pocas organizaciones que han conseguido pasar exitosamente por los pasos anteriores, ya podemos ir preparando el camino para ir montanto sobre nuestro maravilloso producto el resto de capas ITIL (indicencias, problemas, cambios, ect).

Por desgracia para mi y por consiguiente para mi carrera profesional, no he tenido de momento la suerte de caer en ninguna empresa que haya conseguido realizar una implementación de CMDB funcional, pero realmente si que me gustaría caer, en un futuro, en una empresa seria que proporcione a este tipo de herramientas/desarrollo la importancia que se merecen. Personalmente no creo que sea tan complicado, pero como siempre, el politiqueo y las ganas de ganar dinero rápido y fácil pueden sobre los proyectos, en su mayoría gestionados por incompetentes vestidos de informáticos o ni siquiera eso, que se califican de proveedores de soluciones y que realmente no son mas que unos pintamonas que tienen a la profesion en el estado en el que actualmente todos conocemos.

Saludos a todos.