What a difference DevOps makes
By Jason Suttie, BSG Head of Technology
Four things every executive should know
DevOps, a term derived from a combination of Software Application Development and IT Operations, is about transforming organisations into a fully agile state in which more is possible, more quickly.
Twenty years ago, there were only two or three “serious” computer languages one would use to build software. At the time, the development team (Dev) would build out a software product before handing it over to the operations team (Ops), who would then try to install, run and use it without having been part of the decision-making process. This fostered friction between the two teams, Ops possibly finding the software they’d been provided did not function as expected, caused problems or lacked stability. Dev, meanwhile, might conclude that Ops simply lacked the competency to understand the software or apply it correctly.
Today there are approximately 2,000 mainstream computer languages and platforms, and countless applications are built and rolled out daily – speed, agility and efficiency are of the essence.
Without collaboration between DevOps from an app’s very inception, the chance of achieving any of these qualities is negligible.
The key to the success of DevOps is its core pillars: empathy, collaboration, optimisation and measurement. DevOps changes how organisations do things; Ops and Dev work together from the very beginning of a project. Not quite combining the two functions, which are distinct and require different competencies, DevOps rather embeds both within individual project teams so that the needs of Ops and the activities of Dev are aligned from start to finish.
This approach reduces miscommunication and removes unnecessary obstructions to application and service delivery.
DevOps aims to bring people closer together, mimicking the small-team agility of the startup, and its principles aren’t applicable only to the software environment.
DevOps makes an organisation more nimble
A high level of DevOps maturity enables an organisation to deliver massive business value. Mature DevOps involves a way of working and a level of agile communication between and within teams, along with engineering practices and automation that allow a fluent process flow from the business requesting an application to release in the time it takes to write the code, run the test and engage the DevOps pipeline.
Many organisations still run on a monthly release schedule. This is not optimal: first, it slows down the process of delivery and second, it necessitates the business cramming as many changes as they can possibly fit into each monthly release. A much better option is to schedule releases daily or even hourly so that change is incremental but constant – successful DevOps enables releases to go through incredibly quickly.
Because DevOps involves regression testing, allowing the team to ensure that each change has no negative repercussions for the existing infrastructure, it makes code deployment far more reliable and stable. In the event that there is a problem with the release, it is a simple process to back out the change to a previous version quickly and smoothly.
When implemented correctly, DevOps can mean continuous delivery and competitive advantage
Dr Josef Langerman, Executive Group Head for Engineering Transformation at Standard Bank and a vocal advocate of the DevOps movement in South Africa, asks, "Who will win: the big fish or the fast fish?"
As an organisation, one needs to be nimble; that is, the fast fish. One becomes the fast fish by setting one’s organisation up to enable it to move quickly. DevOps enables this.
One example of the fast fish is Facebook, the world’s best-known start-up. The mechanics of Facebook’s DevOps, and how they achieve the speed they do, are not fully in the public domain, but any user can see the evidence of it, as changes to their site are released in a fast and iterative way with seamless efficiency.
One of Facebook’s core principles is “Nothing is somebody else’s problem.” The company has a culture of owning problems from start to finish, with accountability embedded in their ways of working.
DevOps enables a greater degree of velocity in a business; it is a great competitive advantage to be able to move quickly
The core pillars of DevOps can alter the DNA of an organisation for the better
Regardless of the size of an organisation, intentionally or not, silos develop. When Dev and Ops are discrete teams they communicate differently; in a quest for scale and to eliminate key-person dependencies, an organisation inadvertently can create other problems when staff are divided into Dev vs. Ops silos.
In terms of the work they need to do, however, the two should not be separated; to do so is essentially to break up a team, eliminate empathy and inhibit the flow of communication.
When Dev and Ops work together, a project begins by establishing how to measure the performance of a system in production, how to automate the pipeline into production and what that DevOps engineering pipeline will look like.
In some cases, one might even swap people out, putting operations people in development and vice versa, to truly build empathy and allow each to understand the other’s experience. This builds a strong relationship instead of oppositional silos, fostering better and more efficient collaboration and alignment of outcomes.
Agility: it’s not just for software
While DevOps may be specific to the development of new software technology, similar ways of working can be applied across the spectrum of workplaces, from carwashes to finance departments.
The spine model helps to identify:
- What is your need; what are you solving for?
- What are the values by which your organisation lives?
- What are the principles by which you make decisions?
- What are the practices by which you implement these principles?
- Which tools will enable you to engage those practices most efficiently?
At the practice level, two tools emerge that work with a DevOps style of agility, but each is more effective at a different stage of the business life cycle.
If the team in question is running in project mode, building out new products or processes, with releases due on a regular schedule, SCRUM would be the preferred methodology. If the team is working on a mature system, implementing tweaks or improvements in a business-as-usual manner, Kanban would be better suited to the environment. This methodology, inspired by lean manufacturing models, is generally most effective in unstructured or chaos-like scenarios.
In the end, you can’t manage what you can’t measure
This age-old management mantra remains a constant truth. Executive responsibility requires that one seek out metrics by which to measure all components of a business, from projects to departments, systems to staff, and apply these to eke out the maximum effectiveness and productivity.
Identify room for improvement, silos of poor collaboration and spaces where visibility is lacking; these are key to effective measurement and thus to having a handle on your organisation as a whole. In having the measure of all areas of the business lies the power to leverage each to its fullest potential.
BSG Head of Technology