CMDB: The Case for Services

Services are all the rage in the ServiceNow CMDB (Configuration Management Database) ecosystem, thanks to the release of the Common Services Data Model (CSDM). However, not all organizations are grasping the importance of Services in their daily operations. CIOs still struggle to understand that they are not receiving a holistic view of their Operations and Delivery Environments, especially when viewed from the perspective of their Business teams. Services are the central point between consumers and the business itself. Before your organization overlooks Services, let’s talk about the lack of Services in your CMDB, why they are ultimately an important evolution of most CMDBs, and finally examine how they fit into the common conception of a configuration management database.

Why Include Services in your CMDB?

If your organization is like most, you track assets in one system, and your IT teams track operations in other systems. If you have adopted ServiceNow, you are likely traveling somewhere on the path of consolidating these separate systems into a single platform of reference, with ServiceNow probably integrated into the various systems of record (SAP, Active Directory or LDAP, SCCM to name a few).

Reportable data is one benefit achieved by IT teams that consolidate their information into a single, authoritative place . Doing so within a configurable platform, such as ServiceNow, enables automation and integration of your data into various other processes and brings this information into a more useful, actionable position of importance.

If  you have achieved this initial stage of enabling process, you can see the value of tying records to Configuration Items (ITIL calls these IT Assets), so that pulling up the record of a key server in your environment immediately gives you access to all the Incidents and Changes that have involved this server. Context is key.

Many organizations arrive at a point where they must step back from the gains of CI-level tracking and instead consider how a next target of maturity can bring a higher-level view of business impact and risk. Now that you have a solid understanding of changes and impacts within your environment, the next level is to start relating, and speaking of, these changes in the context of what Services are affected.  This is where your business teams will start to take a greater interest.

Services, in the scope of ServiceNow CMDB, are the logical representations of the whole systems that are delivering value to the consumer of the IT complexity . With the representation of Services as CIs (Configuration Items) in your CMDB, your entire conversation can elevate and involve other important teams in the delivery of the key business products. In the example below, infrastructure CIs (to the right) are Related to the Service CIs (to the left) in that they power and support each other. It is an end-to-end look at the entirety of a Service’s dependencies and components that delivers much more business context that a simple map of dependent infrastructure CIs.

A key consideration here is how your organization considers, assesses, and handles risk associated to change. Let us assume that your IT team is scheduling a large, risky  change to a major system (bond_trade_uk above) that has a household name, in this scenario it’s the one notoriously associated with major outages in the past. Can you* (as the implementor and responsible party) answer the following questions easily and quickly in your current environment? (*You-you, without reaching out to pick the brains of your Directors or Senior SMEs.):

• If the scheduled change to the database server fails in this upcoming update, who among my business peers will be most impacted?
• What is the quantified Risk of this upcoming Change?
• Is there redundancy built into the Service being affected by the Change?
• What other Services depend on that Server or main Service that would be summarily impacted by an outage resulting from this failed Change?
• Can I quickly get a list of individuals and/or teams that should be notified of this Change ahead of time?

These questions are a core tenet of any Change Management process and should be remarkably familiar to an organization keen to minimize impacts to the business. But, most organizations only have this “tribal knowledge” for a few key Servers, Services, and systems, and usually that information is not represented in the same platform that their Change Management system resides within. The whole goal of CSDM is to bring the People and Process pieces together with the traditional representation of Technology in a CMDB. In this way, a better business-centric viewpoint is represented.

What if your Change Management system could help in terms of Risk Assessment, Notifications, and improving a holistic understanding of potential impacts due to a Change taking place against a specific Configuration Item, such as a key server ? If a Change is opened against a Server that hosts a key database, are the Business Owners of dependent Services notified in your process? Is that notification process done by hand currently? Let’s take that question one step farther: What would a system that could automate and streamline such important decision-making be worth to the Operations and Business teams working hard to accelerate your business?

What do I do?

