Well, welcome to this IBM Rational podcast, Why. Agile and DevOps Are Important for Communications Service

Transcription

1 IBM Podcast [ MUSIC ] Well, welcome to this IBM Rational podcast, Why Agile and DevOps Are Important for Communications Service Providers. I'm Kimberly Gist with IBM. Communications Service Providers -- or, CSPs -- have a history of adopting agile methods in their development of software-intensive products. However, the adoption of these methods, especially when continuous integration is involved, is impeded with old approaches to the deployment of these solutions to test labs and ultimately to running the system. In addition, test labs are expensive to set up and running, preparation, and usage can be restricted and time-consuming. Finally, the ability to respond in a timely manner to requests from the operations group can also be impacted. This can lead to issues with customer satisfaction and reduced Average Revenue Per User -- or, ARPU. In this podcast, Neil LeBlanc, telecommunications industry offering manager for IBM Rational, and Steve Weaver, solution marketing manager of cloud and DevOps for IBM Rational, both join us to discuss some approaches that help with these issues. Neil and Steve, welcome to the Rational -1-

2 Talks to You podcast series. Thank you for joining us. We're looking forward to the discussion today. LEBLANC: Thank you, Kimberly. Neil, why don't we start with you and give you the first question. What would you say are some of the problems encountered by communications service providers when adopting agile methods? LEBLANC: I think that's a great question, Kimberly. And we know that there's a lot of advantages associated to adopting agile methods. But and actually, I don't know if I would call them, you know, problems; maybe challenges is something more that I would refer to them as. And I think they're more cultural and discipline related more than anything. And I think in order for the communications service providers to be successful when adopting agile methods, they really need to create that culture of agility and not just say, hey, I'm adopting agile practices. And I think the culture of agility is really a fundamental shift in the way that they think and the way that they work and interact. And there's a couple of nuances that go along with that shift. And just I'll give you a couple of examples. I -2-

3 think one is they need to sort of decentralize leadership. I think, for the most part, everyone's used to having this org structure where one person at the top and then you have a number of subordinates underneath. And with agile teams, you sort of create these pockets or use smaller teams and you empower those smaller teams. And I think that's sort of one challenge that people see. I think another is that they need to understand that they need to embrace diversity. They need to be able to complement skill sets. And I think, for the most part, a lot of organizations today and communications service providers, CSPs, really try to say I need all of, you know, the best of the best, if you will. And I think that can create a lot of friction. I think when you can complement the skill sets, for example, balance risk takers with those that are more risk adverse, or balance those that like to rush things with those that hold back, it's a really nice complement. And I think the biggest challenge that we see or that communications...that we're seeing communications service providers take is really getting away from that big, rigorous planning that has a thousand tasks as part of the project plan to really leveraging agile, where it creates a structure as opposed to the individual tasks. -3-

4 And that helps people set their goals, it sets the time delivery, and it really shapes their contribution and coordinates the group effort while respecting deadlines. Great ideas. And I agree these are challenges, not problems. Neil and Steve, how would you define DevOps and in what ways can it help? LEBLANC: Sure. And that's another great question. And actually I'll let Steve supplement what I'm about to say. But to me at a high level DevOps is really about a software development method that focuses on communication, collaboration, and integration between development and of course operations, hence the term DevOps. And DevOps really aims to help organizations, you know, continuously produce software products and services at a much more rapid speed. WEAVER: Oh, yes, thanks, Neil. That's exactly right. And I think one of the things that differentiate IBM's approach to DevOps from some of the more narrow definitions is that we really talk about DevOps as the entire lifecycle process, not just the intersection of the development team and the operations team, but really beyond that as well. We're also concerned about understanding how our applications, how our software is performing in production, -4-

5 monitoring the performance of that application, and then taking that feedback and making sure that it gets inserted back into the planning cycle for the next iteration. So, the end-to-end lifecycle, not really just a handoff between development and operation, is really important. I think that get backs to what Neil was talking about earlier about some of the challenges that the communications providers are really facing. So, I think the DevOps approach of automating software delivery and really driving to a continuous delivery approach rather than waiting for large releases once every six months or once very year is really something that can benefit our communications service providers. Nice examples of how those two processes can be integrated and make it better for the user. So, our next question, Neil, how can the telecom test lab problem be solved? LEBLANC: Well, you make it sound like it's so simple and that there's just one. [LAUGHTER]. LEBLANC: You know, so, one, I think given the initiative -5-

