The Future of B2B Flow Intelligence

In this episode of What the Hoot!, Michael Jauquet, Director of Demand Generation and New Business Development at meshIQ, speaks with Navdeep Sidhu, CEO of meshIQ, about the rise of B2B Flow Intelligence and why traditional observability is no longer enough for modern enterprises.

From EDI and MFT to APIs, MQ, and Kafka, they explore how organizations can move from reactive system monitoring to proactive transaction assurance across complex hybrid environments.

Learn more about meshIQ at https://meshiq.com.

Follow meshIQ on LinkedIn for more insights on messaging, observability, and enterprise integration: https://www.linkedin.com/company/meshiq/.

Transcript

SPEAKER_00 0:05

Welcome back everybody. Thank you again for joining What's the Who? Mest IQs podcast. And from Mest IQs that today, we have special guest now teams to do who is our CEO, but he has a strong background at B2B. In fact, he was a product manager for Sterling Integrate back in the day, and later worked about WebMethods trading networks, also B2B, and launched Web Methods active transfer to MFT product. While I met Web Methods, and between 12 years of experience there, Dorina Sterling is about 15 years of B2B and NFT experience. So we're really lucky and really excited to ask us some questions to that people to hear his thoughts. But now I again really appreciate your time. I would love to hear directly from you. If you could tell us in a few words, you know, what is B2B flow intelligence? What was the genesis of the solution, its capabilities, and if we could, it's a real-world application.

SPEAKER_01 1:02

First of all, Mike, thank you for having me today. And uh since you talked about uh B2B flow intelligence, which is one of my favorite topics, uh I usually describe B2B flow intelligence in just one line. And the line is that it is the ability to see, understand, and assure the business outcome of every transaction end-to-end, and not just whether the systems are up and the transaction was processed by just one application. And the genesis really came from the gap we kept seeing across customers. And you mentioned Sterling, and then you mentioned WebMethod. So, you know, every product out there has some level of visibility built into the product. But if you look at from an enterprise standpoint, enterprises have invested heavily into B2B, EDI, MFT, VANS, and they handle millions of transactions per day. And when something goes wrong, nobody can answer a simple question did the order actually go through or did the payment actually go through, right? Everybody looks at the problem in silos. Everything looks green, for example, at the EDI gateway level, but the business process was somehow broken, and then everybody goes on to this fact-finding mission on why this problem happened. So from a Genesis standpoint, B2B flow intelligence naturally emerged to bridge that gap. It connects the dots across EDI documents, files, APIs, and even MQ Kafka events to monitor a single business transaction end-to-end. And so that was a little bit of a genesis in the history. And then let's talk about capabilities. So from a capability standpoint, it does three key things. One is the end-to-end visibility across systems deployed anywhere, which means across on-prem cloud, SaaS, whatever, right? Hybrid cloud, as we call it. And the second thing is the ability to do transaction correlation across both async and sync boundaries, right? So whether the file, whether the messaging, whether it's a sync API or async file transfer, everything can be correlated. And ultimately, the idea is to give proactive assurance, detecting issues across these transaction boundaries before the business starts to get impacted. So you may wonder you know, these are all very technical, and but in the real world, how does it show up? So, from a real world standpoint, if you're a retailer, making sure the order was placed on an on your e-commerce platform, and not only you accepted the order, you processed it, received the payment, it actually gets fulfilled. So we can do end-to-end monitoring or as we call it, flow intelligent. The second example here is you're a bank, you're processing millions of Swift and ECH transactions, and you want to make sure they don't get stuck between the systems. So the payroll and every other payment that you're making is happening without a hitch. And finally, my last example here is supply chain events across partners so that all of your suppliers are getting paid on time and there are no penalties that they are chasing you after, right? So it's at the end of the day, it's all about moving from system monitoring and silos to business outcome assurances.

SPEAKER_00 4:31

