Avoid friction and confusion around your cloud programme early on! Set clear principles for the cloud build-out. Here’s how.

This article is part of the limited preview of the “The Missing Cloud Programme Roadmap”, a generic roadmap for any enterprise cloud adoption programme.

1. Executive Summary
2. The Cloud and Enterprises
3. The Missing Cloud Programme Roadmap
   1. The Cloud Programme Roadmap
   2. The First Iteration of The Cloud Programme Roadmap
   3. The Unavoidable Disclaimer
   4. The Roadmap for The Missing Cloud Programme Roadmap
   5. The Manual for the Missing Manual
   6. Building the Business Case
   7. Starting the Cloud Programme
      1. Key Achievements
      2. Setting up the Cloud Programme
      3. Attracting the Right Mind- and Skill Sets
      4. Putting People First
      5. Determining the Build-Out Principles for Cloud
         1. Build-Out Strategies
            1. Building out Regions within a CSP
            2. Building out CSPs
         2. Bridging CSP Gaps
         3. Buying versus Building
      6. Getting Into the Details
      7. Recording Outcomes: The Cloud Guidebook
   8. Iteratively Building the Delivery Pipeline
   9. Iteratively Executing the Delivery Pipeline
4. A Cloudy Future

Determining the Build-Out Principles for Cloud

The grande rules guiding all build-outs of the programme still need to be determined before ascending into the details in the next section. These principles then provide all team members with a clear path to the eventual programme deliverables.

Build-Out Strategies

Given the current regulatory resiliency requirements as of early 2021, there’s a very decent chance that the programme is required to adopt the cloud across multiple CSPs and regions; often referred to as multi-cloud and multi-region. While the outcome may be predetermined, the path to it is not.

Building out Regions within a CSP

One option is to start with the build-out of a single CSP in a single region until a certain maturity level is reached; a region should always be its own failure domain. This expertise can then be used to increase resiliency by adding additional regions until a suitable level is reached.

While this approach can make the initial build-out slightly easier at first, one of the drawbacks is that the resulting implementation might be rather region-specific; not all CSPs offer a parity level of services between all regions. Plus, multi-region designs might need to be retro-fitted into existing architectures.

An alternative approach is to again start with a single CSP but rather adopt a multi-region strategy from the outset. This slightly increases the learning curve (read: agony) but encourages a multi-region mindset. Deliverables may manifest at a slower pace but already leverage the highest level of resiliency offered by the CSP.

Regardless of the strategy, bare in mind the management of regions in terms of data sovereignty constraints and data governance. It’s very easy to loose sight of regions and who’s using them for what. Let alone why.

Building out CSPs

If there are slight differences between regions within a single CSP, then there are noticeable differences between CSPs. As such, the decision of when and how to build out other CSPs has a significant impact on the overall delivery speed of the cloud programme.

Traditional approaches focus on a single CSP first and then build out other CSPs once the cloud programme has reached a certain level of maturity. Given the urgency of regulatory requirements, this may not always be possible. Plus, this approach may create an over-focus on a single CSP and lead to the impression that multi-cloud is merely a distant goal.

Simultaneous build-outs of multiple CSPs is the most ambitious approach. While it may seem like the direct route to the pre-defined outcome set by the regulators, this approach can run the risk of pushing the rate of change inside the organisation beyond a sustainable level.

Bridging CSP Gaps

No matter which or how many CSPs are eventually chosen, chances are that not all of them will have every single feature that the organisation relies upon. Naturally, this leaves gaps in the CSP offerings. And the question of how to bridge them.

An ideal outcome is for CSPs to bridge the gaps in their offerings themselves. This not only makes the features available to a broader audience but also moves expenditures and maintenance to the CSPs.

However, this approach either requires a strong working relationship with the CSPs, a concerted effort of other organisations requesting identical features, or simply the willingness to reimburse the CSPs for their expenses.

Until gaps in the CSP offerings are eventually bridged, work-arounds can provide a temporary solution. However,

Building a temporary solution to bridge a CSP gap should always be a last resort.

Temporary work-arounds for CSP gaps should be clearly captured as high risk items in the programme documentation as they entails unforeseen risks and costs. Let alone a predictable timeframe or realistic exit strategy.

Buying versus Building

Gaps in the CSP offerings created by specific requirements, such as from enterprise organisations, are actually attractive markets for third party providers. This is especially true for solutions in the cybersecurity, compliance, and audit realm to only name a few.

There sometimes is a perception that an organisation’s requirements cannot be met with available commercial offerings. This often leads to in-house build-outs of highly specialised solutions. That, once delivered, satisfy a need that may no longer exist or has been satisfied by a commercial offering in the meantime. With the organisation left to maintain the solution.

Focussing on what not to build should actually be a priority. Before building anything, the bigger question should always be

Which business are you really in?!

Buying commoditised solutions for the cloud makes economical sense as they often offer a lower total cost of ownership (in short: TCO) over their targeted lifespan.

Missing features can be added. Sometime with a complimentary solution. Sometimes by simply reimbursing the experts for their expenses. It does’t hurt to ask.

Getting Into the Details

Find out more about it in the next article.

So, How Do You Determine the Build-Out Principles?!

While the above Worx for Me!™ when it comes to determining the build-out principles for cloud, you may have an alternative or better way.

Think this is all rubbish, massively overrated, or generally heading into the absolutely wrong direction?! Feel free to reach out to me on LinkedIn and teach me something new!

As always, prove me wrong and I’ll buy you a pint!