DevOps transformation is in heavy demand. Funny enough, the approaches applied at companies are as diverse as they are inconsistent.
The book DevOps for the Modern Enterprise from our very own Mirco Hering, is an opportunity to align our understanding.
My first impression is that Mirco gives the reader a view on how to start and run a transformation journey, via three important elements, and demonstrates practices that you could use. He also answers common questions and concerns enterprises might have.
The topics raised, have relevance and fit in their scope. However, knowledge workers (developers) who must live in this DevOps environment will have different concerns—which are only touched on briefly.
The book doesn’t need to display a concise, holistic, trademarked framework. It’s more a handbook than a method. Those looking for a quick win to apply in their contexts, might find themselves overwhelmed.
Here are a few interesting takeaways from the book:
I don’t want to partake in the game "stick as many abbreviations together" e.g. DevSecOps, BizDevOps, NoOps. However, there’s value to juxtapose customers –> wanting flexibility against Development –> wanting change and Operations –> wanting stability.
It provides further confirmation of value stream mapping to form the transformation roadmap as first steps in the transformation journey.
It includes baseline metrics that work well in a DevOps transformation, like regression duration, release cycle time and team longevity.
Speed to release value is the single most important indicator of success; other indicators like quality, efficiency, costs improve inherently when you focus on speed.
When you need to scope the transformation, you’d want to spend effort on transforming value generating systems, and none on systems that don’t. The application radar in which you position your systems as true legacy, workhorses, and innovation engines, helps you visualize that.
Four key architecture maturity principles include auto-scaling, self-healing, monitoring and capability for change.
The four phases of delivery (exploration and refinement, sprint delivery, readiness/hardening, support/warranty) are outlined in relationship to contracts and compensation.
The book provides a very interesting take on a common discussion whether to invest in automation and higher skill levels to replace cheap labor and repetitive work. The crux of the argument is that automation in the long run always leads to lower total cost.
It includes an interesting take on scenarios for distributing or co-locating Agile teams, taking factors like single- or multi-vendor, and technology stack into account.
It covers delivery models: delivery through Continuous Integration, Cloud-delivery, Container-delivery and Server-less delivery.
It suggests measuring internal culture with Net Promoter Score.
You should probably Google the following though:
Site reliability engineering
Test automation pyramid
I still don’t believe "DevOps" is a next growth stage after "Agile", or "Lean" the next stage after "DevOps". It implies Agile needs to be tackled first, before DevOps can be tackled, before Lean can be tackled. Maybe the transformation approach is a case of placing emphasis, first on alignment, then on integration, then on value.