Everything is a Service - Why do Service Modelling?

Sorry about he Unicorn

Let me answer before you ask about the unicorn. You are correct  - Unicorns are mythical beasts and just a bit frivolous. You can't catch a glimpse of one in the wild, or find one in your local zoo, but if you really want to see one, you can always build a unicorn robot. In order to build one, you have to design it, define the components, and work out how they will operate independently. Once you have that done that, you can assemble it and eventually, have your own mythical beast. Now if you want to reverse engineer my mythical robot-beast, the first thing you have to do, is decompose my robot into it's components, find out how they work and then you too can engineer your own.

When I posted my last post, I promised that I will try and give you guys a bit of an overview of how a service is decomposed and modelled in order to be able to manage it. It is also my intention to do this, but in order to understand what and how, we first have to discuss why it is important.

That does not mean that I am going to dive into a “Why Why is the most important thing” like Simon Sinek did in his famous Ted Talk. It simply means that it is lot easier to explain what we are doing when we all have a clear understand why we are doing it.

Why services should be decomposed and modelled

Services should be decomposed like our unicorn robot, so that we can understand them better, Once we understand them, we can crate a model of them to ensure that we can reliably "remanufacture" them and actually consistently deliver the same service in the same way. Decomposition of a Service, is to logically take a service apart, and Modelling a Service is the process of creating a "map" of how the Service is constructed with all its dependencies mapped out.  The customer perception of your Service Delivery is hugely affected by the consistency of delivery of that service.

If you for instance order Crème Brulee from a restaurant, and the one time it is fantastic classical Crème Brulee and the next time it is more like a caramel pudding, you would consider the service to be inconsistent (since the product is inconsistent), and I for one would be reluctant to go to the restaurant again, as I prefer Crème Brulee that is just right.

So what does a service consist of?

Services are made up of various components. In the IT world, Services could consist of Servers, Software, network Devices, Transactions etc. Services could also consist of a manual process that somebody has to follow - maybe supported with some technology like pans, ovens and cooking utensils. Services are provided by People following Processes, consuming and using Products to finally create more Products.

Services are all about People

The People who have interaction with a service are:

Initiators:

Initiators are those people who have to design, architect, compose (or whatever is applicable to your field) a service. They could be marketing people with an idea, visionaries who invent, architects who design – any permutation or combination of people who have the idea and can describe or create the idea.

Approvers:

These are the people who have the money, allocate resources, can give the authority to empower people to actually make this Service happen

Builders:

These are the people who have to make the Service work. They are the ones who test the recipes, Design the detailed processes, automate the processes, manage the implementation, ensure the technical design specifications are met. These are basically the constructors

Fulfillers:

These are the people who fulfill various tasks on the back-end of the service. The waiters, the packers – everybody who has a role to fulfill to deliver on the actual services.

Operators:

The Operational team ensures that the service keeps on working and if there are any anomalies these people ensure that the right people know about it so that it can be fixed or could potentially fix it themselves if they are mandated to do that. An example of this, would be anybody who works as part of a continual improvement programme, and the Datacentre staff who ensure that the networks, servers and software keeps on operating.

Customers:

Most importantly – a Service without a customers is absolutely pointless. I have lived in countries which have rules for stuff that cannot go wrong, and I class services without customers right there with those silly laws. It would be like defining a law that describes the colour of the sky. Stupid.

Customers can be all kinds of people. It could be the public. It could be internal customers. It could be managers. It could be a combination. A Fulfiller of a service could also be a consumer of the same service that he or she is a fulfiller for.

Services are executed following a Process

To arrive at a consistent result or the consistent delivery of a service, we need to have processes in place that are following the same path during each iteration of the delivery of the Service, and resulting in the same, predictable Service being delivered every time. That way the Product will be consistent. A process will be specific to the service we are providing. If we look at my earlier example of Crème Brulee, the cook would follow a specific process to produce the expected result. In cooking we call it a recipe. In other areas it would be called various things. So a great recipe for Crème Brulee can be found here: https://www.bbcgoodfood.com/recipes/2745/ultimate-crme-brle-

If you look at the recipe, you will see that to prepare Crème Brulee, you need ingredients (or components), a method of preparation (a workflow) and as part of the preparation you will apply specific techniques. You will notice in Step 6 that the method not only mentions that the sugar should be caramelized - it actually gives instruction for this. This could be considered to be a technique – or in the case of an automated workflow – a sub-process.

I could decompose the process for you, but I think that you catch the drift. The process is there to tell us the who, what, when, where and how. The Why is part of the overall Service Description so the process and all the sub-processes are defining who will do what, when, where and how.

Services Deliver and Consume Products

The product is the final product (tangible or intangible) that is delivered as a result of the service provided, but also includes products that were consumed as well as tools and infrastructure that were used in order to deliver the service to the customer.

This is where it gets really confusing, as in Information Technology, nearly all the focus has been placed on the tools that were used to deliver the service. Being Tool-centric is still is one of the fatal flaws in the delivery of IT.

Another fatal flaw of IT, is that we tend to be like those swinging blades in an old horror movie. When we end up at the one end of the pendulum, we invariably have to swing all the way to the other side.

