Cloud Native Transformation: Practical Patterns for Innovation

the single most important metric for executives to focus on is time-to-value, which can be instrumented most easily as committing to deploy latency for each team. Many companies can’t innovate because they can’t get out of their own way, and short time-to-value (target less than a day) releases pent-up innovation from your teams. Third, there is fa

You can no longer be “just” a healthcare or financial services or retail enterprise: like it or not, realize it or not, all companies are now software companies.

teams are still not really in charge of what they are building; their authority is limited to how to build whatever they are assigned.

Risk reduction today is the ability to respond to sudden or unexpected changes in market conditions when you don’t have much notice, in time to meet or beat the competition. And you achieve this ability through strategy.

If you change your actions, you change your culture.

Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder, but they fail a lot. Half the time the thing doesn’t work properly. You wouldn’t trust what they build. They create ‘crazy’ ideas. Their type of innovation is what we call core research. They make future success possib

example, it is common to see a platform DevOps team in charge of building the cloud native platform, while site reliability engineering (SRE) or first-level support teams respond to incidents (and spend the rest of their time working on automation to prevent them from happening in the first place).

When experimentation becomes routine, the new is no longer to be feared. Innovation as a routine process is, after all, a core cloud native principle.

In our experience it takes two to three years to truly undergo a cloud native shift and adjust to this new way of working. After that, it takes five more years to truly internalize the change —