CSDM Discussion: Technical Service vs. Business Service
ฝัง
- เผยแพร่เมื่อ 10 ก.ย. 2024
- In this CDSM Discussion, David Thigpen and Mark Bodman address common questions and some confusion we typically see when defining Technical Services and Business Services.
We explore Technical vs. Business Service similarities and differences, identify the criteria for each, touch on historic implications, explain go forward approach for Service Classification, and explore edge cases such as Client Compute. We also provide some insight on what we are thinking about addressing or changing in the future as well.
Be sure to check out and bookmark additional CSDM videos on our Data Foundations playlist here: • Data Foundations - CSD...
#ITIL #CMDB #CSDM
Would be interesting to see a list of say the “Top 10” typical Technical Services vs the “Top 10” Business Services
Thank you Mark Bodman , David Thigpen for sharing this very informative and insightful discussion, provides additional clarity on the Service terminology.
Couldn’t agree more on renaming the Appliction Service to System Service, that makes perfect sense.
Keep sharing these talks on Best Practices and DOs and DON’Ts in a successful CMDB / CSDM transformation.
Looking forward for more such discussions on CSDM approach with MicroServices and Containers.
Why not rename Application Service to: Business Application Instance or Business Application Runtime? Those are the things that go in those tables. You can also just name it Application Instance or Application Runtime
Take a look at what we are thinking about for App Services in this video: th-cam.com/video/wKTtX7xxjpY/w-d-xo.html
Great discussion. Glad to know you are leveraging our challenges with adoption to help improve model. Very happy to see technical services move under SPM.
Great stuff. Will you do something about the data model when it comes to handling CI vs. Product model vs. Asset? We utilise both ITSM, ITOM, Devops, SAM/ITAM, GRC/IRM, APM plus SPM with TBM taxonomy, and end up with a lot of entities and records representing aspects of the same "stuff". As of now we have to manually relate lots of records to see what's what.
Can Business or Technical Services be mapped directly to an Application Service (i.e. without the need of an Offering)?
Thanks, this is a very good clarification of these concepts.
Clarification on something said: you shouldn’t relate something like network gear to multiple Technical Service Offerings. Are you saying the entire class shouldn’t be related to multiple offerings or a specific CI shouldn’t be in more than one Technical Service Offering (and thus should also only be in one Dynamic CI Group that is tied to an offering)?
It seems like there is desire to change the Application Service to System, Changing Application Service to “System” or “Application System” might work for some scenarios however it will confuse when we map web services or APIs to Systems. What about “Business Application Service” instead of Application service, that way both APIs and services those don’t have direct relationship to “business application” can be called “business application service” and the one with relationship from Business Application to “Business Application Services” would be the deployment of Business Application (Dev,test, prod etc)
I’d really like to see you model the Now platform as a follow up. Include some of the technical services and offerings that the platform typicality has dependencies on as examples.
There is a Now Platform example available in this video here: th-cam.com/video/-wD-E5IBzys/w-d-xo.html
Great video! Clarified things for me.
Thank you Mark Bodman & David Thigpen. Just curious, 2 years on where are we with the concept of Dynamic CI Groups in the Sell / Consume domain for laptops and the 'follow me' concept? Has this been incorporated in CSDM and/or the ServiceNow platform?
Maybe I don’t get it, but I still think it is not clear, how the model supports the incident process, if the business consumer raise at ticket on the business service offering and it turns out to be the responsibility of a technical service offering, as there is a bco sla with commitments, and a tso with sla and commitments🤔
In our implementation you can only raise incidents on app services or the underlying ci’s, you can’t raise incidents against business services or technical services but they can be added to the impacted services in the incident record.
The anatomy of an incident is "When tries to {with }, happens". Service offerings tell you what work someone was trying to get done, which helps you prioritize the ticket (Are people blocked on saving the universe, or blocked on watching Tik Tok videos?). Knowing the technology they were using helps us understand the tools they were using to try to do that work, and provides an entrypoint for remediating the incident. Both pieces of information are helpful in working the incident.
@@jayson119 not good. end-users can call on anything broken.
@@matthewalkman386 Why would you do that? They should report on the thing that is broken (Asset/CI) not at a service level where it's an aggregation of many associated or like things? How does letting them report on "stuff" help the incident process or the customer experience?
In the example of Desktop Support Service, the first look of it would say that it is Technical Service but since there are actual BUsiness consumers, will it be Business Service Offering vs Technical Service Offering. What would the incident be raised against if user faces issue with laptop at a particular location?
Honestly, all of this would be better with actual examples.
Great thanks, clear as mud.
I would suggest using our free Service Builder app from the store to define your services then. There we have built in help and tutorials that explain things, one attribute at a time and for each step of the way. This video provides a walk-through, and you can see that anyone can define them, even with a very basic, minimal skills. th-cam.com/video/db5wjxz9pm0/w-d-xo.html
I would like to ask for your opinion on a problem that has been bothering me for weeks and keeps me from starting with CSDM.
We are an internal IT service provider that serves our internal companies with IT Services. So we don't "sell" services, don't have SLAs, etc.
However, I would like to urgently implement CSDM to set up our IT service management processes more efficiently.
My first question:
Should I follow CSDM manual and start with Application Services (Crawl)?
Or should I do the APM Guided Setup and start with the Business Applications?
I already have the Application Services in the system for the most part.
(The naming for the instance is e.g. "SAP ERP Solution Manager - Prod")
Our customers order individual applications. What is the best way to provide them?
I personally would not do it through Business Service Offerings.
Why can't I actually provide the instance/application service as an offering?
Your answers would already help me a lot.
Kind regards
Martin
Hi Martin, you should look into Operating Level Agreements (OLAs), which are underpinning contracts that help the units you support meet their SLAs. You likely do not have any in place, but the concept will make more sense than SLAs in your scenario.
So can you use the dynamic CIs under a Business Service Offering then?
You can, it's one of the App Service types that is discussed in this video: th-cam.com/video/0UYFbVErr84/w-d-xo.html
With 30 years of programming, DBA and Architecture experience, I'm trying to understand how this is a data model. Are the arrows and ambiguous relationships some standard that I am just unaware of? It seems like this is at a business object/conceptual level but the composition, aggregation and association relationships are missing. Maybe using Archimate would help make this more understandable.
Likewise, I have worked in IT for more than 30 years, and realize that not everyone is a data architect who understand concepts like cardinality, multiplicity, 3rd normal forms and such. Our objective here in CSDM is to communicate in layman's terms what the data model is on our platform that is common. Archimate isn't specific enough as well to meet a data architecture either, it doesn't deal with multiplicity for example.
Anyway, the white paper here provide more detail on the meta-model for reference: www.servicenow.com/community/common-service-data-model/it-is-time-csdm-4-0-draft-white-paper/ta-p/2309441
Nice discussion, but I will suggest before you go down to the lower level first create clarity at top level. One of the suggestions is dont take all use cases unless you are final at a concept. For example, your example of Laptop user as a consumer does not apply over here.. We are still working at ServicNow products in mind..
Also I think “System” name might be a good fit for “Business Application”
I am not convinced servicenow understands how these concepts are useless with new tech frameworks
Mark is making this up as he goes along, CSDM 5.0 is nothing like 4.0. Sorry to call BS, none of you know how this works.