The Enterprise Alchemists

From Poacher to Gamekeeper: practitioner perspectives on the vendor side

• Dominic Wellington & Guy Murphy — SnapLogic • Season 3 • Episode 5

Share episode

A candid look at turning AI hype into production results, told through the lens of Prakhar Srivastava, our newest recruit on the Enterprise Architecture team at SnapLogic. Over the years, Prakhar has been a practitioner, a consultant, and a vendor, and shares perspectives from each of those roles. We map lessons from SOA and APIs to agentic AI, and show how governance, data fabric, and empathy drive real outcomes in complex, regulated environments, using Prakhar's experience in the airline industry as a guide.

• three lenses on enterprise architecture and value
• composable enterprise as an AI readiness strategy
• agents as APIs with memory and similar pitfalls
• need for gateways, meshes, and security guardrails
• four risks to manage: governance, interoperability, trust, security
• data as water and the role of a fabric
• crawl‑walk‑run roadmap from use case to production
• outsourcing lessons and knowledge repatriation
• retraining, drift, and resilient deployments
• empathy and partnering over hard selling

Dominic:

Hello and welcome back to the Enterprise Alchemist Apologic for Enterprise Architects and people interested in enterprise architecture. I'm your host, Dominic Wellington, together with my co-host Guy Murphy. Hi Guy.

Guy:

Hello there.

Dominic:

And we are joined today by another newest colleague. Actually not quite new now that a couple more people have joined internet. But welcome P rakhar Srivastava thank you for joining us. So the reason we wanted to invite Prakhar on the podcast is because he has a fascinating CV where he's played all three of the big roles: vendor, consultant, and practitioner. And so what we'd like to do is spend the next little while hearing about those different perspectives and how they inform your practice, Prakhar. So welcome to SnapLogic and welcome to the podcast.

Prakhar:

Thank you so much, uh Dominic, and thank you so much, Guy, for having me. Uh it's it's a pleasure. Just to start with an introduction, uh, I've joined SnapLogic as a principal architect, and I met you and Guy, and immediately uh it was a remarriage of old history and the new technologies. Uh, my career has been all about uh helping enterprises unlock the value of technology from data and integration to AI strategy. Over the years, uh I have worked across the different roles as a practitioner you mentioned, uh building systems, as a consultant, advising clients, and now as part of vendor shaping solutions at scale. Uh it all I I have wore hats. I have been a developer, I have been enterprise architect, and I still do wear those hats depending on who the audience is. And uh I have worked, I've been very proud of coding versus what people do today, vibe coding. I've been a coder myself, but I saw the world changing. I was part of a big service provider, um, and I saw flows filled with people doing a transformation program, and those people were not working on Java, those people not working on.NET, they were working on a technology called Progress Sonic. If you remember the SOA old days uh in 2008-2009, that was a big thing. It was a platform, and people were dragging and dropping and creating a workflows. I was astonished, surprised, and I thought these guys, what are they doing? They're they're foolish, they have done four years of bachelor's of engineering with computer science where we were taught C, Java, dot net, whatnot, right? And then now they are dragging and dropping. We are back to mechanical engineering. What are we doing here? But when I entered, when I explored, uh, I never said uh no to anything, and it was always in my genes that why not? Let's let's try. There is something big happening where the floor is filled up, everyone is doing it. The customer is paying for this transformation program. Uh in offshore, they were on four people on site, they were again 200 people. So there's something big happening that introduced me to the world of SOA soap services. Uh then I moved on to the other uh side of the world uh where I was introduced to the RESTful services, then take different technologies, vendors like Zed Hat. Umsoft, which I was part of. Uh then I joined Salesforce in a pre-sales capacity as an enterprise architect for almost five years. Uh, did my MBA from NCAD worked and helped create a go-to-market strategy for uh media industry. So, yeah, it's been a journey uh from a developer who just knew uh how to code to an enterprise architect uh who's close to the business, understanding their outcomes, the challenges, the goals, and trying to align the capabilities that uh I'm coming to the customer with uh and filling the gaps that they have today. Um and we are in the front of uh a big change uh in the name of AI, agents, and everything it's it's hard to keep pace with it. So, yeah, that's that's just a small introduction. Thank you so much for having me.

Dominic:

