May 15, 2019 A Cloud-Native Transformation Primer. Part 1: It's obvious, until it isn't.
An OODA loop, credited to USAF Colonel John Boyd is an action oriented cycle for mission delivery. It stands for observe–orient–decide–act. I was introduced to the concept a few years ago, and I've become very familiar with the response I get when I share it with others. The very same response I had when told of it. "But isn't that obvious?" The response I want to give when challenged, though I've yet to speak it out loud, "If it's so obvious, then why aren't you doing it?"
But it is obvious, so obvious that humans do it thousands of times every day. Something as simple as coming to a red-light on the highway involves this process. But as interactions with the outside world get more complicated it breaks down, we observe too much, or too little, we orient with emotion instead of logic, decisions are made under duress, and actions fail to address the systemic issues they were meant to alleviate.
Cloud Native transformation is not a one-size fit all process. What the cloud is, where the cloud is, and how the cloud is, can be very personal to the organization looking to make the leap. Organizations often fail to perform the full OODA analysis before choosing a platform, and a firm (like Stark & Wayne) to help them make the leap.
Clients often come to Stark & Wayne knowing they want to move to Cloud Foundry, or Kubernetes, to another platform, or to roll their own solution. In a perfect world you'll get help on this journey before deciding on a destination and be open to a full guided OODA cycle before finding your azimuth.
Large scale organizational change is often painful. Cloud Native transformation as a process is more than just the latest technical word salad to come out of the Silicon Valley. It is a package of decades of processes, change management, software development lifecycle best practices, and modern deployment paradigms. Most organizations have already chosen a-la-carte which of these practices to follow. Some have chosen poorly, and a successful transformation should always start with a sober review of institutional mythology, current process, and entrenched assumptions.
So we go through our decision cycle and point our organizations at a target solution. But the change required must flow all the way up and down the stack. We strive to continuously deliver and patch the cloud platform, the same way we continuously deliver the applications and services that run on it. We must advocate for the adherence or understanding of these practices with every team that supports the chosen solution. Each of those teams must perform their own OODA cycle to decide how to best support the transformation.
The OODA cycle is recursive. We make high level decisions, create epics, build stories and a backlog that pushes short, and manageable sprints. An organization looking to make this transformation needs to understand that agility, and self-evaluation are first class citizens of the process. Do not be afraid to make a decision, do not be afraid to change course when that decision has flaws. Fail thoughtfully knowing you can identify solutions and implement quickly; rinse, and repeat.