The Self-Documenting Enterprise: Building an AI-Powered Service Catalog - Srikanth Vinnakota

In this talk, Srikanth Vinagota, a director of software engineering at WEX Health, discusses the integration of AI into their software development processes. He highlights the challenges of managing documentation in enterprise environments, where service development often occurs in silos. To address this, he introduces a tool called AI Scanner, which automates the generation and updating of structured YAML metadata files based on code changes. This tool analyzes the project's code and configuration files, extracting details such as frameworks, databases, and API dependencies. By automating documentation, WEX aims to improve efficiency and ensure that information remains accurate and up to date, ultimately enhancing the visibility and management of their services.

I'm Srikanth Vinagota. I'm director of software engineering at WEX Health. At WEX At WEX we basically work across delivering solutions to mobile mobile fleet management and payment corporate payments and we are and we work in health and benefits. I personally I work in the core platforms over health and benefits. AI at WEX we started off at uh I think uh we are one of the early adopters

of AI. And AI at WEX has been the core center for the software engineering thinking process. We do It's okay. So, at at when when we start when we started off with AI we not just provided a range of tools for our for our developers to use, but also we have provided a safe environment for them to experiment and innovate. And as a result, what we have

seen is multiple tools and multiple frameworks that have actually accentuated not just our technical stance, but also we were able to deliver massive business business benefits. So, today in tune with the developer forum, I I've chosen to spoke about one tool which which fixes a problem that I'm hoping most of us would could resonate with. Okay. Having said that, I'll move on to the presentation. What When

we when we work in enterprise situation, we have noticed we might have noticed many times that you know, we are developing services in in silos where you know, different teams at different places are probably developing delivering the same kind of service with similar capabilities. Why is that? Because there is not an efficient way to one discover your services. And even though if let's say I discover your

service using let's say we use something like a confluence to put up a page like oh, all our services should be here. They should know we should know who's building it, where they are. But that had the overhead comes when our developers are actually making changes to the services. So all the incremental changes when we make, are we going there starting to update those documents on a

regular basis? And are they ever up to date? In my experience, they are usually stale. They are usually stale. And they also give a misinformation, right? You might have probably solved two challenges at when you first went live and those are very well documented. Then later you have made changes. You have made improvements to change the APIs. You probably optimized your database from let's say SQL to

right? But all those changes are not there. So when someone actually looks at your service, what would they what what they get is not what's actually there in production. Right? And this overhead is very generally treated as a big overhead because documentation and developers don't go hand in hand most of the time, right? We when as as a developer as a developer I have been a developer

and I still do a lot of coding. So myself, I do get lazy when it comes to documenting. So what we thought was why not completely kill this overhead? Because with the with the use of AI, why don't we completely automate this process where the documentation is self-driven? We don't have to worry about it. I do what I do best. What developers do what they do best,

they they they code and they deliver the optimal solutions. Let the documentation be the overhead for someone else. Right? In that basis, what we did was we used our we developed a new tool called AI scanner which basically what when we start with a new service, let's say I'm I'm going to now create a new repo for a new service and I on my first setup, my

fabric will recognize my repo and then it basically passes through my code files, config files, and the entire repo and makes a meaningful structured metadata out of the code. So, it basically it looks at what tools am I using, which framework am I using, what technology am I using, am I do I have a dependency do I have a dependency on on an external API, what kind

of database am I using, right? At the very beginning, my my AI scanner would look at my core core repo and you it creates a structured YAML metadata. Now, that structured YAML metadata file becomes a part of your repo. Right? Now, what happens when I keep making changes? Like, I don't want again someone to go and change that YAML file. So, I want to automate that as

So, we'll see how we have approached that problem and I'll also walk you through. Let's say I've created my .NET repo, right? My AI scanner would start looking at this. My AI tool will actually go through the dot the repo and it then realizes based on my project files and my my my code files, it detects that, "Oh, it's a .NET framework." Then, it actually goes and

sees, "Okay, for a for a .NET project, what are the or or a C# project, what are the files that I should actually look at?" And it starts collecting those files and then passes them on to our LLM. That's where the AI analysis is at. That's at the heart of this analysis. What it does then is actually goes through my config files, look at what endpoints I'm

hitting. It goes through my packages and sees what packages am I using. It actually goes through my code and sees, "Oh, there are these controllers, that means I'm connecting somewhere." And then it starts making sense of all of that. Right? Now, as we all know, when AI generates a file, we cannot blindly trust that. So, what we do is we we define a CMDB schema and this

file is validated strictly against the schema. And when that schema validation has is passed, that's when it actually generates that output file. So, once you have that YAML structured So, again this this basically is more relatable to the test. So, like you see there's a CS project and it so goes into the configs and sees oh, we are using a new net and then we are using

ops level and then 10 charts are used for CI/CD. So, so on and so forth and that is that's how it starts interpreting that into human readable language and it starts understanding which frameworks am I using, what am I using for my infrastructure, how is my source code documented and is if there is a read me file, then it goes through the read me file as well.

So, the end product is this. So, you have a purely structured YAML file which not just tells you what is the application, who built it, what is the code repo, where is the code repo, but also it now also deals with okay, the primary language is C#, what is the framework that I'm using. What do I use for CI/CD and internal dependencies, external dependencies as in external