Yeah, and uh as you say, very similar backgrounds to actually from different starting points, but we've wound up with similar backgrounds as we've all kind of uh been working to become rounded professionals and to see all these things we've discussed. Uh uh in the past with GUI and uh oriented architectures and the move to residual APIs and the introduction of AI to all this. But how does that change when you're on the inside looking out when you worked for uh mainly worked for airlines uh in uh in your private capacity, it looks like. Um so if you're working for an airline and you're designing your own architecture and dealing with uh, you know, the like sort of guy and me coming in and telling you about the latest cool thing versus doing it from the other side of uh of the conference room table uh and pitching uh a technology for a vendor that you work for to someone who's responsible for an architecture that is moving passengers and planes and whatnot around. How does that differ? How do you make that transition?

Prakhar:

So uh so airline is a is a unique industry, right? Uh it has got uh when we when we today go to the customer, we talk about the fragmented systems, but they do have a fragmented business as well, they have partners all around, they have a supply chain they have to rely on, the aircraft has to fly on the time, but it's also depending on the crew on the ground, it depends on the crew which is in in-house IT, so it has got a lot of moving aspects, and then business also wants has its own drivers. Uh it wants to grow revenue, have ensure that the customer experience is improving, and you don't find a good customer experience in airline industry if you're going through an airport. So, an airport is also becoming a big partner for airlines because the experience goes through that before sitting in the in the airplane. You have to go through the airport. So, how do you ensure that the journey to the travel is also smooth and good? And and they they're still cracking that uh uh puzzle by the way. But going back to your question, uh, so as a practitioner, I'm very close to the problem of the business. I'm concerned uh with getting things at work today, keeping the lights on, and making sure my system doesn't break, say at 2 a.m. or when the peak time comes, when the Christmas comes, when the Easter holidays uh are released. Having said that, I also know what get gaps I have in-house. Uh if there is there could be a skill gap, there could be a platform technology gap, but it should be a process gap. So when someone comes in and starts selling uh the new trend, uh oh, I want AI, I first look, am I overcomplicating with a solution that has a trivial that is a trivial problem altogether? So I want to be close to the problem rather than just overcomplicating the solution. I could possibly do it with enough resources, uh with given time in hand, but maybe the right process. I might not use the technology. So the conversation has to have uh from us becoming an enabler for the business and also looking out for someone like you becoming a partner in that rather than just coming in and selling the technology. We want help, not just around technology, and that's what we do in SnapLogic, right? We go in, we partner them, and we also inspire them to partner with the business. That's what I look for looked for when I was uh uh solving a problem, looking out for solutions, understanding gaps in terms of capabilities, and the capability is not just about technology.

Dominic:

Yeah, because when you're on the inside, you know your own systems, your own capabilities. Someone comes and shows you a nice shiny PowerPoint deck, a cool-looking demo, and leaves you to do the work of figuring out how does that fit, then you may or may not fully get what they're pitching, and they probably don't know your systems as well as uh as well as you know them yourself. Uh so it's all about having that two-way conversation.

Prakhar:

I may tell you a story if we have time.

Dominic:

Yeah.

Prakhar:

I was in pre-sales uh with one of the great companies, I won't take the name, and uh, you know how sales cycle works. The sales guy knew the CTO and he sold one of the technologies. The technology was not introduced uh to the IT, but IT now has that technology to be used, so they don't have this capability in terms of skills, they don't uh probably know, so it's more like a bus driver has been given a Lamborghini keys, and they want him to win the race as well, right? So he was he when we I met him for the first time, I was wearing an enterprise architect hat, not from a pre-sales or sales capacity. I just went and understood what nervousness he was going through, uh what was in it for him, and what the business wanted, and we created a great road mapping chart to ensure they walk, they crawl, they crawl, walk in, then run, right? And the business, on the other hand, was happy, they have given them the technology, the sales guy was happy, he got the numbers, but this was his this driver who wanted to run uh driver Lamborghini and wanted to win the race, but had no clue how to use it.

Dominic:

Yeah, do very well on the straight, and then they get to the first corner. Yeah.

Prakhar:

So that's what we see to answer your question. If if you keep me in that shoes, and you are coming in, I would want that. I would expect that. I would expect you to come, hold my hands, uh, just show me how it runs for the first time. Give me trials so I can run some laps on the on that Lamborghini myself. And once I am pro, I can train the others to drive that Lamborghini and we can win the race for sure in the end.

Dominic:

It's all about the conversation, isn't it?

Guy:

Thanks for sharing that. We're seeing a lot of conversations driving around different enterprises around AI, but equally we're starting to see that sort of the the old concepts behind SOA and the sort of the early days of API strategies are starting to re-emerge because basically a lot of people are starting to realize that it's relatively easy, I'm not gonna say it's easy, but relatively easy to build things in experimental teams, experimental labs with AI, but actually launching these successfully into a traditional architectural systems and database, etc., is proving to be a lot more complex. So, how do you see the relevance of what's now being called a composable enterprise for medium and large enterprises when they're thinking about adopting AI? Is it criticality? Do you think it's something they can skip over and just hotwire these things together? Um share your experience.

