In the client server era, IT demonstrated responsiveness by designing infrastructure to meet the technical requirements of various applications that the business relied on to do work. Developers spec’d systems. Ops built the systems. Devs changes the specs. The back and forth continued until the systems were live in production.
There were attempts to enforce architecture standards that were designed to control the chaos of having every system be a unique work of art, but business needs for whatever typically trumped IT needs for simplicity. If developers for a critical business application demanded some unique middleware configuration, they usually got what they requested.
As a result, most IT organizations have racks full of one-off systems that are unique and often hard to support. “A museum of past technology decisions” is one way to describe the typical enterprise datacenter landscape.
Cloud Changes Everything
Cloud computing changes this paradigm. With cloud, developers and users experience the value of fast access to standardized commodity compute resources. By accepting and designing around standard resource configurations, developers no longer need to predict usage levels to set capacity requirements, and no longer have to wait through long procurement cycles. Similarly, by accepting one-size-fits-all, consumers can get immediate access a wide range of ready to use apps.
The trade-off IT consumers make is essentially one of releasing control over technical assets in order to gain control over business processes. In return for accepting increased standardization (typically at the ‘nuts and bolts’ level, e.g. infrastructure, catalog, OLA’s, charging models), they get unprecedented agility at the business level (“on-demand” IT both in the form of provisioning and scaling and usage levels change).
In the cloud era, IT demonstrates responsiveness by giving developers and users immediate access to standard IT services accessed and then scaled on demand.
As a result, IT success in the cloud era depends, to a large extent, on IT consumers to understand the tradeoff and appreciate the value of standardization.
Start with Common Service Definition
The first step to achieving standardization is getting agreement on a common service definition. This includes getting multiple groups that traditionally have requested and received custom work, to agree on the details of standard services. There is an art in building this consensus, as different consumers with unique requirements need to come together to make this a success.The key is communication and consistency starting for from collection of requirements to delivery of services. (more on this process in a future blog post)
Another critical step is standardizing and centralizing an organization’s service catalog and portal. This allows for a consistent and secure customer experience that provides access across all services regardless of underlying environment – physical, virtual, as well and private and public cloud resources.
Standardization also enables IT to be a true service broker, picking the right environment to meet the needs of each service or workload. A service broker strategy includes policy-based governance, service-based costing, and end-to-end life cycle management across all types of internal and external services.
Today, organizations that understand the need for standardization are the ones transforming themselves to be more responsive with cloud-based operating models. For them, standardization is the driver to both increase business agility, and become more efficient from an OPEX perspective.
Key actions you can take:
1. Acknowledge the problem.
Is this true within your organization?
- Multiple single points of failure?
- Specific individual’s supporting legacy applications without documented runbooks or recovery procedures?
- Continuous fire-fights due to complex architectures leading to business downtime?
- Inefficient manual procedures?
- War room like setups to solve problems with limited to no root cause analysis and problem solving measures for the future.
2. Before embarking on the journey, take stock candidly of what is actually being delivered today. Ask probing questions from your current-state services.
- What services levels are actually being delivered (not just promised ‘on paper’)
- What services look ‘gold plated’ and could be simplified?
- What services are never, or very occasionally used?
Once you have a firm baseline, you are ready to start the journey.
3. Understand it’s a journey and it takes time. There is no big bang answer to solving this problem.
- Start with small wins within your organization’s cloud transformation.
- Development environments are ideal proving grounds.
- Initialize the cloud first policy.
4. Create a cloud strategy and focus on building business consensus through business communication and outreach.
For more on this topic, join Khalid Hakim with John Dixon of Greenpages for the May 30th #CloudOpsChat on Reaching Common Ground When Defining Services!
For future updates, follow us on Twitter at @VMwareCloudOps and join the conversation by using the #CloudOps and #SDDC hashtags.