Consejos para empezar a definir una CMDB

La CMDB debe ser un mapa que ayude a relacionar los activos de TI con la capa de negocio de la organización. Pero este mapa no debe ser demasiado detallado o podría resultar inútil. Tiene que tener el tamaño mínimo necesario para que pueda servir de utilidad, de lo contrario su mantenimiento consumiría más esfuerzo del que se necesita.

Para conseguir esto debe hacer un diseño de "arriba" hacia "abajo", es decir, desde la capa de negocio (los servicios) hasta la capa tecnológica. Por lo tanto se debe comenzar definiendo unos CI que representen los servicios y continuar definiendo los demás CI que sean necesarios para evidenciar los activos tecnológicos que soportan dichos servicios. El punto en el que deba parar de continuar "bajando" es aquel en el que la información que representa ya no aporta nada. Para identificar este punto se pueden valorar tres referencias:

• Todas las modificaciones de lo que se represente como un CI deben gestionarse como un cambio. Si no se está dispuesto a realizar el esfuerzo de gestionar esa modificación como un cambio, entonces habría que plantearse no incluir esa información como un CI de la CMDB.

• Se deben incluir sólo los CI que esté seguro que son necesarios. Aquellos que resulten dudosos o que se crea que no hacen falta, no se deben añadir. Siempre se podrá hacerlo más tarde.

• Muchos CI que representan activos tecnológicos y se necesiten tener en la CMDB, pueden crearse automáticamente desde Proactivanet Inventario.

A continuación, hay que definir un catálogo de relaciones a utilizar que sea el mínimo necesario para que sea útil. Ejemplos de relaciones son: "contiene" (un servidor contiene carpetas compartidas) y "ejecuta" (un servidor ejecuta una aplicación). Para identificar las relaciones necesarias, la segunda recomendación es que se definan las relaciones a la vez que los CI.

En este punto es fundamental insistir en que la CMDB debe representar lo necesario para organizar la Gestión de Incidencias, Gestión de Peticiones, Gestión de Problemas, Gestión de Cambios y Entregas, de manera que los técnicos tengan claro qué elementos intervienen en la prestación de los servicios. Por lo tanto, el tercer consejo es no limitarse a poner en la CMDB conceptos tangibles (como servidores) porque en la organización hay muchas más cosas que son necesarias para prestar los servicios y que también deberían figurar. Por ejemplo, los CI que representen sistemas de backup relacionados con CI de tipo servidor, base de datos o documentos del sistema de gestión.

Alejandro Rayón