I’ve blogged a lot about my definition of DevOps and what it means to me.
I’ve always thought it much larger than “Dev” and “Ops” and that there isn’t really an end state – it’s an ever changing idea that will adapt to meet the needs of the business.
That said, I’m asked quite often what “good” looks like? How do you know you are on the right path?
For me DevOps is a primarily a cultural idea. If the culture is right then the technology and people will follow. I talk to a lot of people who see this word “DevOps” and reach out straight to technology. DevOps isn’t another word for automating Cloud servers…
In order to an effective “DevOps” organisation I think you need 4 main pillars:
- Culture – does the culture of your company promote collaboration, self improvement etc?
- Process – you need to have processes that support different silo’s working together to achieve a fast pace of change
- People – if you don’t have the right people then it doesn’t matter how great your technology is. People and culture are very linked but I’ve tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
- Technology – what are the building blocks you need to be a mature DevOps enterprise?
The following is very much my view of what “utopia” looks like. The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve. For example, you absolutely don’t need to use public Cloud to achieve DevOps. However, I do think it’s a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.
This is where I want my company to get to…
Culture
- Measure everything, always
- Individuals have empathy for the rest of the team (i.e. they don’t pass the buck)
- Shared goals and incentives
- Don’t reward the fire fighter, reward the fire preventer
- Reward innovation and challenging the status quo
- Don’t punish people when they try something new but fail
- There is no IT and “business”. IT as much “the business” as the sales people.
- Seeking to break down silo’s
- “It’s not my job” doesn’t exist
- “Its my server/code/network/database” doesn’t exist
- Individuals are empowered to make decisions
- Top-up management rather than top-down
People
- Restlessnes (relentlessly looking to improve themselves, others, processes etc)
- Good technical ability across a broad skill set (understand as much of other people’s jobs as possible)
- Everyone can code and use version control
- Everyone understands the test triangle
- Dev-test pairing
- Organised in small product focused teams rather than technology silo’s (align teams to the business not the technology)
- Common incentive schemes
- Favour automation and repeatability above anything else
- CIO/CTO are DevOps biggest guardians & SME’s and seek to destroy anything that affects that culture
- Natural face-to-face influencers rather than endless emailers
- Natural sharers of information
- Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)
Process
- Agile
- Continuous Integration
- Continuous Delivery
- Lean
- Fail-early, fail often
- Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
- All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
- Knowledge sharing and “just enough” documentation is part of the process
- Measuring success and failure is part of the process
- Retrospectives are part of the process
Technology
- TDD/BDD everything (including Puppet etc)
- Everything is in version control (code, automated tests, server config etc)
- Release automation tooling
- Convergent desired state tooling
- Cloud (private or public but the ability to spin servers up on demand)
- The same trending, monitoring & alerting solutions available through nonprod & prod
- Application Performance Management
- Service Virtualisation
- Continuous Integration
- Continuous Unit tests
- Continuous Service level tests
- Continuous GUI tests
- Performance testing
If you can get half way to delivering all of that then I think you should be in a very good place indeed.
It’s a long hard journey if you are a traditional Enterprise. Nothing worth achieving was ever easy though!
I’m outta here for what proved a fantastically successful 2014 (personally and work). 2015 is a massive year too for me but good luck in whatever you have planned ahead.
Happy New Year to you all!
J
xx
