CSDM: How to get there?

[David Skowronek]

CSDM (Common Service Data Model) is a very hot topic nowadays, and many customers are asking: how to get it implemented? This article provides high-level guidance for the CSDM implementation journey based on the discussions with various customers and personal experience with complex data model change project. This article focuses on customers that already have a live ServiceNow instance with a data model different from the CSDM. However, the steps described in this article are generally valid for new ServiceNow customers as well.

Depending on the level of deviation from the CSDM, this migration may be very extensive and complicated – especially as you are doing it in an already live environment. In this situation, you must have a very clear design and plan, with clear steps, risk and dependency analysis, and all stakeholders etc. identified. Therefore, forget about the pure agile approach; this needs a waterfall. Every step is designed upfront, with detailed impact analysis and likely sequence of transitional architectures before reaching your target model. You may spend more than 80% of the time on the architecture, analysis, planning – with minimal technical implementation afterward. And this is the right approach, as you need to mitigate the risk for your production and business.

Where to begin? Define the target model. In practice, there are two main approaches:

• Start where you are
• Start with a “clean sheet”

Based on my personal experience, I recommend starting with a “clean sheet”. Forget what you have today and define the data model that best fits your (business) needs. If you try to begin where you are, you will spend a lot of time in low-level discussions regarding what you have today, how it is done, whether it should stay, etc. And the result will be one significant compromise where nobody will be happy. The target model will likely be neither the best you need nor the CSDM-compliant.

Step 1: Define your target model

The first step is to define your target data model based on the CSDM. One important rule to remember is that you implement now but plan for the future. It means that you should consider your future plans and make sure that what you design and implement now will support your business needs in the future.

Key outputs of these steps are:

• CSDM objects (tables) that will be used
• How they are related to each other
• Who is accountable and responsible for each data object and data inside it
• How do processes consume the data model

CSDM model is extensive, contains many tables and relationships among them. The most important rule is that less is sometimes more. It is better to use fewer well-managed elements than to implement everything with poor data quality.

CSDM is the backbone of ServiceNow, and as the human’s backbone, it has some flexibility. However, do not try to deviate from the prescribed model. Some products have a hard dependency on some classes and/or relationship types (e.g. Event Management, Service Mapping, Application Portfolio Management, impact analysis in Change Management, etc.). You never know what comes in the future.

Define your target data model based on the CSDM by choosing those elements (classes) you need to support your business and your current and future planned ServiceNow products need for the proper functionality.

You may use the following guiding questions for your decision making:

• Does ServiceNow need this element for its proper functionality?
• Do I need this element (to support the business)?
• Is it (will be) used by the process(es)?
• Do I have an accountable person for the element?
• Do I know where to get the data?
• Do I have responsible people that will take care of the data?
• Am I able to manage the data / keep them up-to-date?

If you are not able to answer „Yes“ to all those questions – and there may be more of them – you should consider carefully whether the element should be implemented or not. There is nothing worse than having some element as a mandatory part of your process but not able to keep the data up-to-date. It usually brings more issues than benefits.

There is one critical question listed above: „Is it (will be) used by the process(es)?“. The data model as such has no value. Its value is realized by the processes that consume it. Therefore, you should validate your model against your processes and clearly define how each element is used. This validation is not necessarily against your current process implementation, as it may change due to this activity. Instead, it would be best to validate against your new processes that will leverage the new model. For this reason, it is crucial to not focus only on the data model itself but also consider your processes and how they should work with the model optimally.

During the process usage definition, you should work from the end-to-end perspective as a journey:

• As an end-user having an issue, how do I raise an Incident? What part of the data model is used?
• As a Service Desk Agent reviewing the raised Incident, what part of the data model do I need to understand the impact of this Incident effectively?
• Can I do it seamlessly when I need to raise a Problem ticket? Do I use the same elements?
• And what about the Change ticket?

This journey is an example only – there are many other journeys that you need to define and evaluate.

A defined data model should support the processes and enable the seamless move from one process to another, on top of the same data model and same usage of elements.

During the process validation of the data model, you will consider your as-is state – the current data model and its usage – which may result in the model changes. This is why I recommended starting with the “clean sheet” in the beginning. You have defined the best model you may have, and once you have validated the model, you may need to make some changes if required. But you know how much you deviated from the (theoretical) optimal model.

Step 2: Define transitional architecture(s)

The model you have defined in the first step is the target model, and its implementation may take a while. Therefore, as the next step, you should specify the sequence of transitional architectures. The target of transitional architectures is to implement and enable usage of the new data model in a manageable and controlled way with minimal impact on the business and stakeholders. Do not try to implement everything at once with massive – and unpredictable - impact, do it in smaller chunks.

Change of the data model comes with changes in processes. This means that all your service owners, fulfillers, etc. will likely be impacted. In the worst-case situation – which is not so unlikely as it could sound – it may require re-training all affected users. This situation you need to consider when you plan your next steps. There are a limited number of changes that business and people can accept in a short time. Proper Organization Change Management is essential here. Impact analysis, stakeholder analysis, and communication plan are crucial for every transitional analysis.

