Understanding your Business Services and why you should bother

What do we mean by business service? It seems like everyone has their own definition – well for this document we are going to go with the following ‘A business service is a service (such as email or electronic messaging) delivered to customers (internally or externally) by business units.’

In days gone by IT didn’t know or care about for that matter, what the business did while they were locked away in their department (usually in the basement). They focused on providing ‘IT things’ to the business such as applications or hardware; however, in the modern day world, this simply won’t work. With the explosion in ‘the service-driven era’ it is imperative that IT organisations understand not only what they provide to the business in terms of services but what the business is doing or using to deliver to their customers, and even more important than that is understanding how those things fit together.

A good way to understand this is to look at the components that make up the ‘service driven’ world; these can be broken down into the following:

1. The Business Service Layers (usually capped at three deep)
2. The Technical Service Layer
3. The Application Service Layer
4. The Applications
5. The remaining infrastructure

Completed and ordered in the correct way with the right relationships (and the correct attributes of course) the above will help any organisation sort, map and understand how their business works from a services perspective, and how those services interact with the supplied IT services (in the form an application service).

So, why do all of this work I hear you ask (and to be honest, it’s a long term commitment to pull this off – but boy is it worth it)? Ok settle in and imagine this with me. You lose a database instance due to a gremlin running around the data centre – for this example, we will say it’s a major Application Service that is affected.

Instantly you know exactly what application service is affected, knowing that, by default you know which business service(s) are affected (this can be more than one – think about how many business services rely on email!). Now you know, instantly who in your business is affected – and in some cases, which customers are affected too; neat huh well it gets better! Now we can leverage the real power of ITOM from that initial (automated) database event we trigger the following:

1. A logged alert, and from that an incident ticket with all the information your technical team needs to work on it – which we assign the ticket to, automatically.
2. An Email/SMS/Mobile Push/Desktop Push notification to the business and technical stakeholders informing them of the issue, perhaps even triggering a conference call between them.
3. A notification on your ServiceNow portal advising your business users that there is an issue – this alone is proven to reduce helpdesk traffic by up to 40%.
4. Instant messages to subscribed users – understanding what application services that your business services use allow you to understand what departments use them, therefore what teams and what team members – so we IM them and let them know that there is either an outage or degradation to service, and for good measure they can talk back and forth with a very helpful chatbot to get updates on the incident too.
5. A notification on your company website (where appropriate) letting your customers know that you are experiencing issues which are updated as the incident matures.

And all of this happens automatically, without a human having to do a thing – the possibilities are endless; imagine how it would feel to your end users and customers when you deliver rockstar service like that to them.

Having this structure in place allows you to wrap real context around how your application and technology services are used and what the impact is on the business is if they are unavailable.

If you would like to find out more on business services, ITOM or automation get in touch.

Team ITOM!