Central Data Source: The Practical Implementation of a CMDB
The CMDB as central data source
After having identified the importance of the CMDB for all service-oriented companies in my last article, now I would like to look at this topic from a more practice-oriented point of view.
Nowadays, illustrating an entire user process within a company can be rather complex. The main cause of this is the interaction of a variety of business areas and the consideration of lots of tasks.
To get a better understanding, let’s consider the (simplified) process in case an employee decided to leave the company.
Generally, the HR office is the starting point of this process, but there exist also tasks, which regard the department the employee is leaving, and obviously the IT department.
Which could be possible activities? (Just in parts, to get an idea)
- Transfer of the termination date to all involved departments by the HR department (at the end of the process, the HR department has to be informed about the completed tasks).
- The IT department has to complete the following tasks
- Disable / cancel account
- Lock mail account
- Remove contact from mailing lists
- Disable access to disk drives
- Adjust phone book
- Retract computer
- Retract mobile devices
- Terminate contracts
- Transfer licenses
- Disable VPN accounts/access
- …
- The concerned department has to fulfill the internal tasks and to inform the IT about relevant decisions.
To coordinate these tasks (and lots more) in a structured way, the utilization of a service management tool with integrated workflow function is required. For the workflow itself, the knowledge about the actual CI structure is essential.
If a CMDB with a working change-management-process is filled and maintained correctly, it is easy to retrieve all relevant data regarding the user of interest. Such relevant information may be for example the information if the user had any mobile devices and which contracts were assigned to them. Based on this information a return list can be automatically created.
Another example is the removal of the contact from mailing lists or pick-up groups etc. Such work steps can be automatically executed using scripts. This also applies for the removal of access to applications. Thanks to a well-maintained CMDB, it is always known to which internal and/or external applications an employee can access. These access permissions can also be removed by the execution of scripts.
Beside the assigned devices, there exist many other decisions the department of the leaving employee has to take. What should for example happen with the mail account? Should it be deleted, or should another employee get access to it (attention to data protection policies) or should the emails be forwarded to another colleague (for example if the mail address was used in publications)?
What should happen with the personal network drive? (There could be saved business-relevant information.) All these questions can’t be answered by the IT department, but have to be clarified by the department to which the employee belongs.
The IT department however, has to provide the relevant information regarding the data situation of the employee, to support decision-making. Often, not even the supervisor or the employee himself know to which data he or she can access.
In applied service management processes, information regarding the employee are graphically represented through relationships between different CI types within the CMDB (CI types may be for example hardware, software, documents, services, people etc.). Therefore, the CMDB serves as data source for different service management processes (change management, service request fulfillment, access management etc.).
Conclusion
In summary, it can be said that a reliable service management is not even possible without a working and maintained CMDB. For the visualization and automatization of workflows, actual data from the CMDB is always required.
In this article, the description of the tasks and their interaction was simplified to get a general understanding of the topic. In practice there are many other aspects that have to be considered (but for a global understanding, these details are not relevant). This article was thought to provide a general overview of the practice-oriented usage of a CMDB.
Important: In a CMDB the dependencies/relationships/connections between the CIs are of major interest. Through a relationship-map (Configuration Management Relationship Map) all the connections between CIs can be visualized.
My next article will be about the integration of your CMDB to our IT service management solution WÜRTHPHOENIX EriZone.
Martin Fischer
Author