6 that the current communications service providers are currently undertaking with the transitioning from their legacy infrastructure to IP networks and the rate at which it's happening, you know, it's surprising that some of the CSPs and the network equipment providers, actually, don't consider network testing as a critical function, even though testing is usually a significant cost component. But I think the big challenge that we're seeing is that the CSPs really underestimate the impact on the speed to market. And so with DevOps and continuous testing can actually help with some of the challenges that we do see as part of the test lab challenges. One, I think around cost. So, it's usually expensive to train and actually retain testing staff that are able to be responsive to the peaks and the valleys tests demand. And so with DevOps and continuous testing, you don't see those peaks and valleys. It's continuous testing, as I mentioned. Second, I think around quality. So not all network testing capabilities are alike. You end up with a truly high-quality network testing capability, must cover all the test cycles. Which is especially critical after introducing or updating a software application to ensure that the change has the intended effect. -6-

7 And I think, lastly, around productivity. I think a network testing function must enable companies to increase their use of test automation, shorten the test lifecycle, and then reduce the effort needed to ensure an appropriate test configuration. And, again, I think this is just sort of one of the challenges that are faced inside the telecom test lab. I think scheduling is another. But that's probably a whole nother podcast. Point taken. So, Steve, you get our last question. Why don't you tell us what does the operations team get out of DevOps. WEAVER: That's a good question. The anecdote is that the operations team are always compensated on nothing changing, everything staying the same, and the development team is compensated on making sure that everything changes. So, it's actually interesting to put yourself in the shoes of the operations team and to understand exactly what benefits they're seeing out of DevOps. And the answer I really think is three parts. The first one is all about reducing risk. And I think some of what Neil talked about earlier about continuous testing really is key to this. Very often when we've done handoffs in the past -7-

8 between development teams and operation teams, it's very hard for operations to understand about how the software was tested, against what infrastructure was tested, especially in a more complex network infrastructure. So, when they go and deploy the software, they really don't have a great understanding of what quality that software is, and that can lead to all kinds of issues. With this DevOps approach, the continuous delivery approach, we put in place at each step of the process quality gates as we are moving from developer testing to system testing to staging and into production so that we have a clear idea at each step of the way exactly what has been tested against what kind of infrastructure. So, there is a much reduced risk of the software failing when we get to production. And also because we're doing continuous delivery. Typically the updates that we're making are fairly incremental, so fairly small updates compared to the large updates we typically see with, you know, new point releases every six months or every year. So, the reduction of risk is certainly one aspect. The second aspect I think is around governance. Because we have the entire team collaborating together with the same set of tools, they all have visibility into the process from end to end. -8-

9 So, from an operations point of view, you have an understanding of what the software updates are doing, what...perhaps what bugs they're designed to fix, what new features they're adding, what...the requirements work that led to those software changes, what the tests were that we used to test against the software. So, you have much better visibility, much better auditability of the software as it's going through the process, so it gives the operations teams much more confidence in the software once it's finally deployed. And finally, one of the key things, as I mentioned earlier, is we have this idea in DevOps of a continuous feedback cycle into the plan and process. And operations is really a big part of that. So, there's stakeholders in the process right from the beginning. So, they have an input into the development process too, an input into the architecture that we're going to be deploying the software onto. So, because they have this insight, this great operational insight, it helps the software ultimately have high quality, and it makes sure that they really bought into the whole process. And hopefully, because they're a part of the set -9-

10 of stakeholders in the process, we're ultimately producing much, much higher quality software. So, I think those are the three key aspects where operations really benefit from this DevOps process. And those were three great points, Steve. Thanks, again. Thank you, Neil and Steve, for a great overview on the relationship between agile and DevOps for communications service providers. We sincerely appreciate you taking the time to join us and share your expertise. That was Neil LeBlanc, telecommunications industry offering manager for IBM Rational, and Steven Weaver, solution marketing manager of cloud and DevOps for IBM Rational, with some key points for today's podcast event, Why Agile and DevOps Are Important for Communications Service providers. To hear this specific podcast or to browse additional topics, check out our Rational Talks to You podcast page at This has been an IBM podcast. I'm your moderator, Kimberly Gist. Thank you for listening, and we hope that you will choose to keep tuning in as Rational Talks to You. IBM Podcast [MUSIC] [END OF SEGMENT] -10-