As organizations embarked on their cloud adoption journeys, the established practice was to treat the cloud as a separate domain, similar to other specialized areas such as networking, user management, or databases. This approach involved dedicated and specialized teams responsible for the ownership and operation of yet another single vertical within the organization; cloud. However, this model has proven to be more of a hindrance than a long-term success, resulting in more barriers to adoption and ever increasing costs.
Why are Cloud Centers of Excellence (CCOEs) doomed to eventual failure?
CCOEs were established with the intention of streamlining cloud adoption efforts by providing a centralized governance and expertise hub. They aimed to standardize processes, share best practices, and foster collaboration between different business units. However, despite their initial promise, CCOEs often face challenges that are at odds with the original goals of cloud adoption.
By treating the cloud as a separate domain, CCOEs unintentionally reinforce existing silos within the organization. Each team retains their focus on its specific vertical, resulting in fragmented decision-making, duplication of efforts, and a lack of holistic understanding of the organization's cloud strategy. This siloed approach hampers collaboration and limits the ability to leverage the full potential of cloud technologies.
Traditional CCOE models also tend to be slow-moving and less agile. Decision-making processes often become lengthy, requiring multiple layers of approval and coordination. In the faster-paced world of modern cloud computing, where agility is crucial, this approach can hinder innovation and responsiveness to market demands.
The establishment of CCOEs can inadvertently lead to higher costs. The specialization and duplication of efforts across different teams can result in, redundant resources, inefficient resource allocation, and increased overheads. Organisations that seek to leverage their existing software and services portfolio for solving cloud challenges often find that the cost model no longer aligns with that required for cloud. Additionally, the lengthy decision-making processes can delay time-to-market, leading to missed opportunities and decreased competitiveness.
How can organizations evolve their cloud adoption strategies for better outcomes?
Have the CCOE adopt a similar role to the Cybersecurity team(s); their function and value being; to define the guardrails within which the organization needs to operate and to select software and services that will help the rest of the organization honor those constraints without impeding progress.
A significant secondary benefit of leveraging a software and services approach is that these guardrails can be codified, managed and updated to remain both relevant and of value longer term. Developers can get early feedback on potential risks and mitigate them with approved patterns. Operations teams can rely on more consistent and more importantly; more supportable workloads from delivery teams.
A good example of this is the recent surge in static application security testing (SAST) adoption in automation pipelines where the codified guardrails can be used to quantify potential risks and flag them early to developers. The same codified guardrails can then be used to scan and inspect workloads provisioned into Cloud, identifying gaps in both security and maintainability. The same guardrails can be codified once and leveraged at different stages of the life-cycle.
This approach can be extended further to deliver other benefits by codifying behaviors that accept values from an accepted list and applying a default behavior if none is specified;
Backup & Recovery
- Automated snapshots of resources in production life-cycles to provide disaster recovery and business continuity
- If no backup label or metadata is found on a supported resource then no snapshot is made and unnecessary costs are not incurred
- In this case the default behavior is "no action" which correlates to a guardrail of "save, by default"
Cost Management
- Automated shutdown of resources in non-production life-cycles to reduce unnecessary costs
- If no shutdown label or metadata is found on a supported resource then the resource is shutdown (or stopped) after a default amount of time (ie. 2hrs)
- In this case the default behavior is "take shutdown action" which correlates to a guardrail of "save, by default"
As cloud adoption continues to transform the way organizations operate, the traditional approach of treating the cloud as a separate domain through CCOEs has shown its limitations. To unlock the full potential of cloud technologies and ensure long-term success, organizations must evolve their cloud adoption strategies.
It is crucial to break down silos and encourage collaboration across different business units to promote a unified understanding of the cloud strategy. Empowering teams to make autonomous decisions within defined guidelines enables agility and innovation. A proven method to enabling this success is to codify these guidelines and make them available to your users as a library of patterns ready to use with cloud.
At Hestio, we have taken our experience with designing and building on cloud to codify these patterns and made them available as a low-code pattern library for AWS. Why spend time and effort on reinventing the wheel when it's already a solved problem? Would you start developing office productivity software in a world where Microsoft Office already exists?
If you'd like to find out about worX, our low-code patterns library for AWS you can read more here or get in touch today to schedule a demo.
If you'd like to find out more about the products and services Hestio has to offer, select one of the options below.