APIs. It also detects what kind of database am I using and where is it hosted. So, as part of If you have noticed that YAML file, there are fields that I own the repository, this is my repo name, this is a service name and this is the team that you need to contact. Those are usually the not the fields that that would change, right? What would change

mainly is maybe the .NET framework we might have uplifted or you might have changed may made some changes to the APIs or the databases. So, that's why it treats as that YAML file into two parts. One is static which is usually retained and then the dynamic. So, every time every time I make a code check-in or a PR is merged, it goes through the code and it

starts detecting new additions or deletions or any modification. And then it starts deriving if there are changes to the frameworks, changes to the dependencies, or any other external stuff. And what it does once it's once it gets that is very similar to >> [clears throat] >> what what a dev would do. It would goes in to the YAML file, makes all those updates, and it pushes those

changes to the Git repo, and raises a PR. So, the raising of a PR is kind of a fail-safe check so that it does not write everything anything or everything, but the dev team still gets a chance to review what has changed, and all you need to do is approve, and it gets performed part of your repo. Now, now that we know how the YAML file is

generated and YAML file is updated, and all this talk's done, now let's actually see how it works in the tool. this is coming up. Okay. So, this is the service catalog that I'm talking about. So, in our Wex enterprise, all the services across lines of business, like I told you, we work across corporate payments, we work across fleet management, health and benefits, all the services come and

reside on this catalog. So, it basically goes through the Git repo, picks up these YAML files, and understands how many services we have. It not just does that, it sees what tier it is is it a business critical or a low priority, at what state of life cycle is it at is it in development, is it in production, or is it is is it deprecated? Right? And

it like I said, it starts detecting the frameworks, Java, C#, Python, TypeScript, and the teams. For this demo, I have created this service. So, for Git's demo service, if you look at this service, I can show you how our metadata is now interpreted and visualized. So, if you look at this, you have you you see a basic summary of what this does, where the ownership lies, what

is the technology stack being used, and what are the internal dependencies, what is the database being used, what are the external APIs that we are There is also uh simpler visual representation of the same, where if in you go here, you'll see this is your and you have your API stripe and package and all the internal dependencies listed over here. in here, you can click on this,

and you can actually look at the repo that's the service is hosted at. So, for the sake of this demo, we have made a few changes to this code base, and that PR is raised, and I would like uh my uh buddy to review and approve Sorry. This PR is a code change, a feature change or a bug fix or anything, right? So, our developer has raised

this PR, we look at the changes. If you look at the file changes, so, he's changed the name of the owner from John Doe to Jason White. Uh added some MongoDB related entries, right? And uh what else? There's a business benefits web hook That's it. we go back now. Okay, it's ready to merge. Thanks, Kaushik, for approving. So, when I merge when I merge this, my GitHub

actions start triggering, right? And uh this is the uh this is the task that I'm looking at. So, see how how this update service catalog is running? This is basically looking at uh the current code. It's actually uh passing the entire code changes and seeing what is there. And then, if you see the next task is ingesting that into the catalog. Right? So, now that the ingestion

is also done, what it does, what it should do like I told you before, it should go there, look at all the changes that it needs to make to the YAML file, and make the changes, push, and raise a PR, right? Let's see if that PR has landed. Yeah, yeah, please. Uh that's software development uh thing, right? So, that's the basically release your uh branch management uh

strategy. So, how do you create feature branches or bug branches or how do you maintain Yeah. So, it's it's very similar. However, exactly. It's exactly it's it's just treated as one of the files from your Git Git repo. Yeah? Awesome. awesome. So, if you now look at it, there's a AI generated Git's demo service service catalog. For that, there there is a new pull request that's landed

with me already. So, all I have to do is get in there. And again, I might I request Kaushik to approve it. Okay, cool. Nice. So, now if I go back to the same service, if you remember, we had dependencies. Now, let's see if that has changed. So, if we go back to the same service now, and if you go and view the dependency graph, like you've

seen, let me quickly check if the code has been merged. Still waiting. No. Let me see if my actions are stuck. So, there it is. It is still ingesting, sorry. That's That's why it changes haven't reflected. So, basically my AI would again scan the same file and make sure that this time again are there any further updates. So, it should It would compare it to the previous

version. And once it once it's happy or now it's done. So, now it basically should see the changes. So, now if I go back to the catalog and uh I'm being very cautious not to expose any of the corporate Oh. And now we can see that now a MongoDB service has been added. So, that's a new dependency that has been added here. And if I go back

here and if I go down scroll down a MongoDB that's that has now started appearing here. So, whatever changes that you make, whether we make it to the YAML file directly and or the code, it will be scanned. And in the changes like let's say for whatever reorg or restructure that happened within an organization and now you want to move this ownership to a new team. At

that time you would not actually change any of the code first, but you would actually change the static part of the YAML file. Right? And even in that case it'll go, make a comparison, and see changes checks that okay, actually there is a human human override of these fields, and then it'll approve, and it'll scan, and it'll raise a PR if it is required. Okay? So, that's

basically our demo and our tool that we have created entirely in-house. This is for one is for better visibility of our services and completely removing the AI documentation documentation overhead from the developers and keeping our documentation up to date on a daily basis. All right, thank you so much. >> [music]