Business Services vs Technical Services

srirao
Giga Expert

Hi,

I am trying to understand what should be defined as a Business Service vs Technical Service.

Is there a standard definition for a business service and technical service with some examples and how this definition impacts CMDB/CIs in ServiceNow?

I also looked at the sample data provided by ServiceNow as Business Services.

For e.g. SAP MM, SAP HR, SAP Payroll, PeopleSoft Financials etc. Shouldn't these be created as applications in the CMDB than as Business Services?

And shouldn't be the Business Service definitions be more generic like Materials Management, Human Resources Management Systems etc. than technical and then establish relationship between Materials Management and SAP MM as Depends On?

Appreciate your help.

Thanks

1 ACCEPTED SOLUTION

robpickering
ServiceNow Employee
ServiceNow Employee

What a great topic!



tl;dr   To answer your direct question, you'll only define things as Technical Services if you are using Event Management, as you may want your Event Management dashboards to roll up for IT visibility, whereas the Business Services should be customer-facing and be broken down into Service Offerings.   In your example Exchange and Active Directory should both be Service Offerings, so you can track availability, slas, outages, etc.



Within ServiceNow you have a couple of layers, so it's first important to understand those artifacts and how they're utilized:


  • Configuration Item:   Any item that is being tracked within your CMDB and for which you have configuration information.   This is the lowest layer in a service-aware CMDB.   Conceptually, this is anything with an IP address (though obviously documents and applications could be CIs and won't have them, but this is just a concept).   See here:   Configuration Management Database
  • Business Service:   Work or goods that are supported by an IT infrastructure.   Within ServiceNow we then break these down into different types of Business Services (Business Service, Technical Service, Service Offering, Shared Service, Application Service, Billable Service).   Business Services of type Business Service are the most abstract and will represent the highest level in your CMDB.   These should be how the customer sees the service being delivered, what do THEY call it (forget what IT calls it).   Ask your users to describe the services they consume in a day, you'll probably hear "Email", "Purchasing", "Marketing", "Computing", "Telephony", "Finance".   A mix of departments and services, that's fine, because your goal is to minimize the time it takes to communicate to your users the state of these services, and to quickly allow your users to communicate to your service desk when there is an issue.   I cannot stress enough to talk to your user community to build these, if you build them from an IT point-of-view you'll miss a lot of the value of having a service-aware CMDB.   You can read more here:   Business service tables
  • Service Offering:   Derives from a business service, refining the parent business service to a specific business need.   These are Services / Capabilities that you wish to track for Availability, SLA Adherence, Outages, etc.   They can be made up of CIs and they support Business Services.   They consist of a set of Service Commitments that you're going to track.   You can then build Availability reports on Service Offerings and show back to the Business.   Users can also subscribe to Service Offerings and then put availability gauges on their dashboards.   See here:   Service offerings
  • Technical Service:   A dynamic grouping of CIs, based on some common criteria.   These are used in Event Management (ITOM) and will roll-up to the buckets you see in that application.   You can include Business Services or CIs in these groupings.   In general, you'll only use these within the ITOM suite of applications and Event Management specifically.   See here:   https://docs.servicenow.com/bundle/helsinki-it-operations-management/page/product/event-management/t...
  • Shared Service:   Similar to Technical Service, a Shared Service is a grouping of Business Services and CIs that are utilized in the IT Financial Management application in order to provide cost transparency.   In general, you'll only use these within the ITFM suite of applications.   See here:   Create IT shared services
  • Application Service:   Similar to Technical Service, an Application Service is a grouping of CIs and Business Services that are Application specific.
  • Billable Service:   Similar to Technical Service, a Billable Service is a grouping of CIs and Business Services that you group based on how they are billed.


So, from the above set of artifacts, you'll find you really only want to be concerned with CIs > Service Offerings > Business Services, where your Service Offerings are the Business Services for which you want to track Commitments and then those will roll into customer-facing Business Services.



It's a little confusing, but hopefully the above has helped.



-Rob


View solution in original post

34 REPLIES 34

Hi Rob - your explanation is very helpful 🙂 I'm still a little confused between business service (classification "service offering") and service offering derived from business service. Am I correct in saying that if I derive a service offering from a business service, I have simply created another business service with the classification "service offering" whereas the parent classification is "business service"? If that's the case, is there an example use case where you would setup a parent business service "service offering" with a child business service "service offering"? Also, if I have a top level business service "business service" is it mandatory to have child business service "service offering"? And finally can my top level be business service "service offering"?



Thanks in advance Ben


garybolton
Kilo Explorer

I have a couple of questions that are extensions to this post.   We are in the process of implementing service mapping and application portfolio management.   I understand that business services in the CMDB are separate from the business services in service mapping.   Should you service map at the more abstract business service level or at a service offering?   How should your service offerings and service maps relate to the business applications in APM?   I am using the following example.   Does a Service Map = Service Offering = Business Application and Business Service = Business Capability?   I would consider Okta (but not SSO) a business application because I will assess it, roadmap it, etc.   I wouldn't think I would consider Active Directory a business application because I wouldn't see myself needing to do those types of activities.   Let me know your thoughts.



Business Service Example.png


Hi Gary,

Hope you are well.

This is very similar to the approach I have taken. How are you getting on with this implementation? I have explored the CSDM and whilst I appreciate the motivation behind it, I found more value in pursuing use cases that meet our requirements. 

Would you display Authentication and these offerings in your Service catalogue? Have you been raising incidents against your offerings? 

Kind Regards

Adam

RobinR1
Giga Contributor

Sorry, but after reading all available links/threads and this discussion I am still in the dark as to what an "Application Service" is.   A list of things?  List of what kinds of things?  Is there a more complete definition and examples of application Services?

robpickering
ServiceNow Employee
ServiceNow Employee

Hey Robin,

I wrote this 3 years ago and while it's still technically correct, there has been a lot of movement on these higher level business services.  Internally, we're leveraging a framework called the Common Services Data Model (CSDM).  You can read our white paper on CSDM here.

Within the CSDM an "Application Service" is defined as "a service type that is a logical representation of a deployed application stack".  

There are a couple of key words in that definition:

  • logical - meaning it's not a physical topology, it's a grouping (which also means it can be a bit arbitrary)
  • application stack - meaning not a named application like "Oracle 19c", but rather all of the components that go together to provide the "database service" of which Oracle 19c is a component.

Ultimately, what an "Application Service" is for your company is, well, defined by your company.  Spend time mapping out how you want to derive each layer of your CSDM using the white paper linked here.  You won't be wrong, because it's somewhat unique to your own company.

Hope this helps clarify.

-Rob