/ TMCPR: ITERATIVELY EXECUTING THE DELIVERY PIPELINE

Preparing the Iterations

Avoid friction and agony early on. Prepare your organisation that not every iteration necessarily delivers business value. That some iterations are more about enablement for later iterations.

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
      4. Recording Outcomes: The Cloud Runbooks and the Cloud Reflections
  4. A Cloudy Future

Preparing the Iterations

The overall approach to iteratively execute the delivery pipeline may not be new. However, the individual iterations might be and could thus use some additional preparations. Especially around the structure and type of deliverables. And the management of expectations.

Each iteration is small, time-bound, and incremental in complexity. It provides the bare minimum capabilities required by the current patterns and cloud compagnon applications in the delivery pipeline. As well as the capabilities required in the next few iterations.

By incrementally enabling capabilities in the cloud, each iteration thus “raises the bar” for what can be achieved on the cloud. This in return also means that there’s no real need for a “bar raiser application” as can sometimes be found in cloud programmes.

This phase especially is a balancing act between the broader objectives by the cloud programme or the organisation and immediately required cloud capabilities. This might result in the fact that

Some iterations are more about enablement for subsequent iterations than provisioning capabilities for the current patterns and cloud compagnon applications in the delivery pipeline.

Note that this also implies that iterations may not always provide business value. Their number should be limited. Nonetheless, their existence and impact should be taken into consideration upfront.

A common scenario is the provisioning of a shared logging and monitoring service in the cloud. Here, the service has previously been identified by the cloud programme as a cornerstone in becoming a fully compliant organisation.

The current patterns and cloud compagnon applications in the delivery pipeline may not have a hard dependency on the service as such. However, later ones do.

Moreover, migrating the current ones to a shared logging and monitoring service — once available — moves the organisation closer towards becoming a fully compliant organisation. Let alone standardise and simplify architectural patterns.

Delivering Minimum Cloud Products

Find out more about it in the next article.

So, How Do You Prepare the Iterations?!

While the above Worx for Me!™ when it comes to preparing the iterations, 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!

dominic

Dominic Dumrauf

An Enterprise Solution Architect by profession, an avid outdoor enthusiast by heart, and a passionate barista by choice. Still hunting that elusive perfect espresso.

Read More