Creating cloud governance in an agile world

It may seem that governance and agile are rather a contradiction of terms, given one of the key tenants of agility is the ability to iterate quickly. So by adding a layer of governance into this is only going to slow cycles. And by adding a public cloud it could be considered that it is only going to hinder one of the primary product differentiators. I would like to challenge this belief and provide some insights into what Rackspace considers when operating in the cloud; specifically, around governance models designed for the new world of agile computing.

If you've ever heard Werner Vogels (CTO, AWS) talk at a AWS conference you will be familiar with the phrase "AWS gives you superpowers", it’s a common AWS summit theme.

It’s an incredibly accurate sentiment - the various public clouds will give your business, development team or builders, technology superpowers. In a matter of hours, proof of concepts can be conceived, infrastructure deployed, and applications stitched together with the vast array of ever-growing primitives that AWS provides.

To use another popular phrase "with great power, comes great responsibility". Given the depth of the AWS ecosystem, keeping up with the changes is a challenge in its own right! Currently, there are some 160 services available to your developers and there are hundreds (if not thousands) of new features released every year. At times, it feels like AWS are releasing a new feature every 60 seconds. Given the huge volume and velocity of changes - how does your organisation plan to ensure that everything is fit for purpose? Are you meeting your industry compliance and regulatory obligations (for example, GDPR) as all these technologies are deployed?

The traditional approaches to IT Service Management (ITSM) and change management often do not necessarily work, or can be perceived as intrusive to a truly agile environment.

As a result, we've observed developers making technical and purchasing decisions removed from the traditional IT service management workflows. This is great for agility but not for maintaining governance.

To address this, we recommend incorporating a Cloud Management Office (CMO) which is responsible for defining and maintaining minimum standards within your cloud environments. This group should meet on a regular basis and define the guard rails for your organisation to ensure that your developers are operating within specific limits but still have the autonomy to operate in an agile, iterative fashion. In addition, the CMO will introduce workflows to ensure that your cloud environments are periodically audited to maintain compliance with the defined standards.

Aspects which are recommended for consideration:

• Service Support - Cloud ecosystems are constantly evolving. This means that new functionality is being released with different features. It’s  great as new technologies can be experimented with - but it doesn't mean that they are fit for all purposes. Building out a service catalogue of "pre-approved services" is a good starting point .  Ensuring that you can answer all the following questions before adding them to your service catalogue also helps:
  • Do we have access to the expertise to support and manage the service?
  • What if something breaks at 2am? Who is going to know about it? Who is going to be able to fix this? What third parties can we rely on for support and assistance?
  • How is data integrity ensured? What backup strategy do we use with the service? How should backup data be stored?
  • What maintenance is involved in this service? How we are going to address these aspects to maintain service continuity?
• AWS Account Strategy - AWS recommends using different AWS accounts for separate teams and use cases, e.g. you shouldn't have both testing and production workloads within the same environment. A defined strategy should exist which is documented and understood by all from the outset.
• Cost Approaches - Being able to answer the question around who is going to be paying for a service is important. Is this going to be the department who built the solution? Or are these going to be the consumers of the service? How are you going to be able to track individual resources back to the group, who should be paying for it? Uncontrolled spend in the cloud is a topic which we address daily implementing a good policy ensures there is controlled spending.
• Data Classification - Not all data is equal - some data will be subjected to specific regulatory requirements (such as GDPR), while other data is of little value and shouldn't be retained. At a high-level - the organisation should have a data categorisation process. This should have consideration around some of the following:
  • The sensitivity (or confidentiality) of the data
  • Retention - how long should these be kept for?
  • Data sovereignty requirements. This could dictate which regions and services are used.
• Security - Guidelines around how services should be built out in the cloud to match the intended security posture of your business. This needs to consider any industry compliance or regulatory requirements. There should be clearly documented guardrails combined with auditing processes which will allow you to meet your security governance requirements.
• Reliability - Not all services within the cloud are built equally. Providing guidance around desired resilience necessary for each environment is recommended. This should include both recovery time objectives and recovery point objectives, which are mandatory, combining these with AWS Well-Architected Reviews is a good practice to maintain governance.
• Performance and Scalability Standards - Pre-defined performance and capacity (scalability) targets should be defined in advance and periodically reviewed. This should take into account performance testing as part of the operational activities to ensure that deployed infrastructure can meet defined key performance indicators.

Even with a fully governed model it is possible to have a complaint and agile cloud solution as I have proven in detail in this blog. Whatever stage your cloud journey is at including public clouds, we have the expertise to ensure your cycles aren’t slowed. Some key aspects to reducing technical debt is to consider who is going to pay for the services on-going, what your non-functional requirements will be, the value of the data which are intended to be stored within the environment, the intended security posture and the value which the services will bring to the organisation in the longer term.  Addressing the aspects contained above will best-place you to ensure that your journey to the cloud is a success.

Should you wish to speak to our experts click here to learn how AWS can enhance your business.