The concept behind IT-as-a-Service is to let business units order what they want through a central service catalog portal and let IT use more standardization and automation to respond faster and more efficiently. To enable this seamless, self service, we have had to put together the right tools necessary to make it all happen smoothly, from the first portal click to the provisioning of the service to the final user invoice.
Prior to IT-as-a-Service, if an individual employee or someone within a business unit wanted to order a service, they needed to call an ‘agent’ from the Business Technology Group in IT, fill out a form or pursue the process via the IT Central web page. From there, product managers and developers would need to get involved to deliver the service. Now, EMC IT has built a private cloud and is currently populating it with services, allowing business unit users to navigate through the service catalog portal and order a service.
We have been assembling the tools to achieve this end-to-end process, using a combination of readily available tools on the market and our own development expertise and technology. The goal over the next few months is to create a seamless process for this new user-focused IT delivery model. But longer term, we will be forging the framework for a new way of doing business in IT — one with increasingly stringent service level expectations for agility and efficiency.
IT-as-a-Service Program
The architecture for our ITaaS model can be broken down into two segments: the front-end components that business users can see and back-end processes they can’t.
The front-end operation is essentially a self-service portal with a service catalog underneath it. Among the challenges with the portal is creating the taxonomy of services offerings in a way that makes sense to users. We have established six broad categories—Collaboration and Communication, Hosting, Client Computing, Access and Information Management, Business Capabilities and Professional Services—as well as providing for the right hierarchical dependencies among services. The service catalog basically has all of the IT services we want to offer as part of this comprehensive taxonomy.
We have created an XML mapping model that allows clear separation between the end user service taxonomy and the services within service catalog. This allows a very loose coupling between the portal and the service catalog. Since different services can be part of more than one bundled catalog offering, we can map a service offering on the portal to one or more services in the service catalog. The business can come in and, either on a self-service basis or on a by-request basis, select the services from the self service portal. Included in the portal are service collaterals such as the explanations of what the services are, prices, comparisons with other products, and descriptions of how EMC IT will support them through defined Service Level Agreements (SLAs).
To enable easy updates to catalog information, we have integrated our Enterprise Content Management (ECM) Platform with the portal to allow IT product managers to add or augment service collaterals without requiring development resources and code migrations.
Automation is key
Selecting the tools underneath the taxonomy is crucial. In the end, when you order the service, the expectation is that most of the process is going to be automatic. When a user orders a service, the service catalog essentially initiates an approval phase, based on the rules that have been set up. It also activates escalations appropriately. Part of the approval process is the financial approval. After the approvals are completed, the service catalog initiates the delivery phase.
For this, we have picked different sets of tools. There is a service orchestration tool which actually talks to a variety of systems on the back end for provisioning needs. It also interacts with the configuration management data base as well as the actual IT service management entity that provides for resource allocations. There may still be manual steps along the way for which the system must also provide proper processes.
The key architecture principle at this stage is the seamless interaction of the service catalog with service orchestration. For each service, we have defined a provisioning request XML message. We have also defined workflows within the orchestration engine. The provisioning request XML triggers the workflow for the service to be activated. The workflow steps interact with various back end systems and applications to fulfill the request. The orchestration engine can send status back to the service catalog so that the user can be kept abreast of what is happening to their request through this ordering process. The orchestration engine also interacts with a billing and invoicing tool to charge users for their IT consumption.
We are using standard concepts like web services for the orchestration. The orchestration tool has multiple adapters to the back end systems. It enables us to talk to those systems and get the appropriate provisioning and delivery done. Once it gets past the provisioning and orchestration, it enters into the IT service management system. The IT service management system has many areas of functionality that enable the smooth operation of the provisioned service, including incident management response, the configuration management data base and change management.
One-stop shopping for IT Services
The whole notion of ITaaS is agility. Our intent is to make as many things as automated and available in a one-stop shopping model as possible. Even if it is not a self-service tool to put in front of the business, such improvements can still provide IT with the added agility in provisioning services for the business.
One very important concept we are pursuing is to identify standardized aspects of services so that we can start leveraging that standardization to make IT consumption as automated as possible. For example, with Infrastructure-as-a-Service (IaaS), we’ve set up categories of small, medium and large work environments for users to choose from and created templates for each option. (Note that this is a different use case from the Cloud 9 environment which we have talked about in other blog posts and which is a minutes-to-provision environment for transient workloads.)
So let’s say a user comes to the ITaaS portal and selects a medium IaaS environment from the service catalogue to accommodate his or her application development work. That initiates a workflow to automatically make sure the order gets the approvals required such as departmental and financial approvals. Once those are completed, the orchestration process kicks in—making sure the requested virtual machines are available, provisioning them, and generating change tickets to provide instructions to the infrastructure operations team. The system creates entries within the configuration management data base and the resource plan of record to provide staff hours to do necessary work. The management tool then put entries into the billing and invoicing system. A message is sent back to the user tracking the status of their order.
The IaaS provisioning process takes between one and five days, depending on the complexity of what users are asking for. Once the service has been delivered, the support process starts behind it.
We have already gained many efficiencies in recent months toward faster service provisioning, so in some cases the delivery time for these services via ITaaS may not be less than what is available now. However, what users will gain is a single, central place where they can order all of the IT services they need and get better visibility into the execution of the fulfillment process. Approval processes will also be much more automated. ITaaS will not preclude IT projects that use the expertise of the Business Technology Group. What it will do however, is create a more efficient process for those instances where a full-blown IT project isn’t needed.