These are some incredible applications. And obviously, these capabilities are working for a myriad of technologies. So love to see it. You know, it makes me think, you know, when designing this integration across a hybrid stack, what are the what are the primary risks uh to the transactional integrity during that handoff between asynchronous messaging like IBM Q and the synchronous APIs? And really, how do you implement a single source of truth for that transaction state?

SPEAKER_01 5:04

Yeah, this is uh one of the hardest problems in the modern integration world. When you move between asynchronous systems like B2B EDI, which are file-based, or even messaging, which is sort of real-time, but you know, async, and then you have synchronous, you're introducing gaps. And these gaps could be timing gaps, retry gaps, and even ownership gaps. Realize businesses looking at IT as one thing, but IT has different teams. One team is managing B2B, and they will say, hey, we process the payment, it should be good, right? And the next team, which is managing MQ, they have a Q which is down and the payment actually never made it, right? So the biggest risks in these uh complicated scenarios, I see, are first of all, you lose the context between the systems, what distorted as one transaction becomes fragmented. Second, is you have duplicate or partial processing, and then you may need retries, you're trying to bring the system up, and then you're calling, hey, can you retry that file again? Because we had a queue down on our end, and the payment actually didn't go through, and then you end up with duplicate payments, and then you have silent failures when one step fails, but the upstream systems they think everything is fine, right? And the root cause of all this is pretty simple. There is no negative single source of truth across these systems. So, how do you solve it? You don't try to force one system to become that source. Instead, what we recommend as part of our B2B flow intelligence is that you build a logical transaction visibility layer on top. What that means is you assign defining uh transaction boundary at the start. So you assign a transaction and a boundary for each transaction, and in the boundary you basically say, hey, this is where the transaction starts and this is where the transaction ends, and then you start gathering metrics between that boundary across every system. It could be your EDI MFT application, messaging queues, APIs, etc. And then once you have all these metrics, you're continuously correlating those metrics into one unified view. And think of it from a simplicity standpoint, think of it as a digital thread or a digital twin of each transaction, and you are gaining intelligence into each thread. So if you're a bank, you're processing 10 million payments in a day, each thread can be uniquely monitored end-to-end. And once you are able to achieve that, then you can answer questions like where's the transaction right now? What step in is the transaction failed? And is it recoverable? What needs to get alerted? What system needs to get restarted? And what that these two or three points, what they do is you ultimately create a reliable source of truth, not a system, but a continuously updated transaction narrative, which is extremely helpful for the business.

SPEAKER_00 8:10

Interesting. Interesting. Well, it makes me think the move then towards hybrid or or cloud native brokers has introduced incredible scalability, but it has also shattered the traditional single pane of glass visibility we once had on premise. So, in that scenario, what is the most significant shift you've seen in how teams now must approach B2B flow intelligence now that their data is moving across such a fragmented stack of legacy and modern systems?

SPEAKER_01 8:44

Yeah. The biggest shift we are seeing is that we have gone from monitoring systems to monitoring flows. And if you see how IT has evolved, if your IT team was in one location and you had three teams, they were all able to talk to each other, you had a problem, they could just talk over the cubicle and say, hey, you know, is this up and is this working, right? The reality is some of our larger customers, they have tens of thousands employees in IT, and they have a look, you know, IT team situated in six or more locations. Uh, and you can't be into the business of monitoring systems anymore. It doesn't work, right? So you have to monitor the end-to-end flow. And today a single transaction might touch six or you know, 12 systems between half a dozen to a dozen applications, and it may go through uh B2B EDI, MFT solutions, on-prem messaging, MQ, cloud streaming, you know, Kafka, uh API hosted on Kubernetes, a bunch of SaaS platforms, third-party fulfillment, third-party logistics, right? So in those uh, you know, about a dozen halves, there's no single pain-up class anymore. And honestly, there never will be, because once you build it, the transaction boundary is going to change and evolve. So teams have to rethink their approach, right? So if let's say you are monitoring 10 applications and you know, you sunset one application and added two more, and the transaction boundary just expanded. So the teams who are organizing visibility by technology silos will have to keep up, and then it's a better way to start organizing your flow visibility or flow intelligence uh across business flows instead of each technology hop. And this is a mindset, mind uh mindset shift, right? So instead of asking, is the B2B gateway up? Are the MFT transfers happening today? Is my Kafka healthy? Are my brokers up? Producers and consumers are running fine. You may instead need to ask, are my orders flowing from order capture to fulfillment without friction? It's a very it's kind of a similar lens, but it's also completely different because you're not monitoring individual transaction processing applications. You are more interested in the business outcome. It's a different lens.

