Imagine you invented a new kind of truck chassis. To build it, you developed the most highly automated, efficient manufacturing process in the world, creating highly reliable truck frames that can accommodate a variety of custom configurations: delivery trucks, plumbing trucks, flatbed transports, mobile laboratories, etc.
However, when you release your new truck chassis line, problems appear. Most people have never heard of your amazing new product. When they do, they do not understand the features, and do not comprehend what is included and what they need to add on their own. A few customers have bought your chassis, but are confused about how to customize it. And when they finally started using the completed trucks in the field and support is needed, they have no idea how to ask the right questions, or what kind of service they should expect.
What is the problem here? It is that you built a wonderful product, but you have not empowered your customers to be able to take full advantage of it.
According to the RightScale 2018 State of the Cloud Report, 92% of respondents are using public cloud. Of these, 68% percent either already have or are planning to create some form of centralized cloud team or “center of excellence,” to provide “centralized controls, tools and best practices to help accelerate the use of cloud while reducing costs and risk.”
At Cloud Technology Partners, we help many enterprises who are creating those “centralized controls and tools,” in part by automating the provisioning of public cloud-based complete solution environments for AWS, Azure and Google Cloud Platform. The fundamental tools and capabilities provided by these cloud providers are the building blocks on which a basic account is transformed into a “guard-railed platform.” Those guardrails are Infrastructure as Code (IaC): automatically deployed, standardized capabilities that have been built to reflect the enterprise’s specific security and operational requirements in important areas. These include identity management, encryption, monitoring and cost management, and are available to any internal customer who wishes to deploy products and services to the public cloud.
So far so good, right? You have accomplished centralized oversight and control through the guard-railed platform, while the enterprise’s internal cloud customers benefit from easy-to-deploy accounts, with many essential services ready to use, right out of the box.
Then, what is the problem? The problem arises when companies are so focused on the very real challenge of building out the technology required to deploy these services, they forget that the internal customers for which these platforms are built do not automatically comprehend the platform and what it can do for them. They do not necessarily understand how to interact with the platform nor how to request support. In effect, they are just like the customers of the truck chassis company we talked about earlier. They were provided with a great customizable product, but with little information, operational guidance or support. The result is a sophisticated technology capability that fails to sustain other critical aspects of any business technology solution.
The Other Pieces of the Puzzle
The technology needed to deploy guard-railed, public cloud environments is just the beginning. Think about the following:
- Cloud Customer Applications: What potential new customer use cases are appropriate and compatible with the guard-railed environment, and how are they determined?
- Cloud Services Deployment Process: How are new cloud environments generated, and by whom?
- End User/Cloud Customer Support: Who answers questions about the service?
- Issue Management: How are bugs/defects reported, addressed and tracked?
- Evangelism: How will the enterprise’s potential internal customers be made aware of the platform’s capabilities and value?
- Development and Operational Tools: Who creates and maintains technical tools?
- Exception Management: How are requests for security or operational policy exceptions evaluated and approved, and by whom?
- Request Management: How are new feature requests tracked and prioritized, and by whom?
- Capacity Analysis: How are capacity needs forecast and evaluated, and by whom?
- Systems Monitoring: Who tracks uptime, system failures and associated alerts?
- Security Audits: Who facilitates scheduled or ad hoc security audits, whether internal or external?
This list, while not comprehensive, represents a range of items and activities which are:
- Critical for the success of an enterprise cloud platform service
- Separate from the core technologies that create your guard-railed service
- Unlikely to be appropriate roles and activities for your core platform development staff
In other words, you will need to form separate organizational groups and staff to deliver these pieces of the puzzle.
How to Put the Pieces Together
Determining the groups, roles and staff necessary to cover all these functions is not a trivial exercise. Many of our engagements focus primarily on the question of how forward-looking companies can transform themselves from organizations with traditionally structured IT departments into ones where cloud practices and the associated digital transformations are woven into the fabric of the entire enterprise, delivering agility, customer responsiveness and higher profits. Even when you are not yet trying to transform an entire company, and with the comparatively smaller goal of creating only a cloud services platform, it is important to recognize that there is no “one size fits all” structure that perfectly suits all organizations.
Fortunately, there are some general practices and guidelines that can provide useful reference points. The elements described in the list above fall into a few general categories:
- Support for Cloud Customers
- Core Platform Development
- Strategic Direction/Roadmap
It is not uncommon to have departments or groups aligned with these categories. Here is one example:
The groupings often differ from one enterprise to another, in structure as well as naming. Some organizations will create a separate tools development team, rather than rolling that function into Platform Development. While the final organizational structure will vary, the important point is this: a range of additional critical functions should be addressed by dedicated groups, rather than simply be extensions of your developers’ responsibilities. For example, it is probably not a good idea for automation engineers to spend time on cost trending, or for someone who is great at test frameworks to write microservices how-to documentation. Not only is it more efficient to have dedicated groups for these functions, but different skill sets are appropriate as well.
What About DevOps?
Some of you are now saying: “Wait a minute! Isn’t DevOps supposed to be breaking down the walls between Development and Operations?” That’s a great question. Before we go further, (and without getting too deep into definition debates!) let us look at the fairly generic definition of DevOps as currently cited in Wikipedia:
“The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing, to deployment and infrastructure management.”
Here are some thoughts as to why this focus on “different groups and roles for different responsibilities” does not violate DevOps principles.
- Many of the items in the “pieces” list above are not directly related to “Development” or “Operations,” but rather to functions such as Product Management and Customer Support. For these roles, the DevOps focus on automation aids their functions, but cannot directly perform them for items such as release testing or infrastructure rollout and monitoring.
- In a larger sense, dedicating certain groups and staff to specific functions is directly in line with overarching DevOps principles, especially when this enables reducing development cycle time and continuous improvement through iterative and incremental correction.
- The types of structures described in this article most definitely depend on regular communication within and among groups. Product Ownership needs regular interaction with Platform Development to discuss possible architectures, features and priorities, while Cloud Operations may reach out to Platform Development for enhanced tooling. Cloud Customer Support needs to communicate with Cloud Operations to stay consistent with release schedule communications. These structures are NOT invitations to recreate the IT silos of the past.
Next Steps and Takeaways
Here are some steps you can take to enable your cloud customers!
- Put yourself in your end user’s frame of mind. Imagine interacting with your platform as they would.
- Think about all the forms of feedback and communication your cloud customers want or expect, and who and what systems would be best to create and manage those communications.
- Determine the tasks that must be repeated on a regular basis to keep your cloud platform running.
- Automate these tasks wherever possible; train smart people to perform and improve on them wherever automation is not currently possible.
- Chart out the roles and skills needed, and look for ways to bring in and train the right talent for those roles, from internal or external sources.