Build cloud products as Minimum Cloud Products. Balance customer requirements and organisational reality. Supercharge your journey to the cloud!

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
   8. Iteratively Building the Delivery Pipeline
   9. Iteratively Executing the Delivery Pipeline
      1. Key Achievements
      2. Preparing the Iterations
      3. Delivering Minimum Cloud Products
         1. Defining Minimum Cloud Products
            1. Minimum Viable Products and Dependency Chains
            2. Minimum Cloud Products
         2. Building and Using McPs
         3. Reviewing, Repeating, and Retiring McPs
      4. Recording Outcomes: The Cloud Runbooks and the Cloud Reflections
4. A Cloudy Future

Delivering Minimum Cloud Products

The iterative delivery of prolonged cloud products should be well established by now. However, an exact definition of the products that captures all objectives and allows to subsequently build, use, retire, and review them is still missing.

Defining Minimum Cloud Products

The definition of an iterative cloud product needs to provide the right drivers for its build-out. Yet at the same time be both simple and capture the multi-dimensional complexity.

Minimum Viable Products and Dependency Chains

A concept widely accepted throughout industries for the iterative delivery of products are minimum viable products (in short: MVPs).

“An MVP is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.”

By definition, an MVP is exclusively focussed on the needs and demands of the eventual customers. It is customer centric and customer facing. An MVP essentially provides a vision. Prerequisites, dependencies, or details are only implicitly defined.

Especially in the cloud programme, this intense focus on end user features somewhat obfuscates the need to resolve implicitly defined prerequisites or dependencies beforehand. Let alone implement non-customer facing changes that are part of broader objectives.

Now, cloud products can have quite deep and complex dependency chains. The sole use of MVPs can therefore lead to problems. Symptoms are usually excessively long or oversimplified MVP definitions open to interpretation.

Similar to an iceberg, an MVP only provides the visible customer facing functionality above the water line. All dependencies are then hidden below. But like an iceberg, only delivering the MVP functionality and neglecting the dependencies will not make the MVP float. Much rather, it will sink to the point where it can support itself again, sacrificing functionality along the way.

However, the unavoidable stretch of working through mandatory non-customer facing features can also create the perception of little to no visible (read: end user facing) progress being made during that time. This is even more problematic in organisations used to working with MVPs.

Minimum Cloud Products

The concept of Minimum cloud Products (in short: McPs, deliberately written as such so that they can be pronounced as “MacPs”) aims to resolve the above problems. It intends to strikes a balance between customer facing features, underlying dependencies, and broader objectives.

McPs keep the customer focussed lean approach towards features of the MVP while aligning it with broader objectives and combining them with the corporate reality of complex dependency chains.

For a cloud product, the corresponding McP then consists of

1. The minimal product specific customer facing offering, captured as an MVP. This is the primary driver.
2. The minimal product specific organisation facing offering, again captured as an MVP. This is the secondary driver.
3. The underlying dependencies that are necessary preliminaries to deliver the primary and secondary drivers. This includes a fixed set of readily available implementations of
   1. All technology dependencies such as, but not limited to, compute, network, storage, IAM/PAM, logging and monitoring, asset tracking, toolchain, secrets management, vaulting, configuration management, service meshes, and many more
   2. All process related dependencies such as, but not limited to sourcing, legal, engineering, operations, support, audit, compliance, and many more
   3. All business related dependencies where changes to the business operations, as a result of moving to cloud, need to be identified, agreed, and signed off beforehand

Condensed into a few sentences, a vastly over-simplified definition of a McP for an organisation with the objective of leveraging corporate services could be

“My customers can access a minimum set of services I provide in the cloud. For that, I need to deploy my application, monitor it, support it, and have an audit trail of all actions performed. This is achieved by leveraging corporate services.”

McPs are a means to an end when it comes to balancing the need for delivering business value with the programme’s and organisation’s objectives of delivering a compliant enterprise grade cloud platform.

Moreover, McPs allow to clearly track progress along a well-defined trajectory that delivers on the minimum features required by early adopters. A McP is always customer facing. All other intermediate “deliverables” are milestones on the road to the customer facing MVP.

Building and Using McPs

While the design of a McP is top-down, its build-out is bottom-up, time boxed, and incremental.

Natural starting points for any build-out are those components of a McP that do not have a dependency on others. Note that this especially includes the ends of dependency chains.

Starting with the cloud platform allows to first build out basic shared capabilities. By design of the prioritised delivery pipeline, these capabilities are required by almost every succeeding McP.

Features specific to the McP can then be delivered on top of the cloud platform. In combination with updating or creating all required processes, this eventually leads to delivering the overall McP. Note that

This approach not only delivers McPs but also provisions the broader enterprise grade cloud platform with just the necessary capabilities.

As a side product. Through the delivery of McPs.

Once a McP is delivered, it should be stress tested over a time-boxed window to identify any gaps in functional or non-functional requirements. Operating on the cloud then also allows to gather hard data on metrics such as application performance, environmental parameters, operational processes, maturity, stability, and many more.

The general approach also lends itself well to continuously testing the viability of delivered McPs, or components thereof, through daily use; commonly referred to as “drinking your own Champagne” (or “eating your own dog food” — the choice is all yours). An example of this is the toolchain which can be used to build, test, and deploy itself.

Automation, continuous testing, and repeatability can be further increased during this phase by tearing parts of the environment down on a daily base and re-building it from scratch. However, this should be done with care in order to avoid disruption for incompatible areas.

Reviewing, Repeating, and Retiring McPs

McPs iterations are time bound manifestations of an incremental experiment. The end of one iteration marks the beginning of the next one. This sequence is repeated until a satisfactory outcome is reached.

A cornerstone for continuous improvement in the sequence is the retrospective at the end of each iteration. It captures what went well and what can be improved in the next one.

The lessons learned in one iteration drive improvements in the next one.

However, in the spirit of “Murder Your Darlings”, and in order to avoid uncontrolled sprawl,

After completing a McP iteration, exit and retire all previous ones.

The resulting rolling window of at most two active iterations allows to retain the previous iteration until the current one is completed. This not only provides business continuity but also avoids the burden of having to maintain past experiments. Thus, freeing up and concentrating the limited resources of the cloud programme on future McPs.

With McPs iterations also freeing up other resources, this is a great opportunity (read: obligation) to turn those assets off. Not only does this ensure compliant technology governance but also for the cloud programme to finally realise some of the potentially anticipated benefits.

This iterative and incremental McP delivery process may be prolonged and require multiple iterations before the outcome is satisfactory. If you do get it right the first time — please reach out to me on LinkedIn and teach me something new! I’d love to hear from you! As always, prove me wrong and I’ll buy you a pint!

Recording Outcomes: The Cloud Runbooks and the Cloud Reflections

Find out more about it in the next article.

So, How Do You Deliver Cloud Products?!

While the above Worx for Me!™ when it comes to delivering cloud products as McPs, 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!