First we buy tools to deliver (not assist with delivering) our process. Then somebody tells us that delivering a service has three components. We then discover that we have neglected the process. We swing over to the other side of the arch, and then try to deliver the service with the process and neglect the tools. Somewhere the line we then become bemused and realize that we have neglected the third “P” of the Service delivery – people. All of a sudden we start training the people on tools and processes, and when we get to the end of that, we are back at square one without having delivered on anything.

We then do the obvious thing.

We replace the tools again.

Keep the eye on the ball - Continual Service Improvement

Keeping the focus on the Service is the key to facilitate the consistent delivery of services, and once a servic ehas been decomposed and modelled, allows us to use a Continual Service Improvement process, to allow us reassess and only fix the parts of a service that are broken or performing sub-optimally, instead of doing broad, sweeping changes to organization, processes and tools every few years causing disruption the business. It allows us to effectively do micro-adjustments to a Service to ensure that the service is delivered effectively. The micro-adjustments that we do to the one service then would have a beneficial effect on all services affected by that specific component, and allows us to measure impact of those changes quickly.

 Example - I did not get Paid!!

How does this work in practice? Let’s use an IT Business service being provided – for example a imaginary Payroll Service. The Payroll service is provided by the Payroll Department of an organization, and they are using an IT application called MyPayroll. The MyPayroll application forms part of a suite of products from a vendor that develops HR software for medium and large companies of all verticals. The application runs on a three-tier infrastructure (Web, Application and Database) and is accessible to the Payroll team, Managers for input and queries) and the company employees (they can view their own paysheets online).

There is a support team for all the applications from the vendor in the company, and then there is a Web support team, Database Support Team, server support team and Network support team who have to ensure that he Service Remains available. There is also a security team in the company that ensures that the service is secure, and a helpdesk who fields calls for It when anything does not work.

The Service to the end-user (let’s call him Bob) seems quite simple to Bob, and using that assumption, he expects that he will receive his money in his bank on the 25th of every month. Actually he does not care if the process is simple – he just wants his pay on time.

This month, Bob’s pay however is not showing in his bank, and – as can be expected – is reasonably upset, as there are payments that must go off his bank that will be refused, and of course it is his 25th wedding aniversary the end of the month and he has planned a little trip to the Bahamas with his wife to celebrate this feat of mutual heroic perseverance.

So what does Bob do? First of all you have to understand that Bob is very concerned and more than just mildly irritated. He calls the bank and asks why his salary is not showing in the bank. The bank informs him that there is no money that came into the bank on the 25th of the month. Now Bob is highly concerned and his irritation levels are rising. Surely this is something that must just 'automagically" happen?

He calls the HR department in the company. The HR department say that the Payroll was submitted and the money should be in Bobs account as all of the 2500 people in the company’s pay should be in their banks.

Bob asks that Sandy – who answered the phone - please investigate. As Sandy puts down the phone, John who sits next to Sandy asks her what is going on, as his wife just called him and told him that she had breakfast with some of her friends and here card payment was not honored as was Mary’s who’s husband works in Production. Sandy quickly logs into her Internet banking and sees that her salary was also not paid in and then the phone starts ringing and chaos ensues as 2500 people discover that they have not been paid.

 The outcome

The outcome of our little scenario is that the IT ServicDesk was called by around 1000 employees, Sandy and one of the guys in the Server team received warnings - Sandy because she should have checked if the payroll went through successfully and the guy in the server team because he did not know that applying a patch to the database server on the 25th would impact on the payroll. The Database Administrator was fired. The IT Director was severely reprimanded by the CEO, and ten people resigned from the company because they cannot afford to work for a company that “cannot get the basics right”.

Why it Happened

The incident was caused and exacerbated by three shortcomings.

1. Change Management was not effective because impact of a change could not be determined, and the change was not controlled properly.
2. Monitoring and Event Management in the company was operating in silos of technology. The Server team that managed the Database server did not know that one of the databases that ran on the server did not start up after the server was patched. Monitoring for the Database did pick up that the database did not come back up, but the DBA had an event storm (too many events to make sense of) and did not notice the event and did not unow the importance. In his defense he was with the company for 1 week after the previous DBA left on short notice.
3. The IT department could not do root-cause analysis, and once the Service Desk became aware of the team did not know which team should address the issue so recovery took four hours whereas the only thing that actually had to happen was that the database had to be started.

Finding the Unicorn

In order to be able to manage a Service that crosses technology silos, you need that mythical beast called a Service Model. A Service Model represents information (often in a graphical format) that allows the organization to be able to:

1. Understand the construction of a service
2. Be able to understand the impact of a device, component or service on other services
3. Be able to quickly determine what is wrong if something invariably does go wrong, and ensure that the correct person or team can address the issue
4. Restore a service as quickly as possible if it fails
5. Be more proactive (or fast-reactive) if service components are degrading or failing.

Decomposing a service and modelling a service are the mechanisms or processes that allow an organization to create service models.

In the next delivery of this exciting series, I will look at a use-case and deconstruct a Service, and hen actually reconstruct it. We can then also look at the People, Process and Products and i can give some practical tips on how to do this.

Please Note that these are only my own ramblings and does not necessarily align with any company that I work for or have ever worked for or carries their approval or disapproval.