Fundamental design consideration for a net new CMDB
Fundamental design consideration for a net new CMDB
On the verge of the fourth industrial revolution, every company is trying to be digital. A digitally focused organization is becoming more reliant on technologies to run business processes and automation. With so many technologies getting introduced to support concepts like telemetry, hyper-automation, observability, etc., it is becoming a daunting task for organizations to have visibility into technology components, the IT services, and their offerings and manage them in a way that drives value for the business. The most proven way to do this is through a trusted Configuration Management Database, CMDB. Over years and years, CMDB has stood the test of time and has continuously evolved to be next-gen technology focused. From the world of on-premises infrastructure to virtual infrastructure to Cloud EC2 to containerization and microservices, CMDB technology is continuously evolving.
Navigating Complexity with Strategic Planning and Business Alignment
One most common trend across all types of industries is that both the business and technology teams are not having a positive experience with CMDB. The most common concern we hear is that CMDB is not accurate, or it is very complex to manage. Even to the extent we have heard technology leaders giving verdicts on CMDB as a dead horse. What we need to remember is that an evergreen CMDB does not just happen via a big bang. It requires a carefully detailed Configuration Management Plan by identifying your objectives & goals, establishing a comprehensive strategy to deploy a robust and trusted CMDB, understanding service consumption patterns, and most importantly, understanding the business priorities.
The Crucial Role of a Mature CMDB in Mitigating Business Risks
However, to have a trusted single source of information from disparate technology systems the best bet for an organization is a matured Configuration Management Database established with the buy-in from business stakeholders. This is because the impact an unhealthy CMDB can bring to an organization can be catastrophic. Imagine your organization experiencing unplanned outages most probably caused by unplanned changes. This could cost millions of dollars for your organization. How about a business application having unknown issues where many users are affected and unable to perform their tasks? Without a healthy CMDB, it is difficult to know what recent changes were made to the application or the database it is connected to, or the server running the application. To save time, effort, and cost, and to minimize potential business risk, a robust CMDB will help quick troubleshooting into where the issue is coming from and all impacted services.
The Crucial Role of a Mature CMDB in Mitigating Business Risks
However, to have a trusted single source of information from disparate technology systems the best bet for an organization is a matured Configuration Management Database established with the buy-in from business stakeholders. This is because the impact an unhealthy CMDB can bring to an organization can be catastrophic. Imagine your organization experiencing unplanned outages most probably caused by unplanned changes. This could cost millions of dollars for your organization. How about a business application having unknown issues where many users are affected and unable to perform their tasks? Without a healthy CMDB, it is difficult to know what recent changes were made to the application or the database it is connected to, or the server running the application. To save time, effort, and cost, and to minimize potential business risk, a robust CMDB will help quick troubleshooting into where the issue is coming from and all impacted services.
We couldn’t see any other systems closely challenging the existence of CMDB. Let’s start by understanding what a CMDB is.
Exploring the Significance of a Configuration Management Database (CMDB)
A configuration management database (CMDB) is a data repository that acts as a data warehouse to hold, maintain, track, and manage information about a wide variety of IT services and or digital services known as configuration items (CIs), typically including hardware, applications, software, storage, cloud components, servers, networks, buildings, people, suppliers, and documentation along with the descriptive relationships among them and the operational usage of those assets. It provides needed information to other processes and practices (such as Incident, Change, Problem, Service request, Knowledge, Information risk, HR, legal, etc.) to support their activities, making it a powerful tool that keeps the lights on for IT operations ensuring the operational usage of assets are tracked and managed appropriately.
We took a deeper look into the concerns to understand the fundamental design aspects that need to be considered to have a matured CMDB that can serve the needs of a business & customer-focused organization. Check out these insights before designing a net new CMDB:
Scope Consideration: The foremost consideration when you design a CMDB is the data scope you intend to track and maintain. This includes the CI types that will be entered in the CMDB and the amount of detail that will be tracked for individual CIs. It makes sense to find a balance in what information should be tracked, really necessary, adequate, and or not necessary. Too much detail may be unmaintainable, and some may not be useful. A good guiding principle is “Only track what you use and or you will use, and what you maintain and or you can maintain”.
Determine Data Model: The data model is the structural representation that defines how data, and its elements are organized, standardized, and related to each other. The data model must be designed in a way that supports the business needs of the organization with the flexibility to allow modification as the organization evolves in this age of digital transformation where new business processes, digital services, and products emerge.
The data model could cover the structure and relationships from business capabilities, platforms, business applications, application services, storage, databases, servers, business services, technical services, and their offerings, etc. This will help to maintain and achieve consistent compatibility of data across systems, and it can be provided in 3 distinct perspectives such as conceptual data model, logical data model as well as the physical data model.
CI Class Ownership: CMDB configuration items (CIs) Class refers to the actual table in Configuration Management Database. These are groups of CI types that share the same attributes and are stored in their own tables. CI Type is a friendly name that a CI is known by, such as Windows Server, IP router, or Application CIs.
If CMDB is a big mansion, then you can think of CI Classes as various rooms in the mansion which contain specific objects that make the rooms serve their purposes.
If you pick any CMDB product, you will find plenty of CI Classes offered by the product. However, the big question is do you need to turn on all the CI classes for your IT Operations? The answer is No.
You should carefully select a CI Class in your production instance golden CMDB only where it requires to support a business need. If you have a requirement from your Technology Operations or Security or Technology Delivery for a particular CI Class to manage their operation or deliver a service or for a security reason then you can configure the CI Class in CMDB otherwise it should be hidden from your technology users when a request, incident, change and or problem record needs to be registered or created during IT operation.
Again, before you take the decision to configure a CI Class another important consideration is to have a CI Class Owner identified. Please note this is not CI Owner but CI Class Owner who has the accountability. This is most challenging and most of the time it will be difficult to find a team or a person who wants to take this responsibility. A CI Class Owner should be a decision-making authority on attributes of a CI Class, data sources, edit rights, process to manage data, and CI Class reporting.
During any audit on a CI Class, they have a responsibility to provide necessary information to auditors. If you configure a CI Class that no one needs and no one owns, then it will be never managed in the CMDB. This becomes redundant. Just because we want it does not mean we need it. Follow the rule of thumb. Only track what you will use and what you can maintain”
CI Attributes definition: Every CI Class has attributes that define the CI, such as CI name, Owner of the CI, Groups managing the CI, location. Attributes can differ in each CI Class or can be common across multiple CI Classes. When we talk about CMDB accuracy, or CMDB Health, CMDB completeness is actually an aggregation of the data managed in these attributes level. Hence, it is very important to carefully choose attributes for a CI Class you want to manage in the CMDB.
As a rule of thumb only consider attributes if it serves any use case, for example, either used for incident assignment, change impact assessment, risk calculation, service level calculation, or patch management, business resiliency calculation, or event correlation. If an attribute is not used, no one cares for that and in no time the data will be outdated. If you think of some attributes which might not be influencing any workflow but have a reporting requirement from a management perspective. For example, the Operating System of servers. The Hosting department might ask to produce a report of OS that is outdated. In such cases, put a priority to get these attributes discovered otherwise it will be very difficult to keep the information updated.
Federate and Normalize Data Sources: The data in a CMDB can come from multiple sources via discovery or scanning tools, manual updates, and other systems integrations. The goal is to make CMDB the single source of truth for the usage of data in IT Service Management, IT Asset Management, IT Compliance and enable decision-making related to service delivery, IT investments, and allocation of resources. While it is critical to ensure that data from different sources need to populate the CMDB, it is crucial to understand the strengths and weaknesses of each individual data source, their impact on business needs and operations, set up data source architecture, and then initiate and define processes and business rules to validate and normalize the data via a reconciliation hub before they are populated into the CMDB. One of the major gaps encountered among organizations today is that they do not put into consideration what laundry list of data sources are available in the organization that is separately used by different teams either by Infrastructure, IT security, and or applications teams.
There must be a common agreement of expectations on what and how each data source should be considered to feed data into CMDB so that the organization can have a robust and federated CMDB that supports the objectives of different stakeholders including IT security. Security tools such as Rapid 7, Tenable, SolarWinds, and other tools like SCCM, Tanium, etc. can be considered as data sources to populate the CMDB but the data coming from these sources must be validated and normalized in a hub before populating the CMDB.
However, from an enterprise architecture standpoint, if an organization is using an Application Portfolio Management tool for example, LeanIX, they must determine what type of data is needed to populate CMDB, the CI class it should populate, and the frequency of data update whether unidirectional or bi-directional.
Automate Data population: During design, the target should be to possibly automate the data population of 100% of attributes in CMDB for a CI Class via a data source architecture mechanism. Either through inbuilt discovery, third-party scanning systems, or through automated business rules, you should attempt to automate data population and get away from non-discoverable attributes. One of the major determents in maintaining an updated CMDB is asking a human to update the data [aka non-discoverable attributes]. Most of the time it’s not proactively done by CI Owners or responsible persons or teams. Following up with CI Owners to keep data updated often requires another dedicated person which means an extra cost of resources for the organization. Sometimes, it becomes difficult to justify the cost to management as this proposal often contradicts the policy statement that managing CI is a responsibility of a CI Owner. Hence, CMDB Designers/ CMDB Product Owners are looking for options to completely automate the data population and relationship-building process. An 80% – 20% rule can be applied where we push for 80% automation. Additionally, an error exception handling process must be established to handle any failure occurring from the automated data population process.
With so much data generated by different systems, it is now very possible, and many companies have done it, especially with Cloud Infrastructure. If you believe in the art of possibility and have a design-thinking mindset this is achievable.
Consistent Data Quality: CMDB Data quality is very crucial to how the data are used to meet the needs of both business and IT. It is very important that an organization sets up data quality standards and processes to help in validating the data completeness, correctness, compliance, and relationships. This may involve driving the data certification process on a quarterly basis with CI owners and data owning groups via automated and manual validation to ensure consistent and continual data quality improvement.
This can be tracked via a CMDB health dashboard to help make decisions on what actions need to be taken by the CMDB governance to ensure that the CMDB data are evergreen.
The correctness metrics may track what CIs are orphan (CIs with no relationships), duplicate, and or stale (CIs that have not been updated over a specific period based on a predefined business rule) in the CMDB.
The completeness metrics could track what CI attributes or fields are mandatory and or recommended but missing information on the CI record
The compliance metrics could track a comparison of actual values of specified fields on the CI record against expected values defined in the template and scripted audits.
The relationship metrics could track stale relationships (i.e., a relationship where the parent or the child CI is a stale CI), orphan relationships (i.e., a relationship that is missing either a parent CI, a child CI, or both), and duplicate relationships (i.e., a relationship that has identical parent and child CIs, identical relationship type, and an identical port).
Security: Every CMDB will include sensitive data or information about an organization’s IT infrastructure and systems. This makes security a vital component of designing a successful CMDB.
As an organization, you need to define and determine access privileges given to different individuals and tools (via integration) based on their roles in the organization and ensure that data are protected from unauthorized access to update, override, read, and or delete relevant and sensitive data from the CMDB throughout the lifecycle of the CI or IT service.
CMDB Governance: CMDB governance framework is a critical component while designing a healthy CMDB to support the needs of the business. This requires establishing the policies, procedures, roles, and responsibilities for managing the data in the CMDB from CI class structure to CIs. It is very important to establish a CMDB governance framework that aligns with the organization’s overall IT governance structure, and ensure that there is clear ownership, responsibility, and accountability for the CMDB. We have seen over time that only very few organizations have established Configuration Management Control Board to oversee and direct the actions and changes made to the CMDB.
The CMDB governance involves regulating the Configuration Management plan and all configuration management activities including what and how Configuration items are onboarded (including development), maintained, and retired in the CMDB throughout their lifecycle.
CMDB – ITSM Interface: Apart from the core strategic purpose of having CMDB to provide an accurate, correct, and up-to-date representation of your organization’s assets and the relationships between various configuration items (CIs), the operational usage of those configuration items (CIs) makes CMDB the heart of ITSM serving as a single of truth for CI data needed to troubleshoot and perform IT operations tasks.
When an incident or a problem occurs and affects an IT service or component, or when a change must be implemented whether to onboard a server or for a version upgrade to an application software or a fix to a degradation or outage, the IT service or component will be referenced as a Configuration Item (CI) on the Incident, problem or change record.
As you plan to design your CMDB, you must establish what CI classes you need to populate on Incident, Change, Problem, Knowledge, and Service request records in your ITSM tool as an organization grows and evolves, modifications can be made to suit their business needs. This is achievable if you apply the construct of a data model.
Every organization must ensure all the above key considerations when designing a CMDB to successfully serve the needs of the business efficiently and effectively.
