by Tobias Schwartz and Bryan Graham

The Common Service Data Model (CSDM) is here, and customers WANT IT! And why would anyone be surprised, it’s something that customers have been elevating to for years. Now in its 3rd iteration the CSDM has quickly become THE best practice baseline upon which to build a Configuration Management Database (CMDB) along with service-related data that will be utilised by many ServiceNow products.

But where to start? If just starting out on the ServiceNow journey the CSDM white paper should be all that’s needed, and this article will likely be of little use. This article is targeted to the type of customers that have been building towards the CSDM, with no knowledge of the “CSDM”, creating the attributes and features on the ServiceNow Platform because it made good business sense. Before CSDM came along there wasn’t a Business Application or Application Service, however there was an Application class (cmdb_ci_appl), and it’s this table that seems to have been adopted by many to fill the gap. This is where the Crawl phase of CSDM adoption enters.

First off, what is CSDM? The white paper defines it best here.

“The Common Service Data Model (CSDM) represents a standard and shared set of service-related definitions across our products and platform that will enable and support true service level reporting while providing prescriptive guidance on service modelling within the CMDB. These service-related definitions span the ServiceNow® product portfolio and the Now Platform®.

The data model is a CMDB framework across our products and platform that will enable and support multiple configuration strategies. Included are best practices related to the proper modelling of data using out-of-box (OOB) tables and relationships. Many ServiceNow products have a dependency on data within this data model.”

Figure 1: CSDM Reference Guide as provided in CSDM white paper.

Why Migrate?
All the attributes needed have been captured and built on the cmdb_ci_appl table, so why migrate? From experience, several key constraints have been drivers for businesses wanting to align their data;

• The Application class gets polluted and people tire from trying to find Apptio among 100 installations of Apache. Also, the constant second guessing of staff populating an Incident “Am I selecting a logical representation of all installations of this app? Or a specific instance running on a server?”
• The above is further exacerbated once enabling Discovery
• Implementing Service Mapping will require the adoption of Application Services, a key component in the CSDM
• Implementing Application Portfolio Management will require Business Applications, another key component in initial adoption of CSDM
• Watching technical debt accumulate as CSDM evolves (as can be seen by the leap from 2.0 -> 3.0) and ServiceNow platform and products rely more heavily on the data model, it becomes less a question of IF the need to migrate and more WHEN. The job will only get harder in the future so why not now?

Figure 2: Crawl phase of CSDM adoption and initial focus.

Migration Approach
The migration approach here is based on steps provided in the CSDM white paper, if yet to absorb this, pause and do so before proceeding. The intention is to extend the knowledge offered in the white paper with specific tips identified when migrating from Application class to Business Application / Application Service.

1. Backup Data
Back it up into Excel and XML. Excel is great for reviewing, transforming and manipulating before plugging it back in. XML is great for restoring. The plan here is to have multiple runs of the migration so the XML will be used to bring the environment back to baseline. Also, be sure to backup all impacted data, not just the source and target tables, but referenced data such as tasks, task_ci etc. (a more extensive list is provided below).

2. Attribute and Class mapping
While planning the migration of data from the Application class consider several points for each attribute;

• First, is this still required? Take the opportunity to review any customisations that have been made and identify if they are still required based on current business requirements.
• Second, where does it best fit? Does it describe the logical application record <Business Application>? Or is it more specific to an environment <Application Service>? Does it describe data housed within the application <Information Object>? Is it a stratification of a higher-level service <Service Offering>?
• Lastly, does the attribute already exist on the identified target? Are the data types and choice values aligned or will transformation be required?

Figure 3: Sample attribute mapping for Application class. Important to recognise that attributes may be pushed to two or more different target tables.

