Wednesday, July 19, 2017

Enterprise Cloud Strategy Part 2 - Experimentation

So far in our tour of Microsoft's Enterprise Cloud Strategy Book, we've discussed the 5 R's as a methodology for deciding how to "modernize" your applications.  The next section of this book discusses three common steps to a cloud migration and then focuses on the concept of experimentation.

What is experimentation in this context?

In the context of the book, the authors describe experimentation as a key step to cloud adoption.  In this step, "the engineers and others create the IT department's first cloud applications, with the objective of learning what the cloud is all about...".  The goal, of course, is to give IT the opportunity to learn about the cloud and the various aspects of building applications that live in the cloud.  One interesting aspect is how the book defines the principles of "a culture of experimentation".


My Thoughts

In my opinion, safe to fail experiments are key to the success of any projects in IT.  While I'd like to think that cloud computing does not meet the traditional definition of a complex system, the act of designing solutions in the cloud can be extremely difficult.  Moving business targets, ever-changing cloud capability landscape, and endless possible effective solutions decrease the predictability of design outcomes for similar projects.  Safe to fail experiments are key to testing out architectures that push the boundaries of the cloud platform, make use of the latest enhancements/improvements, and provide targeted feedback for lessons learned.

The second point I'd like to make is that the book makes mention of experimentation as a first step to an organization adopting the cloud.  I would argue that this is an important step not only in the initial phases of an overall roadmap, but also important for every single project that is in scope.  When I am working with my clients, I always push for a proof of concept phase as part of a cloud migration. What this allows us to do is:

  • Put an appropriate amount of design work in, without having to define everything up front
  • Experiment/test with multiple architectures to test for best fit
  • Put focus on delivering repeatable steps via automation
This type of approach has many benefits in my mind.  Firstly, proof of concept phases can be treated as safe-to-fail experiments, allowing the delivery teams flexibility in approach and output.  Proof of concept phases are short in duration, which allow for quick iteration on target architectures.  The focus on automation not only increases the velocity of future work, it supports a more agile delivery approach.  From a business perspective, proof of concept phases help drive down uncertainty/risk in the rest of the project delivery, while increasing the accuracy of estimates around time and effort for project completion.

In conclusion, I'm a big believer of experimentation as an important aspect of project delivery, big or small.  In the context of the book, experimentation is a phase where IT is given the chance to learn more about the various aspects of the cloud and how to run applications within it.  It fits well with a "crawl,walk,run" approach, and one that can pay dividends in the long run.  My addition would be that experimentation is not only fit for the start of a cloud journey, but also fit for every project within that program.