DevOps is about sharing! Sharing is an important part of the success behind the Open Source development movement that has seen such an increase in the software industry for the past 10-15 years. The sole foundation of the Open Source model is to add your piece to the puzzle (in this case software) and share your additions with the rest of the community.
After having worked for a company that focus on implementation and development of Open Source software for close to 15 years, it makes me happy that this is also one of the foundations of the CAMS model for DevOps. As described in previous blog posts on this topic, DevOps is mostly about setting the framework to enable an improved cooperation between the previous Development and Operations departments. It is there to remove silo thinking and tear down barriers in order to improve efficiency.
Once this is done and prestige can be put aside, hopefully we will realize that we have a lot to learn from each other and by start sharing experiences and knowledge we will be able to withdraw the real benefits from DevOps thinking and increase efficiency in key processes like ”From commit to deploy”. This is why the ”S” is the last piece of the CAMS model and the thing that makes all your pieces fit together.
S for Sharing
When your DevOps initiative is rolling and it is time to scale up in accordance with the ”Think Big – Act Small – Scale Fast” approach described in earlier blog posts, it is very important to establish a culture of sharing. This implies everything like tooling, methods, knowledge, procedures and data. If you follow our recommendation on acting small and then scaling up, it will of course be important to share the potential success of the initial team work, but it will be equally important to share failures as well. This is of course to repeat successes and avoid repeating failures.
It also has a lot to do with the Culture part of the DevOps Ready model. To establish a culture of sharing, trust and involvement is a very important part of a successful DevOps initiative. For me, trust comes from involving people and sharing important information. That is why sharing is important and a factor that you can affect, since you can always force people to share things, but not force them to trust you.
With this said, there are different ways and views on how sharing can be done. An easy starting point is to start with the basics. Here are a few examples on what can and should normally be shared in a successful DevOps initiative:
Tooling
What toolings have been used and how did they perform? Which tools worked and which did not for whatever reason? This is normally not controversial at all and will probably be shared already from the beginning as an output from early adopters/teams in your initiative.
Procedures and methods
This is normally also something that will be shared in an early stage. How to work with continous integration and version control? How to establish an efficient pipeline and feed back information from operations to development and vice versa? This is normally also non controversial, but there might be some elements of resistance against sharing failures.
Data
One of the objectives of a DevOps initiative is to remove silos in your organisation. Silos have in the past worked as efficient barriers for not collaborating and sharing data. It has often also fed a view of ”if it didn’t happen here, it is not our problem”. Not seldom have different parts (meaning Development and Operations) of the organisation used an ”information advantage” to prove their point and defend the position that ”it is not our problem or we are not the root cause of this”. By sharing data across the organisation we can really address problems at their core, which should reduce error and incident resolve times.
Organisation sharing
The last part of information that should be shared, is that of data to share to the rest of the organisation. My view on this is that the important metrics that have been identified, targeted and hopefully verified earlier in the process, should be communicated to the rest of the organisation (at least Management).
Sharing progress on how a DevOps initiative can potentially improve metrics like the ”From commit to deploy”, ”Deployment frequency” and ”Mean time to recover” indicators create an extra edge to the initiative, create on opportunity to show real value from and hopefully also a sense of pride and involvement from your DevOps teams/organisation. In general I don’t think we should be afraid of sharing this kind of information to the rest of the organisation, but rather view it as an extra challenge and opportunity to highlight the work of IT.
To sum up the four bullets above, I would like to call for all DevOps initiatives to ”Dare to Share”, firstly with your close colleagues but also with the rest of the organisation. To create a sharing culture is part of the core for a successful DevOps implementation, but can also be used to increase organisational knowledge on the work that is actually done in the IT department (a challenge that can be extended to other departments as well – if they dare).
Final words
This was the last in our series of blog posts to introduce the Redpill Linpro DevOps Ready through CAMS model.
As mentioned at the start of this blog post series, organisations of today are faced with a lot of challenges and even though noone really knows what the future will bring and who will be successful in the coming years, one thing is for sure – a constant change will be required. It is our strong belief that a DevOps oriented approach to this demand for change (at least from an IT perspective) will be crucial to success. We believe that the CAMS model (initially coined by Damon Edwards and John Willis) constitutes the best overall approach to DevOps and covers both the adequate generic and detailed perspectives on DevOps.
This is why we decided to base the Redpill Linpro DevOps model on this acronym. I hope that these blog posts, our e-book and DevOps Ready guide will give you valuable insights to your own DevOps initiative.
Good Luck!
Previous blog posts in the series