First, you must ensure your CMDB is whole and accurate. An Assessment can help here, reviewing the entirety of the CMDB’s health and coverage, and closing any base data gaps. Second, go through an exercise to gather data from various sources and experts in your organization, as Services are not just an IT object at their heart. Most CIOs will start this process from the IT perspective, but bringing in the business owners, enterprise architects, and other experts to the conversation will always give a greater picture of the consumption and support of a Service. You might find small, surprising things during these conversations, such as a developer calling out that the code depends on a third-party API data service for geolocation, or an architect explaining the high availability structures of the database layer.

Bringing all these separate pieces of departmental knowledge together and forming a single, cohesive, and accurate representation of your key services will take some education and guidance. Establishing a common language for all the moving parts and pieces that power a Service can be a challenge at the beginning of this journey. Eventually, everyone involved will be able to quickly convey information and build out these CIs and their Relationships within the CMDB.

This shared conversation is critical. Establishment of a Service-aware CMDB is not possible with just your Enterprise Architecture experts, nor can your Business Subject Matter Experts achieve this on their own.  It takes everyone involved in the Service, from Design, to Delivery, to Customer Service, as every perspective can bring critical data into the picture.

It is no small feat to take your enterprise architect’s beautiful Visio diagrams of complex services in operation and translate them into one of several constituent parts within the CSDM’s data model in ServiceNow. As you can see in the CSDM data model diagram below, there are many “Lego bricks” that can be used to build a map of a Service and all of its moving pieces in your environment. From the Business Service level down to the individual infrastructure components, navigating this complexity takes some learning and practice.

Translating the boxes in a Visio diagram to the proper representation Class in your CMDB is not straightforward mapping in many cases, because of the myriad ways that a Service can be architected.

How a consumed third-party Service represented is always a key question asked in the modeling workshops and sessions. It is critical to our Service, but do we include it in our CMDB? What about SaaS (Software as a Service) products that we utilize in our daily operations or PaaS (Platform as a Service) tools?

Each organization has differing needs when it comes to what is critical to the understanding of a Service’s operation. Each organization may have unique needs for how granular the representation of Services in their CMDB must be. A Managed Service Provider (MSP) business might have no need to represent systems operated by one of their clients, whereas the clients themselves might have a completely different level of detail of that very same Service in their own CMDB. These are prime topics of conversation and decision during a CSDM working session, as teams will learn together, make decisions together, and deduce how to expand their CMDB data layer.

How do I get there?

Evolving your CMDB requires changing the paradigm for how Services are delivered to your customers. This new and improved vision should support many viewpoints from an IT perspective to a business perspective. Transforming this paradigm across multiple teams and groups takes work, but it is the road to a Service-aware organization. This brings with it the benefit of everyone (from IT, to Business, to Leadership), communicating with the same shared language, and eliminates the hurdle of meetings solely to work through miscommunication. Clarity and the ability to illustrate the answers to key questions is a monumental step forward to value for many organizations . Representing Services not only cohesively communicates impact, risk, and complexity within your environment, but it brings more expertise and talent to the table when maintaining this information.

For a basic example, in your Incident and Change Management processes, simply shifting to using Services as the impacted “thing” or the “thing” to be changed, will take a change in thinking within your IT teams. Incidents are no longer opened on a specific Server or Database, we start to open Incidents noting what Service is impacted directly. This results in the Configuration Item on the Incident form changing from ‘exch01prd’ to ‘Email’, or ‘sap19dceast’ to ‘Billing Services’ and greatly increases the readability for all departments.

Building dashboards of Service performance can also go a long way toward instant, accurate, real-time communication across the organization, an area that ties up a lot of Operational teams’ time. Reports at the Service level can supplement work that Business Analysts do, and grant greater accuracy in outage loss calculations, customer SLA impact, and other critical business tasks that occur in response to Service impairments.

Answering these questions in a data-driven, automated way is a goal that many IT and Business teams strive toward. This is not a matter of rote memorization of what powers what, or what connects and depends on what. This is what your CMDB should be built for. Any robust CMDB solution should allow a person to look up the Service and start there, with the knowledge that somewhere on that dependency map is the impacted, critical piece of infrastructure that is causing the issue.

