Kishore Koduri:

So the user expectations are gradually going up. Like you just pointed out whether it is Amazon of the world, now it is X, not Twitter, I guess. So when users like you and me when we are using those services, then we go to a phone company and use their website, your expectations are the same. So we need to meet those and if not exceed.

David Joy:

What is up everyone and thanks for tuning in. In today’s episode of the Big Ideas in App Architecture podcast, we speak to Kishore Koduri from Ameren, senior director of enterprise architecture and shared services. Kishore and I dive into his 17 year career at Monsanto and his current role at Ameren. We talk about what it takes to transform legacy applications and different decisions that have to be taken to drive a successful business outcome. Kishore also shares about why people, process and technology have to be central to all of this. So pump up that volume and get ready for an insightful conversation with Kishore Koduri. Why don’t you kind of introduce to everybody who is listening to you for the first time on, what do you do right now at Ameren? What does Ameren do and what your role entails?

Kishore Koduri:

Yeah, sure David. And so Ameren is a fortune finder utility and we serve about three and a half million give and take electricity and gas. So basically we keep the lights on in many ways. So what I do is I lead enterprise shared services. I’m a senior director there and in my group we have enterprise architecture and I had a fantastic opportunity to revamp that particular practice. And then resiliency, as you know, it’s very critical for utilities. You don’t want your gas or electricity down, so resiliency is very critical. And then I revamped agile office that is other practice in my group and integration. So my team does all the plumbing, all with various systems and applications on-prem, in the cloud and various things like that. And recently I was asked to start looking into the testing practice. As you know, it is very critical for the successful delivery.

David Joy:

It is a lot of works. I’m guessing you should have at least 400 to 500 people in your team that you’re managing right now.

Kishore Koduri:

No, I don’t. We are very efficient. So including everybody, I think we are around 170, 180 ballpark. That is where we are right now.

David Joy:

Well that’s a lot of people to work with too and we’ll get into all of that. When we were speaking last night, you mentioned to me, and I wasn’t aware of this, that Ameren is actually a Fortune 500, even though it just operates in Michigan and there’s another.

Kishore Koduri:

We operate in Missouri and Illinois. Yeah, that’s right. And it is surprising, that’s what I was telling the other day, just operating in two states. It’s still a fortune find company because the number of customers we serve and it is both for distribution transmission of both gas and electricity. And we also have some generation, like we have some coal plants, which we are working on moving away as well as we have nuclear. Quite a bit of gas and sun, solar and wind and energy generation.

David Joy:

Right. Well, this is awesome. This is great to know. How was the transition for you coming from Monsanto bear to a utility company and of course the practices that you have to lead or the way you have to build solutions or work with people, you carry that experience. But in terms of domain itself, what surprised you the most coming into Ameren?

Kishore Koduri:

Yeah, so utility space is new for me. We are all like you or anybody else, we are all using utilities, but we do not know to the most part how they operate other than you pay the bill kind of a thing. Utilities in states at least is a regulated industry, meaning a particular utility will have a territory where you have rights to distribute electricity or gas or whatnot. So with that, there is a lot of regulation comes in. So that is something new, that’s a new domain for me along with how energy works, what kind of technical as well as innovation challenges we may have. Some of the critical components I was talking about, reliability, affordability, and as well as there is a lot of emphasis on green energy now. So those are the things I’m slowly getting up to speed. It’s from technology side that different kind of challenges, but at the end of it, keeping customers what they need and giving them a very reliable, affordable service is the bottom line.

David Joy:

Got it. All right, that’s amazing. So you already spoke about some of the teams that you’re leading. Of course the testing practice is something that you’re going to take over, but you were talking about the enterprise architect team. So maybe talk to us about each of these teams. For somebody who’s listening for the first time, what do these functions entail and how do you keep the integrity of what the business objectives are and drive that with the teams that you work with?

Kishore Koduri:

Sure. So basically like I was saying, there are multiple teams in my organization and keeping all of these teams in sync is a task on its own. We need to make sure there is the right level of collaboration is going. There is the right level of communication going. So enterprise architecture, as you know, we have enterprise architects, solution architects, domain architects, helping the enterprise to create roadmaps, create technology strategies as well as long-term investment planning and so on. So that is what this team primarily focused on. We have solution architects, which they work very closely with these initiatives, projects, large projects. They jump in from the inception all the way going into live production and stuff like that. So they play a very critical part. And again, I can go on with the resiliency and agile office and so on, but going to the gist of your question, how do we keep all of these in sync?

