In this DevOps Chat we spoke with Prem Chandraskearan, VP of Software Engineering at Barclaycard. Prem led the DevOps transformation there. He sums up his learning thusly:
The best way for an organization to approach DevOps is from a collaborative angle. When development and operations experts actively work together in a cohesive effort, solutions are well designed, efficient and smart from both a development and maintenance perspective. When operations is viewed as a software problem, Dev and Ops can work in tandem to implement a tool that is holistically a part of the process from start to finish.
DevOps is always a work in progress, but the initiative can only improve with quality resources that implement a variety of backgrounds and perspectives on both Dev and Ops working together. Barclaycard has had some interesting challenges with DevOps due to being in the credit card/banking industry, so for example, the “you build it, you run it” mantra doesn’t work as well for us as it would for other enterprises implementing DevOps. It is definitely a learning curve, and our goals and best practices are still coming to fruition, but we are continuing to find ways to automate.
The best way to get teams to work together is to simply ensure that they are not in silos, meaning that if there are distinct dev and ops teams, they must spend time in each other’s sectors to understand the pains, how the functions work, what makes it tick, etc. When the development and maintenance perspective are strategized in tandem, it automatically makes for a better, more streamlined workflow.
The best way to ensure a DevOps initiative’s long-term success is to ensure that the foundation of the program is collaborative and understanding of how each function works. With this, automation testing for failure is imperative to discover problems that are typically only otherwise found in production. If all the bases are covered and the process is streamlined and collaborative, the overall quality of your DevOps function will be much higher.
As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation
Audio
Transcript
Alan Shimel: Hi, everyone, it’s Alan Shimel, staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a great chat scheduled for today. We’ve got a real, live DevOps practitioner. I’d like you to welcome to the show Mr. Prem Chandrasekaran—and I mangled that terribly—Prem, why don’t you give us proper pronunciation?
Prem Chandrasekaran: The name goes “Prem Chandrasekaran.”
Shimel: Fair enough. I don’t think I did that bad then. So, Prem, you are a software group leader at Barclaycard US, correct?
Chandrasekaran: That’s correct.
Shimel: Okay. And, well, before we get into it, let’s make sure that, in case people aren’t familiar with Barclaycard, who they are and what they do, if you wouldn’t mind just giving us maybe a quick little background on that.
Chandrasekaran: Yeah. So Barclaycard in the US is a credit card provider. Our primary business is co-branded credit cards, so, for example, when you’ve got an Apple credit card, if you look carefully, it actually says “Barclaycard” on it, in the background somewhere, but we’ve got a whole bunch of partners like that and we provide credit card services for our partners and customers through the co-brand. We also have a consumer lending business, which is a lot recent, but the credit card business is what is our primary revenue _____ _____, if you wanna look at it that way.
Shimel: Very good. And, Prem, in your role as software leader, what exactly does that mean? ‘Cause it means different things in different orgs.
Chandrasekaran: Yeah, yeah. So my actual title is that of a vice president, but, you know, what I was hired to do was to incept this new line of business. We were coming up with a new line of business called “consumer lending.” And our infrastructure, both hardware, software practices, all of those were on a pretty old legacy system, and we had two choices. One was that we would build on top of the legacy system or create a new platform, as we wanna call it, have all of the modern techniques that we use, including CI/CD, a lot of XP factors, and so on.
And I was brought in as a consultant first when I took the role on full time, two years ago, to lead the launch of that new consumer lending business. And I’ve been doing that. And now we’re trying to apply the same processes, software, hardware, all of those solutions, onto the credit card business, as well as we try to migrate.
Shimel: Excellent. And how long has this project been ongoing?
Chandrasekaran: Consumer lending started somewhere in 2015 and we launched at the end of 2016. It’s been live for the last 18 months or so. And what I’ve been doing after that is, again, I’m still in charge of making sure that consumer lending runs in production, but we’re also building what we call a “global platform” – basically, a set of design patterns and application templates and CI/CD pipelines to allow us to create new services, migrate existing ones, and develop what we call the platform –
Shimel: Oh, sorry. Go ahead.
Chandrasekaran: Yeah, so what I’ve been doing is we’ve been defining the learnings from what we did for consumer lending and making it available to development teams here, so that they can focus more on the business-logic portion of things, solving real problems, as opposed to grappling with a whole bunch of the surrounding stuff, nonfunctional stuff like log-in monitoring, CI/CD pipelines, tracing, and authentication authorization, and so on and so forth.
Shimel: Correct. So, Prem, I didn’t hear you mention security or cyber security, though, and that’s obviously something that’s important anytime we talk about financial services. Where did that play in, in the program here?
Chandrasekaran: I mean, we like to think that it’s something that starts with the code that you write, you know, so we make sure that all of our developers and teams think about security right from the ground up. And we have tests, both static and dynamic and penetration test frameworks, which check the state of the code that you’re developing from a security perspective, right through the CI/CD pipelines. And you’ve got a whole bunch of automation and a bunch of manual penetration tests that the teams do, to make sure that we are producing things that are secure not only for ourselves but also for our customers.
Shimel: Got it. So, Prem, let me ask you a question then. What I think is interesting is this was a project that, as you said, started in 2015, and here we are, 2018, talking about some successes you’ve had. And now rolling some of the lessons and learnings and success from that throughout other parts of the organization. And that actually – no two DevOps transformations, no two experiences, are exactly the same, but that’s right in sort of the sweet spot of how we see DevOps expanding within an organization. You get a project and many people are surprised that, in spite of the speed and automation that we think about in DevOps, it actually takes time. It takes time to launch a project. It takes time to bring a project to market like this.
But, once that’s done and you have good results, part of that DevOps way, if you will, is to take the feedback loops, take the learning, take the lessons learned, and apply them in other places within the organization. Prem, what about executives sponsorship of this, if you will? I mean, you’re a group leader, but, above you, what kind of buy-in or sponsorship did you have from your exec team
Chandrasekaran: Oh, absolutely. I mean, without exec sponsorship, I don’t think we would have progressed to where we are. I mean, we’re by no means done, but, you know, we are still in this journey and we’ve got a very solid leadership team which basically said that we need to operate not as a traditional bank, but as an IT organization, rivaling the best in the world, right? And that’s where we want to be. And it starts from there. And it percolates pretty much every single facet of our organization, starting form hiring to the way that we think. Basically, you know, DevOps is really a means of shortening the cycle of getting a product out of the door reliably and repeatedly, right?
Shimel: Yep
Chandrasekaran: So it does take a huge amount of effort in terms of the automation and the processes that we need to put in place, but, yeah, I mean, we’ve got very strong support from our leaders to help us transform the organization that way.
Shimel: Okay. So, Prem, let me put you on the spot here a little bit. We have listeners out there saying, “Wow, this guy’s done a project where they did this,” right? If you could – and we didn’t discuss it, so I apologize for putting you on the spot – can you give our listeners sorta three things they should avoid? What were the three biggest lessons you learned in the course of this project?
Chandrasekaran: Yeah, so, okay, I’m gonna try to look for three things, right? Okay, so the first thing that comes to mind is that, at least at a place like where we are, in a bank, right, buy-in is very important. So you might have buy-in from the top, but you need to have buy-in from pretty much every facet of the organization, that automation isn’t a threat to their jobs and existence, right?
Shimel: Mm-hmm.
Chandrasekaran: Where, you know, it’s normal that now our time and operations person – “Oh, my job can be automated and now I’m out of a job.” Right? That’s one thing that it’s largely a psychology thing, where you have to address that and give people the confidence that that’s not the motive here. The motive here is to churn out software fast and enable both DevOps, business, QA, information security – I mean, you name a whole bunch of these groups – it’s about collaborating and working closely together to achieve the end, which is putting out software solutions for our customers and our stakeholders repeatedly and reliably, like I said before. That’s one. It’s more of a mental shift that needs to happen. And, unless you do that, you’re going to meet with a lot of resistance.
The second thing is in terms of who you hire, right? Like I said, it’s a mental thing. It’s a philosophy where you need to have likeminded people who want to do the automation, as opposed to doing something that’s manual and error-prone, right? So hiring the right kind of people definitely is second.
And, third, it also needs your business folks to be patient while these transformations happen, where you might not see the benefits of it on day two, right? It takes a while for the benefits to start appearing because it does take a lot of practice. And we’re not there yet in terms of saying that we’ve achieved perfection – I guess nobody can say that – but it does take a few patient stakeholders as well. I mean, those are my three things.
Shimel: Excellent. So, you know, Prem, when we started, I said the 15 minutes go quick – we’re wrapping up here – but, again, for our listeners who maybe are contemplating or in the throes of their own DevOps journeys, I mean, this is certainly a success story to date. What else – I mean, what’s next here, though? Beyond what you’ve already mentioned to us?
Chandrasekaran: Yeah, you know, so, right now – I mean, our next step is to scale this out, right? I mean, we’ve got one product line that is using all of these, and a bunch of the rest of the organization, at least here in the US, has drawn a lot of inspiration from the successes that we’ve gained here. You know, we still operate in a private-cloud environment. We’re targeting going to the public cloud, which basically means that we now allow ourselves to scale a lot more quicker and a lot more faster. So, yeah, I mean, that’s probably the next step, where we’re targeting the public cloud and provide value to our business and customers a lot more quicker that way.
Shimel: Excellent. Excellent. Well, Prem, thanks so much for giving us a little bit of insight into how Barclaycard US has leveraged DevOps here and has started out on their own DevOps journey. We’d love to hear more about it in the future; maybe we can check in.
Chandrasekaran: Yeah. Thank you very much, Alan, for having us.
Shimel: Okay. Prem—and I’m not even gonna mess it up or attempt ’cause I will mess it up—Prem, thanks so much for joining us here on DevOps Chat. This is Alan Shimel for DevOps Chat and we hope to see you soon on another DevOps Chat. Have a great day, everyone.
