Effective utilisation of technology, adaptive business strategies and increased quality across the organisation come hand in hand with a DevOps approach. Discover how a DevOps approach can help your organisation bring the tools together to build systems that underpin your business.
DevOps, DevOps, DevOps…
The technology sector is awash with the term at the moment, and as with most terms that the sector get hold of, it is commonly bandied about with scant regard for what it implies. What is DevOps? How do you know you need it? What benefit will it produce for your business?
What is DevOps?
The first thing to understand is that there is no specific definition for DevOps. It isn't a well-defined approach or set of rules you can employ or standardise. All that is apparent is that it is a "movement" away from the traditional culture of operating a technology business, the amalgamation of the historic concerns of software development and technical operations.
Commonly, people hear the term DevOps and instantly think "Ah! I know, let's use Docker, Vagrant, Lumberjack, Puppet, Chef, AWS, etc., it'll totally revolutionise our systems.”
The point of the DevOps approach is missed entirely and failure could be looming.
The technologies mentioned above are all tools. Just as computers are tools, networks are tools, and software is comprised of and creates tools. Even the technical staff and the skills they possess are fundamentally tools. Project management methodologies are... you get the idea! DevOps is not about what tools you use, but how your organisation adapts to bring the tools together in building systems that underpin your business.
To improve the manner in which your organisation utilises its tools is at the heart of the DevOps culture, through increasing empowerment of the employees and promoting a technically innovative culture. Teams that would otherwise have been battling against one another can instead work collaboratively, sharing information, responsibilities and ideas. Communication with the rest of the business is also a focus, where originally it would have been a battle to understand the impact of a technical strategy from those who implement it, as the technical teams can work together to communicate more effectively and in unison.
How do you know you need it?
This is the easiest question to answer based on the answers to three questions:
1. How much time do you spend fixing issues within your organisation?
2. Do your technical staff collaborate across teams?
3. Do your technical staff innovate to meet requirements?
These questions may sound strange, but they're a good indication of the culture operating under the hood of an organisation’s technical teams. Let me explain the psychology behind the answers:
1. Be it a Managed Service Provider, software house or multinational corporate, the fundamental KPI for forward momentum in technology is the ratio of time spent solving existing issues to the time spent on features / new requirements / systems integration. The more time your key technical teams spend fixing issues is the more time they may breed resentment and frustration towards the business for not being able to move things forward.
2. Poor communication can be common amongst technical teams and the booting around of responsibilities between teams can be another key indicator of problems. If ownership of issues / development actions transfer a lot, chances are you've got a set of siloed technical teams who each feel that the others need more work. This can be a genuine waste as they battle to relinquish responsibility and achieve nothing.
3. This is not the most obvious question to answer - how do you measure levels of innovation? In reality it's easy to identify: do you experience the same, or similar issues over and over again? Do your technical staff produce new solutions to problems that help not only your organisation, but the technical community at large? If the answer to the identifications is ‘yes’ and ‘no’, respectively, your technical staff may not be innovative and are doing the bare minimum to get past the humps in the road, without ever fixing the humps themselves. This lack of innovation is quite commonly a product of the previous problems, but is always a sign of technical staff not feeling empowered to make a difference.
If the answers you get to these questions are undesirable (we spend all our time firefighting, nobody steps outside their team and nobody innovates technologically) then you've probably got an unhappy, unrewarding technical culture within your business. You need to employ a new culture to add value for your technical staff, or else you WILL lose them.
What benefit will it produce for your business?
One statement is the key benefit: effective utilisation of technology.
From a practical perspective, a DevOps approach will break down the organisational hindrances where they occur. If something within the organisation does not work, empowering your staff to overcome the problems rather than insisting that process is followed should result in a better process in the long run. This is where DevOps sits nicely alongside Agile, Prince2 and ITIL approaches that get adopted in various technical organisations. Where these approaches are tools defining processes that can be utilised in achieving results, DevOps is a mindset that allows these tools to be adapted based on their effectiveness. It is a breakdown of the traditional "our way or the highway" school of thinking, which alienates teams from one another and breeds resentment, to a feedback based approach that understands change and honesty in communication must exist as a basis for continuous increases in effectiveness.
From a strategic perspective, a DevOps based approach will be the foundation of truly adaptive business strategies and increases in quality across a business. By being empowered to work together and innovate, staff within an organisation will get to know one another and share knowledge whilst upskilling each other in the process. New ideas for strategic progression will bubble out of the DevOp culture as they come up with new ways of improving technology, rather than the business requirements-based approach where executive business requirements are pushed onto the technical teams with limited regard for the appropriateness of the solutions.