How do we motivate them and making sure that we are delivering business objectives. I think that is what we focus very much in. First and foremost, my methodology is around, you probably heard about this autonomy, mastery and purpose. I think that is what I primarily use. That was introduced to me by one of my leaders in previous worlds. So it resonates very well with me and making sure you provide some guardrails and tell them, hey, this is what success looks like, this is what good looks like, and create right expectations and goals and it out. Then don’t get into the weeds of what they need to do, how it starts with why, explain why we need to do certain thing and then explain them how it needs to be done in a way that it needs to be aligned. There is light level of collaboration, engagement and so on. And then give them autonomy and they make wonders. So I have seen it again and again, that particular thing works and works on all cylinders.

David Joy:

That’s brilliant. And what you shared is also your leadership philosophy, which is great for you to share. I think autonomy to architects and developers is really interesting, especially in today’s day and age where they want to be creative and they’re looking at solving the problem, but at the same time, driving guardrails is important because the business objectives is also something you have to drive towards. So that’s awesome. So it’s a great introduction to what you’re doing right now. Tell me about, let’s say back a little bit, maybe a decade or more or back and how was a young Kishore excited to get into this field of engineering? Tell us a little bit about your beginning of computer science and what led you to move into this direction.

Kishore Koduri:

So I’m still young Kishore. Okay. Just point to be noted. Young Kishore.

David Joy:

I’m talking about a 20 year old kishore right now.

Kishore Koduri:

So I won’t bore you with all the different roles in different companies, but I’ll touch some of the highlights. I had an opportunity to start on a startup in India and we were trying to do a Salesforce kind of a CRM solution. It is back in the day and it’s very exciting. It’s not a cloud solution, but it is a web solution. We had a lot of good features and a lot of good customization around it and I learned quite a bit working at that startup from how the venture capital investment works and all nine yards of software development and customization sales. So that was really exciting journey, but unfortunately the startup did not survive and that so ended up in States and you were briefly mentioning, I started with Monsanto that’s biotech company. So I was there for about 17 years, did various roles.

I also had an opportunity, before I moved on to Ameren, I had opportunity to lead part of IT and I co-led IT transformation, which is, we used to call IT 2.0, which is around moving from service-based organization to a product-based organization, waterfall to Agile, and then moving to the cloud. It is a fantastic fascinating journey there. And also had opportunity taking existing applications, move them to mode one and mode two and move mode one applications to manage service partners. So that was all a lot of learning. So basically what excites me at the end of the day is problem solving. That is what the key for any IT guy is what kind of problems we solve and how effectively we solve with the different tools we have in our toolbox. Either it is technology tools, like right from cloud to region AI and all new stuff coming in. We just don’t want to use the tool just for the sake of it, but how do we use it to solve a business problem and make everybody’s life more effective and efficient.

David Joy:

Got it. Yeah. So what’s your perspective on all these different changes that have happened, especially I know the cloud kind of burst into the scene and everybody kind of adopted to it, but not everybody could move to the cloud immediately because I mean there is data specifications on being data centers and things like that. Did you first encounter moving to applications to the cloud at Monsanto? What was that first project like and how did you go about looking at something that’s new and say it needs to be something that we need to be at?

Kishore Koduri:

Yeah, that’s a great question. So even though there’s a lot of journey in the cloud, it is still not that old. So I think the first exposure to cloud is where we have one particular application, which is a legacy application at Monsanto, which brings a billion dollars of revenue. So it’s a huge application in that terms. And it has thousands of users and it brings a lot of profit to Monsanto, but it was not scaling to the use because we wanted to expand it to other countries. We started in one country, we are adding more countries to it, so it’s adding a lot more users to it. So that is the situation. So then we said, Hey, why don’t we start looking into cloud? That is how we started that. Like anything else, we started with the proof of concept pilot and rolling out gradually. Like any monolith, which is so business critical, which brings a lot of revenue to the company, a lot of ice on it.

And we were looking for agility, reliability, availability, and cost effectiveness. So those are some of the principles we were looking. Obviously cloud checks, all of those, right? There is agility because you don’t have to wait for your infrastructure department to set up servers, which may take its own sweet time. It has a lot of resiliency because you can have multiple regions or multiple ways of doing it. I’m not suggesting all applications need multi but you have different ways of resiliency. And availability, again, you can scale up much easy horizontally or vertically and then cost effective for sure. It is cost effective in short term. And there are some questions about long-term that is a conversation for another day, right?

