As you may know, ServiceNow has a Common Service Data Model (CSDM) that is usable throughout the ServiceNow Platform. Each (use of each) object is outlined in the CSDM 4.0 Whitepaper. In the ServiceNow documentation, examples are given so that the CSDM is used as intended. However, for most people, the CSDM concept is hard to understand, and -as a result, the CSDM objects are often filled with content that should not be put in that object.

The CSDM content is a mixture of designed items (baselines), versions of those baseline models, and deployed instances of those versioned baseline models. An incident is related to one or more baselines, and the item that is deemed broken. E.g., in ServiceNow we have “Volvo Cars,” “Volvo V70 Cars”, “Volvo V70 Diesel Cars,” etc. All baselines. Then we have a particular Volvo V70 diesel car with license plate XX-AMS-99, an instance. It contains a D5 Diesel engine (model), with Serial Number 393092. When applying a patch, one usually patches individual instances only. However, one may also fix all cases of “Volvo V70” Cars in one change. That does not mean we register a difference on the “Volvo V70” baseline.

People who use Google Docs from their PC, may not understand why Google Docs is not modeled/treated the same as Notepad++ or Notepad. E.g., Notepad is a desktop application that is an integral part of the Windows OS. Register Notepad as a Business Application, a Service, or a Service Offering is not deemed good practice. Notepad++ is a desktop application that can be installed on a PC like hundreds of other desktop applications. These desktop application instances typically are not governed under formal Change Management. More likely, these application instances are patched automatically, e.g., via intune or similar.

Designers and Architects may want to model each of their granular components as applications, not realizing that end-users often don’t know which part is broken when they call the Helpdesk. MS-SQL Server or JAVA Server are licensed software packages that need to be patched and lifecycle-managed, but that does not make them deployed business applications.

A Business Application may be used for various purposes. Large Enterprises have dozens of Business Applications, hundreds of Software Package Models that may be deployed, and thousands of features that those Models support. Some Packages contain multiple Components. A team may help/treat multiple applications (baselines) in the same way. Business users typically are unaware of what sits underneath the car’s hood. They often want to keep IT simple. E.g., they usually want to mention they cannot use their Virtual Desktop Service anymore. Which component on which infrastructure item causes that malfunction is not deemed relevant by the end-user?

In the past, the content in the CMDB needed to be manually registered, audited, and updated. If the administrators went overboard in how much they wrote, typically, they did not maintain it well, and the data in the CMDB became useless after a while. Nowadays, the CMDB content is predominantly discovered or gathered (federated) from a managed data source. One may be tempted to import everything learned/federated in the CMDB. However, for anything that is stored in CMDB, a relevant use case must exist. What is suitable for one may not be appropriate for someone else. When too many items/attributes are placed in the CMDB, the CMDB becomes slow and complex. When too small items/attributes are set in CMDB, the CMDB is fast but likely of limited use.

Not everybody in IT is an expert in CSDM. IT staff are not huge fans of administration; hence, they sometimes “forget” to adequately register the services they (can) provide. As a result, gaps may exist in the service portfolio. Furthermore, what is not reported can not be charged as a service other than as a non-transparent lump-sump annual fee. What we don’t register we can not adequately protect/manage either.

IT technology, luckily, is highly standardized. CMDB content (the configuration items) is auto-discovered and hence increasingly standardized. Content federated into the CMDB may be polluted and have granularity or cardinality issues. The more that is being auto-discovered for CMDB, the better the consistency and data quality in the CMDB. Having this said, sometimes it is not (yet) possible to discover all there is. Then Federation may be your best alternative.

There is only one way for the administration of application and software/hardware portfolio, the right way. First, define the managed objects, the managed attributes, the allowed attribute values, the naming conventions, and the relationships that are permitted. For every artifact registered in the portfolio, there must be a justifiable reason, an accountable owner, and someone who ensures that certain content is kept up to date. The responsible data owner must approve all changes to the portfolio. The standards, rules, and guidelines must be public to all who use or maintain the content. Data Quality must be monitored, reported and (if needed) improved.

ServiceNow allows the registration of a service hierarchy. ServiceNow however does not come with market-standard Service Portfolio content. Most enterprises fail at well defining/maintaining their own service hierarchy. DIY enterprise-wide service models of enterprises are often inconsistent, incomplete, or (partly) unsuitable. Rather than registering their content, enterprises should use existing market standard names and definitions for the service portfolio artifacts.

In 2014, the  TBM Counsel (an Open Forum of 700 experts, like IT4IT OpenGroup) released the first version of a market-standard data model, incl. defined content for Technical Business Management.IT architects, Financial Planners, and Portfolio Managers in the IT industry increasingly use the TBM standard. The TBM Model is compatible with the CSDM Model of ServiceNow. The object names in the TBM content may differ from the object names in CDSM, but the intentions of the mapped objects are often the same. The TBM content hence may be loaded 1-on-1 into the CSDM model in ServiceNow.

Mapping the TBM Solutions into ServiceNow makes the most sense as a start. TBM contains (definitions and content for) Cost Pools, IT Towers, Solutions, and Consumers. The TBM 4.0 includes defined (Types, Categories of) Solutions. The Types and Categories are hierarchical Taxonomy Nodes (aka placeholders). TBM has 6 Types, 3 for customer-facing solutions and 3 for services that are internally used by IT. The Solutions, in ServiceNow terms, are our Services. The Services that are end-user-facing are modeled as business services. The IT4IT services are modeled as Technical Services.

It is recommended to leave the TBM Types, Categories, and Solutions unchanged, to maximize standard compliance. A standard set of Categories and the Solutions of the TBM “Business” Type is provided. TBM council recommends business solutions that are defined for certain industries. Companies that are not part of a certain industry are recommended to use the standard set

TBM Counsel also provided representative examples of Service Offerings that hang off the defined TBM solutions (CSDM Services).  It is recommended to use these examples as a starting point and update the offerings if/when/where needed.