In the age of disruption, where being able to deploy software quickly can make or break a company, those with strong DevOps teams have a big edge.
By committing to DevOps, a company can quickly implement changes to its internal operations, as well as to its final product. In essence, DevOps makes IT responsive to the needs of the enterprise. But is DevOps really that important, or is it just another tech fad that won't live up to the hype?
Is DevOps as important as many claim it is?
Rachel da Justa, architect, BBD: Yes it is. This is because it's not only about fast deployment, it's also about the quality of the projects being developed. This is different from what happened before, where developers created the software, which they would then pass onto operations, and whatever problems were in it, operations had to sort out.
Johann Els, DevOps specialist, SUSE Sub-Saharan Africa: I see it as a business process. This is because business is looking for a quicker response to adapting to new trends in the market. This is what DevOps brings.
Michael Brink, solution strategist, CA Southern Africa: I want to add that there's a lot of emphasis on the developer, but there needs to be the same amount of emphasis on the operational side.
This is often overlooked in many organisations because a lot of attention is focused on the early stages in the pipeline, but not much effort is put into creating a feedback loop.
Denzil Govender, head of technology: software development & integration, EOH: I just want to point out that DevOps doesn't stop or remove bugs. There will always be something that creeps through. Having said that, DevOps does enable a business to recover quickly. It means an operational guy knows which developer to contact when things go wrong, and can then work with this person to sort out an issue.
Barry de Waal, chief executive of strategy and sales, 9th BIT Consulting: There are two points I want to make. Firstly, I want to concur with Michael on how we don't focus enough on the operations aspect. I think this comes from the mistake of confusing DevOps with Agile, which is more of a development-focused activity.
DevOps comes into its own when it allows operations to move as quickly as agile development is moving.
The second point I want to make is that when someone in operations calls a developer to fix a bug, that's the early-stage adoption of DevOps. It's really a sign of maturity when there is continuous development and deployment of software. This means what you build, you deploy, you own. There's no handover to someone else.
Jaco Viljoen, principal agile consultant and head of digital at IndigoCube: We talk about development and operations, but the reason we do things differently in DevOps is because of the value we bring to the business. The goal is not to make our lives in the IT department better, but, rather, to service the business, which is under increasing pressure to do things faster.
Johann Ungerer, CEO, Azuro Business Solutions: I agree with Jaco that business values are the big drivers. The goal is to get product into the hands of consumers as quickly as possible, be they internal or external. I want to make a slight counterpoint to what Barry said. Agile doesn't stop at the development process, DevOps is just Agile in the operational structure.
And agility is not just for creating software, it's for the entire organisation. It has to go through all the business operations and processes.
Barry de Waal, 9TH BIT Consulting: I agree. It's Agile 2.0.
What do you need to do make DevOps succeed?
Karl Fischer, DevOps team lead, Obsidian Systems: We are trying to create a DevOps culture throughout the organisation. We're trying to make people aware of what everyone else is doing to eliminate information silos. We are doing this by measuring anything and everything, so we know how long things will take. We want to make everyone aware of what we are doing, and also to automate as many processes as possible.
Rachel da Justa, BBD: I agree with most of the points made. But we are still talking about development and operations as if they are two different things. People might have had their start in operations, but they are now contributing to development and operations.
This means when we start a project, the ex-operations people are guiding us from the very beginning.
Michael Brink, solution strategist, CA Southern Africa: I agree. I think DevOps is all about breaking down barriers in an organisation. Not just between Dev and Ops, but even wider than that. The business model needs to facilitate this new way of working. Eliminating the barriers that stall an idea from becoming an outcome should be a driver for business. We need to take a holistic kind of approach rather than an isolated silo approach.
Barry de Waal, 9TH BIT Consulting: To your original question, 'Is it a fad?' Looking at the last research I've seen, 31% of financial institutions in Europe have adopted DevOps, and a further 61% will be using it within the next two years. I would say with over 90% of financial institutions adopting, it's a little bit more than a fad.
Agile doesn't stop at the development process, DevOps is just Agile in the operational structure.
Johann Ungerer, Azuro Business Solutions
Neil Rampton, senior project manager, COLONY: How successful you are in bringing DevOps into a company depends on that organisation's culture. If there's no collaborative culture, then it won't work. Unless it's driven by management, no one will apply the DevOps approach. I've see a lot of pushback from the operations team because they want to stay separate, so it's very important that there is support from the top.
Johann Ungerer, Azuro Business Solutions: To your point, people are a big challenge in the DevOps process because you are breaking them out of their comfort zone. The people in development, for instance, never needed to worry about the infrastructure, and operations never really had to concrete on coding.
Having a management imperative is more than just management saying 'we have to do it', and more than just having people willing to take that risk. People are going into areas where they might not have much experience, so you have to give them the room to make mistakes.
Denzil Govender, EOH: I agree that culture is very, very important. The textbook approach is culture, process and tools, but it's not always the only approach. For example, we have worked with a bank and changing the culture of a bank can be very difficult.
Even so, we found a way of getting through. The bank put the tools and processes in place, and then people started to see the value these things were creating, which saw them coming aboard naturally. This saw the culture being built around the tools, as opposed to first getting the culture right.
Jaco Viljoen, IndigoCube: There has to be the right set of tools, in what I call the DevOps tool chain. We have to look at how these things integrate with one another, because 'lean' has taught us that the handover points create problems. People make mistakes, and if we want to be seen as doing things continuously, you can't do that if you have manual processes in between.
I think DevOps is all about breaking down barriers in an organisation. Not just between Dev and Ops, but even wider than that.
Michael Brink, CA Southern Africa
Barry de Waal, 9TH BIT Consulting: The tool chain is a key point here. Not a tool, but a chain of tools. This is because the tool that tends to be focused on is the one that's preferred by the DevOps 'rock star' in the customer's team. If that person comes from the traditional infrastructure side, then this person will beat the drum for a tool that beats the problem he has experienced before. The goal is to get this person to see things differently and not to just try to solve problems in the same way.
What difference does DevOps make?
Barry de Waal, 9TH BIT Consulting: The one thing I've realised in speaking to clients is that they need to understand how quickly they can fail. They can easily end up spending a lot of time and millions on a project, only to discover that it's not working. With DevOps, however, they can fail fast, and change direction quickly.
This is the crux of what DevOps offers. How quickly can we fail? But, having said that, if you are going to fail fast, you need good brakes. This means despite the amount of automation you have, you also have to have controls, as in having people to manage the processes.
Michael Brink, CA Southern Africa: You are right, the people aspect of DevOps is vital. Something can always go wrong with automation.
Johann Ungerer, Azuro Business Solutions: I led the adoption of DevOps in our business. It was a top-down approach because we had an inexperienced team. However, it could be implemented either as a grass roots or a top-down approach.
I also want to point out that I'm not a big fan of the 'fail fast' language. I think it should rather be 'pivot fast' or 'learn fast'. We should not see it as failing, but rather as finding stuff that doesn't work.
I would rather course-correct than break something.
Coming back to your question, it can make a big difference cost-wise. If a bank worked on something for 18 months, and found that it cost it millions and didn't work, with DevOps, they could have saved a lot of money because they would have found out that it was not working in about 12 weeks.
How do you go about making sure you get the best out of your DevOps team?
Johann Ungerer, Azuro Business Solutions: The first thing I want to say from a DevOps perspective is that we have to stop differentiating. There's no DevOps team. Everyone should be very involved across the organisation.
But to your question, your team has to be multi-skilled, and everyone has to take a high degree of ownership towards the deliverability and quality of the product they are putting out there.
Karl Fischer, Obsidian Systems: The number-one thing is trust. If you don't trust your team mates to do the right thing at the right time, you will be in for a hard time.
Make sure the team has different backgrounds and age groups. The worst thing you can do is create a team where everybody agrees with each other.
Rachel da Justa, BBD
Open communication is also key, in that you need to get them to understand your expectations.
Neil Rampton, COLONY: I agree with Karl. The team needs to have a very high level of trust. They all need to be responsible for the work they are doing. And if there's a problem, they need to step up and fix it.
Rachel da Justa, BBD: The one thing we discovered almost by accident is to avoid creating an echo chamber. Make sure the team has different backgrounds and also comes from different age groups. The worst thing you can do is create a team where everybody agrees with each other. From my experience, this is where things go wrong. In contrast, we have found our biggest mistakes when someone disagreed with something.
I know doing this isn't easy. You will have a lot of disagreements and might have to smooth things over by buying some coffees, but at the end of the day, it's actually worth it.
Denzil Govender, EOH: I agree with all of the characteristics that have been mentioned. I want to add that the team needs to have a common goal. That goal for me is how we can get software frequently and reliably into production.
This article was first published in the October 2018 edition of ITWeb Brainstorm magazine. To read more, go to the Brainstorm website.
Share