1. Scope
1.1. Son los TIPOS de CIs y las relaciones, que serán incluidos en la CMDB.
1.1.1. No se define cuáles CIs se van a incluir específicamente, sólo los TIPOS... La decisión sobre CIs específicos pertenece al Span.
1.2. Puede resultar difícil de definir, pues deben ser elementos fácilmente entendibles, pero que cubran todas las áreas de TI
1.2.1. Para ayudar un poco en este aspecto, el Desktop Management Task Force (DMTF) creó un estándar sobre los CIs que puede incluirse.
1.2.2. Puede pensarse un tener algunas Sub-CMDBs. BDs de configuración más pequeñas con un Scope diferente y que facilitan la estructura de la CMDB principal, pero el costo es un proceso de diseño y definición del Scope y las relaciones, más complicado.
1.3. Criterios para Definir el Scope
1.3.1. Comenzar simple
1.3.1.1. Lo mejor para empezar es lo más simple posible. Debe existir un balance entre la simpleza y las necesidades de la organización. Si ya existe algún sistema, el alcance debería ser el mismo al principio. Se puede simplificar geográficamente también y por profundidad.
1.3.2. Considerar el costo
1.3.2.1. Se debe considerar el costo (dificultad) de mantener en la CMDB algunos componentes. Un servidor por ejemplo tiene pocas variaciones y es algo costoso, pero los celulares pueden ser complicados de mantener el la BD y sus costo es relativamente bajo. Debe considerarse la complejidad de las relaciones de cada tipo de CI a incluir.
1.3.3. Sumar victorias fáciles
1.3.3.1. No complicarse, los componentes que representen un riesgo muy grande para la totalidad del proyecto CMDB es mejor no incluirlos en etapas tempranas. Si algo falla el proyecto completo estará bajo sospecha, es mejor tener poca información pero que toda esté correcta. También debe evitarse incluir duplicados que ya estén en otros sistemas, esto no crea valor.
1.3.4. Enfocarse en dar valor futuro
1.3.4.1. Muchas veces, este tipo de proyectos falla porque no genera el valor esperado o en un momento crítico los datos están corruptos. Hay que analizar o buscar, cuáles son los proyectos futuros parea así definir el Scope de manera que se genere valor a estos.
1.3.5. Reducir el riesgo
1.3.5.1. Aquellos CIs que puedan causar problemas si algo sale mal es mejor no incluirlos. Esto solo aumentaría el riesgo para toda la organización. Hay ciertos componentes, como procesos muy complicados que se sabe que será casi imposible mantenerlos bien en el sistema, esos es mejor no contemplarlos.
1.3.6. Expandirse lentamente
1.3.6.1. El Scope inicial no tiene que ser perfecto, es mejor que funcione bien. La idea es ir creciendo a como aumenta la madurez del proceso, generando poco a poco más valor al negocio y manteniendo el riego en niveles tolerantes.
1.4. Documentar el Scope
1.4.1. Se debe hacer de manera jerárquica, comenzar por las categorías más generales e ir descendiendo.
1.4.2. Los nombres de las categorías deben estar en términos entendibles para el negocio, no usar tecnicismos.
1.4.3. Los nombres deben ser usables, pues aparecerán en las RFC y tiquetes de incidentes.
2. Span
2.1. Consiste en la decisión de cuáles componentes de cada categoría se tomarán en cuenta. Básicamente se trata de definir fronteras, pues los Span pueden variar, puede haber varios diferentes conviviendo.
2.1.1. Cuando se comienza a establoecer fronteras, se presentan problemas con las relaciones. Debe definirse una política sobre cómo administrar las relaciones que trascienden las fronteras.
2.2. Si algún site de la organización se encuentra bajo regulaciones diferenciadas, si existen diferentes proveedores, clientes u otros socios de negocio; deben crearse distintos Span para cada necesidad.
2.2.1. Si una sucursal se va a cerrar por ejemplo o es impacto muy reducido, puede que no interese ahondar mucho en el Span.
2.3. Criterios para definir el Span
2.3.1. El Span define proyectos
2.3.1.1. Normalmente, la implementación completa de la CMDB no se realiza de una sola vez. Los diferentes niveles de Span ayudan a gestionar el proyecto por etapas. Puede ser por divisiones geográficas o por aplicaciones de negocio.
2.3.2. Las herramientas definen el Span
2.3.2.1. Algunas herramientas son muy útiles pues capturan información a través de la red, sin embargo muchas de ellas delimitan el Span al que traen predefinido y se debe utilizar ese...
2.3.3. Seguir al líder
2.3.3.1. Se debe tomar en cuenta el grado de riesgo que los StakeHolders pueden tolerar. Es Span es la mejor manera de controlar el riesgo pues delimita la cantidad de datos que se deberá manejar. Se recomienda realizarlo también de manera incremental.
2.4. Documentar en Span
2.4.1. No hay un método al respecto, se puede utilizar simplemente un documento con la lista de los Span para cada categoría. Debe aclararse eso sí, las fronteras establecidas y las excepciones a las mismas. Debe ser entendible y el negocio puede preferir un sólo documento junto con Scope y Granularidad.
3. Granularidad
3.1. Se refiere al nivel de detalle seleccionado para registrar los CI. Es decir, qué información se va a guardar de cada componente.
3.1.1. Es, de las 3, la dimensión más difícil de definir.
3.1.2. Si algo no genera valor o bien, nunca se va a utilizar, sólo representa costo y espacio, es mejor no incluirlo.
3.2. La granularidad normalmente se define para cada categoría contemplada en el Scope, son embargo, puede variar para los diferentes niveles de Span definidos.
3.2.1. Se debe tener bien claro el Scope y el Span antes de definir la granularidad.
3.3. Granularidad Fija y Variable
3.3.1. Granularidad Fija Es cuando todos los componentes almacenados tienen la misma cantidad de atributos.
3.3.1.1. Se simplifica en gran medida la administración y el mantenimiento de los datos en la CMDB.
3.3.1.2. Algunos CI no se ajustan al modelo así que se deben agregar campos opcionales o almacenar la información en otro sistema.
3.3.1.3. Variaciones
3.3.1.3.1. Un set de campos "extra" que son fijos. Utilizando nombres como Campo1 o Campo2 y que representarán distinta información, dependiendo de la categoría.
3.3.1.3.2. Adjuntar un documento XML o similar en alguno de los campos fijos, con la información específica del tipo de CI.
3.3.2. Granularidad Variable Es cuando el número de atributos, es distinto dependiendo de la categoría de CIs seleccionada.
3.3.2.1. Existe herencia, cada categoría hereda los atributos definidos para las categorías superiores. Las relaciones pueden tener tipo y atributos también.
3.3.2.2. Costo. Es más complicado y costoso tanto capturar la información, como almacenarla y mantenerla.
3.4. Criterios para definir la Granularidad
3.4.1. Obtener lo esencial
3.4.1.1. Se debe obtener lo que represente mayor importancia y valor para el negocio. Además de que permita cumplir con las metas de la CMDB.
3.4.2. Conocer la fuente
3.4.2.1. Se debe analizar de dónde obtener los datos necesarios, generalmente existe algún inventario de activos u otros sistemas existentes.
3.4.3. Comprender las necesidades
3.4.3.1. Como en las otras dimensiones, el nivel de detalle siempre dependerá de las necesidades del negocio. Es importante definir qué atributos son requeridos y cuáles no.
3.4.4. Balance Conocimiento-Esfuerzo
3.4.4.1. Algunos CI son tan importantes que se deben mantener en la BD a cualquier costo. Pero otros son menos importantes y, si su costo es demasiado elevado, podrían omitirse. Hay que mantener el balance óptimo entre las necesidades y el esfuerzo.
3.4.5. Evitar el peso muerto
3.4.5.1. Debe omitirse todo aquello que no agregue valor al negocio por medio de la CMDB.
3.4.6. Evitar los atributos manuales
3.4.6.1. Hay atributos que requieren mucho trabajo manual para almacenarlos y mantenerlos, por eso nuevamente se debe considerar la importancia que tienen para el negocio, puede que valga la pena pero son casos muy exclusivos.
3.5. Documentar la Granularidad
3.5.1. A diferencia del Scope y el Span, este proceso es un poco más complejo.
3.5.2. La mejor opción es usar Diagramas de Clases, pues ahí se puede incluir todos los elementos necesarios.
3.5.3. Si se utiliza Granularidad Variable es más complejo. Debe agregarse las "clases" con atributos extra, como hijas de las originales e incluir sólo los atributos extra.
3.5.3.1. Este proceso, junto con la definición completa del modelo de la CMDB, son ITERATIVOS.