In the previous blog entry we talked about IT becoming service focused. We also talked about the IT environment becoming more complex as, in an effort to reduce cost, services and applications are hosted in a variety of platforms. These platforms extend from the traditional environment, through private, managed and public cloud to SaaS services. Ultimately the IT landscape becomes a mixture of all delivery models.

But it is understandable to want to keep IT simple for the business user (given that you want the business to use IT and not to go to external sources). And by external sources I mean sources that are outside the realm of IT. Other goals most likely include ensuring that you can manage security in an integrated way, regulating data treatment to remain compliant and maintaining a “single source of the truth.”

To accomplish these, you will need a series of services you can deliver to your users and a simple way for them to navigate through the complexity of the IT environment. This is where the concept of the internal service broker comes in.

What is a service broker?

According to NIST (the National Institute of Standards and Technologies), a cloud broker is an entity that manages the use, performance and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers. In general, a cloud broker can provide services in three categories:

  • Service Intermediation: A cloud broker enhances a given service by improving some specific capability and providing value-added services to cloud consumers. The improvement can be managing access to cloud services, identity management, performance reporting, enhanced security, etc.
  • Service Aggregation: A cloud broker combines and integrates multiple services into one or more new services. The broker provides data integration and ensures the secure data movement between the cloud consumer and multiple cloud providers.
  • Service Arbitrage: Service arbitrage is similar to service aggregation except that the services being aggregated are not fixed. Service arbitrage means a broker has the flexibility to choose services from multiple agencies. The cloud broker, for example, can use a credit-scoring service to measure and select an agency with the best score.

An IT department that operates as an internal service broker will focus on the two first categories. They will typically provide seamless access to the service and the more sophisticated ones may integrate multiple services to create new, combined ones, facilitating access to functionality and services even more.

How to become a service broker?

Once you agree it makes sense for the IT department to become an internal service broker, what are the next steps? I believe this is a six step process. Here are the first three steps I would suggest, the other 3 will be described in the next blog entry:

  1. Identify the list of services required.

The first question to ask is what services does the business need? Ideally, go and ask them. But the response might not be that easy to obtain as those in marketing, finance, or other business capacity may not always think of what they need in terms of IT services. So, one way around that is to start from the business processes and identify what services are required to support those key enterprise business processes. Start with some that are used internally as you would want to gain experience with the concept of an internal service broker prior to opening it up to customers, channels and partners.

For each of those services, do not limit yourself to the description of the service, but also think about the data required and how this data links with other services. Particularly when you are planning to consume external services, this step becomes important. External services, particularly SaaS services, come with their own data structures. If data hosted in these services need to be accessible by other services that are internally provided for example, it becomes important to think how the data is kept in synch.

  1. Identify externally sourced services

Once we know the services required, or the services that will be visible to the broker, we now need to find how those services will be delivered. Some will be provided by applications that are delivered by the IT department itself, while others might come from external services such as IaaS, PaaS (both of those mainly for development) and SaaS services. Actually, moving to a service broker might be a good time to rationalize the application portfolio and review which application(s) could be delivered by SaaS services more economically.

In that process, the “Core versus Context” criteria (which I have discussed in previous blogs), play an important role, but they are not the only ones. Latency, security, privacy, compliance etc. are other elements to take into account to decide whether an external service can be used.

For the services provided by internal applications, the migration of these applications to private or managed cloud environments needs to be planned. Again, this is something I described on the blog on several occasions. One important element to take into account is whether the application can be re-hosted or requires a re-factor/re-architect transformation, which might be required due to large variances in service usage. Transforming internal applications might be a good moment to also transform the user interface and mobile enable the services.

For externally provided applications, understand how the applications can be accessed through APIs and what services are available. Questions such as: how do I trigger the set-up of a user, how do I understand consumption, how do I change service options, how do I link the service with my LDAP/AD to facilitate log-on etc. – are also important. This will serve as a basis to understand how those external services are integrated with the cloud broker.

  1. Create portal and service catalog

It’s now time to create the portal and the service catalog. This can be done starting from standard products such as HP’s Cloud Service Automation. Take time to describe each application so the business users understand what services they can consume, and what outcomes they might expect. Advanced service catalogs have the capability to attach services to organizations and roles. Using these, you can display to an individual user only the services they are allowed to consume according to their organization/role in the LDAP/AD. You may also have the possibility to include an approval process. In other words, when a user asks to consume a service for the first time, that request is forwarded to the person that needs to approve the request prior to fulfillment. This may be interesting to limit the proliferation of instances of services.

Conclusion

Now we have established an environment through which users can access services that support the key business processes of the organization. These services will run in a variety of environments, some may still be running on traditional environments, others on a private cloud, yet others in managed cloud environment and the remainder may be consumed as SaaS services. Through the cloud broker this is now transparent to the end-user and IT is dealing with the complexity of provisioning. The great advantage for IT is that it can deliver to the business what the business requires, while focusing on what differentiates the company, the “core” functionality, while using external resources for everything else. How to manage these external relationships is the next step to take into account, and we will do that in the next blog entry.

This blog entry was originally published in the CloudSource blog in 2014.