Here is the latest video that Scott and I recorded to explain the Technical Service in CSDM. We deep-dive into using the Service Builder to create and manage them, use of the Dynamic CI Groups, and how the CSDM Data Synchronization feature should be used when defining them.
Look forward to your feedback and discussion. Enjoy!
Very interesting Mark/Scott - Is the 'Delivery' area where you would add 'Development Services' for an existing application? Separating out the Support/Maintenance of the application/systems with the New Development work (Enhancements/Projects/New Functionality Introduction) - essentially planning work requests?
Also - that Service Builder is awesome! For some reason this is the first time I've seen it! Getting installed in my DEV instance now!
Is there a way to view infrastructure CI's not part of a Dynamic CI group - with the goal to see e.g. servers not included in a service offering/managed?
It's my impression it's not possible to go to a CI and see what dynamic CI group(s)/offering it's part of? I.e. work backwards from the CI.
This is a great presentation! I do have an ongoing question about groups. I agree with the need for consistency, but also wonder why there is only group for support? Our organization has quite a few Level 3 support teams, so it would be useful to have two layers for support. Are we outliers?
Thanks again for the videos! These are really helpful!
Q: With the given example of ordering a new server through the technical request catalog, how to populate support/change/managed by group values when there is a technical service/offering related as well as an application service (or more application services)?
All servers should related to one or more Application Services, especially if that server is shared across many different activities. If it isn't related to an Application Service, you should question why it's there.
A generic shared server may host many microservices for different Application Services for example is a rather common scenario. Rather than dedicating one server per microservice, you can host many low-demand microservices on one server.
That use case you mention is is precisely covered in this design. Given how we associate the server to the Technical Service & offering to assign a group attribute, each CI has a support group that can be specifically identified. The team providing the server, supports it. However, there may be an entirely different team that supports the Application Service as a whole. They may own the App Service tier, but not ALL of the individual CI's. This is especially true when the hardware is shared such as networked devices which are highly shared potentially across hundreds of Application Services. Also servers, such as in the microservices hosting example.
On the part about some technical service offerings would have a matching business service offering and some would not (ServiceNow and HR SN as example). How would you know when to create a business service offering that ties to a catalog request vs tying a technical service offering directly to a technical catalog request? In your example no one would be ordering the platform SN so you would not need a request tied to that. But what about other technical services like hosting or server administration. When do you just create a catalog request off that hosting technical services vs when you create a new business service offering? And then when do you know you need a technical service to match the business service. We defined several business services that could be described as technical in nature but because we were linking them to a catalog item we made them business instead of technical. So when do we know to create a separate technical service.
Sorry thats several questions in one but a bit confused here. Thanks
Great video on explaning the Technical Services. And time-wise spot on, as we are planning al our infrastructure services to be remapped to Technical Services.
You sound very enthusiastic about the Dynamic CI Group, and surely it is, but in practice, as we are migrating, a real pain if you have to create 800+ Dynamic CI Groups. First to create the DCG, then the group and the query. Does ServiceNow have something in the shop to help me out? Like an add-on on the CMDB Query Builder, so when you create the query, and with a push on the button the group and DCG is created? Would b e a great help to all of us.
And, indeed as you mentioned in your comment to @Tobias , with setting op the DCG, we also need control if CI’s are all part of a DCG/TSO, so really looking forward to see what the Health dashboard could bring.
Again thanks for the Youtube and looking forward to you next one.
I saw the response to Cheryl earlier about how to show Level 3 support teams, part of which was to engage with other ServiceNow product teams about how to deal with ticket re-assignment. I have a couple of related questions on that:
One is whether you would classify Level 1 support as a Technical Service? For example, an organisation might have several different channels available for business users to report incidents, perhaps with different SLAs dependant on the channel. Is that something that can be reflected within the Technical Services model?
Secondly, I am aware of that within the CSDM Documentation there are the various Product Views already available, and I’ve also watched the recent video posted to the community on how Change Management leverages the CMDB. Going back to the earlier response to Cheryl, the question of how incident re-assignments work is for me a key one when it comes to modelling services, and the SLAs and OLAs linked to the service offerings. Is it possible to get more integration with the other product teams within this community so that we can see what they have to say to some of these questions?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
