By Pierre Moncassin
Customers often tell me, “I totally get the principles behind the role of Cloud Service Owner – but can you describe what do they actually do throughout their work day?”
Let me start with a caveat: we are all aware that in a knowledge economy few roles have the luxury (or burden, depending on the point of view) of a completely predictable, set routine. We are in an era where many traditional, factory assembly line jobs have been re-designed to become more agile and less repetitive, at least in some leading-edge companies. The rationale being that job rotation and innovation if not creativity, leads to higher productivity. Less routine, more output.
What is a Cloud Service Owner?
When I say Cloud Service Owner (CSO), I am referring specifically to the Service Owner role described in the VMware white paper: Organizing for the Cloud.
A CSO is a relatively senior role that includes responsibility for the end-to-end life-cycle of cloud services, with numerous levels of interaction with the business and cloud team members. So I will endeavor to highlight some typical aspects of a ‘day in the life’ of that role – bearing in mind all the caveat above.
Cloud Service Owner Stakeholders and Interactions
The CSO interacts with a number of key stakeholders, first of all within the business lines. When a new service is requested, the CSO reviews the requirements with the Business stakeholders; which may include not only the definition and costing of the service but also a discussion of how quickly it can be placed into production.
In a DevOps environment, that interaction with the business lines will still take place, with the difference that business and application development may be a single team (the business stakeholder may be an application product owner). When the (DevOps) business proposes to launch a new product (i.e. cloud based application or application features), they may need to discuss with the Service Owner how to develop the continuous delivery automation to support that new product.
The CSO will also interact with the members of the cloud operations team, for example with the Cloud Service Architect who will assist in all aspects of the design of the automation workflows and blueprints underlying the services.
Interactions will also include working with other support groups such as the Service Desk – for example, to review incidents relating to the services and work out patterns or root causes; possibly involve the Service Analyst to improve the monitoring and risk management underpinning these services.
Of course the list does not end there. The CSO may also interact with third party providers (especially in a hybrid cloud or multi-cloud model), as well as contractors. If the cloud platform is part of an outsourcing arrangement, the CSO will likely have a counterpart within the outsourcer.
Key Processes for a Cloud Service Owner
From a process perspective, our CSO will be involved in all aspects of the service life-cycle – this is by definition of the broad remit of the role. But I can highlight some key ‘moments’ in that life-cycle.
- Initial definition of the service in cooperation with the business stakeholders.
This is a critical stage whether both the scope of the service is defined, but also the expected costs and service levels. - Monitoring the performance of the service.
In traditional IT, the review of SLA performance with business takes a key role once a service is up and running. In a cloud environment, much of SLA monitoring may be automated, however SLA review is still an important role for the CSO. - Continuous Improvement and ultimately, de-commissioning of the service.
It is expected that the service will evolve and that ultimately it will be de-commissioned (possibly freeing some capability). This is also an activity that needs close cooperation with business lines.
Toolsets for a Cloud Service Owner
I mentioned at the outset that the CSO is not necessarily expected to a toolset expert. However, in order to fully leverage the capabilities of a cloud platform, the CSO will be able to leverage the key cloud management tools, specifically:
- vRealize Automation – the CSO will have a solid understanding of how blueprints are designed and where/when existing blueprints can be re-used to create new (or amend existing) services.
- vRealize Business – understand the costing models and how they can be built into the tool to automate charging/billing.
- vRealize Operations – leverage the tool to track service performance, and generally managing service ‘health’ and capacity.
- NSX – the CSO is less likely to interact with this tool on a daily basis, but will benefit from a solid understanding the capability of this tool to help design the automation workflows and to plan the security controls that may be required when deploying the services (e.g. leveraging micro-segmentation).
The list is not exhaustive. Many organizations are considering, or already working towards DevOps adoption, and in those cases the CSO will benefit from a broad grasp of industry tools whether related to continuous delivery (think Jenkins, Codestream, Puppet, Ansible), or specifically to Cloud-Native Applications (think Docker, VMware’s Photon OS).
Take Aways:
- For roles such as Cloud Service Owner, design activities should take precedence over fire-fighting. These roles will prefer an engineering approach to problems (fix a problem once).
- Do not expect a rigid work-day pattern – the Cloud Service Owner is a senior role and will need to liaise with a range of stakeholders, and interact directly and indirectly with several tools and processes.
- The Cloud Service Owner will maintain a healthy understanding of toolsets; and leverage that knowledge daily to design, manage and occasionally de-commission services. This is an aspect of the role that may be significantly different from more traditional Service Manager roles.
- However, the Cloud Service Owner is not meant to be a toolset specialist. If they spend their entire day immersed in toolsets, it is a sign that the role is not fully developed!
- The Cloud Service Owner will work in increasingly close cooperation with the business lines– not from silo to silo but through an increasingly permeable boundary.
=======
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.
