posted

2 Comments

(This is part 1 in a series of blogs for service providers, assisting with go-to-market strategy and services.)

By: Guy Bartram, Director of Strategy & Advisory, VMware

A service catalog is a core interface between a cloud provider and its consumer, akin to the shop window. Within this blog I will discuss the various considerations and approaches that a provider should consider when looking at a catalog and what VMware can offer in this space.

For a cloud provider to successfully provide self-service; externally the catalog must be simple to use, provide tailored (personalisation) services and granular cost control even to the largest customer. Internally the catalog services should tie back to the, component product SKU parts and provide extensibility to allow for simple new service creation.

How does VMware approach the catalog for platform services?

vCloud Director Service Provider (vCD-SP) and vRealize Automation (vRA) are the primary infrastructure cloud offerings for providers to run in their Data Centres, with each product comes a catalog of services. This blog is not intended to compare the two, rather to examine various parts of the catalogs that are of interest to the strategy conversation.

What should a catalog look like and what sort of strategy should be considered when looking at a catalog?

The ideal catalog should be three fold:

  1. The catalog should include simple and well-defined (pre-bundled) offerings such as a set menu choice, which provide customers an easy option to select a service that suits them. In this case it is critical that the provider understands their potential customer base to ensure alignment between supply & demand, as they could effectively become a tower of limited services.
  1. The catalog should also fulfil a granular pick and choose ‘a la carte’ choice, allowing for a more advanced customer experience and with an ‘Service Designer’ component suited to the needs of larger enterprises tailoring their services. Critically all offerings, whether fixed or flexible, must be sustainable to operationally run and allow for extension to innovate new services, building on old and extending.
  1. The catalog should be able to integrate to service lifecycle processes such as the asset management, ITIL service management and problem management – integrating the catalog to the provider Operational and Business support systems.

So, what typically happens and why?

Typically, providers meet item 3 from the ideal list – this is an absolute must, but occasionally even that can be a silo. Most of the time catalogs have number 1 from the ideal list, but comprising services with limited flexibility or applicability long term. This is typically the result of the service strategy and service definition disruption from acquisition or vendor changes causing new silos of functionality to be shoe horned into the catalog.

The long-term impact of this may be problematic:

  1. It is not clear to the customer exactly what the service provides and its benefits due to additional components the customer not needing nor wanting (‘service tax’).
  2. Sales struggle to up sell to the next tier as the ‘service tax’ becomes more expensive and less attractive to the customer.
  3. It forces the ‘flexible sale’ behaviour; the value proposition is unclear and provider’s sales cannot sell the service – instead sell customised services as part of a normal deal cycle in an attempt to fulfil their targets.
  4. Custom & bespoke services mean additional operational costs to support and maintain, which in turn means less budget to spend on new services & innovation.

How do VMware catalog cloud platform products reinforce the ideal strategy?

VMware vCloud Director Service Provider provides a catalog ideally suited to drive consumption of VMware infrastructure services. Providers can realise revenue fast with services based on virtual appliances or machine templates in a role based consumer catalog. vCD-SP supports all necessary lifecycle processes to deliver pooled multi-tenant (isolated from tenant to tenant and provider to tenant) virtual infrastructure (IaaS) resources and virtual network services. However, the vCloud Director catalog is a fixed catalog, and does not provide an extensible service offering beyond VMware based IaaS. This is not a product limitation – it is very good at what it does, and by exposing the vCloud API it fits the ideal strategy to provide services within its capability within a bigger picture if necessary. Most service providers looking at self-service will also look at a ‘marketplace’ capability, which can pull on catalogs southbound to expose services to the consumer.

The vCloud API and the vCD-SP catalog are certainly one of the biggest benefits of vCloud Director providing a fast to market and easy of use to create ‘application’ infrastructure templates to deploy virtual appliances.

The vRealize Automation (vRA) provides a catalog ideally suited to provide not only infrastructure services, but X as a service also. vRA provides unique extensibility of the catalog above beyond VMware based services.  Before diving into the vRA catalog in too much depth, it’s probably appropriate to address the multi-tenancy question about why I’m talking vRA and ‘provider’ platform first…

Whilst vRealize Automation has not been seen as a multi-tenanted true cloud platform, it can be used in a ‘provider managed’ manner to manage multiple tenants with less isolation requirements. In this manner the provider must manage all tenant endpoints and all infrastructure.

Now back to the catalog and providers…

Perhaps the critical difference for a provider is the ability to get closer to the customer by moving away from virtual machine services to individual application services and understanding their customers’ business in their application infrastructure. VMware vRealize Automation provides catalog driven application ‘Blue-Printing’ allowing customers to standardize, deploy, configure, update, and scale complex applications in cloud environments whilst architects can create best practice configurations/workflows and integrations of these architectures for repeatability.

Stay tuned for Part 2 of this blog series, where we’ll discuss commonalities in vRealize Automation and vCloud Director Service Providers, sustainability, extensibility support, and more.

For more updates on the vCloud Air Network, visit vCloudAirNetwork.com. Be sure to follow us on Twitter @VMwareSP, and ‘Like’ us on Facebook at Facebook.com/VMwareSP.