It seems like DevOps is absolutely everywhere now. Pretty much every company is talking about it – even if they are not ready to explore it yet. In this DevOps adoption frenzy, it is inevitable that some of the core principles of DevOps (what it is, how it adds value to your business, etc.) will get watered down. When DevOps is mandated, the word itself becomes overused and the core message can get lost.
What DevOps is NOT
I would like to share with you a few of my thoughts on what DevOps is NOT. Hopefully this will help you to keep focused on the primary message of DevOps and result in better ROI throughout your journey.
1. It is not an end goal.
There is no logical end state to DevOps as each organisation is operating in an evolving customer market. For businesses to stay competitive, they need to grow and change. DevOps is a great way to make your business more agile and seize opportunities, but tools and processes will always need to change and improve to remain fit for purpose.
2. It is not a body of knowledge.
There is no “right way” to implement DevOps in your organisation. DevOps provides the principles and highlights the goal – Business Value – which everyone should focus on. Each organisation has different challenges and takes a different path along their DevOps journey, which can all be valid.
3. A DevOps solution cannot be bought off the shelf from a vendor.
There are vendors now who are offering a full DevOps toolset, and that is great because the tools will likely integrate well together and can help to give you a joined up pipeline. However, just incorporating the tools does not mean that you are doing DevOps, it is just the first step. To really reap benefits of DevOps in the long term, you need to embrace collaboration and ensure that the tools you have chosen are fit for purpose and adding efficiency to your processes. It is very easy to use the right toolset in the wrong way, or simply to not get the maximum benefit out of it!
4. It is not sacrificing governance and compliance.
In fact, DevOps can be a real enabler for more efficient, more effective governance and compliance. The automation and streamlining processes which are part of DevOps help to focus the governance and compliance requirements and usually enable more thorough auditing.
5. It is not just automation.
If you have automated part of your delivery pipeline then that’s great, and its (probably) going to add value to your team, however there are so many aspects of DevOps which work with the automation to multiply the benefits. It is quite easy (and common) to have automated processes, but some of those processes will not have been streamlined and are actually wasteful / unnecessary. In cases like this, automation just hides the waste more effectively, but it is still there.
6. It is not just a toolset.
Using Jenkins to do CI is great, but that doesn’t mean that you have got DevOps. It’s a small part of a big journey, and you need to remember that continuous improvement is key to DevOps, so your CI strategy needs to evolve to make sure that you are continuing to meet your business goals and deliver for your teams. This means that stagnating with an embedded tool generally in not in line with DevOps.
7. It is not “using Cloud”.
Cloud is a great thing which has the power to transform your IT capability, but just using the cloud doesn’t mean that you are realising any of the potential benefits of proper DevOps.
8. It does not mean that anyone can release any change to production at any time.
Releases should be entirely in line with the business needs. Having a streamlined, highly automated delivery pipeline enables you to release changes quickly. Releases can then be easily aligned with business needs to provide maximum business value and reduce unnecessary work and wastage.
9. It is not a separate team or organisational unit.
DevOps, at its heart, is about removing silos not creating additional ones. Having a separate team to kick-start the process, come up with a strategy and adoption guidelines is a valid way of embarking on this journey. However, the “DevOps team” should be a short term measure with a view of dismantling the team once the goals have been defined and progress is being made across the organisation.
10. It is not combining the Development and Operations team and leaving it at that.
Real value won’t materialise unless changes are implemented in ways of working on the ground. A thorough and interesting article about how teams can be structured when embracing DevOps is featured on the DevOps Topologies website.
11. It is not replacing or removing Ops.
Similarly, DevOps does not mean that developers are suddenly responsible for supporting their own code in production. Operations do continue to have a very big role: they also take principles from DevOps to implement Lean practices, streamline their work tasks with an eye on business value, as well as automating tasks where appropriate. Successful DevOps means that the Dev and Ops teams have THE SAME BUSINESS GOALS. This is such an important point as traditionally the objectives of the Dev and Ops teams were at odds with each other, but they need to be aligned for the journey to be successful.
Summary
To finish on a positive note, let’s bear in mind the key things that DevOps IS:
It challenges the status quo.
By adopting a change in mindset, you are able to analyse what really adds value for your business. The pieces that are left over are simply waste.
It is a culture shift.
DevOps brings a culture shift that spreads across the whole organisation. It radically changes the way we work and engage with each other, to become more collaborative and responsive to change.
I hope this has helped your understanding of the DevOps principles and how they can improve your organisation.
Good luck on your journey!
Bronwyn Davies
Latest posts by Bronwyn Davies (see all)
- Winner! Unicom Most Innovative Project 2023 - 27th February 2023
- Sandhata Gini – Our internal chatbot - 1st February 2023
- Goodbye 2022 - 19th December 2022