Capture your delivery pipeline execution. The provisioning of an enterprise grade cloud platform. In the Cloud Runbooks. And the Cloud Reflections.
This article is part of the limited preview of the “The Missing Cloud Programme Roadmap”, a generic roadmap for any enterprise cloud adoption programme.
- Executive Summary
- The Cloud and Enterprises
- The Missing Cloud Programme Roadmap
- The Cloud Programme Roadmap
- The First Iteration of The Cloud Programme Roadmap
- The Unavoidable Disclaimer
- The Roadmap for The Missing Cloud Programme Roadmap
- The Manual for the Missing Manual
- Building the Business Case
- Starting the Cloud Programme
- Iteratively Building the Delivery Pipeline
- Iteratively Executing the Delivery Pipeline
- A Cloudy Future
Recording Outcomes: The Cloud Runbooks and the Cloud Reflections
The main objective of this phase was to iteratively define, build, test, and retire cloud products detailed in the delivery pipeline.
Moreover, this phase also focussed on exiting and decommissioning assets no longer required due to the move to the cloud while simultaneously keeping the rate of transformation at a sustainable level.
By now, patterns and cloud companion applications are delivered as McPs in incremental and time boxed iterations.
The data driven evaluation of each McP iteration permits realistic retrospectives and subsequent improvements in the next iteration. Exiting and retiring all previous iterations of a McP before starting a new one prevents the burden of having to support past experiments.
By leveraging synergies and prioritising the build-out of common cloud capabilities, the McPs are also the main drivers towards the creation of a suitable cloud platform.
A broader enterprise grade cloud platform with just the necessary capabilities for the patterns and cloud compagnon applications in the delivery pipeline is being provisioned through the use of McPs.
For each McP and iteration, all updates to processes or activities related to the support of the McP in the iteration need to be capture in the corresponding “Cloud Runbook” and subsequently made available to all involved parties. However, the document does not necessarily need to be printed, as frequent updates may be required, while the McP matures with use during the iteration.
For each McP and iteration, all definitions, frameworks, assessments, metrics, data points, decisions, and rationales used need to be captured in the corresponding “Cloud Reflections”, as described above.
Providing the details of the current iteration and the main drivers for the next one in the context of The Missing Cloud Programme Roadmap, the Cloud Reflections need to contain at minimum
- the definition of the McP
- the relative position and classification of the McP iteration in the delivery sequence
- the design and implementation strategy pursued in the iteration, including corresponding documentation
- metrics gathered during the build-out and testing phase
- processes that were created, changed, or removed due to the delivery of the McP iteration
- complications experienced during the iteration
- outcomes of retrospectives, especially the lessons learned
- exit strategy for all previous McPs iterations, including fixed sunset dates
- exit strategy for all assets freed up by the delivery of the McP iteration, including fixed decommissioning dates
- an assessment of the alignment of the results delivered by the McP iteration with the objectives of the cloud programme, including corrective actions for the next iteration
- key areas of improvements for the next iteration, including a preliminary draft of the next iteration
The Cloud Reflections are again to be published in print and distributed to all members of the programme — this step is pivotal. Not only does it impose a publication deadline on the programme but it also creates a solid point in time snapshot of the entire state of the programme.
Spending real money for publishing the document also increases its significance and importance. Let alone create a common understanding across the entire programme, document progress, as well as provide a physical part of the audit trail.
A Cloudy Future
Find out more about it in the next article.
So, How Do You Record Outcomes?!
While the above Worx for Me!™ when it comes to recording the outcomes of the phase iteratively executing the delivery pipeline, 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!
Subscribe to How Hard Can It Be?!
Get the latest posts by following our LinkedIn page