WEBVTT
00:00:00.239 -->
00:00:02.399Hello and welcome back to The Enterprise Alchemists.
00:00:02.399 -->
00:00:06.400I'm your host, Dominic Wellington, and I'm here with my co-host, Guy Murphy.
00:00:06.400 -->
00:00:07.040Hi, Guy.
00:00:08.080 -->
00:00:09.119Greet ings, Dominic.
00:00:10.400 -->
00:00:15.519The Enterprise Alchemists is a podcast for and by Enterprise Architects.
00:00:15.519 -->
00:00:20.640It's hosted by SnapLogic, but we talk to people from across the industry.
00:00:20.640 -->
00:00:25.440But this time we're going to be talking to one of our colleagues, Brad Drysdale.
00:00:25.440 -->
00:00:26.960Welcome to the podcast, Brad.
00:00:27.440 -->
00:00:27.760Thank you.
00:00:27.760 -->
00:00:28.559Pleased to be here.
00:00:28.719 -->
00:00:29.280Welcome everyone.
00:00:29.280 -->
00:00:30.160Thanks for listening.
00:00:30.160 -->
00:00:39.280So 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.
00:00:39.280 -->
00:00:45.759This is not a new concept, but it's one that has very much come back into the conversation.
00:00:45.759 -->
00:01:03.679And 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.
00:01:03.679 -->
00:01:09.280So, Guy, why don't you lead us off because you have the deepest background of the two of us?
00:01:09.920 -->
00:01:11.120Absolutely, Dominic.
00:01:11.120 -->
00:01:12.560So uh yeah, welcome, Brad.
00:01:12.560 -->
00:01:27.439Um 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.
00:01:27.439 -->
00:01:45.519So, 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.
00:01:45.519 -->
00:01:54.239Um 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.
00:01:54.239 -->
00:02:06.319Uh 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.
00:02:06.319 -->
00:02:10.080So um really looking forward to this conversation.
00:02:10.080 -->
00:02:14.000So um let's kick off with the Wayback Machine.
00:02:14.000 -->
00:02:22.719Um Composable Enterprise was really being kicked around as a phrase by Gartner back in around 2008-2009.
00:02:22.719 -->
00:02:35.039Um, but the reality was really that ancient concept of SOA, service-oriented architecture, was really emerging in the sort of 2002-2003 period.
00:02:35.039 -->
00:02:42.080Um when you were out there with me in the trenches talking about it, it had a lot of the similar characteristics.
00:02:42.080 -->
00:02:47.039It was talking about the idea of the flexible enterprise, the ability to decouple things.
00:02:47.039 -->
00:03:05.840Um 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?
00:03:06.400 -->
00:03:08.080Yeah, no, it's a great question, Guy.
00:03:08.080 -->
00:03:19.680And 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.
00:03:19.680 -->
00:03:26.560I think there was probably many protocols that were a bit too heavy and people overcooked how they went about it.
00:03:26.560 -->
00:03:39.599But 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.
00:03:39.599 -->
00:03:48.400What that has resulted in is an IT landscape that is incredibly distributed, you could argue fragmented, but incredibly distributed.
00:03:48.400 -->
00:03:54.960And the ways that many of these new application components have been built is very heterogeneous.
00:03:54.960 -->
00:04:20.800So 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.
00:04:20.800 -->
00:04:39.759So 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.
00:04:39.759 -->
00:04:45.600I think the downside was you know, in the beginning people didn't really know how to do that.
00:04:45.600 -->
00:05:00.399And 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.
00:05:00.399 -->
00:05:13.680So 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.
00:05:13.680 -->
00:05:24.879Um, 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.
00:05:26.240 -->
00:05:27.839I can't agree with you more.
00:05:27.839 -->
00:05:36.720Um I'm just going to touch upon for maybe our younger listeners, um Brad talked about the heavyweight nature of the SOAP web services.
00:05:36.720 -->
00:05:42.399So um, for many people, web services will appear to be um a way back technology.
00:05:42.399 -->
00:05:58.879Uh 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.
00:05:58.879 -->
00:06:09.920Um when I say many, I mean thousands of them, um, often around some of the slower moving platforms, such as ERP, CRM, supply chain.
00:06:09.920 -->
00:06:19.519Um again, for the older listeners, actually we used to think that SOAP was going to be um the new RESTful APIs.
00:06:19.519 -->
00:06:32.399Uh 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.
00:06:32.399 -->
00:06:53.439So 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.
00:06:53.439 -->
00:07:17.600And 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.
00:07:18.000 -->
00:07:32.480So, 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".
00:07:32.480 -->
00:07:34.720That one's special for you, Brad.
00:07:34.720 -->
00:07:41.680So we started out not having enough standards and then wound up having too many in fairly short order.
00:07:41.680 -->
00:07:42.959Is that a fair summation?
00:07:43.279 -->
00:07:44.560Uh very much so.
00:07:44.800 -->
00:07:52.240And at the technical level, the problem was that in some cases you would have to support multiple standards at once within your service.
00:07:52.240 -->
00:08:12.079Um, 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.
00:08:12.079 -->
00:08:33.039So 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.
00:08:33.039 -->
00:08:38.000But for the mission critical services, um it was acceptable.
00:08:38.000 -->
00:08:52.480The 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.
00:08:52.480 -->
00:09:04.159So 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.
00:09:04.159 -->
00:09:19.919So 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.
00:09:19.919 -->
00:09:29.600So, 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.
00:09:30.000 -->
00:09:31.919Yeah, we saw a lot of that globally, I think.
00:09:32.080 -->
00:09:45.600Yeah, 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.
00:09:45.600 -->
00:09:48.240But you still need to have a framework around it.
00:09:48.240 -->
00:10:00.159So 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.
00:10:00.159 -->
00:10:04.240Um what's kind of changed with the shift to the iPaaSes?
00:10:04.240 -->
00:10:24.960And 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.
00:10:24.960 -->
00:10:27.039Um, what's your point of view on that?
00:10:27.360 -->
00:11:04.320Yeah, 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.
00:11:04.320 -->
00:11:18.559And 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.
00:11:18.559 -->
00:11:23.120And so APIs did a really good job around servicing that space.
00:11:23.120 -->
00:11:29.440The challenge was that you ended up with so many of them, and discoverability became a challenge.
00:11:29.440 -->
00:11:38.799If 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.
00:11:38.799 -->
00:11:57.120And 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.
00:11:57.120 -->
00:12:06.320And so a big shift there we saw was um how do you focus on a mindset that promotes discovery and reuse?
00:12:06.320 -->
00:12:27.279Where 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.
00:12:27.279 -->
00:12:36.960You 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.
00:12:36.960 -->
00:12:53.840And 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.
00:12:53.840 -->
00:13:05.679So 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.
00:13:05.679 -->
00:13:27.919Um, 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.
00:13:27.919 -->
00:13:35.200So, with that comes the answer to your question there is well, what does that mean from an agile way of working?
00:13:35.200 -->
00:13:42.720Because you're now not only dealing with a distribution of heterogeneous style services, and you want to allow that.
00:13:42.720 -->
00:13:51.279You 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.
00:13:51.279 -->
00:13:59.279Whereas, you know, the data repository component might be in AWS and you know built using Java or something like that and some other technologies.
00:13:59.279 -->
00:14:12.000So 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.
00:14:12.000 -->
00:14:36.639And 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.
00:14:36.639 -->
00:14:38.399It just made it harder.
00:14:38.399 -->
00:14:52.879And 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.
00:14:54.879 -->
00:14:56.639I can agree with you more on this.
00:14:56.639 -->
00:15:11.360Um 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.
00:15:11.360 -->
00:15:46.240And 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.
00:15:46.240 -->
00:15:51.039Now, obviously, reuse may not be a universal concept and not may not be required.
00:15:51.039 -->
00:16:00.240I'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.
00:16:00.240 -->
00:16:29.200Um 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.
00:16:29.200 -->
00:16:45.360And 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.
00:16:45.759 -->
00:16:47.200We'll fix it in prod.
00:16:48.240 -->
00:16:49.679Are you still seeing that today?
00:16:49.919 -->
00:16:51.679Of course, yeah, absolutely.
00:16:51.679 -->
00:16:59.039Um, 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.
00:16:59.039 -->
00:17:03.440You know, agility, which is why the composable concept is so powerful, right?
00:17:03.440 -->
00:17:05.680Because agility and fungibility is important.
00:17:06.319 -->
00:17:10.319Yeah, it's all very reminiscent of object-oriented programming.
00:17:10.319 -->
00:17:21.359That 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.
00:17:21.359 -->
00:17:23.119It all sounds very familiar.
00:17:23.119 -->
00:17:30.880The big addition of uh composable architecture seems to have been that central repository that was updated live.
00:17:30.880 -->
00:17:34.400Uh, but the the failure was the same.
00:17:34.400 -->
00:17:38.079It's that it only worked if you'd already done it, so to speak.
00:17:38.079 -->
00:17:39.039Is that fair?
00:17:39.359 -->
00:17:40.720Yeah, there is a lot of that.
00:17:40.720 -->
00:17:50.640I 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?
00:17:50.640 -->
00:17:52.640The the number was very low.
00:17:52.640 -->
00:18:08.240Um, 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?
00:18:08.240 -->
00:18:11.440And we'd look for commonality and reuse of requirements.
00:18:11.440 -->
00:18:16.400So, what would the APIs be that would comprise these applications and these use cases?
00:18:16.400 -->
00:18:23.680And 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.
00:18:23.680 -->
00:18:35.839And 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.
00:18:35.839 -->
00:18:38.559Um, adoptability was the other big thing, right?
00:18:38.559 -->
00:18:48.319Because people were building stuff that would eventually get used by one party potentially, and then often retired, or not only retired, just forgotten about.
00:18:48.319 -->
00:18:56.400And we've seen many security breaches over the years of surfaces attack inside of APIs that people just forgot about.
00:18:56.400 -->
00:19:08.480You 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.
00:19:08.480 -->
00:19:19.440Um 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?
00:19:19.440 -->
00:19:36.720Because 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.
00:19:36.720 -->
00:20:05.039So 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.
00:20:05.039 -->
00:20:26.240So 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.
00:20:26.640 -->
00:20:31.440No, and that's still challenging 2025 in certain environments.
00:20:31.440 -->
00:20:36.400So it is becoming very interesting that you know some of these concepts are going full circle.
00:20:36.400 -->
00:20:45.759Um, 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.
00:20:45.759 -->
00:21:34.319Also, 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.
00:21:34.319 -->
00:21:57.839Where 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.
00:21:57.839 -->
00:22:05.599Um, and I think that's one of the remarkable changes, is especially with the rise of the external API as a business construct.
00:22:05.599 -->
00:22:19.759Um, 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?
00:22:19.759 -->
00:22:21.759Would say, No, we don't.
00:22:21.759 -->
00:22:32.160So 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.
00:22:32.160 -->
00:22:53.200If 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.
00:22:53.200 -->
00:23:06.720So 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.
00:23:06.720 -->
00:23:08.880They're actually how you have to do business.
00:23:09.119 -->
00:23:09.599Yeah.
00:23:09.599 -->
00:23:32.160And 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?
00:23:32.160 -->
00:23:40.079They'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.
00:23:40.079 -->
00:23:48.559Now 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.
00:23:48.559 -->
00:23:50.400But everything else can change.
00:23:50.400 -->
00:23:57.759Because everyone builds that long-lived dependency on the contract, the implementation of that is free to change, right?
00:23:57.759 -->
00:24:05.759When 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.
00:24:05.759 -->
00:24:14.319And just because a database table changes doesn't mean that the contract of here's an order ID, give me the order information back.
00:24:14.319 -->
00:24:16.559That that shouldn't necessarily need to change.
00:24:16.559 -->
00:24:57.039And 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.
00:24:58.480 -->
00:25:00.400So that's a perfect segue.
00:25:00.400 -->
00:25:04.799So I wanted to bring this into some of the sort of the modern thinking around this.
00:25:04.799 -->
00:25:10.799So um let's have a candy conversation about what we're seeing with in the AI domain.
00:25:10.799 -->
00:25:14.640So obviously, it's the hot topic for the last two years.
00:25:14.640 -->
00:25:19.200We've seen some incredible shifts in the marketplace because of the launch of LLMs.
00:25:19.200 -->
00:25:32.160Uh, 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.
00:25:32.160 -->
00:25:58.720Um 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.
00:25:58.720 -->
00:26:07.440Um, 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.
00:26:07.440 -->
00:26:12.640But do you think that REST and the old APIs are dead?
00:26:12.640 -->
00:26:19.920And this is obviously a bit of a wait weighted question because the reality is legacy never seems to die in IT stacks.
00:26:19.920 -->
00:26:26.960Um, how how do you see the balance for modern architects where REST has actually become the preferred dominant pattern?
00:26:26.960 -->
00:26:48.079But 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.
00:26:48.720 -->
00:26:50.160Yeah, really good question.
00:26:50.160 -->
00:26:56.559I I think it's really hard to predict where this is going to go given that it changes on an almost hourly basis.
00:26:56.559 -->
00:27:05.119Um 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.
00:27:05.119 -->
00:27:24.720You 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.
00:27:24.720 -->
00:27:26.400I think there's still a lot of power there.
00:27:26.400 -->
00:27:39.119But 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?
00:27:39.119 -->
00:27:53.599What 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.
00:27:53.599 -->
00:28:04.720How 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?
00:28:04.720 -->
00:28:09.920And we've seen examples where agents have done that in a vocal world using things like Gibberlink.
00:28:09.920 -->
00:28:18.160They basically create their own audio codec to be able to speak more efficiently than a human spoken language.
00:28:18.160 -->
00:28:45.440And 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.
00:28:45.440 -->
00:29:05.920What 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.
00:29:05.920 -->
00:29:07.359And that's an interesting thought.
00:29:07.359 -->
00:29:20.559That 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.
00:29:20.559 -->
00:29:21.839Maybe, right?
00:29:21.839 -->
00:29:23.839That's one guess, but it could be anything else.
00:29:23.920 -->
00:29:25.839It's it's really hard to predict.
00:29:25.839 -->
00:29:30.720Yeah, but my guess is that's how it's been with every previous generation of technology, right?
00:29:30.720 -->
00:29:42.240There'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.
00:29:44.640 -->
00:29:45.839Very very likely.
00:29:46.400 -->
00:29:50.319Bringing this around, I mean, every company I'm talking to is looking at AI.
00:29:50.319 -->
00:30:12.079The 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.
00:30:12.079 -->
00:30:18.400Oh, 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.
00:30:18.400 -->
00:30:46.799Um, 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.
00:30:46.799 -->
00:31:02.720And 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.
00:31:02.720 -->
00:31:08.960And Gartner talks about 70% of the AIs aren't getting out of the labs.
00:31:08.960 -->
00:31:16.880Pretty much every organization I've seen that have AIs, the lab teams, that when they say, Why can't you get it in production?
00:31:16.880 -->
00:31:33.759It'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.
00:31:33.759 -->
00:31:54.960And 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.
00:31:54.960 -->
00:31:58.319Um, would you agree, disagree, challenge my point of view on this?
00:31:58.480 -->
00:31:59.839Yeah, no, I do agree.
00:31:59.839 -->
00:32:11.200Um, 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.
00:32:11.200 -->
00:32:18.960Um, 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.
00:32:18.960 -->
00:32:24.079It was all about let's assume we're gonna get hacked or attacked or there's a threat.
00:32:24.079 -->
00:32:37.200Whereas 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.
00:32:37.200 -->
00:32:55.200So 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.
00:32:55.200 -->
00:33:08.240Um, 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.
00:33:08.240 -->
00:33:17.519But 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.
00:33:17.519 -->
00:33:27.279Otherwise, 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.
00:33:27.680 -->
00:33:28.880Absolutely.
00:33:28.880 -->
00:33:32.960Brad, as ever, um great talking to you about the topic.
00:33:32.960 -->
00:33:40.400Um Dominic, is there anything else you think we've missed in this um rambling of two old veterans from the industry?
00:33:41.119 -->
00:33:51.119No, 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.
00:33:51.119 -->
00:34:17.199Um 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.
00:34:17.199 -->
00:34:26.000And in the planning for this podcast, we talked about you know what might that look like if we started to think about vibe engineering?
00:34:26.000 -->
00:34:47.920Could 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.
00:34:48.320 -->
00:34:49.599Yeah, I I think so.
00:34:49.599 -->
00:34:52.960I I had a you know a strong dream on this one.
00:34:52.960 -->
00:34:58.960I think vibe coding was all about using AI to help you write snippets of code, review code, refactor code.
00:34:58.960 -->
00:35:04.320Then it became all about how does it write whole applications or games or useful utilities for you.
00:35:04.320 -->
00:35:09.679And I think that concept is going to extend further where you'll get vibe orchestration, right?
00:35:09.679 -->
00:35:27.440You'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.
00:35:27.440 -->
00:35:51.840And 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.
00:35:51.840 -->
00:36:06.559And 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.
00:36:06.559 -->
00:36:17.599I argue a day will come where we will have very successful new businesses in motion that have no humans at the wheel.
00:36:17.599 -->
00:36:35.119And 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.
00:36:35.119 -->
00:36:40.880And there may not be a human at the wheel along in any stage of any of that.
00:36:40.880 -->
00:36:42.320Now that's a that's a way off.
00:36:42.320 -->
00:36:46.880I 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.
00:36:46.880 -->
00:36:52.000But I I I don't see much in the way of that not happening at some point.
00:36:52.000 -->
00:36:59.679So vibe engineering, vibe orchestration, vibe, vibe company ideation and creation.
00:36:59.679 -->
00:37:00.559I mean, why not?
00:37:00.559 -->
00:37:00.800Right?
00:37:00.800 -->
00:37:03.599It's it's definitely the out of the possible.
00:37:04.559 -->
00:37:06.800And that's a slightly terrifying thought.
00:37:06.800 -->
00:37:07.280It is.
00:37:07.280 -->
00:37:24.480Although 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.
00:37:24.480 -->
00:37:29.599The future's bright if you need documentation.
00:37:29.599 -->
00:37:32.239But at that point, who's reading the documentation?
00:37:32.239 -->
00:37:33.920That's a whole other question.
00:37:33.920 -->
00:37:38.559No, this has been a fascinating conversation.
00:37:38.559 -->
00:37:58.239So 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.
00:37:58.239 -->
00:38:00.719Let's hope so anyway.
00:38:02.000 -->
00:38:02.719Excellent.
00:38:02.719 -->
00:38:06.000So once again, Brad, thanks for your time.
00:38:06.000 -->
00:38:14.480And uh thank you listeners for uh hopefully what was an uh interesting conversation.
00:38:15.199 -->
00:38:16.079Yes, indeed.
00:38:16.079 -->
00:38:24.079As 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.
00:38:24.079 -->
00:38:29.119If you have thoughts, comments, suggestions for future episodes, please do come and find us there.
00:38:29.119 -->
00:38:31.760Uh, we would love to hear your thoughts.
00:38:31.760 -->
00:38:35.840But for now, thanks for listening and thanks once again to Brad for coming on.
00:38:36.159 -->
00:38:36.559Pleasure.
00:38:36.559 -->
00:38:37.199Thank you, everyone.
00:38:37.199 -->
00:38:40.239It's good to see you, and uh hello from Australia.
