It’s been a long time since I did my last post: as promised, I only post information from my experience in the real world and I avoid echoing messages from marketing :-)
I’ve not been at rest, though, but I’ve worked at customer projects that can’t be mentioned publicly (yet).
But I’ve also been in vacation and I could finally read a great book, “The Phoenix Project”.
It is a novel and a very educational reading at the same time.
I wholehearted recommend you to read it (though I’m not earning anything from the book) because I enjoied it a lot and I learned important lessons that deserve to be spread - for our common benefit as IT community.
You are not required to be a IT professional but, if you are, you will benefit the most and it will recall many familiar stories.
Since I’ve led some mission critical projects, and my skin is still impressed with both tragedy and triumph, this story reminded me those great moments.
If you are new to DevOps, you can read my introductory posts in this blog.
Essentially, The Phoenix Project describes the evolution of IT in a company that, on the verge of a complete failure, pioneers DevOps and revolutionizes the way they work.
The impact on the core business is huge and their strategy creates a gap with the competition thanks to agility and flexibility.
Also personal lives are affected because the new organization ends the tribal war among Development, Operations, Security and the business stakeholders: they establish respect, trust and satisfaction for all the involved parties.
Of course the DevOps methodology is not a magic wand that makes the miracle for them: it is the outcome of a new way of thinking and working together.
This is a story of people, rather that technology.
If every IT department put themselves in the shoes of the others, instead of finger pointing, they can help each other to reach a common goal.
If the whole IT is not a counterpart of the LOBs but is a partner (understanding why they are asked something instead of focusing on how to do it), they can offer a huge value to the company… and be highly rewarded (see the coup de théâtre at the end of the story).
This would stop the “dysfunctional marriage” between two parties that don’t understand each other and suffer from a forced relationship.
In my experience, most of the business people see the IT as the provider of a services that is never satisfactory.
On the other side, IT sees that business people don’t understand the complexity and the effort required and ask for impossible things.
In most cases, they are bound to a traditional way of working and don’t even raise their head to see that they already own what’s needed to win.
They are overwhelmed by current tasks, troubleshooting and budget cuts, so they can’t think strategically.
The great idea, here, is importing the concepts and the experience from Lean Manufacturing into IT.
They start considering the IT organization similar to a production plant and optimizing its organization.
Finding bottlenecks and avoiding rework are the first steps, then automation follows to free the smart guys from the routine work and so the quality skyrockets.
At the end of the story the release of new features required by the business no longer takes months (and high risk at the roll out) but they can deploy 10 project builds per day!
That is not impressing if you think that these days some companies achieve 1000s of deployments per day thanks to Continuos Integration and Continuous Deployment.
But it is light years ahead of what most of my customers are doing, though some are exploring DevOps now.
Of course, one organization cannot change overnight.
You shouldn’t see the adoption of DevOps as a single step, and be scared by the effort.
In the book, they learn gradually and improve accordingly: you could do the same.
They go through a process that is made of Three Ways, until they master all.
A brief description of the three ways follows, thanks to Richard Campbell:
A brief description of the three ways follows, thanks to Richard Campbell:
The First Way – Systems Thinking
• Understand the entire flow of work
• Seek to increase the flow of work
• Stop problems early and often – Don’t let them flow downstream
• Keep everyone thinking globally
• Deeply understand your systems
First Way Goals
• One source of truth – Code, environment and configuration in one place
• Consistent release process – Automation is essential (one click)
• Decrease cycle times, Faster release cadence
The Second Way – Feedback Loops
• Understand and respond to the needs of all customers (internal and external)
• Shorten and amplify all feedback loops
• With feedback comes quality
Second Way Goals
• Defects and performance issues fixed faster
• Ops and InfoSec user stories appear as part of the application
• Everyone is communicating better
• More work getting done
The Third Way – Synergy
• Consistent process and effective feedback result in agility
• Now use that agility to experiment
• You only learn from failure – So fail often, but recover quickly
Third Way Goals
• Ability to anticipate, even define new business needs through visibility in the systems
• Ability to test and optimize new business opportunities in the system while managing risk
• Joy
You should not think that The Phoenix Project is a technical book: though I’ve learned new things or reinforced concepts I knew already, the value I found in it is motivational.
It really moves you to action, and you want to measure the immediate improvement you can get.
More, you want to partner with other stakeholders to achieve common goals.
The Essence of DevOps
• Better Software, Faster
• Pride in the Software You Build and Operate
• Ability to Identify, Respond and Improve Business Needs
My final take from this story is that everybody in the IT (like in other fields) should:
- take risk and innovate - if you fail, probably the result would not be worse than staying still
- invest time - at cost of delaying important targets - to think strategically: the return will overpay the effort
- study what others have done already: learning by examples is much easier
- always try to understand your counterpart before fighting by principle, there could be a common advantage if you shift your perspective
Some useful references:
Amazon - http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592
R. Campbell's presentation - http://techdays.org/wp-content/uploads/2013/05/Essence-of-DevOps.pptx
Other DevOps books: R. Campbell's presentation - http://techdays.org/wp-content/uploads/2013/05/Essence-of-DevOps.pptx
- Visible Ops Handbook (Gene Kim)
- Web Operations (Allspaw/Robbins)
- Continuous Delivery (Humble/Farley)
- Lean Startup (Eric Reis)