SPEAKER_00 11:18

Yeah, make that mean, you know, as soon as you said that word friction, it made me think of the, you know, you know, we often we often talk about high-speed commerce, but we rarely talk about that friction. You know, that that digital friction that happens when a transaction is it's technically successful, but functionally incomplete. So from a business standpoint, you know, why has a transactional assurance moved from the back office IT concern to a frontline priority for maintaining revenue integrity and more importantly, customer trust?

SPEAKER_01 11:50

Yeah, you hit the nail. It's the customer's trust and uh customer's uh experience and also your supplier satisfaction. Uh if you're a retailer and you're buying uh tons of goods from a supplier and you're ranking their your suppliers, they're also ranking you, right? Are you worth doing business with? And are you worth giving all the discounts when every payment that they're receiving from you is actually getting late, right? So this is where the things actually get really, really interesting. In the past, if something broke, it was an ID issue and you had time to fix it. Now every transaction is tied to revenue, to customer trust, experience, brand trust, supplier satisfaction. So that argument that a technically successful but functionally incomplete transaction is actually worse than a failure is true now because customer thinks the order went through, but it actually didn't. And the systems are thinking everything is fine, but the business outcome is getting impacted, and the transaction that you think went through didn't happen. So digital friction is real and it's becoming um more complicated, more complex as the systems are evolving, and now we've with the AI, there's another hop, right? So as I mentioned earlier, the system boundaries just keep expanding, right? So you don't want lost revenue, you don't want chargebacks, you don't want customers' churn. Every transaction assurance has now moved to the frontline because every broken flow is now a business event. It's not just a technical event. And it can impact your revenue, chargebacks, and customers' churn. So you don't get it right. Um you need to protect that revenue in real time. Yeah, absolutely.

SPEAKER_00 13:25

Yeah. You know, I think one of the major hurdles for a lot of these support teams is that false positive, right? Where technical monitors can show that every queue and every broker are healthy, yet a critical business process has stalled. You know, how can practitioners solve that problem of the visibility gap so they can they can detect a stalled business flow before the results in financial penalty uh or even a lost customer?

SPEAKER_01 13:56

Yeah, this is uh absolutely frustrating problem for the operations team, any operational uh whether it is the B2B team or the infrastructure team that is managing your brokers and queues, because everything seems green. The B2B gateway is up, MFT system is processing files, they're not seeing any failures. The queues are up, brokers are running, latency looks okay, but the business process is somehow impacted. And the issue that traditional monitoring applications will answer is the systems are healthy and the latency is fine, and but they will not answer are the transactions progressing as we had anticipated. And to solve this complicated problem, the teams then need to introduce flow-level intelligence, right? Instead of looking at the silos, you look at end-to-end business transaction flow. And you need to do some work there because you need to define the transaction boundary, first of all, to define what is the complete transaction looking like, and then you start tracking each transaction against expected milestones. You can set time level thresholds, not just system metrics, right? If the transaction is progressing, but there was a gray outage in your task, and it took it took three more seconds and caused uh uh downstream failure, uh then you know the uh order has not moved from validation to fulfill fulfillment within certain time frame, and you need to flag it, right? So by detecting these, you become uh more proactive. And the this whole shift of monitoring flows enables you to make that shift from reactive to proactive. And the idea is pretty simple measure the progress of your transactions, not just the performance of the applications that are handling the transaction.

SPEAKER_00 15:53

