Five years ago, I wrote “Cloud Native Transformation: Practical Patterns for Innovation” ​​ drawing from my 5 years in Cloud Native consulting and over 2 decades in IT. The book’s core message was that Cloud Native—defined then as containers, microservices, and dynamic scheduling—was a transformative business change. It wasn’t just new tools, but a shift from monolithic to distributed systems. Conway’s Law dictated that this architectural change necessitated an organizational one.

The need for a Cloud Native approach traced back to the DotCom boom. The Internet expanded customer reach, and businesses could serve customers from their servers instead of shipping software. Giants like Google and Amazon, unable to scale vertically, embraced distributed computing and horizontal scaling. Their success and the growth of online activity led others to adopt Cloud Native technologies. Traditional businesses, however, had to adapt their ways of working. “Cloud Native Transformation” aimed to guide them through this journey.

Successful transformations begin with research and experimentation by a small, experienced group. They need freedom, resources, and leadership support to navigate by trial and error. As they move from PoCs to an MVP, the team expands, and structure emerges. Documentation and onboarding processes are created, and legacy systems and teams migrate to the new setup. This process typically takes 2-5 years. The book detailed practices for the transformation: MVP creation, team management, Agile methodology, etc. It also suggested that as systems mature, teams shift from agility to quality, stability, and operational efficiency. This mirrors what we’ve seen at Google and other tech giants as they introduced platforms, SRE, DORA metrics, and other tools and processes.

Five years ago, we understood the monolithic waterfall systems and we had a good idea on how to transform them, but the mature Cloud Native systems were defined less clearly. We focused on change-oriented concepts like DevOps and Agile and mostly were busy with breaking the old order before the new one was created.

Now, we see many examples of mature Cloud Native systems. Containerized, dynamically scheduled microservices are still central, alongside a move to platforms, Continuous Delivery, Team Topologies, and an operational metrics-driven approach (SRE, DORA). We see a shift from Agile to Lean. From adjustability to operational excellence. Every organization moving towards Cloud Native follows a typical project lifecycle: Research, Transformation and ongoing Operations.

Each phase requires a different technical approach, people management and overall organizational structure.

• Horizon 3 - Research: Experimentation and exploration. Random ideation, small experiments, freedom, creativity. Separate sandbox, small team. The goal is to find new ideas and learn.
• Horizon 2 - Transformation: An agile and often challenging phase where the organization adapts by iteratively introducing new Cloud Native elements, starting small and scaling up while establishing order. This process, divided into Development, Introduction, and Growth stages, should only be undertaken with a clear business justification and a focus on minimizing disruption through swift and efficient execution. The ultimate goal is not change itself, but the creation of a superior Cloud Native system that delivers tangible business value.
• Horizon 1 - Operational: Reduce change, focus on operational excellence. Exploratory experiments are done, the organization is a well-oiled machine. Efficient, resilient systems. Teams are stable, well-structured, and aligned with architecture following Conway’s law. Not Agile, but Lean, like the original Toyota Production System. Aims for high velocity of value delivery and low cost through automation, high quality, and well-defined processes.

The “Cloud Native Transformation” book stopped at the transformation phase. It didn’t define the mature target state, where a healthy organization aims to spend most of its efforts: operational excellence.

In conclusion, the journey to Cloud Native maturity goes beyond transformation. It’s about reaching a state of operational excellence where the focus shifts from constant change to stability, efficiency, and delivering value at scale.

P.S. This is the first post in a series about Cloud Native Maturity. In the following posts, I will discuss the Cloud Native Platforms, methodologies, team structures and more. The goal is to lay out the target for a successfully finished Cloud Native Transformation and prepare for the next transformation likely to be driven by AI.

Need help with Cloud Native or AI Platforms? Reach out for a Maturity Assessment