The Enterprise Alchemists
The Enterprise Alchemists is a new podcast for Enterprise Architects to have honest and in-depth conversations about what is relevant to our world. Expert guests provide additional context on the topics of the day in Enterprise IT.
Your hosts, Guy Murphy and Dominic Wellington, are Enterprise Architects at SnapLogic, with more decades of experience between them than they care to admit to, and the stories that go with it.
The Enterprise Alchemists
From SOA To Composability: Why Now Is The Time For Composable Architecture
Composable architecture isn’t a buzzword; it’s the overdue upgrade to lessons we learned the hard way in the SOA era. We share a pragmatic path from heavyweight standards and ESB monocultures to API-first, domain-driven systems that actually deliver reuse, speed, and resilience across cloud and on-prem. With guest Brad Drysdale, we map the shift from monoliths to distributed services, the rise of REST and gateways, and why a discovery-led mindset matters more than any protocol.
We dig into the techniques that make composability real: treat API contracts as products in their own right, with owners, roadmaps, and strong versioning; build a living catalogue that developers can trust; and use domain-driven design to create bounded contexts that align services to business language. We talk openly about governance debt, API sprawl, and the trap of point-to-point integrations disguised as microservices. Then we connect the dots to modern DevOps — Kubernetes, Terraform, and infrastructure as code — showing how to run heterogeneous, multi-cloud estates without drowning in complexity.
Now AI raises the stakes. Agents need secure, reliable access to knowledge and tools; contracts machines can interpret; and guardrails that earn trust. We compare REST and OpenAPI to emerging agent-to-agent standards like MCP, and explain why the future likely builds on today’s contracts rather than replacing them. Finally, we explore vibe coding’s next act: vibe orchestration, mapping intent to capabilities letting AI assemble outcomes from a curated service catalogue. The takeaway is simple: composability scales when you fund shared capabilities, measure adoption, and make reuse the default.
If this sparked ideas for your stack or strategy, follow the show, share it with a colleague, and get in touch with your questions and suggestions. Your stories and challenges shape what we explore next.
Hello and welcome back to The Enterprise Alchemists. I'm your host, Dominic Wellington, and I'm here with my co-host, Guy Murphy. Hi, Guy.
Guy Murphy:Greet ings, Dominic.
Dominic Wellington:The Enterprise Alchemists is a podcast for and by Enterprise Architects. It's hosted by SnapLogic, but we talk to people from across the industry. But this time we're going to be talking to one of our colleagues, Brad Drysdale. Welcome to the podcast, Brad.
Brad Drysdale:Thank you. Pleased to be here.
Dominic Wellington:Welcome everyone. Thanks for listening. So the reason Guy and I want to talk to Brad is there's a lot of talk right now about the notion of composable architecture. This is not a new concept, but it's one that has very much come back into the conversation. And so we thought it was worth talking through that and discussing why that is, where this idea of composable architecture comes from, and why it is suddenly all over the place and relevant to everyone again, especially once again in the enterprise architecture field. So, Guy, why don't you lead us off because you have the deepest background of the two of us?
Guy Murphy:Absolutely, Dominic. So uh yeah, welcome, Brad. Um and uh myself and Brad won't read off our CVs, but we've spookily enough over the last 25 years working in several overlapping companies, um, many of which have actually been looking at this domain uh in depth. So, um as Dominic says, um I'm seeing composable enterprise um service-driven patterns, the service grid, there's quite a few fuzzy names out there um being adopted as a key concept within organizational strategies. Um but we uh thought it'd be really good to really maybe do a bit of a look back in time because uh some of these concepts have been around for a long time. Uh what failed in the past is there's always lessons learned, and really then focus on what's different this time around and how is it being impacted by some of the new modern trends. So um really looking forward to this conversation. So um let's kick off with the Wayback Machine. Um Composable Enterprise was really being kicked around as a phrase by Gartner back in around 2008-2009. Um, but the reality was really that ancient concept of SOA, service-oriented architecture, was really emerging in the sort of 2002-2003 period. Um when you were out there with me in the trenches talking about it, it had a lot of the similar characteristics. It was talking about the idea of the flexible enterprise, the ability to decouple things. Um from your recollection of that period, what do you think worked and what didn't when enterprise architects were trying to apply these what seemed to be relatively simple concepts, um, and yet ended up being considered by probably 2010 to be a bit of a failure?
Brad Drysdale:Yeah, no, it's a great question, Guy. And I think I think looking back in it, and if history, if we were to judge history, you know, based upon that, I would say on the whole, the composable architecture was probably a good thing. I think there was probably many protocols that were a bit too heavy and people overcooked how they went about it. But if if you look back then and compare it to now, where the trend has really been blowing up monolithic applications, people are moving more and more workloads to the cloud and rebuilding applications in a cloud native fashion. What that has resulted in is an IT landscape that is incredibly distributed, you could argue fragmented, but incredibly distributed. And the ways that many of these new application components have been built is very heterogeneous. So you've got a lot of different technologies out there built by different teams of people, small cohorts of team, uh cohorts of people that are putting together pieces of applications and capability to sell as a service or to be able to stitch together with other components from other teams in order to rebuild a full capability of what used to be available in a monolith back in the day. So being able to have these enterprise Lego bricks, if that's what you want to call them, um, available to be highly discoverable and easily adoptable to use and reuse to stitch together far more quickly than you ever could build applications in the past to bring composite applications to bear is a good thing. I think the downside was you know, in the beginning people didn't really know how to do that. And much like we're seeing now in the in sort of in the AI and the agent discovery space, there's these new protocols and standards that are coming about which need a lot of work and they need a lot of practical application-level work before they'll really start to seeing. So if you think about what didn't work, it was it was probably some of those standards like um Corba and even SOAP-based web services, good initially, but you'd argue probably very heavyweight in hindsight. Um, and then you know, the the patterns and the the approaches people took to how they piece this together really matured over time um and became better as time marched on.
Guy Murphy:I can't agree with you more. Um I'm just going to touch upon for maybe our younger listeners, um Brad talked about the heavyweight nature of the SOAP web services. So um, for many people, web services will appear to be um a way back technology. Uh reality is uh when I'm moving around some of the larger uh enterprise accounts, uh mainly in the Amir region, um there is actually a huge number of these services still, I will say quote unquote, alive and not so well out there. Um when I say many, I mean thousands of them, um, often around some of the slower moving platforms, such as ERP, CRM, supply chain. Um again, for the older listeners, actually we used to think that SOAP was going to be um the new RESTful APIs. Uh so the heavyweight nature of it was yes, some of the core pieces were clunky, but what we actually saw happened was an interesting trend that was effectively standard via um bureaucracy. So over the course of approximately six years, what started out as a relatively simple set of standards that was uh getting a lot of traction, snowflowed, often driven by vendor requirements and politics, into a pretty large set of very complex standards, some of which were almost contradictory. And it meant for a standard developer, if they wanted to sort of be both compliant and achieve these outcomes, they would have to navigate themselves in some cases through 10 or so even on a really large project, 38, 39 different standard groups, of which you had to then compile them all together to try and build what was meant to be a simple to roll out interface.
Dominic Wellington:So, what it sounds like, based on uh what you're saying, and for someone who wasn't there, or was there but not quite as deep in this particular domain at the time, is that wonderful Australian phrase, "falling off both sides of the barbed wire at once". That one's special for you, Brad. So we started out not having enough standards and then wound up having too many in fairly short order. Is that a fair summation?
Guy Murphy:Uh very much so. And at the technical level, the problem was that in some cases you would have to support multiple standards at once within your service. Um, the second bigger issue was strangely enough the precursor concept before the modern iPaaS, which was the Enterprise Service Bus, which again carried the core characteristics of the modern platform, but was often rolled out in a effectively a monolithic pattern. So you would have enterprises building these gigantic single clusters that meant that if you were building mission critical integrations, um, it was okay, it could be quite expensive, but the cost of managing, testing, security in these environments became very, very expensive. But for the mission critical services, um it was acceptable. The downside though was, you know, as has not changed in the last 25 years, about 75% and maybe an 80% of integrations aren't mission critical in the enterprise, but you had to put them in the same environment. So the upshot was that you had to do full five-nines, four-nines regression testing, slow life cycle, boards were put in place to confirm that you weren't going to break the bus. So I personally saw environments that said a simple moving data between a data store and a container or a simple database could take upwards of three months to get into production due to internal process and bureaucracy. So, of course, this frustrated people, and they went around the buses and they went back to their point-to-point integrations, and it pretty much undermined the entire concept of these strategies.
Brad Drysdale:Yeah, we saw a lot of that globally, I think.
Guy Murphy:Yeah, I think probably enough about history, but I think it is important to consider these issues because um things like that last one too much bureaucracy, too much process can choke any modern technology stack as well. But you still need to have a framework around it. So if we move forward, obviously, you know, REST stepped forward, and we've seen a simplification, but there is still a big legacy set of protocols out there, as you were talking about, Brad. Um what's kind of changed with the shift to the iPaaSes? And you know, let's talk about you know the rise of federated development and agile um around the landscape, because for a while that seemed to almost be fragmenting some of these concepts, and as Dominic said, there's been almost like a return to these design principles in I'd say the last five, six years. Um, what's your point of view on that?
Brad Drysdale:Yeah, and I think before we get deep into that, we we've got to look at the fact that you know REST as a standard and APIs as a concept sort of really came to save the day in a lot of areas because when you broke apart a monolithic application or monolithic service on where all the intercommunication was done in memory in machine effectively, you and into um multiple sort of even microservices or smaller capabilities and started to interconnect them in the more of a composable fashion, you moved the interconnectivity to the wire. And so all of the communication paths were on the wire, and suddenly you think about surfaces of attack, you think about latency, your performance, um, and standardization of how does one component call another component easily and safely and reliably. And so APIs did a really good job around servicing that space. The challenge was that you ended up with so many of them, and discoverability became a challenge. If the composable enterprise was to be successful, then reuse needed to be a number one, you know, first-class citizen engineering practice across the enterprise. And what we saw that was teams were building applications and application components in siloed environments from each other that they weren't assuming uh a service or an API or a capability already existed and they'd go and engineer their own and end up with uh duplicate and potentially redundant services. And so a big shift there we saw was um how do you focus on a mindset that promotes discovery and reuse? Where we saw organizations saying if we're gonna start to expose capabilities so that you can be agile and fungible in how you compose composite applications, if we're gonna do that through APIs and we want reuse to be high and adoptability to be high, then people have to adopt this mindset of like discovery-led consumption. You assume a service, you assume an API exists, and you go looking for it in a developer portal, you discover it, understand it, and attach to it and consume it. And if it doesn't exist, then you'd build it through a production with intense cycle, whereas you would build that capability for the benefit of your application and the wider benefit of the organization so that it can be made discoverable and reusable by other applications across the business. So I think it's fair to say APIs did a really, really good job of modernising the legacy, so hiding the complexity of older technologies and standards behind a lovely interface. Um, discoverability and adoptability became high, and the rise of API gateways meant that there was a way for you to easily manage these and get full visibility and control of all this interconnectedness, which used to once be in a single machine, is now distributed across polycloud sort of footprints, and you can get a view of where all this is and how it all hangs together. So, with that comes the answer to your question there is well, what does that mean from an agile way of working? Because you're now not only dealing with a distribution of heterogeneous style services, and you want to allow that. You want engineering people to be able to say, let's build this component of the application in GCP using Rust because that's the best actor for the job. Whereas, you know, the data repository component might be in AWS and you know built using Java or something like that and some other technologies. So you want to foster this heterogeneity of best to breed capabilities and languages and tools and clouds and platforms, but that's a real headache to manage from a DevOps and an infrastructure management point of view. And so thankfully, you know, the DevOps movement around everything as code, declarative configurations, infrastructure as code, leveraging things like Kubernetes for very rapid assembly of runtimes and Terraform for putting together, you know, um quite heterogeneous runtime environments from a platform perspective became really, really key and really valuable. It just made it harder. And so the skill set required for people to be highly productive with these environments was higher, and it raised the bar in terms of what you needed to be able to be, you know, to stand out in your industry as uh you know, a strong engineering player in this space.
Guy Murphy:I can agree with you more on this. Um I think being quite transparent, one of the challenges, and what's again what I'm seeing, which is interesting with the rise of this actually becoming a sort of strategic design principle in organizations, is I think there was actually a period that they kind of started to fail. And the the issue was actually um around developers being under such small or tight delivery timelines that they made the mistake that you touched upon really elegantly there, which was um the assumption that using a protocol created reuse when in reality they were actually just doing internal development point-to-point wrapped in in this case a REST API uh protocol stack rather than having the design principle within the team to say you and you should be looking for reuse as appropriate. Now, obviously, reuse may not be a universal concept and not may not be required. I've seen many dev teams complain that they literally just want to move things from A to B within their project, their platform, and that's suitable. Um one of the tools that I've used historically for really trying to understand inside of, and again, this is not a microservices discussion, this is much more like large-grain project development, is domain-driven design, um, where it allows you to think about the boundary context of your capability, which means that you can actually understand what who will be potentially the consumers of the reusers, and you can understand then where the extra investment. And I think sometimes that's the one pushback I still hear from this is for those that are working under a tight budget, very tight timeline, is and I'm sure Brad, you're gonna remember this the great myth of we'll get it out the door now, but then we'll refactor it into reuse later.
Dominic Wellington:We'll fix it in prod.
Guy Murphy:Are you still seeing that today?
Brad Drysdale:Of course, yeah, absolutely. Um, you know, the if we build it, they will come, and if we build it, it's gonna be perfect for everyone, and they will want to come, and that's never the case. You know, agility, which is why the composable concept is so powerful, right? Because agility and fungibility is important.
Dominic Wellington:Yeah, it's all very reminiscent of object-oriented programming. That that was the great promise then, too, that if everyone did object orientation, then you'd have all these wonderful reusable components you could assemble like Lego bricks. It all sounds very familiar. The big addition of uh composable architecture seems to have been that central repository that was updated live. Uh, but the the failure was the same. It's that it only worked if you'd already done it, so to speak. Is that fair?
Brad Drysdale:Yeah, there is a lot of that. I mean, you we saw so much duplication of services, and when we looked at organizations and said, what's what's the value of reuse of APIs across your you know your business? The the number was very low. Um, and so I worked at companies you know with Guy where we started to do composability workshops where we sat down with the organization and said, before you build a thing, what are the first N important projects, the first 10 important projects that are coming up, and what capabilities do they need? And we'd look for commonality and reuse of requirements. So, what would the APIs be that would comprise these applications and these use cases? And which of those are common across user cases and therefore reusable, and then we'd stack rank them according to the priority of the project. And that gave you a sheet you could look at and say, these are the APIs we're going to build first because they're not only high value in the projects they're they're adding or they're delivering, but they've got a high degree of reuse as well. Um, adoptability was the other big thing, right? Because people were building stuff that would eventually get used by one party potentially, and then often retired, or not only retired, just forgotten about. And we've seen many security breaches over the years of surfaces attack inside of APIs that people just forgot about. You know, you can only put an API gateway in front of something that you're aware of, and suddenly this traffic's hitting these APIs that were kind of forgotten about and left to hang, and and you know, they become a risk. Um the difference was how how do you drive reusability, but how do you make the APIs honor their domain, as Guy was talking about before? Because if you're exposing like uh an inventory API out of a mainframe, the concept of a product in a mainframe has different uh nomenclature, it has different wording, it has a different value to someone who's trying to track an order all the way up on a mobile device and then everything in between. So domain-driven design was really about have your services that are domain-bounded, but then reusable enough so other services could sit on top of that and put their view of um what that data, what that capability was that more closely aligned with the applications and the users and the systems that were going to uh leverage that capability without needing to air the dirty laundry of APIs and services that sat below it. So it became complex and it became something that someone, somewhere in an organization had to actively manage, otherwise, it was just API sprawl for the for the sake of APIs, and that that defeated the agility, it defeated the composability because people said there's just so much stuff out there, I may as well just build this application monolithically myself.
Guy Murphy:No, and that's still challenging 2025 in certain environments. So it is becoming very interesting that you know some of these concepts are going full circle. Um, but obviously, the we are seeing the success with some of these strategies, we are seeing some understanding, as I said, me and you are both fans of looking at the idea of domain within it. Also, I think ownership is a critical issue of this, and I think that's really what you started talking about, which is making sure that your organization actually has people who um and I'm gonna use modern speak, but the reality is is a product owner and or a product portfolio owner of these services, because the again, as you say, if you're a day day-to-day developer, and um in some cases I see organizations where they heavily utilize third-party developers, be it point specialist consultancy or the big GSIs, where those particular developers may not really care about some of these principles because they're again under the gun to get something in on time, under budget, or on budget, uh, and out the door. Where you do need to have people that actually care about these larger outputs, and again, this avoidance of the API sprawl, where it just becomes uh not a mound of cleverly well-architected Lego bricks, but basically just a huge mound of fragmented bits of plastic that no one can be bothered to wade through to work out where the the value is. Um, and I think that's one of the remarkable changes, is especially with the rise of the external API as a business construct. Um, I would be struggling now to think of any organization that I'm working with in the last five years, that if you were to say, Do you have customer or supplier facing digital capabilities? Would say, No, we don't. So I think that's the other big shift, which is this has gone from back in the days of SOA B2B was kind of something that hung off the edge of the architecture. If you thought about all the top processes in the organization, whereas now that's go that's effectively gone away, and this is definitely something that the rise of the SaaS vendor, I think, has influenced these concepts in the architectures that says actually, I will have customer APIs, I will have supplier APIs, I will have content APIs for marketing. So this boundary context, not just within the sort of business unit, but actually the acceptance of your digital assets, even if you're a bricks and mortar type of organization, are not optional. They're actually how you have to do business.
Brad Drysdale:Yeah. And the you talked there about a product owner, which is interesting because they they matter for software products, physical products, digital products, but you they also matter for APIs because the API contract is the product, it's the long-lived dependency that any other interface or system or supplier or consumer is going to build long-lived dependencies upon, right? They're the ones that are going to build portals and mobile apps that leverage the other systems that call in to that product are going to rely on that API contract. Now they will change over time, but the life cycle of those is very well understood, and API versioning is a is a well-understood and well-managed process. But everything else can change. Because everyone builds that long-lived dependency on the contract, the implementation of that is free to change, right? When you then you pull out one version of a you know a database and replace it with something else, you update the wiring from the contract through to the back end. And just because a database table changes doesn't mean that the contract of here's an order ID, give me the order information back. That that shouldn't necessarily need to change. And so it also means as we move forward in the world of AI, that these API interfaces, these products, become really, really interesting and important in how AI can use them and finally potentially you know displace what used to be a fairly static human discoverable process of what APIs exist and how do I use them, to be in a very intelligent machine-driven one where you know LLMs can take advantage of API contracts and say, I know exactly what this does, what do I need to send it, what response I get coming back, and there machines are now driving these interfaces far more intelligently than humans ever did.
Guy Murphy:So that's a perfect segue. So I wanted to bring this into some of the sort of the modern thinking around this. So um let's have a candy conversation about what we're seeing with in the AI domain. So obviously, it's the hot topic for the last two years. We've seen some incredible shifts in the marketplace because of the launch of LLMs. Uh, we're seeing the I'd I'd argue the beginnings of the Agentic, and as you say, um not just chatbots now, but actually logical um networks of AgenTic services. Um but as we talked about a little bit earlier in the podcast, um, but strangely enough, we're now seeing again um quote unquote uh new open source standards being driven by very large corporations uh who have their own individual views on it, and obviously um MCP and A2A are the first two new integration protocols, probably for a while. Um, and I'll be quite open to say I think we're gonna see a number of new protocols emerging at pace in this because it's a new piece. But do you think that REST and the old APIs are dead? And this is obviously a bit of a wait weighted question because the reality is legacy never seems to die in IT stacks. Um, how how do you see the balance for modern architects where REST has actually become the preferred dominant pattern? But the HA are now going down this new set of self-dis-describing capabilities, and it gains the landscape that is in most situations, basically, if you're not a startup, the overwhelming system landscape is not an AI LM driven environment, they are the new emerging capability in the strategy.
Brad Drysdale:Yeah, really good question. I I think it's really hard to predict where this is going to go given that it changes on an almost hourly basis. Um some interesting things that did come up when I thought about this earlier was well, first and foremost, I don't think REST and APIs are dead. You know, there's argument that you know the fact that APIs are exposing themselves as digital products and it's a really well understood, manageable, easy-to-secure interface in terms of how a client can call a capability without having to have any knowledge or understanding of how that capability is implemented through this standardized interface. I think there's still a lot of power there. But I asked Chat GPT this a few months ago now, and I said to it, um, if if you were an agent and you needed to call another agent, uh, how would you do that? What would be the and you know it it responded in using you know sort of current technologies and the and sort of answer that I would expect I would say if someone asked me that question, then I said, but you're both agents, you're both AI-based. How would you optimize your communication so that you've got the the most secure, most efficient, um, best way of exchanging information with each other? And we've seen examples where agents have done that in a vocal world using things like Gibberlink. They basically create their own audio codec to be able to speak more efficiently than a human spoken language. And the response ChatGPT came back and said, Oh, okay, well, if I'm an agent and I'm talking to another agent and I get to decide how we standardize in that communication, it came up with a heavily optimized uh enhanced version of uh an open API spec because it was just really building on the shoulders of giants and saying open API as Swagger did a really good job in the REST world for the human view of APIs today. What would be extensions to that that um that LLMs would leverage so that LLM to LLM or agent-to-agent communication was optimized, but retaining all the benefits of strong security, monitorability, discoverability, you know, observability, all the things that you need to make this stuff day one and day two operationalizable. And that's an interesting thought. That means that REST and APIs are not gonna die, they're gonna be the giants that you know these new standards potentially sit on the shoulders of to bring us some new things that are relevant to the AI space. Maybe, right? That's one guess, but it could be anything else.
Dominic Wellington:It's it's really hard to predict. Yeah, but my guess is that's how it's been with every previous generation of technology, right? There's uh mainframes still running around underfoot, and then layers of technology wrapping around that, and this'll just be the latest layer, and then someone else will layer something else on top of that, no doubt.
Brad Drysdale:Very very likely.
Guy Murphy:Bringing this around, I mean, every company I'm talking to is looking at AI. The reality is composability has become a hot topic because additionally to the composable reuse patterns, um I think the one thing that is interesting is AI is actually forcing people to yet again, and again, Brad, you remember this back in the day with the e-commerce strategies. Oh, oh no, I can't actually see where my stock is, I can't see my customer, I can't see the status of an order. Um, AIs are actually utterly dependent on the under underlying capabilities of an organization if you want to achieve an agentic outcome, because obviously what most people are seeing in the public domain is obviously the models were built on the public knowledge framework of the of the web and everything that was published out there, but the enterprise strategies even more focused on it's my data, it's my processes I want these services to drive. And this is really forcing people to re-examine, you know, the age old challenge of the silo and the legacy, because without that access and control to the data, to the processes, then these things become you know the brain in the glass jar. And Gartner talks about 70% of the AIs aren't getting out of the labs. Pretty much every organization I've seen that have AIs, the lab teams, that when they say, Why can't you get it in production? It's actually that sudden realization of this isn't just cut and paste and move the train initial training data into the labs to get the concept working, it's how would you drop this into a complex mixture of modern and legacy to actually achieve the real life use cases. And I think this is from my point of view why this has become such a massive discussion now in a lot of organizations, and no longer is just a developer discussion about design best practices, but rather a if we don't start cracking this, we're actually not gonna get the real potential value of AI strategies. Um, would you agree, disagree, challenge my point of view on this?
Brad Drysdale:Yeah, no, I do agree. Um, you know, agents are gonna need access to knowledge, that's data, they're gonna need access to tools, they're gonna need um secure mechanisms by which to communicate with with other agents. Um, and I think the new piece that's come along today is trust, because you know, think about trust or a zero trust posture for organizations. It was all about let's assume we're gonna get hacked or attacked or there's a threat. Whereas trust in the AI space is trust that the this AI is gonna do what it says it's going or we want it to do, and not hallucinate, not make things up, not run rampant and not skirt around the rules. So it's less of a bad actor from a human hacking perspective, it's more a case of do I trust my company with this technology not to give me brand erosion or racism or bias or hallucination or any of those other things, and that's a whole new can of worms. Um, so yeah, there's a lot of good best practices from enterprise architecture that helped solve a lot of those challenges before AI came around around trust from the other view of the world. But there's there's new lenses on all of this that needs to be very seriously and carefully considered and tested and thought about by the brain's trust. Otherwise, it will be just a brain in the jar, as you say, and the brain of the jar, you know, won't have access to knowledge, won't have access to tools, won't have access to what it needs to get it done because there's no trust.
Guy Murphy:Absolutely. Brad, as ever, um great talking to you about the topic. Um Dominic, is there anything else you think we've missed in this um rambling of two old veterans from the industry?
Dominic Wellington:No, it's been fascinating to listen to, and as I say, there's uh some parallels that I've I've made and I think others will be able to make to uh other related concepts. Um the one big other topic that uh we might talk about for a few minutes is our friends and colleagues on the programming and software engineering side of the house are all excited these days about the potential for vibe coding, uh basically creating new software by talking to models rather than by coding it themselves or by having them assist to various degrees. And in the planning for this podcast, we talked about you know what might that look like if we started to think about vibe engineering? Could there be a future where the central catalogue uh that uh we discuss as part of uh composable architecture is something that uh a larger language model or an agentic set of uh models and tools can go and analyse and potentially build something up at a larger scale than an individual program.
Brad Drysdale:Yeah, I I think so. I I had a you know a strong dream on this one. I think vibe coding was all about using AI to help you write snippets of code, review code, refactor code. Then it became all about how does it write whole applications or games or useful utilities for you. And I think that concept is going to extend further where you'll get vibe orchestration, right? You'll be able to have a human intent to say, um, you know, build me a capability where I can get a view of all customer or a customer based on a customer ID, all of their orders and any current returns or tickets that are opened by that customer, traditional sort of integration use case. And I can see where uh Vibe Orchestration would be able to take advantage of all of those APIs and services and agents and tools and knowledge and applications and data sources available in the very distributed, very heterogeneous enterprise and bring that together dynamically to be able to engineer the outcome in real time. And if you take that all the way to the extreme, you know, there's you've seen examples now of companies, startups that have popped up where they've got to sort of that hundred million or billion valuation with only three, four, or a dozen employees. I argue a day will come where we will have very successful new businesses in motion that have no humans at the wheel. And Gen AI found a gap in the market, built a company, bought a domain, built the software, built the go-to-market model, built all the marketing material, deployed it, went to market, and sold capabilities. And there may not be a human at the wheel along in any stage of any of that. Now that's a that's a way off. I don't want to say a long way off because I don't think we can predict anything these days in terms of velocity of this. But I I I don't see much in the way of that not happening at some point. So vibe engineering, vibe orchestration, vibe, vibe company ideation and creation. I mean, why not? Right? It's it's definitely the out of the possible.
Dominic Wellington:And that's a slightly terrifying thought. It is. Although on the one hand, maybe that's how we do finally get properly documented interfaces and APIs, because the the models will just do that as a matter of course, in a way that we've been trying and failing to get human engineers to do since forever, really. The future's bright if you need documentation. But at that point, who's reading the documentation? That's a whole other question. No, this has been a fascinating conversation. So I think we have all got some thinking to do about how we're going to be layering these new technologies over what's already out there and how we get to that uh bright, shiny future in which I guess we all get to go to the beach and hang out because the AIs are running the companies. Let's hope so anyway.
Guy Murphy:Excellent. So once again, Brad, thanks for your time. And uh thank you listeners for uh hopefully what was an uh interesting conversation.
Dominic Wellington:Yes, indeed. As ever, there will be a thread for this episode on the Integration Nation Forum, and I will put the link to that in the show notes. If you have thoughts, comments, suggestions for future episodes, please do come and find us there. Uh, we would love to hear your thoughts. But for now, thanks for listening and thanks once again to Brad for coming on.
Brad Drysdale:Pleasure. Thank you, everyone. It's good to see you, and uh hello from Australia.