Prakhar:

I think I was speaking to someone uh in the company or the customer. Uh history repeats itself, and we we are lucky that this time the history is short enough. We have seen SOA, we have seen microservices, composable architecture, and these are all uh jargons thrown to us by Gartner. Remember, and Gartner also came up with autonomous uh AI and it's all linked together. So a lot of problems that we have seen in the SOA world has repeated itself. Um if you remember the three-tier architecture, which uh obviously you have uh uh you would know we we did it in one of the previous companies, uh, and you have documented that in SnapLogic. Uh that replicated itself in the data world uh with medallion architecture with silver, gold, uh, silver, and gold. Then it replicated itself, I think, in the infrastructure world, and now it is, I think, replicate, it will be replicated in the AI world. What is what is an agent in short? Agent is someone who will do a task, a given task that has a task. Autonomous agents will handle the task, it will give uh the handle to another agent possibly, and if you put MCP into the equation, then it will get some context. Now, if you remember what API was, uh API was a microservice that has a contextual boundary per se, and it also had a similar task. We had problems in the API world, we had a problem that's you know so we gave us discipline, by the way. SOA gave us processes, it gave us discipline, uh, it told us how to solve a problem, but it was heavy. It was heavy in the process, uh, it was hard to manage it. Uh that's why we had different control gates to take it to production. Comes uh your composable architecture where everything was broken down into modular architecture, then comes now agentic uh AI, which are similar to API, I would say, but will have similar problems. Uh in API world, we created API gateway so that developers can expose their APIs to the outside world, secure these APIs. Similar problems are coming up with MCP protocols, they are not secure, they're new enough, A2A is new enough, they're evolving, so we might need some security uh layer on top of it. It could be API gateway or an AI gateway. There are some technologies like Databricks who have created their own AI gateway on the mosaic uh platform. Then we wanted developers to take away the infrastructure uh problems, uh the problems where they had to think about how big the API is, how many volumes they'll be coming in, the NFRs that comes alongside. Uh we created uh infrastructure as a service or mesh. Mesh will all probably also come with AI mesh. So it's all linked. The problems that we are seeing today, we have seen it before. Now, what is in front of us to handle uh as an experienced enterprise architects, uh IT leaders? How do we solve this problem? Uh do we overcomplicate it uh by using a technology that we don't know or we don't have a capability of? Or maybe it's uh it's it is a problem that has not been solved before, so we have to try it and get it solved. That in turn matches with the business outcomes. But it is very important and imperative that whatever we are picking up and solving has to match the outcomes of the business. Now we have been driving business outcomes before as well, nothing much has changed. The business is going with the risk of uh within AI lens of not doing anything. That's why they are getting into the bandwagon, most of it, 80% of it, and they don't know how to go to production. The uh your latter part of your question was how to go to the production. So the guardrails that we defined uh during API uh development in our API strategies, those guardrails now have to be wrapped from AI lens. Uh, how do we collaborate with partners? Uh how do we ensure the data that has been exposed and the products that have been created on that on that data is not secured and it's not shared to bad people, bad uh organizations, how do we ensure it's we are reusing those assets as well? We we also spoke about API sprawl. I think uh that was one of the key use cases we go to the customers with. The organizations are so silos, the systems are fragmented, each flow has almost by an average 35 systems. If each system which has silos assets, now each system starts creating their own co-pilots, and people start using their own co-pilots, then we'll have fragmented AI, like we had fragmented API. How do we discover that? How do we ensure that the governance will happen in a way that we want it to?

Dominic:

And I think that's where our roles as architects come in potentially, because as you were saying, you know, the uh let's say the the you of a few years ago when you were sitting on the airline architecture team, uh you would know very well, you know, what the airline's goals are, what its current technological capabilities are. But especially when it comes to something like AI, maybe you don't have the time to keep up with the the current bleeding age. And so when you have a vendor come in, uh then it's the responsibility of the vendor side to uh to advise you and say, hey, look, you may want to think about uh like this because uh the people who who are coming from individual vendors may say to you, you know, we have an AI and we have an AI and we have an AI. And if you're not careful, you know, this is a pattern that we have seen in the past, and this is where the good the grey hair has come in handy. And we've seen this pattern play out a couple of times before. Here's how we can help you uh get control of that and map it to your goals and requirements and your current pain points.

Prakhar:

