This entry was originally published on the CloudSource blog in February 2012.
In part 3 of this series we pointed out the CIO should become a “strategic service broker.” In parts 4, 5 and 6, we looked at criteria to decide which services should be delivered by the IT department itself and which could be sourced from outside service providers. That’s looking at the problem from a pure service provisioning perspective.
Let’s now put ourselves in the shoes of the end-user. Does the end-user care from where the service is sourced? Probably not. So, the real issue for the CIO and the IT department is to source services from multiple origins with no effect to the end-user. Let’s think about how we could do this.
The role of the service catalog
As a user, I want to use the services I’m eligible too without having to know where they are provisioned from. To do that, I want a service catalog, something that looks like the app store I use to choose the mobile applications I download on my smart phone or tablet. Once logged on I get a list of what I can choose from and make the appropriate choice. Do I need to know where the service is coming from? Absolutely not. I just want to know what I will receive (please describe it to me in layman’s terms), and if the cost is charged to my budget, tell me how much it costs.
That’s fundamentally what the service catalog does. Once you have authenticated yourself, the portal uses your credentials to define which services you are allowed to choose from. You can scan through the services, search them, look at the details of what will be delivered and in some cases even get feedback from other users.
However, you should realize the service that is described to you may turn out to be a combination of multiple services, some of which may be sourced internally and others externally.
Services & service elements
Let me give you an example. Assume you are an R&D project manager and start up a new project. You have a global team and need a “project collaboration environment.” As far as you are concerned, this is ONE service, providing you a communication and collaboration platform that will help your team in the project. It consists in a document repository, a collaborative documentation tool, a digital whiteboard to be used during teleconferences, a project e-mail address, a forum where you can discuss topics and a platform on which you can propose and evaluate ideas, suggestions, etc. In reality this service uses Microsoft SharePoint, HP’s Virtual Room service, a wiki, a forum and an ideation platform. Each of those is actually a service in its own right. Each of them may even be proposed in the service catalog as a separate service, but for the service I illustrate here, they are serving as service elements. You may decide to keep the SharePoint and wiki internal for example (they contain your IP) and use external services for the others.
Whether it’s a service present in the service catalog, a service element, part of a larger service, or if the service is performed by an external provider, the cloud needs to interact with an external cloud service. That is what we call aggregation. Multiple actions need to be executed as part of this process:
- When the user chooses the service, once the approval process is performed (if any), the cloud environment reviews whether this is a service that is delivered locally or by an external environment.
- If delivered by the cloud, the service orchestration takes place. It may be that despite the overall service is delivered by the cloud itself, some service elements may be delivered by other clouds.
- If a service (or service element) is delivered by an external provider, the local cloud functionality interacts with that external provider through the use of API’s. It requests the provisioning of the service and receives the credentials for the users. Those credentials are stored against the user to allow him or her to access the service once logged into the cloud without having to log into this external service using different identification.
- Next time the user wants to use this external service, he logs into the cloud platform using his regular credentials, and the aggregation function opens his session on the remote cloud from which the service is sourced. From that moment, the user works directly with the external cloud service and performs his duties. The external service meters consumption, checks whether the service quality adheres to the SLA, etc.
- On a regular basis, the external service provides to the local cloud platform information on billing and service levels. That information is used to bill the user for all services he consumes (both internal and external). Again, the user does not want two different bills.
These are the main functions performed by the aggregation function. Obviously, aggregation is also responsible to ensure end-to-end security for the user in a transparent way to him or her.
Aggregation allows a CIO to truly become the “strategic service broker” while providing his or her business users one place to get the services from. It’s an important concept that may not be fully understood yet as many discussions are still limited to the provisioning of infrastructure. But don’t worry, it’s coming. NIST calls it the Cloud Broker concept. Unfortunately they see this as an external service provider in its own right and completely miss the internal dimension. In my mind that’s the most important. What do you think?