Make sense? I feel like we've all been in a situation, or at least you know, worked with a team. Middleware team is the reporting normal Q depths or in latency, yet the business side is seeing a drop in orders or a delay in payments. You know, I'd love to learn from your experience, you know, how how do you move beyond just sharing that technical raw data and start presenting business health indicators that actually empower the stakeholders to make decisions?

SPEAKER_01 16:27

Yeah, and and the stakeholders are becoming more demanding, right? So they are they are assessing the process flow level intelligence, and they are asking for more business transaction level metrics than ever before. And by just saying, hey, the B2B gateway was up and we processed this EDI file, um, or you know, my cues look healthy, the throughput seems fine, and the latency is uh not an issue, then what went wrong, right? So you can spend hours after each failure to do detective work and say, oh, well, this happened at this time and usually it doesn't happen, and we were not able to catch it. Uh the business stakeholders don't think in those terms, right? They want outcomes. They want completed orders, they want payments being processed, they want their SLAs being met. So, how do you step up, change the game from these technical signals into monitoring and measuring business outcomes? And instead of saying we processed 99.9% of EDI files successfully, you can say 15% of today's orders are at risk of missing SLA due to A, B, and C, right? That is very actionable. Um, and to get you there, you have to map B2B transactions, processing events to business stages, define KPIs at the transaction level, aggregate them into business health dashboards, and you change the conversation from diagnostics to decisions about transactions and transaction flows and SLAs and penalties, right? This is where the IT then steps up and provides to stakeholders what they actually need to act in time. Right?

SPEAKER_00 18:16

More happy stakeholders-driven decisions. Absolutely. Love it. Um, you know, I have one last question for you, Dev. Um if an organization realizes that, you know, today that their current support model is too reactive, right? We talked about proactive versus reactive. Their current support model is too reactive. They're waiting for a partner to call and complain. What are the first steps that they should take to build a more proactive governance framework that scales without having to add a massive amount of manual overhead to the IT team, which is already swamped?

SPEAKER_01 18:53

Yep. Great question, Mike. And uh every problem starts by acknowledging the truth that it is a problem, and then by by brushing it under the carpet and saying, oh, well, we don't have any problems. It happens once in a while, but you know, we just paid half a million dollars of penalties, and wow, well, you know, the supplier is disputing this payment and they want uh a rebate and whatnot, right? So first of all, um, you have to acknowledge the truth that you have a problem and you can't scale in this reactive model for a real-time business. You want to run a real-time business, you have to be proactive. And you, if you're waiting for the partner to call, it's already too late, right? The partner and the customers, when they call, you have already impacted the experience, you've already impacted the trust. So the shift to proactive governance typically starts with three steps. Identify your critical business flows. Not everything matters equally, right? So focus on order to cash, payment processing, partner integrations. Totally up to you. Every business is different, and the critical business flows in your business may be different. So identify those critical business flows, define what good looks like, work with your business team, set expectations for completion time, success criteria, failure threshold, SLAs, penalty alerts, everything that you think is important to business, sit with them, define what good looks like. And finally, once you have all that nailed down, you instrument for visibility. You instrument for flow level intelligence. You set up your alerts at that level, not just system alerts, but you monitor transaction delays. You have proactive visibility into stalled processes, and you look at those SLA breaches very proactively, and you alert the partner that we are noticing a breach which is beyond our control, and we are taking these steps. A little bit of proactive communication goes a long way. So those are my three key points there.

SPEAKER_00 21:05

Love it. I, you know, I'm so happy we had some time to sit down today, Nav and and really get into the weeds here. Um, because I think that these are real problems that require, you know, modernized solutions. All right. Um, but really excited to uh to continue the conversation and then and hopefully if anybody has any questions, they reach out to us. We'd love to answer any questions that come up from anybody listening out there. Uh, we really appreciate your time. Uh this has been you know the early May edition of What's the Hoot and Nav, I really can't thank you enough for the time and uh look forward to our next opportunity to chat again. Thank you, Mike. Thanks for being a great host, and I look forward to seeing. Yes, sir. Yes, sir. All right, everybody. Have a great day. Appreciate you listening.