For this episode of Enterprise Alchemists, @GuyM and I were joined by Kams Narayan, Director of Product Management for APIM at SnapLogic. We were interested to discuss what it means to have a truly API-led architecture, also known as a composable architecture, and what some of the key considerations should be when adopting this model.
Subscribe to the podcast to receive this and all future episodes directly in your podcast player, or find the Enterprise Alchemists wherever good podcasts are downloaded.
Chapters
- Exploring Composability in Enterprise Architecture
- Challenges of Embracing Composable Enterprise
- Pioneering AI in Enterprise Architecture
Transcript
Dominic Wellington:
Hi and welcome back to the Enterprise Alchemists, a podcast from SnapLogic for our audience of enterprise architects. I'm your host, Dominic Wellington, together with my colleague, Guy Murphy. Hey, Guy!
Guy Murphy:
Hello again, Dominic. How's it going?
Dominic Wellington:
Not too bad, especially today. I'm very excited about our interviewee. So we're joined by Kams Narayan, who leads all of our APIM efforts at SnapLogic. So hey, Kams.
Kams Narayan:
Hi Dominic Hi Guy
Dominic Wellington:
Welcome to the podcast. Um, do you want to introduce yourself briefly, explain to everyone what you do at SnapL ogic and how you got here, sitting in this chair?
Kams Narayan:
Sure, yeah, uh, I am Kams Narayan, director of product for SnapL ogic's API Management solution. I've been here with this company for three and a half years, coming from a background that started or a career that started in engineering and made my way into product management, working in a diverse set of industries that span fintech mostly health and wellness next and communications with companies like Comcast and Cisco. And in my current role here as the lead product manager for the API management solution, I leverage this multifaceted experience in developing API solutions for our customers that just not just meets market demands, but also trying to stay ahead of the curve and anticipating where this industry is moving and shifting towards. So that's a little bit about me, and happy to be here to talk about our API management solution platform in general.
Dominic Wellington:
All topics related to APIs, nice. A great introduction, thank you. And, on that note, talking about where the industry is going, some of the macro trends, one of the big things that we've been talking about is composability, this notion of composability and everything that goes along with that. Can you maybe, for people who are not maybe super familiar with this world, explain briefly what that's all about and why people are so excited about composability?
Kams Narayan:
Yeah, I think the whole concept of composability is a little bit of a I would say a lot of concepts, a lot of process, a lot of, like you know, things that the company would like to get to.
Kams Narayan:
It starts out to me from based on conversations that I've had with our customers it's a journey and I think as a journey, each company is trying to get to the objective of what they would like to be in a composable enterprise model to be truly agile, being able to react fast to market changes, technological improvements and and all of these like different market drivers, uh, and using a consistent approach or using an approach that seem that helps them go, get to that final destination. And in the journey, uh, you know, bringing along various different teams and various different people and processes that's involved to sort of accomplish that end objective. So, in a nutshell, I mean it is a very big topic but a very fascinating topic and you know, if you ask this question to different customers, different companies, they would all give you their viewpoints on this. It's a big journey. A lot of it is a cultural shift mindset, people, process, technology all coming together.
Dominic Wellington:
That's generally the hallmark of an area that hasn't quite settled out yet. When you have a lot of different opinions battling for the same concept, the same space, would you say. That's where we are with composability. Is it something that the market hasn't quite agreed on? How exactly to deliver?
Kams Narayan:
yeah, I would say so.
Kams Narayan:
There's no true and tested formula that has worked for various different companies. Using the same model for one doesn't necessarily lend itself to being easily successful for another, but there are in general, like I said, a lot of principles and concepts that can be applied and, in terms of how a company or an enterprise approaches this, it depends on various different factors. What are some of the business drivers? They're coming with the challenges I've seen or from based on conversations. A lot of it is around addressing things on where companies are in their maturity cycle of where, assessing their existing ecosystem and what's the future path forward, and also doing it in a consistent way that can be used across all the other different teams that are going to be thinking along the same way. So, yeah, to answer that I think there is still a lot of work to do, but companies have been successful and they have used this approach, not to say that it's not been out there, it's been out there for quite some time. Thanks for that insight.
Guy Murphy:
Could you give us an overview of how you see these concepts becoming a core driver within the SnapLogic platform? And, just for some of our audience, SnapLogic has been in the marketplace now for over a decade. We've one of the first iPasses, but, like all good modern technology platforms, we've been evolving. So we actually started as a data integration platform, then we moved into real time streaming patterns and then over the last two and a half years strangely enough, since I joined the company and it wasn't causing an effect I've seen the API M. But this shift towards thinking about composability from the point of view of architecture and we'll touch upon it later using in different styles and domains of users, become a key aspect of our strategy. Could you just take some time talking about that journey and where you see us today and where you see us moving forward around? You know this, this slightly nebulous concept, but definitely seems to be key to a lot of enterprise organizations.
Kams Narayan:
Yeah, I think the key enabler for Composable Enterprise is the adoption of, you know, cloud-native technologies, patterns like microservices and, you know, architectural, those kind of architectural solutions and being solely focused by being very API driven. You know all the API driven integration concepts. So that's where SnapLogic comes into play. It's because, you know, we have built this platform on these same fundamental ideas and principles of, you know, being the very first cloud-based integration platform, also very focused on the connectivity that we provide in that enterprise with the various connectors and interfaces that we provide on data integration, application integration, again, you know, because all of this being very API driven, the concept of, like you know, breaking down the whole system components or, like you know, a whole business workflow into various different modules and then allowing the users to work in a collaborative environment.
Kams Narayan:
And you know some of one of the challenge that that we see on the composable enterprise is that, you know, addressing the sort of the skills gap. You know the technology is quite vast but you know, for everyone to be able to understand and work on integration or develop services, it's not an easy task, it's not something to sneeze about. So, using these kind of platforms like SnapLogic, which brings the whole low-code, no-code movement into making these kind of solutions very easy. It's quite important, it's quite powerful. So that's sort of like where I see companies and platforms like SnapLogic playing a large play here in trying to create these. You know, business value chains, with tooling and with also being able to provide solutions. That addresses some of the other key concepts of composability too, which is around. You know, how do you get a collaborative environment, how do you get, like you know, the technology tooling into one place and then also in the process angle, working on things like, you know, security, governance and all those other aspects too.
Guy Murphy:
Thanks for that. So you actually started to touch upon my next question, which is what are you seeing for the challenges and the pitfalls of trying to approach this? Because, as you say, I came across the early concepts before pre-Gartner, even way back in the day with SOA. If anything, you'd argue, if you read the business, cxo takes on the outcome of adopting service orientated architectures. Cxo takes on the outcome of adopting service orientated architectures. It was the Composal Enterprise back then and then we fast forward to today and we've gone through the adoption and Salesforce, amazon, et cetera. Google really launched the API, restful API, the public web service pattern successfully and yet in 2024, as you say, and you know my accounts very well we're still seeing some large organizations struggling with this, not necessarily in their fringe teams and their innovation teams, but as a corporate organization. What's your views on the sorts of things customers and people need to think about these things?
Kams Narayan:
Yeah, I think the adoption challenges are, you know, there's there are quite a few. I think the top ones that come into mind for me is uh, one that I mentioned earlier, it's, it's, it's just, it is a cultural and they can know, an organizational change. Sometimes these are decisions driven top down but, you know, having those percolate all the way down to every single team within the organization, trying to approach into this mindset of like, you know, how do you develop modular components that are reusable, that can be leveraged to create larger value chains on business processes and other things that they are trying to do? I think that is definitely a challenge on the people side. You mentioned the skills gap too, but I think those are some things that we can address through tooling and platforms like the one that we have.
Kams Narayan:
Some of the other things that I would say is, even as we are all getting into a more of a what do you call more of a distributed architecture. So there's a lot of things around. How do you address this? These systems are properly designed to be able to handle a lot of these various different patterns and various different distributed scaling sort of scenarios that comes along with it. So I would say, consideration something's on more on the architecture side and I think this is where um, you know, opinions from experts like you who have seen where companies have done this well, have have been successful, comes into play. But that's, you know, that's that's bringing in expert inside uh, you know, industry expertise in layering, layering it with what is going to be the solution approach. I think that is something that's quite critical because, as a company, as they are making their journey, you need to make sure they are doing it with the right design and the right approach. So other things are, like you know, we are operating in a world where the market conditions are very strict and very stringent right now.
Kams Narayan:
So, you know, for companies to say, I am going to be composable, you know I'm embracing a composable architecture, I'm going to be a composable enterprise questions on, like you know what are going to be my like you know what's going to be the cost. What's going to be the cost? What's going to be like you know the return on the investment I would get in making a very strategic investment like this. What are, like, you know some of those kind of things that that's more on a commercial, business side of things. That's, I think that's another thing.
Kams Narayan:
And all of this comes with change, I think you know, for organizations to have a change management process. You know what does that go to mean? Moving away from things that they have been doing quite comfortably for a period of time and moving on to something that's into a new concept or, like you know, a new platform, brand-new services and all of those things. So that's, that's another uh thing. That's a bit of a of a challenge that, uh, you know, companies face is you know, how am I going to be successful? What is my adoption and migration maintenance? Uh, all of those different aspects. Uh, once you've reached that point and gone, what does that look like?
Guy Murphy:
Oh, absolutely. And again, you're mentioning something I know we've spoken about in the past, which is with certain account enterprises. We've seen where the front digital teams are actually like organized and structured to successfully adopt this and measured for it, whereas we have seen some uh environments where, strangely enough, some of the big backbone parts of the organizations, the project teams, are actually still being run in a kind of a classic itil risk adverse model. Um, but that also means that things like reuse is not something that they build into like a chain of projects. So, um, which is and again, this is not a technology discussion, this is a sort of organization, and I hate to say it, but funding, you know how. How do you measure success when you know if you're an operations director, your cfo may be constantly asking for take the, take the cost out of the platform, whereas if you're the e-commerce platform, you're a revenue generator. And yet these relationships, um and again, we've talked about this a lot in the past um, the air gap between the innovation and your core systems.
Guy Murphy:
The record is closing on a monthly basis in some pieces. But, uh, the business sometimes is struggling with is how to merge innovation across the landscape. Um, thanks for that insight. That's you know again, I'm sure, um many of our listeners. The business sometimes is struggling with is how to merge innovation across the landscape. Thanks for that insight. That's you know again I'm sure many of our listeners will have seen it, but also we all often work in our own environments that this is still an issue today, and it's not just in legacy companies, but I've seen these things in even high tech companies as they mature up as well. So thanks for that.
Dominic Wellington:
Not very much so, and that's one of the thesis of the podcast, that this is an opportunity to hear from people who have a slightly different experience of seeing maybe a different aspect of the same problem, and we can all discuss it together and, with any luck, learn from each other, learn something interesting.
Kams Narayan:
Yeah, just one more thing I want to add is, like you know, the composable enterprise, you know the concept does give you, like you know, speed and agility, but there is also the need to strike a balance between the speed and the agility that you get, you know, if not compromising on things like quality, as you're bringing to the market services and applications faster. Uh, there's also the, the challenges that we know that organizations and users face is uh, how do you deliver a consistent quality, because you know you're ultimately putting your company your brand name all behind some of these services and other things that you know.
Kams Narayan:
You're all. You know, if your end goal is that you are exposing these to your partners and your end users, you know those kind of shifts as you keep if you keep. Every company wants to innovate. They want to innovate faster, but you also want to be able to try for some consistency, some standardization and other aspects related to governance and controls that you would need to place too.
Dominic Wellington:
Yeah, the cliche phrase here is take the friction out of the process, and I always have to remind people that friction is also traction, as it's more about where do you want to have the friction or not have the friction. If you zero friction everywhere, you have no control, no ability to change direction, to accelerate or decelerate in response to changing conditions, and that's going to be a problem. So, but yeah, you talked about adoption. So one of the the thesis that we have here at SnapLogic is that a big part of getting value from technology is getting it into the hands of more people, and not just people who have a core programming background, a sort of default software engineering expertise, but getting the technology into the hands of people who are in the line of business, who are not in it, and that this will deliver additional value.
Dominic Wellington:
Because once again, we're taking friction out of that communication. You don't have to, for every bright idea you have in the business, go find a programmer, explain your problem, go back and forth in a whole process of requirements gathering. You just sit down in a low code, no codes, graphical interface and start at least mocking something up, and maybe you will need some expertise further on in the process, but you can at least get rolling on your own and it's a lot easier to talk about something if you have a straw man, a template or something. So how does that map specifically to the ap, api management side of things, because this is not quite accepted wisdom, but it's a fairly mainstream position in our core territory of data and app integration, but not nearly as much on the API side of things from what I've seen.
Guy Murphy:
So how do we see the citizen developer persona inside of API, possibly beyond just being a consumer, because consumer is the. How do we see the citizen developer persona inside of API, possibly beyond just being a consumer? Because consumer is the obvious piece, because that's the whole point. But obviously we're starting to see the idea of API producers being data architects, being low-code, no-code users, which that is not a traditional view of the API world not a traditional view of the API world.
Kams Narayan:
Yeah, I think in the concept of, you know, citizens, developers, embracing the more of the API-led or the composable concepts, they do have some areas where they struggle with. It's like you know understanding the interactions between various different components and you know understanding the interactions between various different components and you know how does this all tie into the overall system architecture. Some of the complexities. I mean integrations can be quite complex and you know developing a service. I think each user comes with, you know, their own skill sets. There's, again, various different principles, methodologies that users apply when it comes to creating an API or creating a service. The challenge of trying to address that skill gap. There are things where the integration complexity can be made more easily accessible and enabling citizen developers to create components that can seamlessly integrate with other systems in creating enterprise-grade applications or services. There are tools to be able to do that. That, you know, addresses that challenge.
Kams Narayan:
But you know, getting into where we see the largest struggle is that you know back to what I said earlier the standardization, the governance.
Kams Narayan:
So, back to what I said earlier the standardization, the governance, the best practices and other things that need to be able to bring forth a service that represents the function that they do.
Kams Narayan:
But you know how do we strive for consistency and you know how do we address things on what's like. You know the best practices and how to develop these kind of components, um, and and often uh things around, uh when they do create these. These services, scalability and other things are, are are sometimes you know a little bit more uh of a higher level decision making. So you know that's when you do get into more of a of system administrators and other things also coming in to weigh in on some of these, some of these concepts, and you know some of the products that they're building. So I would say that you know a lot of the things has been. Or I see as a challenge is one on the design but making it more consistent, the quality, the sort of compliance and other aspects that also needs to go along when you're creating services that's meant to be creating that connected enterprise for a composable architecture pattern. I think those are, I would say at least, some of the top of mind challenges that we still see in the citizens developer arena.
Dominic Wellington:
Yeah, that's super relevant and I can definitely confirm. Guy and I spend a lot of our time advising customers, advising our counterparts, the enterprise architects on the practitioner side, how to put that sort of best practice guidance into place. How can we best enable people who, once again, are coming from the business side of things and may not have the reflexes that someone in IT has around these sorts of things, to work in a way that's going to be productive, that's not going to cause problems further down the road that they might not have foreseen? So, how to put in place that center of excellence is usually the term that gets applied here, but basically someone that you can go and work with. That will not be the traditional IT role of the department of no, but there will be someone, a true partner in getting to where you need to get.
Dominic Wellington:
So, with that, this is 2024. It is absolutely mandatory for a tech podcast to have an AI angle, otherwise the podcast police will descend upon us. But no, it's all. Joking aside, there are some genuinely exciting developments around AI and generative AI, also in the field of API management. Do you want to talk for a moment about what you're seeing out there and what you think are some interesting questions that people might want to ask and consider as they look into further developing their own API management capabilities.
Kams Narayan:
Yeah, I mean, again along the same lines of what we talked earlier. You know, the citizen developer model. Everyone now is empowered to use AI. Most organizations are using AI in some form or the other. Like you know, their daily, everyday job function.
Kams Narayan:
Some of the things that I think from AI, and where API management all comes into play, is again around the whole governance and security aspects. This is where you do see people interacting with large language learning models, sharing about the company trying to leverage AI for some of their work and decision-making, but how do you ensure that the data that is being shared is confidential? Any of the confidential information is protected, so, you know, having these kind of that, I think, is some of the concerns I would say, like you know, top of mind for larger adoption of I ought to say wider adoption of AI tools within the enterprise is that companies are still looking to see how they can protect and create guardrails around the information and the users who are getting access to systems and what's being shared, and API management solutions and platforms. Gateways have a key role to play in this in being able to provide more stricter controls on what's being shared, who's sharing it, what are some of the information that's flowing back and forth and how you can actually monitor what's going on in terms of the usage, because the platform as such has the ability to monitor all aspects of these kind of user interactions and user activity. So you know, you have a way to protect the enterprise.
Kams Narayan:
But, having said that, there's also AI which can be used in developing products, like even for our API management solution. You know, as a company, we are thinking about infusing AI into the product as well. So I think this is a very fascinating area. Several companies are jumping in headfirst, but also more on strictly regulated industries, there's a lot of caution. On strictly regulated industries, there's a lot of caution. There's a lot of apprehensiveness about how do we enable this safely across to our users and to their users, and I think we as a company, SnapLogic products we have a role to play in creating AI-based products, but also being able to create those things responsibilities so that companies don't have those kind of fears that we generally are seeing some pushback from.
Guy Murphy:
So, absolutely, because, again, when we look at some of the clients we talked to over the last couple of years, it's interesting that the composability is sometimes being subsumed by other trends, fashion statements in architecture. So we saw things like data mesh and, prior to that, data as a service. But I think what's fascinating with this is we're seeing what used to be very much locked down to the integration specialist teams and it was a black art and basic plumbing is now becoming key design patterns across actual business architectural landscapes and with data mesh, even they go as far as organizational structures of running the business. And, um, yeah, everything you you've been talking about, I completely see in um, some of our more conservative and actually some of our more sophisticated accounts because, again, the journey has been accelerating and I can think of one account that was very interesting, that we were talking to one part of the business and they were talking about that. They're running hundreds of APIs and now we're starting to realize they actually have a separate team with a microservices framework that probably has more micro APIs within the architecture than the rest of the enterprise put together and, interestingly enough, those APIs don't conform very easily to.
Guy Murphy:
Are they apps? Are they data? Are they some cases? Events, are they correlations of other patterns within the microservices frameworks? So this need for more intelligence is going to be a hot topic, which is going to bring this back to the table for a lot of senior architects because, being candid, the API space I saw was kind of ticked off in most organizations four or five years ago as a yes, it works, it's fine, let's move towards it. It's SOA 2.0, arguably, and now actually is becoming a fundamentally different thing that it's not just a gateway pattern but actually it's a core capability. Whether in some cases, the enterprise wants it or not, it's being imposed by these other meta trends. Does that reflect what you're seeing when you're talking to the analysts and, again, some of our more advanced customers?
Kams Narayan:
Yeah, I mean I think we have seen enterprises have definitely reached a certain state of maturity when it comes to using APIs. You know there are companies out there that are, like you know, api led or, like you know, the API first companies that have been very successful in bringing their products and, you know, services to market. I mean it's interesting we ask and you know we've talked about this a lot in the recent two, past two is APIs. It's a nice mixed bag.
Kams Narayan:
You know you have, like you know, the more forward looking technologies when it comes to APIs and you know design patterns and all of those other architectural areas, areas, but there's also the whole uh apis which are, like you know, 30, 40 years back in in like in the past, and you know enterprises are looking at a mix of both, where it is the it's balancing the legacy with, like you know, with the uh, with the modern stack. So it's it. It is a really great challenge and I know, guy, you could talk on and on about this. It surfaces, you know what you can see and you can do with APIs, but a lot of the things that you know businesses face is the you know we have to keep the lights on.
Kams Narayan:
We have these older systems which everyone's very comfortable using. You know have to keep the lights on. Uh, we have these older systems which, which everyone's very comfortable using. You don't want to turn it off, but you know we want a way to be able to seamlessly transition that into, uh, something new, uh, and all of these like sort of you know, architectural patterns, microservices. Yes, you, we're looking for future in the future. You know, with the proliferation of all the IoT devices going into event-based architectures and all of those things are very, very nasty buzzwords in the industry and every company wants to plant their flag and say, yes, we have this, we've done this. But I think this is an area that is, like I said, a great topic to talk about over maybe another session.
Guy Murphy:
Absolutely, and I was laughing to myself because you were resembling my CV, unfortunately, with that speech. It was just scary and just for the listeners. And again, this is not in any way criticizing vendors out there, but we are now entering a period where we have heritage, standardized technologies.
Dominic Wellington:
Heritage technologies. What a concept!
Guy Murphy:
That are less than 20 years old, heritage technologies that are less than 20 years old, uh, and if you want a proof point, go and have a look at the sap api portal.
Guy Murphy:
Uh, and again, this is not an insult to the uh, great german vendor that I spent six years working for, um, so being candid about it, um, but what's interesting is is actually their challenge is of the enterprise, and this is for their latest platforms, and yet they are still rolling out web services technologies, rfc patterns, as well as REST and a mixture of new other technologies, and what you see there is.
Guy Murphy:
This complexity in the landscape is not going to go away, and no one is actually saying we're going to go off and build every back-end CRM, erp, hr system from scratch. So we all like to hang out on the cool part of the conversation, but this is actually the new reality that we're seeing, which is actually the ongoing service creation also now has and in some cases, we have enterprises running thousands and potentially tens of thousands of these legacy interfaces tied to these systems, and the one of the struggle is how to integrate them into a wider, more modern strategy, and not necessarily having the will or the investment or a business case to go back and refactor all of these into a newer tech stacks. So, interestingly enough, everything is new and then everything is the same old world. It's just got new anacronyms each and every five years.
Dominic Wellington:
Everything old is new again.
Guy Murphy:
That's the one. Anyway, thanks for that.
Kams Narayan:
And thanks for sharing your point of view across the board. Yeah, I'm going to save that term to use: Heritage API.
Guy Murphy:
It's really, really great, I'll give you the copyright on that one.
Dominic Wellington:
There you go. Well, thank you very much. That was a fascinating insight. I hope the listeners also found it useful. You will find more information in the show notes and on the page on the Integration Nation community for this episode of the podcast, but in the meantime, thank you Kams, thank you Guy, as ever, and thank you to the listeners, and we hope you'll check in again next time.