So that is the journey we started with and slowly, what we did is we migrated one piece at a time from monolith legacy application and then we did a lot of data synchronization. During this transformation, people had to log into multiple systems to get their user journey finished, but eventually after a couple of years it’s all moved to the cloud. We got a lot of rewards for doing it and there’s a fantastic user experience and the roll out of kudos and everything. It was very well recognized initiative. So then what we did is took that and replicated multiple times because we have a path for success, and how do we best customize it for future needs.

David Joy:

Yeah. So I’m curious to know about 1 billion dollar project that’s on legacy and it’s a critical piece. Why did you guys decide that you need to move that one? I’m assuming that you wanted to take on a challenge of looking at the most complex problem first, and if we could do it then it can be replicated more easily other places. Was that the thought process?

Kishore Koduri:

That’s a great question. Even though I said that is the project I’m more excited about, but that is not where we started. So we started with internal applications first and we did the pilots and proof of concepts like I was talking about, and then we ventured into this one. But even when we ventured into this particular mega project, quote, unquote, we started with again doing a pilot and we are doing a POC and make sure it fits our needs. What are the different frameworks we need to use? What are the tool sets we need to use and then expand in an agile way. You don’t want to do a big bang, you do one, create a roadmap, you do release one release to release three kind of a thing, and continuous delivery.

David Joy:

And this is an interesting point of view that you’re bringing that you are in a position where you also not just have to drive strategy, but you also have to ensure that somebody has a knowledge to move these. And when the cloud really came about at the time, you don’t have engineers sitting there who have the certification, there’s nobody there AWS certified or Google. Even I don’t think a certification existed at that time. I mean, I’ll have to go and check. But you are actually actively learning and applying. So you have this trial and error and then you have senior asking for how’s the project moving? And so how did you tackle all of that, being in that position?

Kishore Koduri:

Yeah,, that’s a fantastic question, right? It is not as simple as copy paste and most of the transformations we need to look through into three lens people, process technology, like you are briefly mentioning people aspect of it is there is a lot of change management. It is change management inside IT or digital and also change management outside digital and to some extent to the customers too. So that is the first aspect. You need to upskill the folks you have. And also you need to have right level of engagement with some of SI partners to bring right level of talent to augment what is happening. And then the process side, it is not like you just take a old wine and pour it into a new bottle kind of a thing. Even though everybody likes old wine, that’s a different analogy. So I think you need to look into the processes and make it optimized. There’s a lot of transformation there.

Either it is the processes goes into building the application and also the business processes inside the application. For example, you need to look into what is the DevSecOps pipeline looks like? What does CACD looks like? How is your deployment on-prem may be different than what you do in cloud for example. Like you were talking about the talent on doing those foundational items. How do you do logging? How do you do monitoring and system health checks and unit testing, performance testing, you touch any of it. It is different in a way when you build a cloud application compared to a legacy application. So you need to build those muscles, you need to build that processes and then you need to scale them up when you need to expand from one team to, I don’t know, maybe 10 teams now, then how do you scale it and still maybe able to reuse them for a new application you’re going to build by other teams or so on.

David Joy:

Yeah. What you just said here, I mean for folks who are listening, what Kishore explaining here is a true testament of what it really takes to move legacy applications to the cloud and to re architect the application, just the amount of things you just shared in the two minutes, each of them is a cycle of effort that requires lots of brains, a lot of efforts and it truly brings the effort that you have taken to put something out. It’s not like building a new application, legacy migration is a big challenge. So when you were trying to do this, of course we have compute is easier, servers, okay, we have EC2 instance or we have instances available. You need network? Okay, we have networking VPC available. What was the biggest challenge in terms of migration? Was it the data? Was it the compute layer? Was it just breaking the entire application into small microservices and how agile? What did you feel like your team really did well and maybe you struggled with?

Kishore Koduri:

Yeah, I think, can I say all of the above?

David Joy:

I mean I really do take all of them.

Kishore Koduri:

So yeah, those are all challenges, but some are smaller lines than other little bit longer lines. So I think the biggest challenge we faced is taking this monolith and breaking into smaller consumable units because now you need to take a vertical cut, not a horizontal cut. If you take a horizontal cut then it cannot be as much of transformational because we still have a lot of dependencies and everything like that. And then our challenge is around when you do a vertical cut, how do you synchronize the data? So we went with microservices event-based architecture, we stood up for example, Kafkas and all those things. So it replicates still if one process is down, it is not bringing everything down with it. So you can still continue to do, you can have eventual consistency and then the data is eventually flowing where it needs to be.

