In the previous blog entry we started discussing why IT should become an internal service broker and I shared the first three steps of the process to get there. We started by defining the services that are expected from the business, then looking at which services should be delivered by other entities, to finally discussing how to set-up the service broker itself. These are the three basic preparation steps that need to take place. But before we get to launch the service broker three more steps need to be executed.

  1. Fill the Service Catalog

At this point, we have the infrastructure and software environment, now we need to populate it. That means we are looking at describing the services that will be delivered and automating the delivery process so they are available when the user chooses them. Let’s start discussing the automation first. Indeed, when a customer requests a service, a number of actions have to take place for that service to be available for him. (And, of course, you do not want that to take hours or days. That was the old IT. It’s important we move away from that.)

We need to set-up an appropriate service provisioning. But the user can request many types of services. Let’s look at a couple scenarios and how they could be addressed:

  • An HR employee has been asked to take responsibility of a recruitment process. The company uses Workday, so the first step includes the employee gaining access to the recruitment software in Workday. To do so, the employee will ask for an extension of his account to also cover recruitment. This may require an approval from the head of HR, and once that approval is gained, the system will request the extension to Workday by calling upon a restful API and looking for the response as the actual work will be performed by the Workday platform. Note that the employee did not need to go to Workday to initiate the process, he just went to the service broker.
  • A developer wants to run some initial tests on a piece of software he wrote. To do that he will need a Linux server on which a webserver and a database instance are installed. So he will request the size of server he believes he needs, highlight the webserver and database type he requires and wait for the server to be provisioned. Once provisioned he will be given root access and can now install his application and run his tests.
  • A project manager is starting a new project. As multiple teams in different locations will work on the project, he orders a collaboration environment instance for his project. Indeed, by aggregating multiple services (see service broker definition in the previous blog entry), IT has created a service that includes a SaaS based MyRoom to interact and share documents, an Office 365 based SharePoint, a private cloud based ideation platform, a private discussion group in Yammer and a project e-mail address. The project manager chooses to provision that service and these 5 services are created on five different platforms. All of this is done automatically for the project manager. He does not see any of the complexities associated with this. He just gets what he asked for.

There are plenty of other scenarios. I choose those 3 as they each illustrate a different aspect of how a service broker works. In the first two it is about provisioning an account within a service that is already up and running. In the third, it is about obtaining an environment set-up specifically for the user so he can do his work, and in the fourth it is all about combining multiple services into one aggregated one. But to be able to do that, the IT team needs first to set-up the automation needed in each case, and then describe the service so the user knows exactly what he gets, what options he can choose from and how he is made aware of the availability of the service he requests.

  1. Multi-Supplier Integration

In some of the example scenarios I highlighted in the previous points, the service, or a portion of the service, is provided by a third party. The modern business user wants a service with a defined level of service and is pushing IT to ensure an agreed upon service level agreement. But with multiple players participating in delivery of the service, and each participant having their own SLAs, being able to deliver a standard one becomes difficult. First, one has to identify ‘who’ is responsible for ‘what,’ and depending on the type of service provided, this can vary widely. The picture below tries to demonstrate this.

MSI.png

For some services the IT department is able to negotiate SLAs that are in line with its own SLAs. For example, in outsourcing or when a managed private cloud is used, obtaining SLAs in line with their own. But when consuming a standard service (IaaS, PaaS or SaaS) companies are typically confronted with standard SLAs. Unfortunately, they are not always obvious. The devil is in the details. For example, you can find the AWS SLAs here. Be sure you take the time to understand the implications and identify what you can reasonably agree to with your customers knowing you will be dependent from such services to deliver yours. If you believe you cannot achieve your standard SLA for a specific application, make sure you make this visible ahead of time so you avoid false expectations. Creating the right expectations is critical to improve the experience of the end-user and demonstrate the commitment of IT to deliver the best service to the users.

  1. Develop a service thinking

Once you have all of the above in place it’s time to launch the service broker. Those that start using it will most likely have comments, suggestions and ideas for improvement. Be at the listening end, and evolve the services regularly. The automation tool designers available in the service broker allow you to graphically adapt automation flows when needed, add steps, remove others, perform parallel activities when it is possible to provide faster user response etc. Start by launching a limited amount of services and delight the users by adding more and more over time.

Make life easy for your users, shield them from the complexity. Let me take an example to illustrate what I mean:

  • Assume a manager has a new employee joining and he wants to make sure that employee has a mailbox when he/she arrives. So, he goes to the portal and to request a new mailbox. This process most likely includes answering some questions, including the name of the employee, potentially the size or type of mailbox required etc. Once that is done, the system automates a workflow that configures the mailbox and returns an e-mail to the requester. This email may tell him the mailbox is up and running, and may give him a temporary password so the new employee can go in and continue to set-up his or her mailbox. But some things can happen during this process. Let’s assume we have servers that each support 5000 mailboxes. And for the stake of the argument, let’s assume that this request creates mailbox 5001. Unknown to the requestor something more drastic needs to happen. A new mail server needs to be established. This will probably go through an approval process, but once done, the server is provisioned automatically and the software is installed so the mailbox can be created. There is no need for the requestor to know about this or to be involved. That’s not his responsibility. He just wants a mailbox.

In this example, it’s the service broker who decides what needs to happen taking into account the current situation. It’s done transparently to the user.

You might also want to include a social media platform in which you discuss how users perceive the service broker, initiating a direct, open and honest link between the users and your teams.

The Service Broker, the one stop shop for all IT services

Over time the service broker becomes the one stop shop. Not only does it facilitate the way IT is consumed within the organization, but it also makes IT more responsive. When I mention to IT staff that the end-users are their customers, I often get puzzled faces. Actually the end-users are the customers and consumers of the IT services. This is way too often forgotten. Treat your customers as you want to be treated by your suppliers. As IT percolates throughout most of the business activities, and as younger business users increasingly become IT literate, delivering a superior service should be at the center of the IT objectives or IT may end-up being bypassed increasingly. And that is neither good for IT nor for the business overall.

The original version of this blog was published in 2014 in the CloudSource blog