Defining Business Services

Gordon

I know this is likely a personal choice/business driver kind of question, but I am curious as to your opinions, so please feel free to give em!

As we start to think about defining business services, I get most of the technical components of that process, attaching assets, SLAs, users, owners, etc. What I am more interested in is the conceptual side of it all.

Do you define software apps as business services, do you define services as a collection of apps/hardware to form a business segment, do you define email as a service, or would you go higher and define electronic communications as a service (to include Skype for example?)

Thoughts?

Tom_Hendricks

This is a terrific question!  I agree that there is not a "correct" answer here, but there might be one or more suit your objectives better.  I'll share my thoughts here and hopefully we get other perspectives as well.

Business services, as far as your users are probably concerned, are typically more along the lines of your last example.  But within them are the supporting and enabling services that allow that business service to be provided.  Your example of "Electronic Communications" with "Skype" included is a good one.  Perhaps if your users think of it as "Messaging" instead of "Electronic Communications", then the service is called "Messaging," with "Email" and "Chat (Skype)" belonging to it.  Within email, we should start seeing Distributed Applications such as Skype and Exchange, if you are letting SCOM define (part of) your services.  If not, building the service manually in SCSM still makes sense so that all the servers that make up your application are properly related, and the reliance on that application and all of its components can also be accounted for.

The most important point made within this model is that you always start with the way that your users see your service, then work down.  You will probably be asked to report that way at some point, so why not be prepared?  It is also never a bad idea to help IT folks deep in the trenches of their work to gain some customer-based perspective.

Your question is about the concept, and like I alluded to above, the concept should be fulfilling something for you or else it's just a ton of work with a bad ROI.   In my case (everyone's list will almost certainly vary):

• it enables drill-up and drill-down reporting (dashboards, etc...)
• aids with conflict detection among changes and releases
• assists with support and configuration documentation (both by providing good info and also by making it more obvious when there is something outdated/wrong with the documentation)

Brian_Winter

Hi, sorry, late to the discussion (by a few years).  My company is just now getting ready to dive into this part of the Service Manager pool and we're bringing baggage.  We have both off-the-shelf software we support (like Skype) as well as a bunch of legacy built-in-house systems.  

The old-timers can't get their head around Business Services; instead, they carry the idea of App Portfolio for in-house and Software lists for store-bought (both in SharePoint).  I think their idea is to port this data into our Service Manager CMDB.  I like the idea of coming at this from the end user instead of the IT department.