And then user is continuing processes. For example, for this particular application we’re talking about if application is down, the trucks are rolling with seed, so you’re losing the revenue right there before you rise. So you need to have a way of collecting that information and still able to synchronize eventually. So some of the challenges like that I think, we solved it, but it took a little bit of a trial and error. Another one which is obvious for most of the listeners is change management, either inside change management and also quote, unquote, “business change management.”

There are certain ways that you’re able to do it and want to do it and they were doing it for years and now the dropdown is weight that is supposed to be, and the dropdown or check bots doesn’t do what used to do for tens of years if not years together. So doing that change management, now working with them, they need to log into two different systems to complete their journey, those kind of things. Those are challenging, but at the end of it is very rewarding. You can look back and see, man, we accomplished something. It is a lot better than what we started with.

David Joy:

I mean it’s so great to know that. I know just when you were seeing or sharing, I was just thinking this problem is so interesting to solve and not many people go in hard on to go and say, okay, this is an aggressive project, it’ll take time because everybody wants to solve the scale problem tomorrow. I want solution. But there is so much that goes into breaking a monolithic application and breaking it into a microservice that again, needs to scale. I mean you have topics that you’re writing into, but that topic has to be scaled in a way and replicated in a way that you will never lose that data in an event architecture. So you have to consider all those things. So you spoke a true veteran who has handled and solved these problems multiple times. So yeah,

Kishore Koduri:

Appreciate that. David. Another thing, we are actually working on moving one of the monolith legacy application to cloud. We were part of that workshops last weekend and before kind of a thing. So I was talking to one other person who was part of doing the initial implementation of that particular application, and again, it brings up millions of dollars of revenue, that particular application. And he said, I thought it’s fascinating. He said, Hey, when we rolled out this application for the first time, we introduced mouses along with that application for the first time. And again, it works, the application works, but it is not scalable, it is brittle and the talent is not there to make updates or business changes. It is difficult. So those are some of the reasons why we want to do it. But then being said, it is decades of knowledge and decades of customization you need to take and take a fresh look at it. And it takes years to redo this.

David Joy:

Yeah, that reminds me of an episode, or not an episode, but a conversation I had when I was working at a company. When the company was finally changing offices. The company had been in an office location for almost 20 years and then they were moving to new office, a new floor, much more modern setup. And then when they were moving, they realized that under a desk there was an AS 400 cap, which is an old, it was still running. Nobody knew what it did. And they were so concerned about unplugging that because they did not know what was running on that. And we knew that it hadn’t been touched for a while because whoever sat there was saying, well, it’s been around for at least so many years. So they’re talking about technology that’s working for such a long time and people are really wary of like, Hey, do we really need to change it? Of course we need to, but.

Kishore Koduri:

Yeah. I’m sure you have seen in some other desktops and servers that are stickers, do not turn off.

David Joy:

Yes, I have.

Kishore Koduri:

And people who put those stickers, I think they moved on and there are certain applications people do not know what it does and how it does. So you need to reverse engineers those things to redo them. Well, some of those challenges.

David Joy:

That’s how I feel sometimes when I’m talking to people who have been working on mainframe. It’s a great technology, but once you’re on it, it’s just so difficult for you to kind of think in another way and the effort is wild. So going back to what you were just sharing is now at Ameren, your control also entails these kind of efforts where you’re trying to move legacy applications into a more modern paradigm and more modern architecture and then these challenges still remain.

Kishore Koduri:

Yeah, that is right because we need to work very closely on various things. We talked about do we have right talent? We cannot take on multiple transformations at the same time. We need to make sure there’s the right level of organizational throughput and right level of subject matter experts and funding and you can’t throw too much change in the organization and still able to do a good job at it. So there are multiple factors. My team works closely with the various business and digital leaders to understand how do we lay it out, that is what we call it as ILTP, integrated long-term planning and we create roadmaps and make sure, hey, we have ability to do this, then it needs to stagger, these five things needs to go together, this needs to happen before we get to touch on this one. Those kinds of things.

David Joy:

And that’s how I think that kind of team is. Well, for folks listening, it’s so important for you to have that kind of a team in an organization because that then drives or connects business to the actual stories that are going to go into a release and there is an alignment. And if there is no communication, that can affect and cause disaster, that directly affects your revenue, right?

Kishore Koduri:

That’s right.

David Joy:

Well said. I wanted to ask about how do you look at cloud strategy right at Ameren? I know you’re moving towards or are on cloud as well, but what is important at Ameren now with the cloud strategies that you have? Do you get involved in conversations on what kind of solution to pick, do you think about multi cloud, multi region? How do you think about that?

