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

Rob, thanks for the clarification. However, i partly disagree in one part. In ITIL terms, a Business Service is, as you explain, the Customer´s view of the service. This service can then (they usually are) contain/be built of internal services, more of a technical perspective. I am in a project of configuring the structure of a customer´s services, and trying to visualize the relationships between Business Services (customer-facing), internal services (Technical) and applications (aka Systems...). I wish the Dependency view could visualize this. As for now, all Business Services show up as.... Business Services, no matter how they are classified. I am in the mood of creating an extension of the Business Service table for Technical Services, but I have yet been holding my horses...

Is there any way to configure Dependency view to show the Service Classification value instead of the table name for Business Service objects?

Best regards

 

//Per

This usage is problematic and in need of a clean-up.

Some definitions conflict with widely adopted definitions in external frameworks. There are also numerous internal inconsistencies and oddities in the SN platform. For instance, why would Business Service, Technical Service, Service Offering, Shared Service, Application Service, and Billable Service be types of a Business Service? There are at least two different "kinds of things" in that list. Any definition that reads "XYZ Service is a grouping of Business Services" or "Business Services of type Business Service" are markers indicating the need for conceptual and architectural remediation. 

Business Services should decompose into Service Offerings. Service Offerings (and in their absence, Business Services) should be supported by Technical and Application Services (both of which should be internally facing and not customer facing). Shared and Billable Services are financial and operational concepts and should be composed of one or more Business, Technical and/or Application Services and not be peers to those services.  A Business Service in the CMDB should not be different than a Business Service in a Service Map. 

All SN Applications should use these and other terms consistently. There should be no definitions that are unique to, or specific within, a given application.

Hopefully these and related issues are on the roadmap for resolution? 

 

 

Thank you Rob for a great answer!

I have also worked with many cases where Business Services have been used as part of Service Portfolio. More of a Business Service Catalog type of approach as in Service Portfolio Management plugin, with Service Offerings etc. All the undiscoverable parts of services and how those are offered to users/subscribers.

BUT, it seems that newer features such as Service Mapping, is using the same Business Service class in a very different way. More from the technical, discovery point of view. But not all Business Services are related to "applications" or "entry points". Maybe that is why Kingston release also introduces the Business Application class. Which in my mind is more towards the Service Mapping use case, while the "old" Business Service should be used as part of a Business Service Catalog.

Anyway... seems to like two conflicting use cases for the same class. Which way ServiceNow is going? Any "official" answers from the ServiceNow staff?

How to use Business Service class if you want to have best of both worlds? Thought?

Cheers,

--Mikko

 

srirao
Giga Expert

robpickering Rob Can you also please help me with this question regarding the Service-CI relationship:



Our service provider has defined services such as "Backup Service" and "Anti Virus Service". These services are being provided to us to backup our servers and protect them from viruses.



I am trying to figure out the appropriate relationship between them.



Should the relation be the "Server CI" uses "Backup Service" (Backup Service used by Server CI). This is because the Server CIs are dependent on the backup and anti virus services for their sustainability.



I also think that the reverse of the above relation is also correct i.e. the "Backup Service" uses "Server CI". This is because the technical components of the services i.e. a backup agent or the anti virus agent run on the Server CIs and from an impact perspective i.e. let us say the backup agent goes down on a server then the service impacted is the backup service.



Appreciate your help!


robpickering
ServiceNow Employee
ServiceNow Employee

Sorry it's taken so long to respond to this, but I wanted to answer:



Yes, Server CIs "uses" Backup Service (and Server CI "uses" Anti-Virus).   The reason being that if there is an interruption to those services, you'd want to know what CIs are impacted in order to prioritize it.



You will also have Server CI "provides" Backup Service for the infrastructure that supports the DELIVERY of the Backup Service.   This could be a SAN, the Application Servers, etc.   This allows you to understand that when Backup Service is experiencing an outage, what infrastructure components are involved in the delivery, so you can quickly diagnose the root cause of the issue.



-Rob