If you have your enterprise monitoring systems feeding alerts into your platform, the system already knows what is experiencing errors, and can highlight it on the map. In the above scenario, an alert fired from ourStorage (NAS)  platform, consumed by ServiceNow Event Management, and correlated to a Configuration Item, has already created an Incident record. This turns the related Service(s) red in our dashboard, and if your Service Operations Center has this dashboard up on a screen, or your Business Operations team has a screen up in their office area, everyone is instantly notified (in one small way).

Imagine further automation sending customer impact notifications to dependent consumer businesses, or orchestration remediation flows kicking off to execute scripted responses designed by the engineers and developers of the system itself.

Speeding up the Incident resolution process is invaluable. It is one of the highest-requested business outcomes that come up when I speak to CIOs about their pain points. Rapid identification of impacted components of a Service is, to many, the holy grail of improvements to their operational processes and systems. It is no surprise that, at the high velocity speed targets of most IT organizations today, time is money, and a primary target for cost reduction on a CIO’s to-do list.

For your Business and Customer executives, the SLA (Service Level Agreement) or Service uptime numbers are the bread and butter of performance, and in many cases, the core tenet of public opinion of your business. This extends doubly to the business relationships to subcontractors, outsourced organizations, and teams. Keeping these numbers high is always one of the top three goals of any IT organization delivering services, so any improvements that decrease Incident MTTR (Mean Time to Resolution) statistics for outages is going to be an area for continual improvement.

What do I need?

First and foremost, a shared vision and goal is one of the most pivotal criteria for achieving this evolution of your CMDB. Everyone involved in the exercise needs to understand the business case for putting in the time, getting things right, and being proactive towards the end goal. Everyone in your IT organization will be asked to elevate their understanding and conversation when it comes to a Services-aware process. This is where strong leadership is critical and should be highly prioritized, as opposed to an overlooked piece of a transformative project.

Relationships within the CMDB are not just a nice-to-have feature of the ServiceNow platform, but turn out to be critical to accurately representing any complex Service. Without Relationships  being drawn from CI to CI, such as tracing dependencies from webserver to database server, automation of processes within the ServiceNow platform is going to be a distant dream. The platform logic and automation components use these connections to trace a failing NAS system to the Services that depend on it. Thus properly populating an Incident record, and finally perhaps sending automated notifications to those most concerned with an outage involving the specific Service. A lot of individual work can be automated simply through leveraging the ServiceNow platform, teaching it (through the CMDB and Relationships) your IT environment, and then freeing up your talented SMEs to do higher-level work.

Working through the modeling of your Services is no small task. I have worked with organizations that have taken several sessions to fully understand the various Classes within the CSDM portions of the CMDB, which allows them to understand the difference between a Business Application and an Application Service. Or the frequent  misunderstanding and (from a ServiceNow perspective) misuse of the term ‘Application’ to represent Application Services, Business Applications or Business Services. It takes work and time for this taxonomy of terms to become familiar and understood so that the real work of accurately building Service records can begin.

One underlying reason businesses do not undertake CMDB maturity is that it is tedious, monotonous, boring work that commonly falls to the likes of an architect or engineer to maintain due to complexity.  It takes detailed understanding of the relationships between components to properly map these systems, and in most organizations, the engineers and architects have more pivotal work to be doing.

Some organizations feel that CMDB is a waste of time, and to be fair, in the way that they perceive a CMDB, it is. The issue is that a CMDB is far greater than a spreadsheet of systems and diagrams of processes. It is not just a translation of your Visio diagrams; it is also an operationalization of that information in a way that your entire organization can work with, and that you can automate on.

One of the key messages that I try to highlight in any CMDB or IT Operations  project is getting Engineers back to doing Engineering work, automating the “small parts” of their responsibilities that the business depends on them for, and thus freeing their time to do those things that challenge and fulfill them. Smart people want to do smart work, instead of being responsible for constantly updating spreadsheets that still do not fully answer the questions they are called on for. In addition, manual work is prone to human error and stale information, other areas that automated upkeep of your CMDB will eliminate.

Taking your operations to the next level is a common goal for any leader. There are so many features and functional processes already built into the ServiceNow platform that you can leverage once you transform your whole organization’s understanding of how your business runs.