There are three main steps you will likely follow:

• If you have defined new elements that have not been used so far, you need to collect the required data
• You need to move (and maybe transform) data from the current location (classes) to the target ones
• You need to change processes to consume the new data model

From practical experience, you need to limit impact to various personas so that you - in the best situation - impact only 1 or 2 personas simultaneously and only once. It means they need to do some work / be re-trained only once. How do you achieve it? By the proper sequence of transitional architectures.

Following the three main steps above and need to limit impact at the same time, you can plan your transitional architectures in the following way:

Migrate existing elements to the target location

As a part of the new data model, you will likely introduce new elements. Even though it sounds like a logical point to start with, CSDM elements are related to each other. Therefore, having the current data in the right location (class) is often a prerequisite to introducing some new elements. Otherwise, you have double work.

But at the same time, you need to limit the impact to processes that consume such data; otherwise, you go with a big bang, which is not optimal.

The target of the first transitional architecture should be:

• Move the current data to the correct location (class)
• Enable the creation of the newly introduced elements
• Do not impact the current processes

The last point is the most important: you should move the data but keep the same usage as today. In practice, this means that you need to adjust existing reference qualifiers in the current processes to target new classes, etc., but the data usage in processes is the same.

An example can be having business and technical services inside the same table. You may need to move them to dedicated Business Service [cmdb_ci_service_business] and Technical Service [cmdb_ci_service_technical] tables. The current reference qualifiers may need to be changed to point to the Service [cmdb_ci_service] table with condition WHERE Class IN = cmdb_ci_service_business OR cmdb_ci_service_technical.

This approach limits the impact of this first transitional architecture on Service Owners, Configuration Managers, and similar roles that are responsible to create/maintain Services, Service Offerings, and similar attributes that are most likely impacted by this first transitional architecture. Your fulfillers – consumers of the data model – are not anyhow impacted.

Populate new elements

You may start working on adding new elements as you have the current data in the correct location. They are not used by any process now, and this gives you time and flexibility to make sure that they are appropriately implemented and populated.

Those new elements are also likely managed by the same people impacted by the first transitional architecture – the migration of elements. Therefore, they should be already trained for the new data model, how it is supposed to work etc.

Change the current processes

You already have the model in place in the current stage, but it is not optimally consumed by the present processes yet. Now you need to define one or more steps to introduce the model into your processes.

For example, it can be Application Services that are not used in the current model; you may need to introduce this element as part of your processes – add to forms, implement reference qualifiers etc.

Depending on the complexity, you may choose an approach per-process where you go process by process and make needed changes. For example, you may start with Incident Management process, do all needed modifications in forms, fields, reference qualifiers, business logic etc. to consume the new data model, and train all stakholders for the new process. Once completed, take the next process.

Alternatively, you may go per-element where you change/introduce one (or more) elements across all processes. For example, you may start with Application Services (if they are not used yet) and embed them in all ITSM processes at once.

Big-bang, where you adapt all processes is also an alternative here. Everything depends on the number of changes required and the impact they have. The target is to maximize the value and reduce the impact to stakeholders to the minimum.

This is also an opportunity – even though I would rather say mandatory step – to perform a data cleanup, ensuring that obsolete data are not used anymore.

Step 3: Implement defined target architectures

Everything that I described so far is happing “on the paper”. There are many things to consider and plan carefully, so the waterfall is the right approach. When you have everything defined, every single step, you may start with the implementation.

You should never underestimate one critical aspect, as your success depends on it: ORGANIZATION CHANGE MANAGEMENT. You may do all the steps correctly, but you will fail if you underestimate the OCM and communication.

Key take-aways

• Design for the future
• Take the time and do the architecture right; change on the paper is much cheaper than trying to fix an issue in production
• The data model itself has no value; value comes through processes that consume it – design them together
• Do not underestimate Organization Change Management – this is the critical success factor

[cwooten]

We recently kicked off our CSDM journey. This article is timely as we have been asking ourselves Where do we start? and How to get there? 

[Debalina Mukhe2]

This article is very relevant now. We have started our journey with CSDM 4.0 recently.

[Pradeepkr]

Hi David ,

I want to implement CSDM .Is there any document provided by Service Now which have complete process by following which we can successfully implement CSDM .

What challenges comes in while implementing CSDM in environment ,can you explain it with an example . The points you have mentioned are not easy to understand for beginners .

There are several examples and steps have been discussed in White paper and Product documentation as well but while trying to get into it is very difficult to start.

Example of EPIC healthcare ,Kindly explain this example what  is the starting point from where anyone should start and what will be the steps that are required to implement it and how much time would be required for it.

[ShantelM]

@David Skowronek  Hi David, I am working on developing a plan to implemenet CSDM and understand its important to determine the critical CI classes to start with. As a large bank, what do you suggest as a starting point for CI Classes to narrow the focus and be able to get started? Server class, Database class, etc. Thanks so much