It takes more than one champion: Getting DevOps working for you
One techie alone cannot deliver on the promise of DevOps.
The tech industry has been talking about DevOps for quite some time but there is still plenty of confusion about what it is and how it can benefit organisations.
ZDNet recently caught up with Ritu Mahandru, who runs CA's EMEA application delivery business, the company's fastest growing business unit, to talk about how DevOps is developing and impacting businesses.
ZDNet: The industry is talking a lot about DevOps, so how do you assess its takeup?
Mahandru: People are wondering how DevOps is going to drive the next phase of digital disruption, and we really have to start delivering. We have got to take it from being a philosophy to something delivering tangible benefits. I see a lot of customers who are just in the early stages of adopting DevOps.
Have you any idea where that kind of initiative is coming from?
It is definitely coming from the business side -- the C-minus-one-level -- who are trying to drive through change. The marketing people are trying to drive it, those who are trying to push through more revenue generation, and then there is customer experience. There is a lot of emphasis in that area. There is a growing focus on finding ways to improve the customer experience. It is so easy for customers to complain that there is a lot of emphasis on finding ways to improve the overall customer experience.
It appears that some companies understand that very well, while others do not. Why do you think that is?
It is an interesting area because you have the traditional businesses versus new startups. The traditional ones seem to take it for granted that if you are not happy, then you are going to come back and tell them, while the newer ones are more likely to constantly check and ask customers to find out if they are happy.
The issue is getting companies to that level. People want to complain and tell you what they think and so it is important to make them feel that they can do that easily.
How do you get organizations to do that?
The first thing is to make it easy for customers to contact you. That should be easy, but if you go onto the average website, how many times have you found it difficult to see who to complain to if you are not happy?
It is about organisations making themselves accessible to customers and a lot of companies are talking about that. Things like the seamless experience, better interaction on the website, interaction with call centres, and so on. One of the most interesting areas is retail. We are finding that the retailers are ahead in thinking about it because they know that if they don't they are going to get disrupted.
The hardest part of DevOps must be getting those parts of the business talking to each other. What's your advice there?
The problem there is that people will always silo unless they are brought together behind an initiative. If you start with one area saying that they are going to look at how they can manage customers better, then you build the dev and ops teams to come together behind that initiative and instead of working their silos you can bring them together as one team.
People talk about DevOps as if it were a bunch of tools but I think it is a way of getting people, process, and technology to work together much better and in one effective team. You get the people together and get them behind an initiative and take it from there.
Some people talk about the need to have a champion to push through DevOps. Do you agree?
You need a lot of champions because one person alone can't make this sort of change happen. And, very often, when you have one champion that person tends to be a technologist. That isn't enough.
A technologist can get what DevOps can do but that does not go far enough. When you are trying to push through a major business issue, it is very hard for a technologist, alone, to do that.
A lot of people say that you have to get the MD involved to make this happen. Would you agree?
You should at least have a senior executive to drive this. You do have to show success early on and people will come back and say, 'What have you done? Whatever it is, we want to do that.'
If you look at our customers, I would say that where they have tried this, within six months they have started to create a groundswell of interest. Often it has taken one team or one landing point to try out the technologies and then try out the approach and build it up from there.
I think that within six months you will start to get a backlog building up and then you will get a few projects that people want to get started on and most of them will find a timing point that works for them, and then they will try it on their next release, or their next version or whatever. Then they will understand the DevOps way of doing it and will set a timeline. We do see that.
What we have also found is that what doesn't work is a sort of 'ivory tower' approach. What doesn't work is to get up a DevOps team who sit and work on best practices and whatnot. What we find works best is to get the DevOps specialist actually embedded into project teams.
What do you see as the differences or the commonalities between Agile and DevOps?
I do see a difference because you can be doing Agile and not doing DevOps. That's because you might be adopting scrum methodologies and moving towards DevOps but it might still be that, when you are moving to release, you are still releasing in the old-fashioned way.
I mean that ideally they should be done together but I don't think that when you are doing Agile that you are necessarily doing DevOps. Obviously, they do work better together but you often find that organisations are struggling with waterfall-ish development and think they are doing DevOps.
So you are seeing a takeup in Agile?
Goodness me, yes. Every developer wants to be developing in an Agile way but the challenge is whether or not we have enough of the expertise out there that is set up in such a way that it is supporting Agile.
DevOps illustrated as the intersection of development/software engineering, technology operations, and quality assurance (QA).
Do you think this is an industry-wide issue?
It is and we ask ourselves how can we be better at this but I think that is mainly an education issue. The key issue is that we all have to get used to changing things fast. Once people become used to doing things in a waterfall way, then the idea of moving to Agile and delivering things in two days becomes more interesting.
But then isn't there an issue that you release something and some of it works and some of it doesn't -- and then you release an update and the same thing happens?
Yes, you have to hold the developers. They can develop things quickly and release quickly but the question then is, has it been adequately tested?
That is because the whole process needs more focus and not just on the development side. The developers do their bit but then what do we do from the time the code is finished, through testing and through to release?
In your experience, is there an optimum team size?
It is a case of getting a team of analysts and programmers together to do something and then you need to get the business involved as quickly as you can. Don't try and do it in isolation.
Do you get a sense of where we are in the UK on this in comparison with other countries?
Most companies have started something, but how many have actually gone through the cycle is another thing. Internationally, I do a lot of work in Europe and I am quite impressed by how far the UK has come. There are some countries like the Netherlands that are well-advanced and France is quite advanced too. In terms of sectors, it is financial services, banking, and insurance where there has been the most progress.