Intelligent Operations at Enterprise Scale - with Dhrubojyoti Das Deb of JPMorganChase

Daniel Faggella (0:12)

Welcome everyone to the Emerge AI in Business Podcast. Today's guest is Dhrubojyoti Das Deb, Senior Vice President of Global IT at JPMorgan Chase. Dhrubojyoti discusses why alert overload has become one of the biggest operational drags on enterprise IT teams, and how AI driven correlation can group thousands of alerts into a handful of actionable incidents. He outlines where human accountability still sits once AI takes on more triage and root cause analysis, and what leaders can do to start moving their teams from reactive firefighting toward more intelligent operations. Today's episode is sponsored by BigPanda. A quick note for our audience that the views and opinions expressed by Dhrubojyoti on today's program are his own, and do not reflect those of JPMorgan Chase or its leadership. In this episode, we cover how AI can help teams cut through alert noise. To go deeper on this topic and learn how to structure landing pages for higher conversion and how to use self-qualification systems to prioritize high-intent leads, download our free PDF report B2B AI Lead Generation Guide at emerj.com/aig1.

That's emerj.com/a-i-g-1 to download your copy. Now the conversation with Dhrubojyoti.

Dhrubojyoti, welcome to the Emerge AI in Business Podcast.

Dhrubojyoti Das Deb (1:48)

Thanks, Yolande. It's exciting to be here. Thanks for having me over.

Daniel Faggella (1:52)

It's super exciting, and I'm very excited about our conversation today because it's all about trust and alerts and noise and managing all of that. And I think something that comes up in almost every conversation that I have around this topic is that teams are drowning in alerts, and they spend half of their day trying to just figure out which of these alerts are real and need their attention, and which is not really an actual problem.

And you've kind of lived inside of this. So perfect person to ask, where does the friction actually show up for most teams trying to stay ahead of incidents?

Dhrubojyoti Das Deb (2:29)

Yeah, that's a very interesting question. So right now, I think we have moved from less information or no information to too much information, like going down the line, like if you go back 10 or 15 years, we had systems running with very less logging, very less traceability, very less observability, very less telemetry, but going forward, like as we had evolved, so has the data, so has the logging, so has the tracing, so has the volume coming in, the business has evolved, and so the data has evolved with it.

We have created intelligent applications to log data, but I think at one point of time, we never had too much thought given into how we are going to handle the data and how we are going to line the applications in sequence so that we know where the point is coming from, where the issue injection point is coming from. So I would say in two words, it's alert overload that we are dealing with right now, where we have a complex chain of systems lined up, and with different applications stack, like the tech stack that we call, different applications talk to different applications, each application has their tech stack, and when they generate the data that is in silo, that data is not getting fed to the next application, and that happens, and that can get cascaded down. So if you look at the whole picture, starting from top to the bottom, there are multiple applications, multiple levels of data, which are kind of sitting in silo, and there is not a central point, which is kind of marrying this data together. So if there is an incident, we are tracking incident at different points in the application, at point 1, point 2, point 3, point 4, but not on a holistic level. So much of the time gets into figuring out if the issue is actually coming from the application, where the alert is coming from. So let's say we have five applications which are talking to each other in a sequential manner or in a parallel manner, and we have a red dashboard on application number 4, which is kind of sitting down at the bottom. Now it so might happen that the data that got generated and fed into application 4, it's impacting application 4, but it's a problem with the data that got generated in application number 1

So how do we know? Because no alerts came in application number 1, it passed to application number 2, 3, and when it went into 4, something flipped and then it's showing as red. So how do we know that the issue is there in application 4? The punch of time, it will take operations to find out whether it's not a problem with application 4, but it's going beyond and going at the top. So I would say the main frictions of ID operations right now are, one is alert overloading, where there is too much data to process. The second is, it's a complex dependency stack, because each application, when it's talking to another application, it might be a different stack. One is running on Java, one is running on Python, one is running on C, and then we have AWS coming in, then we have AI coming in. So all those things create a difference in the dependency stack. So we need to take care of that. The third thing that I would say is with CI-CD coming into picture, like continuous integration and deployment, applications are changing very fast. So we have multiple installs in a week, and multiple installs in a month. So the state of the application that was a week before, it may not be the same as a week after, and all these changes are coming with tons of data, which is going down the line. So new data is coming in. Is that getting into the traceability? Is that getting into the telemetry like the way it used to? That's another bigger question that we need to deal into. And the fourth thing that I would say is the SMEs, the people who actually know the application, because they're engineers who know stuff on the application, and then there are engineers who know what they're doing, but they don't know how the application runs.