_
_
Most people I’ve spoken to get super excited about the CSDM once they have the light bulb moment. At that moment, they understand the pieces of the CSDM puzzle. Great! Ok, they are ready! The question that comes next is, “Now what”? “Well, Johnie Owner, tell me what components you need.” It happens more than I like, but the answer I stumble into is “I don’t know. What do you think?” This always puts an unexpected hurtle into the timeline of the process. Both parties of the conversation don’t know the composition of the puzzle!
Let’s put this in perspective. What percentage of the rest of the potential conversations will have this hurtle? How many Business Applications are out there? What about the Technical Platform Services and their Application Services? Sheesh, there’s got to be a better way of approaching this hurtle than with brute force conversation.
Populating the CSDM can naturally take years. Depending on the scenario, there may be existing hierarchy data to build off and hopefully programmatically migrated/aligned to the CSDM. I’ll leave the automation part for your next engagement with RapDev, hint-hint-wink-wink—shameless plug for a company I love. Whew, ok, now that I’ve got that off my chest, let’s get back to the complicated, messy part of this topic. From a high level, the approach provided by ServiceNow’s “How to implement the CSDM framework” article makes sense. It breaks the journey down into stages, but in actuality, each stage has a data population component that should be broken down even further. A “boiling the ocean” approach makes little sense and will get nowhere fast. So let’s break this down so that a starting point is obvious. What conversations have the highest potential for confusion? It’s unlikely that they can be avoided, so how can the conversations become so efficient that the outcomes become predictably successful? Should specific conversations be prioritized over others? Is there a way to approach different audiences in an orderly fashion that builds upon itself? What if the conversation was treated like a scripted process with options and decision trees?
Resist the urge to put the cart before the horse! Before designing the conversation itself, developing an engagement approach is crucial. Consider a layered approach that traverses through the ownership hierarchy of the model. The entry points of the CSDM are the responsible parties of Applications and Services. It is recommended to start with Services because Applications are built upon services, and there tends to be a more clear escalation hierarchy to follow.
https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=dde64c62875255d0f2f443f7dabb354b
When deciding how much of the CSDM to bite off first, it is not really fair to stay within the scope of the Crawl stage because the sphere of control for each party will dip into each stage. Therefore, keep an open mind and a sharp pencil. Identify all the teams responsible. Understand what they do at a high level. Then dive into each layer of the CSDM at the appropriate time. As each layer is addressed, the data-gathering process should be refined, which makes the next, more complicated, layer easier to approach.
Prioritized CSDM Layers
This article assumes that the Foundational Layer is solid and doesn’t need any attention. It’s time to populate the CSDM! Therefore, the first layer of interest includes the infrastructures’ Technical Services & Offerings. This layer provides hosting services and does not require Application Services. Instead, the Technical Service Offerings are associated with CIs via Dynamic CI Groups. Several examples would be Windows Support, Network Support, and NAS Support.
Graphic: Technical Infrastructure Services Layer
By design, ServiceNow has provided a helpful wizard called Service Builder. It’s a free feature of Service Portfolio Management. Its target audience is Service Owners and Delivery Managers that want a workspace-driven experience to manage their CSDM data. It’s got a tremendous amount of detailed descriptions that are very helpful to anyone creating a Service and Service Offering in relation to a Service Portfolio.
The output of all conversations regarding this layer should lead to populating the minimum requirements necessary to use the CSDM Data Sync and, optionally, Commitments (e.g. SLA) features of Technical Service Offerings. This CSDM Data Sync feature provides immediate value to IT Operations by improving the trustworthiness of the CMDB by reducing the amount of manually maintained data. Incident time-to-resolution will also likely improve because ticket miss-escalation will decrease. Commitments enable the Business to hold teams and vendors accountable for the provided services. While valuable, capturing Commitments is optional for the Crawl Stage.
This is the typical layer of the CSDM that leverages the Technical Service Offering’s “Managed By Group” field to supersede the default “Managed by Group” value for a CI class (the “Managed by Group” is responsible for the infrastructure that contains CI data. It’s also typical that such teams are responsible for the availability of the CI, such as server OS availability). An example scenario of when to use this functionality is when two or more teams support CI of the same class, like “Windows Server Support - UK” vs. “Windows Server Support - US.”]
That’s all for now. As you can tell, there’s many layers to cover. The next post will be on Technical Platform Services, a critical part of the ecosystem.
