 Hi, this is your host of LimbHartia and welcome to a brand new episode of our series, TfHire topic of the month, a.k.a. T3M. And this month's topic is platform engineering is DevOps there. And today we have with us, once again, April Hickel, Vice President of Product Management at VMT Software. April, it's great to have you on the show. Thank you so much for having me. It's great to have you today, especially the topic of this month's discussion is about platform engineering is DevOps that. So it's really interesting to have a BMC because you folks create a lot of technologies. I mean, I think mainstream predicts me. So I really, it's interesting to see how from your lens, how you have seen the evolution of all these personas, paradigm shifts we're talking about, the disciplines like DevOps, developers, SREs, DevSecOps, platform engineering. So if I asked you how you have seen this evolution of folks and then we'll ask, how would you define platform engineering or how different it is from DevOps? Let's start there. Well, I think Swapnil, to answer the question, it's good to look at the end in mind. So it used to be in application development that everybody was excited and satisfied to have a new application delivered in some period of time. Maybe it was a year, once a year you'd do a big release and then you'd have some fixes. And that's sped up over time and it's infrastructure has changed, but I think consumer demand has changed a lot. And so now when we talk about doing software releases, you're talking about people that wanna do it every day or you're talking about people that have a much higher expectation for how frequently you're releasing. And at the same time have an equal demand for performance, for availability. And I think that evolution has brought us to a lot of these topics. It brought us to DevOps. It brings us to talking about site reliability engineering. It brings us to talking now about platform engineering. So I think that's the thing that I see, the demand for speed and agility and frequency while maintaining quality is sort of the origin of that. How would you define if you just look at this description, platform engineering? What is platform engineering? And if you can also say, hey, this is how it is different from DevOps. Well, I think of it this way. Platform engineering is sort of industrializing DevOps. So in DevOps, the idea that you could integrate and automate and create automation pipelines that really supported developers in releasing more frequency. And we saw people looking for continuous improvement. Well, now if you scale that and you think about DevOps at sort of the next level of maturity, you've got all these different teams, all these different parts of your organization, embracing automation and using integrations. And you mentioned that it involves security, right? So security comes in as part of that. So do you teach every single one of those teams to do every single one of those things? Or do you say, look, our DevOps has evolved to the point that we need to do platform engineering. So we'd like to centralize and standardize and perhaps have a group who knows how to do certificate management and can do it on behalf of the developers or knows how to create an automation pipeline and can build that integration to the infrastructure in a more standard way. And does that take the friction out of every developer having to do it? So I think of it as like a DevOps enabler or a DevOps accelerator versus something that's in a conflict with DevOps. So if I draw a Venn diagram, so platform engineering DevOps will kind of overlap. Is it like evolution of DevOps or is it kind of a separate parallel but complementing it? I would say it's separate and complementary. So the idea in DevOps is that I as a developer can work on my project, I can develop my code, I can send that code through some sort of automation pipeline to release it, maybe check security on the way, do all of these things. And also the promise in DevOps is that I build it, I run it. So that's where it kind of intersects with SRE practices. But in that, that automation pipeline and all these infrastructure integrations that are required for me as a developer to have this sort of seamless and automated experience have to be built and maintained by somebody. And that's the promise of platform engineering that you can get a group of people who are experts and who can maintain all of those integration and automation so that I as a developer have this frictionless experience. How would you define developer experience number one? And number two is that how platform engineering kind of enables that experience? So I think of developer experience as, I'm gonna roll into my job in the morning and I'm gonna have to take some business problem and try and solve it. And that's the power of developers is them thinking about how you address some business outcome. So I talked with a developer not too long ago and one of the applications that they work with is really about passenger safety on airplanes. And to do that, they track the genesis of every part and every time that plane lands, every time it takes off, every time that part has maintenance. And if you think of how many parts are on a plane, this is a lot of things to keep track of. But they come into work and they're looking at how do I make changes to this application in order to better deliver on our commitment to passenger safety? They are not thinking about how do I connect to this piece of infrastructure and access this particular piece of data? How do I, they wanna focus on the big problems. So in order to free them up to do that, all of these things about how do you establish a connection to that database? How do you manage getting your code through the policies of your organization to make sure you're not opening up any vulnerabilities? All of these things that happen in the automation pipeline associated with those code can be built into basically a platform, a reusable set of tools and processes that I as a developer can use. And therefore more of my time can be spent creating, developing and coding. And I think that's the promise of customers who have scaled their DevOps maturity to a point where they can introduce platform engineering as a developer benefit. There are companies who have been around for like hundreds of year banks and other industries are there. And there are a lot of companies who are like just emerging today. But when we do talk about things like cloud edu, Kubernetes, service mesh, and now we're talking platform, it can be intimidating. And a lot of new companies, sometimes they are like, you know, just chasing, hey, we need to have Kubernetes, we need the platform engineering without even understanding whether they need it or not. So can you also kind of talk a bit about, you know, that when we do look at these terms, how companies should look at it, that it will evaluate it, that it's not that everybody is on that bandwagon. So we should also jump how they should evaluate we need it or not. Yeah, I think it's really important that you look at your own maturity level. So when you're on the initial stage of a DevOps journey and you're starting to think about, okay, how do I improve my developer experience? What sort of integrations and automation do we need in order to get to a release, to a release deliverable? You know, who is gonna own and operate that code once it goes into production? You know, what types of policies do we have? That is the beginning of DevOps, right? That's where you start and you get your teams empowered and enable and you organize around it and you engage around it. As you scale that and you don't just have one team, but you have 20 teams or you have 50 teams or some of the customers that I talked to, you know, have thousands of developers. If there's a lot of commonality in what those developers need to do. So let's say Swapnil, you're developing and you have an automation pipeline that looks very much like the automation pipeline that I have in my team, then there starts to be a case for platform engineering because the promise would be there would be one team that could serve both you and I. If everything that everybody does is so disconnected and not common, then there might not be a case for platform engineering because platform engineering is abstracting away from all the individual teams, some of the burdens of maintaining integration, setting up automation. I mean, there's quite a lot to those automation pipelines. So I think you've got to evaluate, does having a centralized organization with a lot of expertise give us the ability to move faster within the team? Let's talk about things from the perspective of BMC, your ecosystem, your market. Talk a bit about BMC solutions that kind of enable your customers or the whole larger ecosystem to first of all, bring that developer experience to them to embrace things like platform engineering. Can you talk about your portfolio there? I think that BMC is investing along a number of angles that really speak to how do we do better application development? So one angle I would say where we've put a lot of emphasis is in developer experience. So developers want to spend time being creative, writing code. And so a lot of them have a preference for in which system they do that. And there's a lot of integrated developer environments on the market. So we are trying to make sure that BMC capabilities are available in them whether you go to a Microsoft marketplace and you're interested in doing it in VS Code or whether you're using a more traditional development environment, we wanna make sure that the capabilities there for developers are in all of those. The second place we're really investing is around integration. So if you think about, there's no single company or vendor that you're gonna be dealing with in DevOps. If you think about the time you develop software until the time you deliver software, there's a lot of things that happen in between there and you need integrations, you need your code scan, you need all sorts of things. And there's a lot of great automation technology. So at BMC, we've decided to take a very open borders, ecosystem friendly approach and make sure we package and deliver integrations from all of our DevOps products into all of the ecosystem players. So I think that's really important. So those are, I think, two major investment areas where you see us spend a lot of time. One of the things that we're doing, Swapnel, which I think just denotes our interest in working with developers and really understanding that persona is we feel like the DevOps and the developer experience is so important that we're actually changing our portfolio naming and branding to reflect that. And I think that that is just a signal on where we think the market is going. We think that developers are really key to customer success in the future, right? They're the ones executing on the outcomes these customers are looking for. April, thank you so much for taking time out today and talk about this topic with me and I would love to have you back on the show. Thank you. Thank you so much, Swapnel. I really enjoyed it.