De los muchos debates que leo en las redes sociales, quiero escribir sobre uno que puede dar para horas y horas de debate en vivo: ¿Qué nivel de detalle es necesario para mi CMDB? Aprovechando el tema, quiero hacer una pequeña recopilación de respuestas, que he resumido en cinco, y la conclusión que nos da ITIL®. Creo que el debate es interesante:
Respuesta 1: "El nivel de detalle se determina a partir del uso que le quieras dar a la CMDB. Mayor nivel de detalle significa que algo no será usado y tendrá difícil mantenimiento. Menor nivel significa coste sin beneficios."
Respuesta 2: "Deben estar todos los datos que sean representativos de los componentes, unidades de negocio, de auditoría, de financiero, herramientas de infraestructura y monitorización. Debemos dejar de pensar en la CMDB de 1999 y empezar a pensar en las soluciones y el valor que traerá a la organización la CMDB de 2020".
Respuesta 3: "Mira las formas que tienes de alimentar la CMDB y comprueba cómo se relaciona toda la información, en lugar de perder tiempo en estar del lado de 'cuanta más información, mejor'".
Respuesta 4: "Céntrate en las unidades de arquitectura y las unidades de negocio, y olvídate de la microinformática: PCs y Switches".
Respuesta 5: "Ten en cuenta a las funciones de negocio específicas y a los usuarios específicos que están afectados cuando monitorizas los servicios. No tienes que complicarte si la CMDB va a ser usada para monitorizar desde el punto de vista del Negocio".
Respuesta ITIL® (pequeña parte):
"La CMDB no es un inventario, solo contiene elementos de configuración
necesarios o importantes para proporcionar un servicio. Se recomienda hacer un análisis TOP-DOWN para su diseño, partiendo del catálogo de servicios, y un análisis bottom-up para calcular el coste de un servicio".
El debate sigue abierto, pero el resto de respuestas viene a ser un diálogo entre dos comerciales, bastante interesante por otra parte. No obstante, todo el debate se centra en estas cinco.
Los debates de CMDB son de los más demandados y uno de los más complejos de abordar, ya que cada organización tiene sus requerimientos, sus necesidades y sus objetivos, además de que cada técnico tiene diferentes formas de hacer las cosas (ni mejor ni peor, sino diferentes).