Yes, uh so if I wear a practitioner hat, if I wear a customer hat, uh I will look at the risks that AI will bring. And from a vendor perspective, I will try to match those risks, how they can help me mitigate it or remove it. Because I already would have a framework in place for enterprise IT. Um, it's not that if an AI product is coming, I'm removing everything else. People people also uh uh I might digress a bit, but people also get confused. If AI is improving your productivity, it might also mean that you would lose your job. You might, might not, depending on how we are mapping and translating it to you. Increasing productivity could also mean mean you're improving customer experience. That could immediately mean that you're driving uh Revenues up, but on the other hand, somewhere at some planet at the corner of the planet, improving productivity could also mean that you are uh reduced trying to reduce costs. It all depends on what the drivers uh we are translating this use cases to. Now, the coming back to the risk, uh uh what you were saying around. So, one of the biggest risks I see is governance and control. But with more autonomy comes the risk of shadow integrations, right? So, I have mentioned the silos. Then I have interrupt operability standards. So, MCP has been introduced, A2A has been introduced. Will that be adopted widely? Will anything new be coming in? How do I ensure that I'm agile enough, flexible enough for new protocols, and also robust enough to ensure I'm adopting these protocols that has been introduced? Then comes trust and transparency. Everyone wants to understand how this agent will behave once it is in non-production or production environment. And then security. We can't go to production without getting a sign-off from security. So agents with too much autonomy could unintentionally open up to vulnerabilities. You don't know, for example, uh granting excessive permissions or exposing sensitive data across systems. The systems you you are not supposed to feed in, but it could do it. So those four uh points, as an enterprise architect with a practitioner hat, I would want them to be addressed. Uh, yes, uh, the other things come later: the technology, the skills gap, uh, the process, the people, but these are the four things I want to. You also have to understand as a practitioner, I'm already in pressure. There's a delivery gap which is increasing. There's this huge uh demand from the business, and I'm nervous already with all these risks and the demand from the business. So I'm in a very vulnerable situation myself. Uh uh, so you as a uh vendor or me as a vendor have to show empathy, listen, as you and as you said, have conversations, be in their shoes, and try to sell less. Obviously, we all we all we all are normal guys, but uh we have to be partnering them throughout.

Dominic:

Yeah, yeah, you can you can't be selling all the time, and if you have an honest conversation, then a sale may still happen without having to be in sell, sell, sell mode. But yeah, no, it's true. The pressure is real. I mean, as a frequent customer of airlines myself, to stick with uh that example. I mean, there's a huge disparity between individual airlines, and I absolutely will all else being equal, of course, prefer some airlines because they give me a better experience from the app to the check-in to the airport experience before you even get on the plane. And there are other airlines that uh they do not give uh such a good experience. So it's uh definitely room for competition and improvement there. But airlines themselves are very aware of this. So uh one of the most recent projects I personally did was with an airline, and they they see the disconnect between all their systems. They they have all sorts of different systems to manage all sorts of different aspects of of their environment. And of course, they uh they've been working to integrate them, but they see the potential to do something big and strategic. And with any luck, uh that's gonna take a minute, but uh we'll be able to uh get someone to come on and talk about them. That's on the podcast uh sometime.

Prakhar:

On top of it, uh add a pinch of regulations that comes from the government on airlines. You got you can't you can share you can't share inform all the information with the airport, and airport can't share all the information uh with the airline, so they're restricted. Uh and that's where the customer journey, the user journey gets broken. Airline wants to know when the customer leaves from the point. If he's uh stuck in the traffic, has he parked his car? Has he got down? How far is he from the airport? Then what's the airport journey? Has he got enough time? Airport wants also to know has he got enough time to board and also spend time in the for leisure, uh trying to buy something or spend in the lounge, and then the boarding so that the boarding can so it's it's we we can document the user journey and we do as part of the business architecture, but you also understand the capturing of those data points is restrictive and it's not just a technical question, yeah.

Dominic:

If it were just an API call, that part would be easy, but that's the governance.

Prakhar:

So it's broken. Uh it's hard to get that data out, uh, and that's why it's uh difficult to provide that level of experience you get, for example, in a hotel or a hospital, other hospitality areas.

Dominic:

And of course, that's not unique to airlines, all sorts of uh businesses have this problem. That just happens to be the example because of your sort of use, it's something that both Gary and I are deeply familiar with. But yeah, most airlines have, you know, we have the data somewhere. Can we access it technically? Probably somehow, but that's often the easiest question. Then there's a question of, okay, but how? How do we do that securely? How do we do that in a way that's compliant with our internal regulations, our external legislation? How do you manage all of that? And then AI has just accelerated the level of expectation from the business, but surely you just tell the chatbot to do it, right? Uh no, not quite.

