1. Scope
1.1. Ideas:
1.1.1. CMDB based on two elementary constructs:
1.1.1.1. 1. Configuration items
1.1.1.2. 2. Relationships
1.1.2. Desktop Management Task Force (DMTF) created the Common Information Model (CIM): sets of categories and associations.
1.1.3. Multi-tiered CMDB.
1.2. Examples of Included and Excluded Scope
1.2.1. Included:
1.2.1.1. Infrastructure:
1.2.1.1.1. Hardware: workstations, servers, personal devices, etc.
1.2.1.1.2. Software: operating systems, business applications, database management systems, etc.
1.2.1.1.3. Network.
1.2.1.1.4. Documents:
1.2.1.1.5. People ¿?
1.2.1.2. Relationships: you have to look at the list of configuration items
1.2.2. Excluded:
1.2.2.1. incident records, change records, relationship printer-workstations, etc.
1.3. Criteria Used to Determine Scope
1.3.1. Star Simple
1.3.1.1. Things can be easily learned and maintained
1.3.1.2. Geographic: only one or two locations
1.3.2. Consider the Cost
1.3.2.1. Cost/Benefits Analysis
1.3.2.2. Not everything
1.3.3. Score Easy Victories
1.3.3.1. Success determined by confidence in database
1.3.3.2. Do only what you can manage
1.3.3.3. Reduce risk
1.3.4. Look Ahead to Value
1.3.4.1. Think about the future value, just do that
1.3.5. Reduce Your Risk
1.3.5.1. No erroneous data
1.3.6. Expand Slowly
1.3.6.1. Initial scope does not have to be perfect!
1.3.6.2. Relationship between scope and maturity of processes.
1.4. Documenting Scope
1.4.1. Category structure: best way to document it
1.4.2. Starts at high-level, then continue to the sub-categories
1.4.3. Use organization-familiar terms
2. Span
2.1. Ideas:
2.1.1. Which items of each class you are going to capture
2.1.2. Its all about establishing boundaries and ways to describe span
2.2. Criteria Used to Define Span
2.2.1. Span Defines Scope
2.2.1.1. Span can be used to help define projects
2.2.1.2. Partitioning the span
2.2.2. Tools Sometimes Dictate Span
2.2.2.1. Tools sometimes dictate span of the CMDB
2.2.3. Follow the Leader
2.2.3.1. Understand degree of risk your project sponsor will tolerate
2.2.3.2. Policy statements should be documented
2.3. Documenting Span
2.3.1. There is no perfect format
2.3.2. Span document should be concise and understandable
2.3.3. Combine it with the scope document
3. Granularity
3.1. Ideas:
3.1.1. Describes depth of the configuration management effort
3.1.2. Cost/Benefit analysis
3.1.3. Granularity: set of attributes you want to understand about each of your configuration items
3.1.4. Defined for each individual category from your scope
3.2. Fixed or Variable Granularity
3.2.1. Fixed:
3.2.1.1. All configuration items and relationships share the same set of attributes
3.2.1.2. Benefits:
3.2.1.2.1. Makes efforts much simple
3.2.1.2.2. Data collection and maintenance are greatly simplified
3.2.1.3. Drawbacks:
3.2.1.3.1. Choose between two inconvenient options for things that does not fit the model:
3.2.1.4. Variations:
3.2.1.4.1. Addition of a optional attribute
3.2.1.4.2. Attachment of an XML document
3.2.2. Variable:
3.2.2.1. Allowing the category to determine which attributes are present
3.2.2.2. Set of information you track differs based on the type of configuration item
3.3. Criteria Used to Define Granularity
3.3.1. Get the Essentials
3.3.1.1. Elements that are critical to know about each CI
3.3.2. Understand the Source
3.3.2.1. Asset management system or people
3.3.3. Know Your Needs
3.3.3.1. Think about the stakeholders
3.3.4. Balance Knowledge and Effort
3.3.4.1. Cost/Benefits
3.3.5. Avoid Dead Weight
3.3.5.1. Not too much details, just enough
3.3.6. Caution: Manual Attributes
3.4. Documenting Granularity
3.4.1. More complex than scope and span
3.4.2. Use object-oriented concepts
3.4.2.1. Classes
3.4.2.2. Inheritance
3.4.2.3. Associations
3.4.2.4. Attributes
3.4.3. Variable needs more work
4. Introduction
4.1. Requirements needed
4.2. CMDB in three dimensional matrix:
4.2.1. Scope: potential contents of the CMDB, categories of objects and what kinds of relationships.
4.2.2. Span: specific groups will be tracked within each object that was defined in the scope.
4.2.3. Granularity: what will be known about each configuration item or relationship.