3. Data Dependency
This step is all about identifying the data that is currently referencing and relying on the application records being migrated. A fantastic script is provided in this community post Migrating into CSDM identifying table dependencies which will provide a list of Business Rules, Client Script and Reports to evaluate. A similar approach should be undertaken to the attributes above where each is rationalised as still relevant and if they already exist on the target.
One issue in defining dependencies for the Application class is a lot of the references to an Application won’t be a reference directly to the Application class, rather they will reference the parent class of Configuration Item (cmdb_ci). Search the ServiceNow dictionary for every table referencing cmdb_ci and get 1000+ hits. Here’s a list of tables identified as often including referenced Applications and may need updating:

• CMDB Relationship (cmdb_rel_ci)
• Knowledge (kb_knowledge)
• Outage (cmdb_ci_outage)
• Affected CI (cmdb_outage_ci_mtom)
• Requested Item (sc_req_item)
• Task (task)
• Task CI (task_ci)

4. Refactor Attributes
The approach here will depend on the data currently stored in the Application class.

• Is the Application class data essentially an inventory of the application portfolio? In this case, move existing Application records to the Business Application table and create an Application Service (normally just the 1 for Production).
• Are Applications representative of deployed stacks or environments? In this case, move Application records to Application Service and create a related Business Application.
• Or is it more complex with a mix of everything stored in one table, installed applications coexisting alongside application environments and business applications? If this is the case, identify a method of distinguishing the data ie. Environment is populated for some, Business Owner completed for some while others are “installed on” a server.

Take this opportunity to clean up the data for applications. In previous steps, attributes and features built for the application table were assessed, now review individual records. Is the application still relevant or long retired? Is it actually an application? Or would better reside in another table like service?

5. Migrate Data
Hopefully now there is a clear idea on what data is stored, where it needs to be and what needs to happen for it to get there. What’s important during this phase is there’s a plan with clear, repeatable sequence of actions, checkpoints and rollback steps. As with any code being developed on the platform, the data migration should take place in a non-prod environment, tested and validated before given all clear for production.

A sample plan might look like this:
1. Import excel spreadsheet in to create Application Services
2. Use script to redirect CMDB relationships from Application to Application Service
3. Use script to update task, task_ci and outage records to Application Service
4. Use script to move Application records to Business Application
5. Use script to create relationship between Business Application and Application Service
6. Checkpoint – has data migrated successfully? No? Execute restore plan
a. Delete migrated Business Applications and Application Services
b. Delete updated tasks, task_ci and outage records
c. Restore records from XML

While some of the above steps may be all part of one script, an advantage of breaking it down at execution will allow sanity checks between each. If there’s a mistake it can be corrected before flowing onto dependencies down the list.

Other Tips

• Preparedness – Run through the migration end to end multiple times in a non-prod environment, especially if there will be multiple people involved. Even then, allow for the unexpected when performing the final execution in production.
• Data Cardinality – While the immediate focus is the migration of Applications, plan with the bigger stage in mind and how entities will relate to each other.

Figure 4: Cardinality of the data surrounding the Business Application and Application Service tables.

• Organisational Change Management (OCM) – As with any change, managing how it is implemented, communicated and adopted by the business is crucial to success. Ensure all stakeholders are aware of the alignment to CSDM and the impact it will have to their role. If training will be required, plan to have this complete before go-live.
• Federate Data Maintenance – Ensure correctly populated key ownership fields such as Business Owner and IT Application Owner for Business Application and Managed By Group and Owned By on Application Service, then allow these people to own and maintain the data. The Data Certification module can be very handy in this regard with regular audits.
• Governance – Once the migration is complete, take the opportunity to review any governance in place. Make it plain what data is expected where and ensure the right people have the right access. Review any processes and approvals in place so they’re appropriate to the data being maintained.

Now armed and ready to tackle the most difficult step a lot of customers will face in adopting CSDM. Remember, adopting CSDM, like adopting ServiceNow, is a journey. Follow the Crawl, Walk, Run, Fly (CWRF) approach documented by ServiceNow to start capturing value as soon as possible. Still have questions, feel free to check in on the CSDM Community or call on TMLabs, always happy to share knowledge and experience and help find the optimal approach.