Prakhar:

I think that's just one side of the business, right? Which is customer front. There's a lot of things you can do operationally. You can improve operational efficiency. You use fuel and you pay for the fuel in US dollars, right? So you can ensure how you can bring the fuel efficiency by looking at the data and the routes. Then you can also look at uh how do you increase the revenue per se, marketing, Martech? Right now, marketing technology, like we had retail technology pumping up in the last couple of years, marketing technology is pumping up right now, and everyone is pumping money right now in that area. So, how you can improve that? How you can ensure that the data points are flowing. I see that uh I see data as water, right? So you you have water, we take it for granted. You open the tab and the water comes out. So data should be exposed enough in the right way, in a in the right quality, that when you open it, you can immediately consume it. And that's that's how uh if if you do that, if you if an organization reached that level, they can create any innovation, they can embark into any journey they want, uh, any product. They just need to then focus on uh the process and the people.

Dominic:

And that's the data fabric that we're trying to build with SnapLogic, right? Okay, so yeah, that sounds uh promising as we work to resolve all of these issues for our enterprise clients. Do you have any examples of doing that in practice of getting AI projects to production and the hurdles and obstacles that you met along the way?

Prakhar:

Sure. Uh I think last two years I was working with uh VP of AI and data in one of the major Airlines, and uh he he was a great guy, but he had a lot of struggles, uh starting from reorganizing his own team, building the streams a structure so that he can then create AI products on top. So I helped him uh uh reshaping the structure of the team, starting from data engineers, then data processing, uh data analytics, reporting, and once the data products were defined, use the KPIs of business to find the use case, define the use case, educate teams to uh on those use cases, buy in on those use cases. And this part still, we haven't started the development and designing. We are we are only doing the the pre-bid where we are exposing the teams and organizations to what AI means and what use cases we have identified that can help them. Uh then we realize once we have got a stamp on the use case, we realize we don't have skill set uh to go to production, we don't even have the right data that is that was exposed. Uh so integration comes uh uh uh to great importance. It is imperative one to understand you have the right data exposed before even you go for that use case, yes, you're wasting another six weeks, eight weeks just to get that data out. Now, once you get the data out, you pre-process it, send it to send it to the AI. You don't have a team with the capability of building LLMs or building RAC. So, what you do, okay. We will do go back, do some crawling, uh, some walking and then running. We outsource. And another pain I realized was when you outsource. Yes, you can outsource, you have you buy the IPs, but what you don't buy is the knowledge. That that process that human brain is still with the outsourcing teams, uh, you still have to bring it in, and then going to production because the what you have tested your data with is the old data now, and you are already creating new data every day, every second. You also have to ensure once that it goes to production, you bring it back, you train it again with the new data, and then send back to the production, or ensure you have a capability where it gets trained at real time in production. But how do you do that? Do you do that during the day? Do you have robust environments? Is it resilient enough? Those questions starting from uh your defining the use cases, educating until going to the production, pre-training, it's it takes almost, in my case, took almost one and a half years.

Dominic:

I can well believe it. And that's why I always say, you know, the we're still in the earliest days of AI because many large organizations they're still in that process somewhere, they they're still dealing with the complexities. It's all well and good for products or start-up to get something out of the door by Monday. Uh if you're some sort of large multinational in organization in a regulated industry, there's a lot more upfront work that needs to happen. And so we're only just now starting to see the leading edge of those universities.

Prakhar:

And it reminds me of uh one of my classes, one of my uh uh professor told me that digital transformation and innovation is not a destination, it's a journey. And you have to be on the journey, right?

Dominic:

Yeah, absolutely. Fantastic. Well thank you so much for sharing all of that with us, Prakhar. Welcome once again to SnapLogic. I look forward to many more conversations and uh to many successful customer engagements where we can uh uh use your experience to help smooth.

Prakhar:

Thank you so much, and I'm very much excited about it. Thank you so much, Dominic and Guy, for having me.

Guy:

Absolute pleasure.

Prakhar:

I'm looking forward for more beers and coffees, maybe.

Dominic:

Indeed. Always a pleasure. Great. So thanks everyone for listening. Uh as ever, we'll put some useful links in the show notes, and all of the transcripts and those show notes will also be available on the Integration Nation community website where you will also find a comment thread if you have thoughts. Uh, please do share those and suggestions for any upcoming episodes. In the meantime, thanks for listening, and we'll talk to you again soon.

Head Shot

Dominic Wellington

Host
Head Shot

Guy Murphy

Host