Kishore Koduri:

Yeah. So we have a cloud strategy and recently we worked on revamping the cloud strategy. Change is the constant thing in IT, right? So like I was saying before, there are four things we critically look at. One is agility, second one is how resilient and availability and cost effectiveness. So those are some of the pillars in cloud strategy. We are making good progress. We have a strong team which implements DevSecOps. We have a strong team which works closely with Agile and make sure we can do these things in a way which is scalable as well as sustainable. And right now we are actively looking into what we call it as crowd hosting rationalization initiative. So as the name suggests, we have quite a bit of applications, we have hundreds of applications in our data center. And what we are doing is we are cataloging all of those applications and trying to understand what segment they fit in.

Are they ready to transform into cloud application or they need to stay back for various reasons including some regulatory concerns or do we need to retire and this is the time view to transform, invest, eliminate, and those kind of a view we look into, and we try to put them into different segments. Then we need to prioritize, this is a critical application, so maybe we need to prioritize based on the availability of resources as well as funding and so on.

And this is not as important application probably we can just lift it and shift it, right? With a view of, hey, we are going to eliminate it in five years. So we are taking different aspects, like we call it a decision tree, and then we are putting them into various segments and then we convert them into roadmaps. Now we take those applications and put a business case and put a roadmap around it. Then what is our two year window looks like? Four year window, five year window looks like. So we have a view into how much of investment we need and they know how does that effort going to look like and so on.

David Joy:

Got it. Yeah, and that also helps you with the planning of what-

Kishore Koduri:

Absolutely.

David Joy:

…talent you need, what kind of technology you’re going to go dive into. So do you have innovation teams that are focused on research early on too before you fully fledge out and plan what that looks like? Do you do that as well?

Kishore Koduri:

So basically the way we are trying to do this one is we have something called pre-work or pre-implementation we say it. So we say, Hey, for example, this particular application we need to transform. So we put a roadmap before we call it pre-implementation, which includes understanding about different opportunities or different ways of doing it, doing a POCs or pilots working with various SI providers, putting S4Ws, vendor discussions. Those are all we call it as a pre-work. Depends on size of the effort. It may run for months or maybe a year. There is limited value in jumping on it without knowing all the details. For example, I was talking about that application. We do not know how the current system works, so we probably need to do some documentation, understanding current processes and then we need to do some user journeys. We need to do some mappings around what does the future may look like. So those are all the pre-work you need to do.

Probably you don’t have to do what the individual story level, but at least you need to do it at the epic level. You need to understand. And then it gives you a good view of, hey, this is my roadmap looks like, then how am I going to chunk it into media’s continuous delivery and that is what we call it, pre implementation. And again, all applications do they need it? I don’t know. Depends on the size and criticality of it. We need to carve out some dedicated deliberate effort before we jump on it.

David Joy:

Got it. Yeah. And I know you mentioned this, but I wanted to dive into this a little bit more for folks who are listening to learn a little bit. So what drives the kind of technology you choose for the transformation, right? I know you mentioned scale, but is it driven by, hey, the company is growing, we need to add more utility users, there’s more data required. Now the experience that is required by these users is different. They want to see real time, Hey, how much electricity am I using? Where can I save money? So what is driving the requirement for the technology that you’re choosing?

Kishore Koduri:

Yeah, that is fantastic. I was saying before, we don’t want to implement or bring in technology just for the sake of it. So it needs to tie with some business justification or written non investment or some aspects of it. So we definitely need to do that. Going back to your question on what kind of technology we bring, it depends on the type of problem we are trying to solve. So for example, there is something called outage when a big storm goes through your territory or something of that. So it happens, you need to make sure the systems can sustain large volume of data coming in. Now we have so many transformers and meters pumping data or so many people are calling and there are outage notifications you need to send. So you need to have ability for that particular application or integration because I also lead integration. So now all that integration is a lot more chatty because so much of data coming in.

So you need to have ability to quickly scale up. And that is one critical component. And second component is when for whatever reason they fail, they need to come back very quickly. That is the resiliency aspect of it. And now you have the power is down and also your application is down. It’s not a good scenario. So you need to make sure the outage notification is also down. It is not a good experience for our customers. So you need to have fault tolerant, very resilient. So we are working towards the act two act to act two pass through kind resiliency strategies and having a good monitoring alerting. We are constantly improving, continuous improvement on that one. How do we make things better? We are learning from certain past mistakes and make it better. We don’t repeat the same thing again.

