Welcome to another baking session featuring Charles the Baker and a sprinkle of Common Service Data Model.
As with any blog post with respect for itself, I will start by quoting A. Einstein to lend my piece the added authority that my humble existence lacks.
If you can't explain it simply, you don't understand it well enough.
See, what a perfect start. You have to agree, as the man was a genius. Are you perhaps smarter than him? Touché reader!
What a bang of a start we have.
Other than this nonsensical introduction, you can refer to the previous article's opening for the intents and purposes of this article series here.
Essentially, I am challenging myself to explain a complex theory in as simple terms as possible. Like Einstein, you know.
(underlying correlation between Einstein and me established in incognito inception style. Good job, me - I never knew I would be the Dicaprio type).
In this second part of the epic tale of Charles' CSDM exploits, we are introducing some new boxes to our overall CSDM diagram as we look into the walk maturation stage.
Now let's understand how the mapping of the Manage Technical Services domain can help our struggling protagonist of a baker.
Please read on as I first introduce you to another page in the life of Charles the Baker, and in the end, illustrates how it can relate to the Walk-stage of the CSDM maturation journey.
The Common Service Data Model of Your Local Bakery Continued.
Let's get back into the dough!
Getting ready to Walk the flour line
Oh boy, the flour has gone bad since last time.
Our good friend, Charles the Baker, is n quite a predicament. See, when he started his IT investment building his applications stacks in the Configuration Management Database (CMDB) he did all the right things:
-
He leaned into the experience of his industry peers by consulting online forums like the ServiceNow community, which even has industry-specific forums. Sadly the baker forum is not yet solidified here.
-
He also consulted the industry solutions as described by ServiceNow itself. Look at that guy, just doing his beautiful homework.
-
Based on his reading, he initiated his configuration management journey on the premise of a business justification; he needed to ensure proper knowledge management in his organization to ensure delicious caky-bakys.
-
He realized and accepted the value of service-level reporting provided by CSDM and that it was too risky and complex to take on as a one-man army. After all, his specialty is making cakes. Not weird diagrams. Therefore he invested in the ServiceNow platform as well as the Impact offering.
-
He continued to focus on the vital part of his IT business: the continuous uptime of applications underpinning critical services through uncanny utilization of the incident and change management in ServiceNow.
So, the crawl-stage CSDM of Charles is an immaculate representation of his IT infrastructure. As good health the data might be, there is trouble in the real-world uptime for Charles' business applications - perhaps the data representation is a bit too pristine when comparing the CSDM/CMDB with the grim setup of servers haunting the storage room of Charles' bakery.
Lately, Charles has been spending too much time in the server room attempting to switch around cables to remediate connectivity issues. Sometimes he kicks it, and in his frustration, it has become quite the jumble of cables and baking supplies.
To help him out, Charles ordered a mail-order catalog containing different services. Charles is focused on maintaining business continuity by ensuring a healthy IT infrastructure. Therefore, he focuses on technical services for now.
Once everything has settled down, he might flip his fancy service catalog around to look at business services.
Upon looking through the available technical services, Charles decides to cheap out. Instead of getting the actual professional experts of Mixer Fixers Ltd. to untangle his server mess, he has opted to order a self-service / DIY knowledge article.
The queues in front of the bakery become longer and longer, the quality of the cakes is failing, and Charles is stuck in the server room.
"Finally, my time to shine!" #2 thinks to himself. "OK, so we pinned the decision on me becoming the supporter for BakeMaster 3000 Pro, but please let me help with the server room.
I don't mean to be bragging, though I have installed everything from a VHS player to an honest-to-Dough surround sound system."
Oh, wow, #2. So much to unpack there. I'm afraid we can't make it all in this article.
Maybe a future one?
"Oh, you are too kind; I get my own special feature?"
Well, no. Maybe. We'll see - probably not in the budget this quarter.
Only a physical injury could stop Charles from heading into the server room himself.
That, and the crippling debt from his IT investments coupled with the realization that #1-3 probably needed some help if he was to sell any caky-bakys.
This time Charles isn't hesitant anymore. This mess needs some professional cleaning. He talks with Jessica of Mixer Fixers Ltd. on the phone, who promptly arrives at the baker after being bribed with a free caky-baky (that wasn't baked by #1, #2, or #3).
Charles wasn't particularly enthralled with the prospect of opening up his now contemporary art-Esque server room. There was no way around it. The door opened, and quite the sight met Jessica.
Charles was quick to explain that he had no idea how all of the baking gear ended up in the server room. He concluded that it probably was one of the other guys. Jessica wasn't too sure.
It all looked dim and impossible to resolve. But that is where the Gold standard of Mixer Fixers Ltd. kicks in.
Jessica pulled out her boom blaster and Morgan Freeman from her van, and they all got to work.
Feel free to read the rest of the article in the voice of Morgan Freeman.
When the last chord of 'Eye of the Tiger' was played and the last moving words of Freeman spoken, the dust settled. Only no dust remained, as the work done was impeccable.
Getting real with the CSDM of Charles the Baker
Charles was beyond impressed with the technical services of Mixer Fixers Ltd. All applications in the bakery were online.
"Thank you, Mixer Fixers Ltd., Jessica, and Mr. Freeman!" Charles exclaimed.
"You are welcome, my friend," an out-of-this-world and beautifully deep raspy voice replied as the van of Jessica sped to rescue the next server room.
Before the Van left, Charles made a contractual agreement with Mixer Fixers Ltd.; no more could the critical infrastructure be left to Charles' blissful ignorance. Henceforth, Charles was only to do first-level support for the servers.
This meant that the bakery's new technical service provider, Mixer Fixers Ltd, was to manage anything above dusting the servers free from flour.
The contract also stated that the new service provider was to take care of all switches, routers, and even application support for BakeMaster 3000 Pro.
At a light monthly cost, Charles had secured the operations of his critical IT infrastructure (and if it failed to the point of breaching agreed service commitments, a monetary sanction was in place, effectively making it senseless not to have Jessica and Co. as a partner).
To make the collaboration with Mixer Fixers Ltd. swifter and seamless with the calculation of provided service levels, Charles invited Jessica and Mr. Freeman onto his ServiceNow instance. This way, they could collaborate on the same platform based on the same foundational data and application stacks.
To achieve this, Charles made a point to ensure that his data foundation was aligned with the prescriptions of the wise Platform Architect of ServiceNow (that's me, though we already made the implicit link between Einstein and me, so this is fine).
Foundational data
Charles went ahead and created.
-
Jessica and Mr. Freemand as users
-
An assignment group for Mixer Fixer support.
-
The new users were related to the assignment group.
-
The ITIL role added to the assignment group, enabling all its members to manage the resolution of incidents and service requests raised by Charles, #1, #2, and #3. Though, they were instructed to have any incidents raised by #2 validated by Charles, as #2 tended to report dirty dishes and spilled milk as incidents.
-
Mixer Fixers Ltd. was created as a record in the company table with the attribute 'vend set to true.
-
The new users were related to the vendor entity through their user record referencing the Mixer Fixer Ltd. vendor company in the company field.
Technical Services
The basis for having Mixer Fixers Ltd. as a service-providing vendor is to obtain technical services from them.
-
Charles created a Technical Service record named 'Hardware Support,' and one called 'Software Support' and set Mixer Fixers Ltd. as the vendor related to them.
-
The technical services were set to be owned by Charles, while their delegate became set to #2, who was ecstatic at the prospect of the responsibility.
-
#2 promptly updated his LinkedIn skills to include 'Technical Service Owner(ish).'
-
The person responsible for the day-to-day collaboration with Mixer Fixers Ltd. was #3, both set as the Delivery Manager and Business Relationship Manager—effectively making #3 accountable for the future partnership and roadmap for the service. They didn't tell #2 about this.
Technical Service Offerings
The foundation for the technical service delivery was in place.
We knew who the service provider was, and we knew approximately what they did.
But, to keep things straight, Charles created Technical Service Offering records to solidify precisely what, how, and when Mixer Fixers Ltd. was to deliver technical services to Charles' bakery.
The offerings were related to the two technical services as fitting.
The Hardware Support service had the following service offerings attached:
-
24/5 (Gold) - 4/8/16hr hardware support
-
Twenty-four hours five business days a week, Mixer Fixers Ltd. is responsible for resolving priority one incidents within 4 hours, priority two incidents within 8 hours, and priority 3+ incidents within 16 hours.
-
8/5 (Silver) - Request fulfillment
-
fulfillment time based on the individual piece of hardware item requested from the technical service catalog
The Software Support service had similar offerings related to
-
24/5 (Gold) - 4/8/16hr support support
-
8/5 (Silver) - Request fulfillment
Dynamic CI Group
Now the partnership with Mixer Fixers Ltd. is getting somewhere!
But one thing is knowing what, how, and when the support is delivered; another is easily understanding the scope of what is supported.
Charles and his crew shouldn't need to figure out precisely who to reach out to if a specific piece of hardware fails.
As of now, it is easy enough to know that Mixer Fixers Ltd. probably is the go-to for general support, though the offerings clearly state a scope, which means that Mixer Fixers Ltd. can't be held accountable for all breakdowns.
The hard- and software that isn't supported might be supported by a new vendor in the future, muddying the picture a bit more and making it less clear when to have Mixer Fixers Ltd. support an issue.
Therefore, it makes sense to specify precisely what type of hardware and software Mixer Fixers Ltd. is to support.
The application services already make a logical scope of how the bakery's IT infrastructure enables the different applications. However, application services describe how the applications are deployed and dependent on each other, not how they are supported.
Here we need another logical scope called dynamic ci group.
This grouping operates on another dimension than the dependency nature of the CMDB.
A dynamic ci group might span across several different application services.
At its core, a dynamic group can be related to a technical service offering, and it describes a set of configuration items that share characteristics.
If the relationship is set to 'managed by::managed,' you can even synchronize the group fields on th..., helping you to maintain the individual support group fields for each configuration item.
Here the groupings could be achieved in different ways like 'location,' 'CI type,' or whatever you might come up with using the query builder.
The essential aspect is that the queried CIs all should have the same support, change, and management group references (as those CI fields will - as mentioned - be managed by the technical service offering related to the dynamic ci group.)
Let's compare the two logical scopes: Application Service VS Dynamic CI Group.
As demonstrated in the above illustration, the application service encapsulates the IT infrastructure that enables the application to service its end users. In contrast, the Dynamic CI Group is a logical grouping of CIs based on shared attributes.
How technical services might be used in an incident process
Let's throw some cakes around and see how an incident might be managed with the above in mind.
-
#1 might raise an incident by putting "BakeMaster doesn't load!" in its short description.
-
The incident lands at Charles, interim 1st line support, until he can hire one for the job or outsource it.
-
Charles determines this is related to the Application Support technical service and references it in the incident's service field.
-
He then populates the service offering field with the 24/5 (Gold) - 4/8/16hr application support.
-
He then indicates the application stack causing trouble for #2 by setting the application service to the configuration item field on the incident form.
-
Because he knows the technical service offering, as well as the application service, we are almost ready to be able to determine if Mixer Fixers ltd. Would be contractually obliged to support our software incident.
-
Based on the error description Charles reaches out to Mixer Fixers Ltd. and Jessica realizes that it is probably due to a server error and not the actual application.
-
Now Jessica can take over, as she corrects the incident from field service to Hardware Support and the correlating service offering to 24/5 (Gold) - 4/8/16hr hardware support.
-
Additionally, Jessica can pick the correct server in the configuration item field by accessing the dependency view of the application service to determine the culprit.
An application stack (Application Service) might look something like this. From here, we can determine the dependencies that the specific application is running on.
Bringing the Crawl and Walk maturation stage together
Let's bring it together.
In the crawl stage, we started to map our foundational data and application stacks. This enabled us to understand how our applications are running and who owns them and to relate ITSM tasks (e.g., incidents) to them over time. At this moment, the historical data of ITSM events related to the application stacks can be leveraged to understand problem trends, optimization routes, change impacts, and probable causes for occurring incidents.
We know Mixer Fixers Ltd. is set up in the foundational data of Charles' ServiceNow instance, enabling us to relate the vendor to our CSDM objects of the technical domain.
Mixer Fixers Ltd. provides Charles with a technical service for Hardware Support, which takes the form of 24/5 - 4/8/16hr support based on the priority of an incident. This is described via a technical service offering contained by the technical service.
In turn, the technical service offering is related to a dynamic CI group. This enables efficient routing of incidents and changes based on service commitments with Mixer Fixers Ltd. as the CI grouping's relation to the managing offering synchronizes the group fields of all CIs contained in the group, thereby enabling ServiceNow to automatically populate the assignment group field of incidents and changes via simple assignment rules.
Let's try to map out the different CSDM items we are working with.
Now the support can run smoothly!
Thank you for reading this CSDM-inspired baking blog. If you liked it, remember to like, subscribe, send a blood sample, yell 'SERVICENOW IS NOT A TICKETING TOOL,' and send your mom a text saying 'I love you.
Follow the next article in the CSDM series with Charles the Baker to understand the run maturation stage. It's going to be yummy!
