By David Crane
As more IT organizations move away from the traditional, siloed model of IT and toward becoming a service provider, new questions arise. Running a smooth, cost-effective, efficient service portal can ease a number of the issues that IT faces, but only if done correctly.
The portal serves as the interface that helps consumers navigate through available service options and select them as needed. Behind the scenes, IT is serving as a contractor, comparing service requirements to different capabilities that may be internal, on premise, or from other providers. The user doesn’t care, so long as they are getting what they need.
So you have a portal, and you have a cloud. Now what?
Consistently Capture Service Requirements
With the right foundation, managing the service portal can be a smooth process,. The first step is to understand the unique requirements that your users have, and deliver the resources that are going to meet their needs. The best way to understand that is to step outside the traditional organizational silos and engage directly with the lines of business.
Once you understand the various service needs, create service charts, such as the example below:
These will serve to identify all the different components required in each service. Most of these components will be common across different services, and can then be built out separately. Take a “cookie cutter” approach to these components, so that when mixed and matched they will create the services needed. Part of correctly understanding these components will involve a deeper understanding of the service definition process. What tasks will need to happen across all operational levels? Who will be responsible for those tasks?
Right People, Right Services
Oftentimes, IT organizations feel anxiety about the level of automation that stands behind a portal. It’s challenging to think of users that have previously been carefully walked through specialized processes suddenly having the ability to requisition services through an automated process. Creating clearly defined roles and restricting access to the catalog based on those roles can alleviate these fears.
Once you have the roles defined, deploy provisioning groups to different IT resources consumers. Allow these provisioning groups to handle the issue of deployment capabilities and instead focus on using policies to govern how those deployments will take place. Use the defined roles for the portal to determine which users can perform which actions within their environment. The policies will dictate which components will be required in each context.
When Is a Service Ready to Go in the Catalog?
Some IT organizations, once their portal is set up, try to lump the service portfolio process in with the service catalog management responsibilities. This can lead to frustration and inefficiency down the line, and can undermine the cost savings and automation value that the cloud provides. Instead, use your senior technical resources to create the service definitions and components. This will be the best use of their skills, and is also the work that they are going to find challenging and interesting.
Once that is done, more junior resources can combine and deploy those components into the catalog. It becomes a simple process of handing the service configuration document to the person responsible for deployment.
Integrated Transition to Catalog
The transition process — getting services out of the catalog and into the portfolio — can be difficult and technical. Avoid a lot of the messiness by getting operational input early in the process so that all the requirements are understood up front. Here, again, is where it’s important to keep your senior resources working on high level issues: getting components aligned to the corporate enterprise structure, security, and any other issues that require IT’s attention. If the components are aligned to the business needs, the services that are composed of those components will also align by default.
Once the business and IT agree that there is a need for a service, the service owner and service architect should ensure that the required components exist. For any component, security, access policies and provisioning processes should already be determined — no need for testing, change process or QA. From there the service architect can take the components out to create the service configuration. Keep this streamlined and simple.
New Roles
Making all this work smoothly requires some new roles within the organization. A customer relationship manager (CRM) will act as the interface between the tech teams and the consumer. The CRM captures the requirements, keeps the consumer happy, and keeps IT aligned and communicating with the business. Unlike a managed service provider, the CRM should operate within the cloud tenants team to ensure and understanding of internal IT. The service owner, discussed above, is responsible for taking the requirements gathered and doing something with them, including negotiating contracts with the cloud providers.
The service portfolio manager will know the portfolio inside and out, and create a standardized environment. The service architects will combine components and author a configuration document whenever a new service is required. The service QA will test the created services. The service admin will be responsible for taking the configuration requirements and deploying into the catalog.
The service portal should serve as a powerful tool that connects consumers, both internal and external, with the services they need. By building strong component foundations, creating well-defined roles, and assigning resources where they will be most effective, IT organizations can ensure that their portal process runs smoothly and efficiently.
—
David Crane is an operations architect with the VMware Operations Transformation global practice and is based in the U.K.