David Joy:

Yeah. And also learning from mistakes is just so critical too. It’s just a part of building a better solution is what I feel. Active, active, that’s the world I live in. I want everything active, active all the time. I don’t want to think about disaster recovery. CockroachDB is one of those solutions where I always felt like why do I need a dependency in my architecture or in my design? It should be a peer infrastructure, it should be, I can write and read all the time. I don’t need to just scale reads. I want to scale everything. And that’s where I feel like these architectures and these kind of design patterns kind of make sense. And when you were saying that active, active, are you considering or you are building your applications with Kubernetes infrastructure where self-healing, auto healing capabilities have to built into the infrastructure and application transformations?

Kishore Koduri:

Yeah, there are definitely. And also we have hosted in AWS and other clouds, and we also have some SaaS products. Like we use Salesforce, we use Oracle, we use other Maximo and other. Some of them are on-prem, most of them are hosted in cloud and they in turn, they bring some of those resiliency out of the box and all the custom solutions we have, like you just said, they’re running a container with right level of resiliency built into it. For example, we use MuleSoft for integration and they have cloud solution which has resiliency built into it. And we also use quite a few APIs on prem. So we are building active active for that. So we have two data centers and for whatever reason, API is down or one particular segment is down.

It automatically routes to the other active active region. So users do not even know something of this kind happens. So it is not just to that level now we need to look into underlying database. It needs to be active in some shape or form. And if you’re using message queues, if you’re using file systems, everything needs to have that kind of a posture. So the user process is able to sustain these kind of volatile tolerance and having that high level of resiliency end to end.

David Joy:

Right. Yeah. Of all the technologies you said, honestly, Oracle is the only one that I don’t like. Part of the reason is, part of the reason is, and nothing because I’ve working in CockroachDB, nothing to do with that. It’s just that my personal experience with new modern paradigms and new architectures that I’m building, I have to go in. I hate Golden Gate and designing replication that way. And I used to work at another company that had OPLS architecture. So I don’t want to think about failover at all or blue-green deployments. And so that’s why I use actively technologies, not just on a database level or I try to build it in a way that we have a pay less architecture and it’s done in a way that I don’t even think about disaster recovery. Only thing I think about is making sure I replicate the data to maybe another region and keep it there just in case my region is not available. That’s the max, but I don’t want to get involved in Golden Gate and things like that. So except for Oracle, I love everything else that you said.

Kishore Koduri:

That makes sense. If you keep that problem outside and it is solved already so you don’t have to solve it again, why reinvent the wheel if it is given to you already? Right, exactly.

David Joy:

Also, Oracle is just so expensive. Just

Kishore Koduri:

Yeah, I hear you.

David Joy:

Maybe we need to have a different conversation after this call. But I think what you said, I mean there is so many amazing insights that you shared about just the design pattern itself that you have to consider when you’re thinking about scale. It’s great to know that even utility companies, I mean we talk about amazing stuff that Uber is doing. Amazing stuff that Twitter is doing, or say DoorDash, all these modern new companies. But we have to realize that these patterns and these transformations are happening within companies who are Fortune 500 like Ameren, that have been historically known for building one lithic applications and things like that. So I’m really glad that someone like you were sharing that perspective with the listeners here. That’s great to know.

Kishore Koduri:

Yeah, so the user expectations are gradually going up. You just pointed out whether it is Amazon of the world, now it is X, not a Twitter, I guess. So X of the world and our Ubers of the world. So when users like you and me when we are using those services, then we go to a power company and use their website, your expectations are the same. So we need to meet those and if not exceed. So we are doing all these transformations. We are doing doubling down on these technologies where they’re applicable and Ameren is in top quartile when it comes to customer satisfaction. So we do that every year and we got awards from the customer satisfaction, we are in top quartile and that is very what they say is enforcing and that we are going in the right path and we are providing it to our customers what they’re looking for.

David Joy:

Right. And you were talking about this whole idea of looking at resiliency. Of course it’s important to you, but at the same time, how do you look at the whole build versus buy, right? I mean there is a lot of things that you can, and you’re in a position where you have to at least highlight talk or make decisions around, hey, this is something we need to buy. Why do we build and put engineering effort into something versus when something already exists? So how do you get into, give me an example of that as well as how do you think about those problems? Yeah.

Kishore Koduri:

