I doubt it is just me. I have this gut feeling that most of us struggle to understand the emperor's new cloth, the Common Service Data Model (CSDM). And I think most of us know that the model is as invaluable as it can be enigmatic and esoteric.
It is a bit as if no one dares to ask anymore, as everyone else seems to get it. Well, that is the thing with group think - if you are struggling but are too afraid to ask, the others probably are in the same boat.
"Don't you see, the Emperor is Not wearing any Cloth!"
The little boy from the story exclaimed. In this case, we have the cloth as the CSDM; in fact, it is core to the platform and your ability to claim all its value. But that is not to say that it is easily approached or understood.
Though they are all very theoretical, you can find many blogs, documentation, and white papers on CSDM; for me, the documentation and articles are not easily absorbed. This is a potential issue as we all rely on a healthy CSDM. Not adhering to CSDM now probably means the incurrence of technical debt and a substantial bill to be paid in the future.
I have spoken and worked with several senior advisors who all find it challenging to utilize on a practical level. Not to mention that I am still learning about the topic every time I do work with it. And so is the product team of ServiceNow - that is why it keeps evolving.
The really difficult part is not having you understand it. You are a genius, of course, and have the lovely Charles to help you. But consider all of the colleagues that are swamped and busy having their hands dirty putting out one fire after another. Maybe. Just maybe understanding the complex depth of the CSDM is not that appealing, especially as it is not easily absorbed. You will need to champion in, and everyone does not need to know everything, though we need to ensure that the key players know the 'whys' and you can know the 'hows'.
That is not to say that we do not have a usable model yet. We do, and it is essential to understand. Luckily we do not need to understand it all at once, as it can be implemented in bite-sized maturation packages.
The maturation phases prescribed by ServiceNow are representative of a 'happy flow'. In reality, you might need to cut and paste a bit in the stages to make it fit your context.
In any case, why don't we attempt to understand CSDM like a five-year-old?
A five-year-old likes cakes. Cakes come from a bakery.
The Common Service Data Model of Your Local Bakery
Let's get into the dough!
Charles is a locally famed baker due to his magnificent Caky-Baky-Licious cake. All the locals knew of his talents, though one dreadful day, a teenager grabbed her smartphone and hashtagged a picture of his wonderous cake for her social media. Unfortunately, she was a famous influencer, and Charles was nowhere near ready for the sudden influx of influenced customers.
Charles is a reasonable man.
He realizes he cannot make the long line of customers happy, as he is only born with two hands and one mixer.
Therefore, he invests in new materials and hires identical triplets. They were so indistinguishable from each other that their mother named them #1, #2, and #3.
Charles taught them to make his Caky-Baky cake, though they were not the fastest learners.
The results were not up to service standards of Charles, and his reputation on SoMe quickly took a turn for the worse, which would be OK if Charles had not just taken a loan to sustain his investments.
The problem was that Charles only had one recipe book, and he needed it dearly.
So #1-3 were unable to improve their baking as they couldn't recall the entire recipe.
Distraught, Charles took to the internet, where he searched baker forums. Luckily he was not the first to experience the predicament of knowledge-sharing constraints, and he found a piece of software available on ServiceNow that would enable him to share and update his recipes from a central device efficiently. What a practical business application!
Charles utilized the free value estimator of ServiceNow and found the prospect lucrative. With his last pennies, he acquired the software, Cakemaster 3000 and devices for his employees to use. They all had a client installed from where they had access to a shared application service. It was almost as if the application was servicing a group of people. Someone should make a word for that.
No man is an Island, and help is nearby.
Charles is no fool, either. He not only acquired the application but also wanted to ensure that he used it correctly; the newly acquired IT only had as much merit as its ability to support Charles' cake-baking business.
As such, he utilized the Impact offering of ServiceNow and was wisely led to a Common Service Data Model accelerator.
"You need this, Charles. You already paid for it; you just need to learn how to use it!" the platform architect of ServiceNow told Charles.
He ensured Charles that adherence to the service model would enable Charles to receive maximum value for his investment today and in the future.
It was crucial if he wanted to understand how well his baking services performed.
And Charles needed this - he was tired of the SoMe ordeal and debt.
Business Drivers - Figure out why we make cakes
First, the ServiceNow platform architect told Charles that it was essential to gear the new ServiceNow towards the business objectives of Charle's bakery.
"Before we dive into understanding the infrastructure needed to bake a cake, we must ensure that we know the bakery business. Why is this bakery in business? What is important you them? What are your goals?"
Perhaps we can even have a list of key performance indicators and establish a baseline to see if the introduction of ServiceNow with its adoption of CSDM empowers the organization as we go along.
Understanding the business enables us to map the CSDM and correlated CMDB at a meaningful level.
We mustn't just map anything that is connected to a power outlet. Data management is costly and requires a lot of governance. Let's stick to the outlets related to cake baking.
"Oh, my," Charles thought to himself. "There is much more to consider than installing the application to manage my IT services."
Foundation - Before Baking the Cake, We Must Know the Baker
Both Charles and all of his employees - right down to #3 - now had a shared understanding of the bakery as a business. That was positive in itself.
"Now, let's sort out the foundation of your Service Management tool, ServiceNow, before we start mapping your applications and services," the ServiceNow advisor continued.
He let Charles know that throwing the applications and services in ServiceNow wouldn't provide any value if the foundational data was not in place:
"When something breaks, you need to understand at what location it is, who owns it, who supports it, and who should approve any changes to the broken item."
"I can help with the support; I once took an Excel course at an elderly center!"
"Thank you, #2. Let's circle back to it."
We need to understand the organizational structure of the bakery through out-of-the-box (OOB) tables.
Does the bakery consist of several companies, and what about its vendors and consumers? We must understand who makes the cake, provides the flour, and eats it.
Great, now let's look at the business units of our beloved bakery. Charle's lovely wife, Anne, is in HR as she deals with employees, and Charles is in accounting... because he does the register and talks with the tax man. Oh, and #3's girlfriend is in Sales as she is our cake pusher at the desk.
If our bakery was huge, it might contain departments in all business units. Sadly, this is your local bakery and not yet a large enterprise.
Nevertheless, we need to understand where our cozy bakery is location-wise.
What region (EMEA), country (might be a danish baker making danish pastry!), state/providence (probably in Jutland, they have the best bakeries), city (let's go for Aarhus - also congratulations you now live in Aarhus as this is presumably your local bakery), Site (we have one), building/structure (Well, the shop, our storage facility, and #1's kitchen when we are swamped).
The Location table of ServiceNow fancifully allows us to hierarchize locations. How neat is that? That is pretty neat.
Let's now ensure that we have our product models stored as well, so we have a digitized version of all our beautiful recipes: danish pastry, rye bread, chocolate cake, cake-cake, caky-baky-licious, and all the others.
And, since we have the companies in place, both our service providers (vendor companies) and service consumers (customer companies), we might as well ensure that we have our contractual agreements stored. This will make it easier to understand if we meet our service commitments through service-level agreements regarding baking and eating our cakes.
Wuptihoo! We can now relate any cake task to an organizational entity or customer/vendor relationship. It is almost as if our foundation for CSDM is shaping up!
"So, about that support assignment for Bakemas..."
"- Let's move on to the next topic, #2!"
Crawl - Add applications and mix the basic components
Let's go! This is the point where many enterprises find it challenging to mature beyond. But not our bakery, nor sire, not our fine bakery.
What is that? New boxes appeared! Hold on to your flour!
In this maturation phase of the Common Service Data Model adoption, our bakery is to understand its applications in relation to its core infrastructure.
Knowing these applications and related infrastructure allows us to relate them to our organizational foundation data, as well as any baking-related ITSM tasks of the future (e.g., sugar spills, aka Incidents, mixer replacements, aka Changes, "why are the chocolate cakes bad" aka Problems, and "please run to the store for more flour" aka Requests, ...).
"Hold up, why all the focus on business drivers and objectives if we are not mapping our applications to it?" Charles protests.
Well, Charles, the maturation model of CSDM is only prescriptive in its designation of data tables to use and relations between them, not the sequence of their adoption. This means that you can deviate from the maturation roadmap - it is also relatively normal practice for adopting organizations to start with the business service layer to understand how the services of the business are supported by their application infrastructure.
We can only bite so much of our cake at once.
The business driver sessions ensure we achieved consensus around our understanding of our business objectives, which we can lean into when mapping our applications even if we do not have a precise mapping of the business services they underpin (more on business services in part 2).
Once we mature beyond the quick wins of application mapping, we can soon focus on our infrastructure's business criticality as a product of their relation to business services.
For now, we praise ourselves as lucky that we can understand our application stacks and their history in terms of changes, requests, problems, and incidents.
All helpful to ensure a constant baking service level.
-
Want to know why an incident occurred? Why don't you look at existing problems, changes, and requests that may relate to it?
-
Want to know if it is safe to implement a change? Beyond using maintenance windows, why don't you look into other related changes that may be planned or happening on the application stack?
The confusing part: three application types?
Stay calm. This part is weird. Yes, CSDM has three levels of applications.
Applications come in three different packages inside the CSDM.
Though, it is possible to understand their correlation. To prove it, we'll have Charles explain it after the Platform Architect taught him the difference.
Business Application
That is right, Charles. The business application is what is known as a non-operational object in the CSDM. That means that we use it to understand the application on a conceptual level, though we are unable to relate any ITSM tasks (e.g., Incidents) to the business application as it is not really associated with foundational data; we can know who governs the business application, though there will never occur an incident on this level.
Thank you for the great example, Charles. This is indeed how a business application might appear in casual conversation. You should be an actor.
Application
That is true - the application is actually the code of the software as it has been installed on a specific device. Most commonly found on servers from where the application is made available to an entire organization.
Application Service
Wow, Charles. Look at you go, you nerd! That is yet again correct. As alluded to in the previous sections, the application is installed on a server, from where multiple devices of the organization can authenticate and use it according to their user authorizations. For example, Charles has the baker_admin role, which allows him to govern and manage the recipe processes in the Bakemaster 3000 application. In contrast, #1-3 have the baker_user roles enabling them to access and interact with the recipes.
In a sense, you might consider the application service as the deployment of the application, comprising both the application itself and the infrastructure it is installed on and enabled by. In the example above, we might find the computers, switches, shared server, and the bakemaster application installed on the server. In total, this unison that enables the application to service the user is the application service.
The cherry on top - SDLC
Our bakery could go further. Say, if #3 was also a computer God besides making cakes, he might develop some business rules and emails to tailor the bakery's UX of the bakemaster application.
This development would be considered an SDLC component of the more extensive Bakemaster application.
This way, our business application is comprised of several SDLCs.
The actual instantiation of the business application might happen through a relation to a product model that describes a specific version or configuration of the application.
Not all software is created equal (remember to update, folks).
All application services would be an instantiation of the business application through deployments. These deployments, in turn, consist of an application stack containing configuration items related to the application itself, the hardware it is installed on, and any other hardware critical in delivering application service to its end-user.
| More content by Jakob Anker Nielsen |
