The Now Platform® Washington DC release is live. Watch now!
on ‎04-29-2021 12:16 AM
Disclaimer
Any statements, opinions and remarks made by me in this community post are personal. As such, they are not representing any official stand of my employer. The text here is reflecting my personal experience working 8 years in the ServiceNow ecosystem as partner, customer and now as a ServiceNow employee. Needless to say, I draw on the insights of all the smart people I have had the pleasure to work with during my professional career.
Introduction
In this very first Now Community post of mine, I'll briefly concentrate on:
My goal is to write a few articles under the broad CSMD topic during 2021. The overall intention is to look behind the whitepaper.
Approaching CSDM
Do you ever get this feeling when working around CSDM?
Believe me, you are not the only one. I see this feeling often derive and result from taking a wrong approach to begin with. Something that works for an organisation may not be the best fit for yours.
One exact golden rule to follow does not really exist in my opinion but there are a few things to every organisation consider. These include topics that help you formulate a fit for purpose approach for you organisation. Let me give a few pointers.
CSDM is not an outcome but supports achieve desired business outcomes
Being CSDM 'compliant' (such does not really even exist) does not in itself take an organisation forward. A better approach is to tie actions and phases to your desired outcomes and overall roadmap.
Let's imagine your initial scope is ITSM. You surely have some business reasoning to have made the move to ServiceNow platform. Any expected improvements to support modernising your ITSM operations should also drive actions taken from CMDB viewpoint under CSDM framework.
Define your critical use cases for your processes including reporting first. This fuels the must-haves for CMDB setup governed by CSDM. Acknowledge what you may not be able to do initially based on your chosen approach. For example, targeting infrastructure at first and leaving service layer to smaller attention will:
The key is to not only understand what the chosen approach enables but also what the implications are. So, instead of than just documenting technical data classes along with your phases, it is better to also include what the particular data enables for your operations giving it more business context. Internal discussions around this are never easy but are easier when this type of home work has been done.
Translate CSDM to your business
Your business likely has a set of terms or language that is commonly used. The fact is, your business language will not change. At least, such a change would be very hard to accomplish. Neither will change the official terms and descriptions prescribed by CSDM.
There very likely will be the time when you have a set of data of importance to you required to be managed in CMDB while it may seem hard to fit directly in CSDM prescriptions. This requires translation which should not be done hastily. In addition, ensure that a sufficient participation of decisive stakeholders takes place. Involve experts from your implementation partners as well.
E.g. the term service is used various contexts. Officially, a service is an outcome expected by a customer. A service goes along with action. Something tangible does not really constitute towards a service.
Scale CSDM efforts for your organisation
Whatever you do, do not target for something your organisational structure cannot support. Do not establish something that cannot be maintained.
The play is utterly different in a scenario where there is a dedicated and centralised config team with a defined CMDB process in place vs. having a single config manager or not having a CMDB process formally in place.
Why should you try to model and establish something comprehensively that lacks e.g. clear ownerships? There might even be some internal debate on how manage different types of data. Better to start small allowing room for expansion than trying to guess on behalf of your internal subject matter experts.
In practice, it is not really realistic to explicitly follow CSDM suggested phases crawl, walk, run, fly or the dedicated outcome based approach either. In reality, it is very likely you'll end up having a mix of phases ongoing for different types of services supported by different types of technology.
Preserve time for OCM
Funnily enough, often CSDM/CMDB is not mentioned in communication or training plans. Instead, the focus is fully on training some admins initially as well as getting the agents up to speed. I say that CSDM/CMDB should have its own dedicated place in these plans.
ServiceNow CMDB is very extensive even without complementary products such as ITOM. The current CMDB Fundamentals class is 3-day training alone. Acquiring basic understanding what is out there is a step closer to your success.
You may want to consider involving the CMDB process key stakeholders in establishing any policy, guideline and process documentation. Plan and deliver recurring info sessions, maybe even for targeted groups such as service owners, infrastructure teams and agents working on cases.
Prepare documentation that explains why things are done in your predefined way including the value aspect for different audiences. Internal complaints are more than likely. Preparation helps manage these situations.
CSDM is a framework
Finally, embrace the fact that CSDM is a framework. This is also stated in the first sentences of the white paper. I derive a few things from this:
Having said this, there are matters that are given and which should not be bypassed:
Foundation Data
I chose foundation data for this article as it affects each and every organisation and therefore their CSDM/CMDB efforts as well. I know what you are thinking. Your are thinking that your foundational data quality is not good. Get over it! Generally speaking, other organisations are not better off with this topic.
For many organisations, foundation data becomes widely visual across the organisation when they start using ServiceNow. This may be the first time the organisation tries to workflow something relying on their foundation data. I am not going into further details here on example issues but you can view this blog post by
The main differences between organisations around this topic are:
I'll concentrate on the life cycle thinking here. When establishing foundation data you need to:
Unfortunately, foundation data is often part of platform core configuration and rushed for getting into process implementations. Surely, the related debt is to be paid later on.
Why this life cycle thinking is important also for foundation data?
Firstly, just think of the user object in ServiceNow and how many other data objects relate to it. Many of these data objects are just as well obsolete when the user is ultimately invalid. You do not want to have this kind of data mixed with current operational data.
Secondly, without life cycle thinking it is harder to execute reliable reporting and/or data audits against your CMDB data. This can lead to a scenario where the expected attributes are in place while they are false in reality. I.e. audit activities may indicate green status while the situation is more towards red under the surface.
Ending words
First of all, thanks for reading! I would be very pleased to hear your tips and experience around the two main topics of this article in the comments below:
I'll close the article with the below key takeaways:
Hi Venni
Interesting article! Regarding Foundation Data I have a question and a comment on experience.
Question: Do you mean everything shown in the Foundation Domain of the CSDM 3.0 Data Model or just the objects included Core (or Common) Data?
Experience: At my last employer (a large global group of over 100 operating companies), there was effectively no ownership of the Core Data. As an example most IT people assumed that the HR departments in the operating companies at least owned the user life-cycle but generally HR were only interested in employees of the company and not contractors or 3rd party users who needed access for one reason or another.
We were building a single global ServiceNow instance for ITSM - we did not have the time or the resources to do anything but use a global directory which was in turn fed by a huge array of disparate data sources owned and maintained by the operating companies. It was a certainly a challenge because, as you've said, this data was hugely important for our implementation.
It was a recognised problem faced by every global project within the group - I envy anyone who has implemented a solution in their organisation!
Hi Steve,
Big thanks for sharing.
To address your question: "Do you mean everything shown in the Foundation Domain of the CSDM 3.0 Data Model or just the objects included Core (or Common) Data?"
--> My focus here was core data. This data is always in play regardless of how ServiceNow is finally used. And every ServiceNow implementation includes usage of this type of data.
The scenario you described is definitely something a single party nor a ServiceNow architecture/platform team can themselves make better. This moves closer towards to overall company strategy and how Enterprise Architecture is executed to support that strategy. Tangible actions around this would require c-level decisions and sponsorship. Not an easy nut to crack.
Interesting article, and very good to see some activities from ServiceNow around the CSDM - Framework, next article may I suggest to come up with business value for going down the CSDM route, as in my experience this is a heavy path for many companies and will required heavy investments.
When that said, I don't see CSDM only as a framework - not a rule book. CSDM is maybe a framework, but first and foremost a hard defined "Data model" - that have huge impact on all modules within ServiceNow - and you really need to follow the data model to gain - most value implementing various ServiceNow modules - and of course here is Foundation and all other Data governance extremely important:
Thanks for your thoughts and insight into this topic Venni.
Since you already shared my post on the "Importance of Foundation Data", I hope you don't mind, if I share another article here about "How to establish ownership in your CMDB": https://datacontentmanager.com/how-to-establish-ownership-in-your-cmdb/
Having a predefined model and phased approach is all good, but in order to succeed, you need to identify different roles around data management (consumer, owner, provider) and get commitment from each, especially the owner and provider before populating any data into your CMDB.
What are the best practices or simply good examples on how to establish (data) ownership in your organizations?
Cheers,
--Mikko
Thanks for the comment!
This is definitely a matter of perspective and how is business value understood in this context. In order not to re-invent the wheel, example value statements and outcomes are referenced in this public CSDM resource: https://nowlearning.service-now.com/nowcreate?id=nc_asset&asset_id=9a353c80dbb764903ce56451ca961997
ServiceNow products have their own value statements. Maybe CSDM could be seen to support these. Maybe CSDM could even be considered as a supporting capability for optimal usage of different ServiceNow products and achieving those business outcomes, whatever they may be.
Like you said, many ServiceNow products expect underlying data to be present in a certain way for proper use.
This definitely one of the key success factors and must for successful CMDB setup and governance. Thanks for the comment!
Thanks for sharing this link Venni - I've watched every CSDM presentation I can find on Youtube, and reviewed the CSDM training available on ServiceNow sites. This is the first time I've seen this particular slide-deck, but am still very eager to get new comprehensive examples from
Still some great visuals here in this slide-deck, so thanks for sharing. Looking forward to more examples and presentations of how others have built-out their service portfolio.
Hi
Have you seen the latest slides for CSDM3.0 from nowcreate, there is a description of the process to define a service definition
Yep, this is indeed in the public resource I also linked above. Good to be aware of this great material my colleagues are always improving 🙂
Yes, and thanks
I heard there were some new examples and documentation about CSDM supposed to be released before or during K21 - any updates you've heard on the inside as a ServiceNow employee? 🙂
Can you tell I'm still SUUUPER in demand for a comprehensive set of examples for services/service offerings from business and technical side, so we can try to ratify our new portfolio of services in the CSDM framework. Thanks
Couple very good articles on application services authored by my colleague David Skowronek.
My relatively small experience has always struggled to onboard an Enterprise Architect decision making when the scope, again relatively is "small ITSM project" at an organisational level.
Even the product owners at customers really struggle to get the EA onboard.
Any tips/tricks (magic wand) to get this rolling
Nice and smooth article !!
Cheers
Ishan
In general, I have seen but cannot explain why core data and data stewardship are not defined and owned properly thereby creating multiple efforts for each silo that defines the needed data without proper ownership themselves for 'practical' reasons to be able to go forward (into your technical debt hell).
The example of a 'relatively' small ITSM project just underpins this. How can any process in a service value chain be unimportant and small when there is basically no enterprise that works without IT being an essential part of that chain?
I urge you before thinking about the CSDM data model, to let Enterprise Architects, Executives, Process, and Service Owners align on a framework and proper understanding of service design before you touch technology.
Examples would be ITIL, IT4IT, and USM.