Sure. See we have a decision three mantra. The way we try to do it is the emphasis is to go to cloud. And if there is an exception, that’s fine, but the default, quote unquote, is why not cloud? That is the first one. And also why we need to custom build when we can buy it. And utilities, there are quite a few utilities in states and maybe hundreds of utilities if you add all the countries in the world. So in many ways the problem is already solved. So we go that route of, hey, can we just bring a solution, which is like a SaaS solution that is the route we try to take in some niche areas where we probably need to do custom build.

And going back to your question on, hey, example of it. We recently implemented ERP, I think that is a good example where I don’t know how much value it is for you to custom build A E R P. And the same, we have a lot of, Maximo is one of the examples where we have lot of utilities, use it and I think some non utilities use it as well. So limited value building that kind of a functionality and custom build. So wherever it makes sense, bring a best possible industry leading solution and try to make it as a cloud hosted sales solution if possible.

And so that’s where we get into a lot of challenges around integration. We need to now have a robust plumbing to connect all the data coming in from various clouds and sales solutions and also on-prem solutions and how do you make all of this work and do not make it as a single point of failure? Imagine your plumbing gets choked now you have everything else working but no water flowing. So that is something very critical for us and we doubled down on making sure we have right level of emphasis on integration.

David Joy:

So I wanted to ask you, when you were saying that, is that you have all of these things that you have to do transformati?on on how do you vet out which technology makes sense for this? There has to be a vetting process. Have you built that into your engineering practice or your architectural process principle process that you have built?

Kishore Koduri:

We have quite a few patents established and we have standards established. We have a process, we call it technology work assessment. So TWA, so any new application or any new product when it comes through, it has to go through that process. We add bunch of requirements. They’re not always just architectural requirements. We give architectural requirements, data requirements, resiliency requirements, as well as cyber requirements. We provide those and then we weigh them based on that. It has to fit those particular requirements. And also we add in patterns. Hey, you need to have single sign-on for example. So it is weighed based on those criteria. And then we try our best effort to meet all the requirements. In some cases you need to throw in an exception for certain reasons. There is a regulatory reason or a timebound reason you need to get something done, you come back and register it later. So there is a vetting process before we bring some S4Ws or something like that, or a procured tool or a technology. We go through that vetting process and it is effective so far.

David Joy:

And the idea is that the process should enable innovation, but rather than slow it down, it’s something that’s right. You’re also thinking about that. Okay,

Kishore Koduri:

I agree. And that is why, going back to our previous conversation a little bit, we need to provide good guardrails that way people know, Hey, I understand I just don’t jump off and add no authentication and create a huge cyber risk or I expose all my data. But if you provide that a guardrail, I think it gives a lot of liberty for folks to innovate. And that being said, you need to constantly check in it just if your guardrails are in a well-placed location or not, or you need to move them around and make sure it aligns with what’s happening in the ground.

David Joy:

Right. That’s brilliant. Yeah. I wanted to ask, where does Kishore go for keeping himself updated with all the technology wildness that’s going on? I mean, here’s why I’m asking that question. 15 years ago you had a hundred softwares that you need to pick and you need to aware about and you would hear about it in conversations. And now we have 10,000 solutions almost. Like every cloud company has the same or similar solutions on their platform. Then there are third party SaaS products who are also solving this. And then there are all those other people who are innovating in the open source space. So how do you keep up with all of that and you’re in a position where you have to be like if somebody says something, you’re like, at least I should know about it. What do you do?

Kishore Koduri:

Yeah, to be honest with you, there are a lot of key buzzwords. I still need to be a little bit reactive. I need to go and find out what they mean because they’re a little bit contextual also. So I agree. It’s a constant learning. I think one of the areas I go into is Gartner. So we go there for research and try to understand what is the quadrant they’re in and some other. We try to do some little bit of research there before we feel comfortable and it needs to be, we set up some analyst calls and try to understand what, is the industry trends. And there are some industry consortiums. For example, EPRI, Eprin is an industry consortium.

We have some forums there. We go there and understand, hey, if any similar utility has done something like this, or what are the industry trends happening? And some assays, like Accentures of the world, Deloittes of the world, they also bring their perspective of what’s happening in the industry, other implementations they’re doing. And last but not least, I started using chat G P T and Bard, Google Bard, and they give a good perspective too. Obviously need to take it with a grain of salt, but that is an interesting new space to go as well.

David Joy:

