Hello, everybody. This is John Pocknell with Quest Software and welcome to this Fireside Chat. I've tried to do my best here given that it's a virtual fireside chat. So I've got a background here. Hopefully, you can see this with a fire. Vamshi and I are ready to get started. We've got our mugs of hot chocolate and we're going to get going.
So first of all, I want to thank Vamshi Damera for participating in this Fireside Chat. And we're going to talk about model-driven DevOps at Quest Empower. And we also want to thank you, the audience, we want to have you participate in this discussion as well. So feel free to ask questions of either Vamshi or myself as we go through this discussion on model-driven DevOps.
And we'll have some questions and answers at the end of this session. But feel free to drop questions in the chat because we know what it's like. You think of a question at the beginning and then you forget towards the end, right? So if you think of a question you want to ask, just drop it in the chat and then we'll go through them at the end.
So just to lay out a little bit of structure, first of all. We're going to start by talking about Vamshi's background, his current experience, and his previous experience, which is heavily weighted towards DevOps and Enterprise architecture. And specifically, we're going to start talking about some of the business goals of DevOps in general.
But some of the other challenges that companies face when they're trying to align business and IT together. We hear about DevOps a lot, but we tend to hear it in terms of involving IT people, and not so much the business people. And that can lead to some challenges, which we'll get on to.
And then, we'll then feed that into the conversation around what model-driven DevOps actually is. And by the way, you may have also heard the term biz DevOps, which is a term that's been around for a while, otherwise known as DevOps 2.0. You may have heard that term as well. And they are all pretty much the same thing in terms of the need to bring business and IT together when we're talking about software delivery, OK?
So Vamshi, how are you?
Good.
Welcome to this session. It's great that you're back and talking to Quest and customers again. This isn't the first time we've done this, right?
Right. Thank you so much for inviting me. It's a pleasure to talk about these topics.
Pleasure's all ours. So Vamshi, just for the audience, could you first sort of describe your current role? I mean, we've known each other for a few years now. And you're in a new role-- relatively new role as Enterprise architect at the Washington Metropolitan Area Transit Authority. Can you describe what your current role involves? Because it's a little different to your previous role, right?
Right, so my role at Washington DC Metro is to evaluate their ERP solution. So they've been heavily invested in their ERP solution for past 15, 20 years. And now, they're in that stage where they want to reevaluate their ERP roadmap as to where they want to go from there. Switch the vendors or get-- is it worthwhile to switch the vendor? Or they stay current and keep their ERP versions current or migrate to the newer version or migrate to Cloud.
And to do that, I was-- I'm chartered to capture all the business processes, capture all their interfaces, which go to and from ERPs. Capture all the customizations in their ERP systems. And any third party, how they integrate into the ERP system. So my role was to get a entire picture from business perspective to the implementation perspective. And how do we move towards-- and the marketplace has several other ERPs-- competitive ERPs, which would be a fit for their needs.
So my role was to evaluate this-- capture all the data-- metadata from functional to technical to implementation. And then, draw a road map, which fits them.
Right, so you're actually talking to both the business community and the IT community, right?
Correct.
Right, and I understand that there's a team of enterprise architects there as well at DC Metro.
Yes, there are.
OK, good. So we'll circle back to your current role in a second. The other thing I wanted to focus on as well-- because I think the audience will be really interested in this. Because I'm not assuming that the people listening in are sort of [INAUDIBLE] with DevOps particularly. They may be involved in beginning the path towards adopting DevOps. DevOps is not something you just switch in overnight. That's obviously something which is a cultural change within an organization.
So you've got to have people in different functional areas collaborating together. But then, you've also got to combine that with automated processes. And along with those automated processes, you generally have-- you look for tools that will help you build an efficient software delivery pipeline with automated processes that can get the whole thing going. So it's typically around the cultural change involving people, processes, and technology.
So just on the subject of DevOps, let's go back to your previous role as well. Because you were involved with a number of DevOps projects as well, right Vamshi?
Right, I was.
And with those projects, there were obviously some business drivers behind that because you were involved in implementation of-- particularly the database side into-- which I think was an existing DevOps infrastructure. But the piece that was missing was bringing the database change management processes into that. What were the biggest drivers behind that? Why did they go down the road of DevOps in the first place?
So I was working for Hartford Insurance, a 200-year-old company.
In Connecticut, right?
In Connecticut. And then, had a huge applications--
35:53