Yeah, no, I agree. I think one of the biggest things that when you just said, it suddenly hit my mind as that I was talking to somebody else about it/ there’s so many papers that are getting released, research papers, and sometimes you feel like I don’t have time to read 30 paper or research paper to get that knowledge. Now you can pull that into ChatGPT or wired and it condenses it down and you have enough information there for you to have an executive conversation with somebody or have a conversation with your architect on, Hey, why don’t we look at this as an idea of implementing something? Right. It’s very helpful. I’m doing that myself and I’m glad to know that people in your position are also feeling that’s something valuable for you to try. So that’s good.

Kishore Koduri:

Yeah. Yeah, I think so. That’s why it got a hundred million users in two days or something. That’s what they said, right? Yeah. I think it definitely has value on how to use it, but you need to double check and validate. I think that is where it is right now.

David Joy:

And one of the ways I really do it is I will ask the same prompt on ChatGPT. I will ask it on 3.54 as well as on Bard. And the difference really is the output. The output from intelligence or the way it makes me feel GPT4 does a great job, but it doesn’t have internet data unless because they had the browser plugin available and they took it off because of an issue. But Bard gives me more realistic timeline, and so I agree with you. Validation is the biggest factor where it comes to AI LLM.

Kishore Koduri:

Meaning that’s still maturing, right? We need to give them a little bit of a slack. They’re working on it, I assume.

David Joy:

Yeah, I’m assuming, because I’m paying $20 just for that

Kishore Koduri:

Plugin. That is for the ChatGPT 4, isn’t it?

David Joy:

ChatGPT4. Yeah. And I use a few plugins as well. I use a PDF plugin. I also personally use the Instacart plugin, which I feel is a great use case where we make our meal plans on Instacart. So what we do is ask to produce a meal plan for us and then I bring the Instacart plugin, it creates all the ingredients I need for the week. And you just order it directly from Tom Thumb or an RD?

Kishore Koduri:

No, that’s awesome.

David Joy:

That’s a pretty practical use case.

Kishore Koduri:

Yeah. I’ll tell you one more practical use case, which I recently did. We went to Iceland for vacation, and then I went to one of these region ais and said, Hey, create diary for me. And it did for multiple days and I tweaked it a little bit here and there and it worked. I just used that iterate.

David Joy:

Exactly. The way I see these is it’s enabling us to save time and refocus that time towards something that might need more attention. And somebody like me, and I feel like you who wants to save time and make the time more valuable, I think definitely is a place to invest in.

Kishore Koduri:

Oh, I agree. I think we all become like region AI experts very soon.

David Joy:

Yeah, I think so. I think we will be. Well, I know we are getting towards the end of our podcast and I mean first of all, some of the things you shared is prospectively so important for folks to consider when they are moving from legacy and re-architecting everything. For a modern architecture or an agile thought process or M service and things like that. For companies who or folks who are trying to build infrastructure like this or looking to move in this direction, what is your advice to them and what would be your, I know you’ve already mentioned a few things, but what do you want to say that this is what you have to stick to make sure that you don’t make those mistakes that probably you have made in the process?

Kishore Koduri:

Well, yeah. Everybody has cars in the back, right? For sure. I think it is not just a technology problem. I think that is what I probably emphasize. Again, it is a people process technology. You need to look through all three lenses. I think making an assumption that technology only can solve everything is probably a pitfall. You need to make sure, like we talked about, do you have right level of skills from the people perspective and how do you upskill them? Or you need to go to somewhere and get augment, right? Skillset. Do we have right level of subject matter experts in technology and also in the business process? And do we have a product mindset if that’s what you’re looking for, and are you able to take that big piece of delivery and can you chunk it into smaller pieces and show success, show delivery, continuous progress and value?

Are you able to realize that value as soon as possible? So I think you need to look through all three lenses. I think technology in many ways is easier problem to solve in a corporation than people and process perspective. That’s what I would recommend and encourage people to take a look when you’re embarking into this and take one step at a time. You don’t have to do the whole thing like a big bang approach. It is not usually the best way to do it.

David Joy:

Sure. That was great advice. For folks listening in. Kishore is active on LinkedIn. I think that’s one of the places where people can follow you. Is there any other place that you recommend people can connect with you or learn from you in terms of material that you post or repost?

Kishore Koduri:

LinkedIn is the best way and happy to collaborate with folks and learn from them as well as I can provide my thoughts as well. Happy to do that.

David Joy:

Okay, sure. Thank you so much for being so candid and for all the amazing ideas that you shared, all the big ideas in our architecture podcast. It has been a pleasure to have you here and again, I appreciate it.

Kishore Koduri:

Thank you, David. I can’t thank you enough for hosting me and thank you for this opportunity. Thank you and good luck with you.