From SOA To Composability: Why Now Is The Time For Composable Architecture

WEBVTT
00:00:00.239 --> 00:00:02.399
Hello and welcome back to The Enterprise Alchemists.
00:00:02.399 --> 00:00:06.400
I'm your host, Dominic Wellington, and I'm here with my co-host, Guy Murphy.
00:00:06.400 --> 00:00:07.040
Hi, Guy.
00:00:08.080 --> 00:00:09.119
Greet ings, Dominic.
00:00:10.400 --> 00:00:15.519
The Enterprise Alchemists is a podcast for and by Enterprise Architects.
00:00:15.519 --> 00:00:20.640
It's hosted by SnapLogic, but we talk to people from across the industry.
00:00:20.640 --> 00:00:25.440
But this time we're going to be talking to one of our colleagues, Brad Drysdale.
00:00:25.440 --> 00:00:26.960
Welcome to the podcast, Brad.
00:00:27.440 --> 00:00:27.760
Thank you.
00:00:27.760 --> 00:00:28.559
Pleased to be here.
00:00:28.719 --> 00:00:29.280
Welcome everyone.
00:00:29.280 --> 00:00:30.160
Thanks for listening.
00:00:30.160 --> 00:00:39.280
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.
00:00:39.280 --> 00:00:45.759
This 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.679
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.
00:01:03.679 --> 00:01:09.280
So, 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.120
Absolutely, Dominic.
00:01:11.120 --> 00:01:12.560
So uh yeah, welcome, Brad.
00:01:12.560 --> 00:01:27.439
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.
00:01:27.439 --> 00:01:45.519
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.
00:01:45.519 --> 00:01:54.239
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.
00:01:54.239 --> 00:02:06.319
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.
00:02:06.319 --> 00:02:10.080
So um really looking forward to this conversation.
00:02:10.080 --> 00:02:14.000
So um let's kick off with the Wayback Machine.
00:02:14.000 --> 00:02:22.719
Um Composable Enterprise was really being kicked around as a phrase by Gartner back in around 2008-2009.
00:02:22.719 --> 00:02:35.039
Um, 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.080
Um 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.039
It was talking about the idea of the flexible enterprise, the ability to decouple things.
00:02:47.039 --> 00:03:05.840
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?
00:03:06.400 --> 00:03:08.080
Yeah, no, it's a great question, Guy.
00:03:08.080 --> 00:03:19.680
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.
00:03:19.680 --> 00:03:26.560
I 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.599
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.
00:03:39.599 --> 00:03:48.400
What 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.960
And the ways that many of these new application components have been built is very heterogeneous.
00:03:54.960 --> 00:04:20.800
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.
00:04:20.800 --> 00:04:39.759
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.
00:04:39.759 --> 00:04:45.600
I 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.399
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.
00:05:00.399 --> 00:05:13.680
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.
00:05:13.680 --> 00:05:24.879
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.
00:05:26.240 --> 00:05:27.839
I can't agree with you more.
00:05:27.839 --> 00:05:36.720
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.
00:05:36.720 --> 00:05:42.399
So um, for many people, web services will appear to be um a way back technology.
00:05:42.399 --> 00:05:58.879
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.
00:05:58.879 --> 00:06:09.920
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.
00:06:09.920 --> 00:06:19.519
Um 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.399
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.
00:06:32.399 --> 00:06:53.439
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.
00:06:53.439 --> 00:07:17.600
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.
00:07:18.000 --> 00:07:32.480
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".
00:07:32.480 --> 00:07:34.720
That one's special for you, Brad.
00:07:34.720 --> 00:07:41.680
So 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.959
Is that a fair summation?
00:07:43.279 --> 00:07:44.560
Uh very much so.
00:07:44.800 --> 00:07:52.240
And 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.079
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.
00:08:12.079 --> 00:08:33.039
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.
00:08:33.039 --> 00:08:38.000
But for the mission critical services, um it was acceptable.
00:08:38.000 --> 00:08:52.480
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.
00:08:52.480 --> 00:09:04.159
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.
00:09:04.159 --> 00:09:19.919
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.
00:09:19.919 --> 00:09:29.600
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.
00:09:30.000 --> 00:09:31.919
Yeah, we saw a lot of that globally, I think.
00:09:32.080 --> 00:09:45.600
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.
00:09:45.600 --> 00:09:48.240
But you still need to have a framework around it.
00:09:48.240 --> 00:10:00.159
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.
00:10:00.159 --> 00:10:04.240
Um what's kind of changed with the shift to the iPaaSes?
00:10:04.240 --> 00:10:24.960
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.
00:10:24.960 --> 00:10:27.039
Um, what's your point of view on that?
00:10:27.360 --> 00:11:04.320
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.
00:11:04.320 --> 00:11:18.559
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.
00:11:18.559 --> 00:11:23.120
And so APIs did a really good job around servicing that space.
00:11:23.120 --> 00:11:29.440
The challenge was that you ended up with so many of them, and discoverability became a challenge.
00:11:29.440 --> 00:11:38.799
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.
00:11:38.799 --> 00:11:57.120
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.
00:11:57.120 --> 00:12:06.320
And 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.279
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.
00:12:27.279 --> 00:12:36.960
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.
00:12:36.960 --> 00:12:53.840
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.
00:12:53.840 --> 00:13:05.679
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.
00:13:05.679 --> 00:13:27.919
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.
00:13:27.919 --> 00:13:35.200
So, 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.720
Because 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.279
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.
00:13:51.279 --> 00:13:59.279
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.
00:13:59.279 --> 00:14:12.000
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.
00:14:12.000 --> 00:14:36.639
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.
00:14:36.639 --> 00:14:38.399
It just made it harder.
00:14:38.399 --> 00:14:52.879
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.
00:14:54.879 --> 00:14:56.639
I can agree with you more on this.
00:14:56.639 --> 00:15:11.360
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.
00:15:11.360 --> 00:15:46.240
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.
00:15:46.240 --> 00:15:51.039
Now, obviously, reuse may not be a universal concept and not may not be required.
00:15:51.039 --> 00:16:00.240
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.
00:16:00.240 --> 00:16:29.200
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.
00:16:29.200 --> 00:16:45.360
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.
00:16:45.759 --> 00:16:47.200
We'll fix it in prod.
00:16:48.240 --> 00:16:49.679
Are you still seeing that today?
00:16:49.919 --> 00:16:51.679
Of course, yeah, absolutely.
00:16:51.679 --> 00:16:59.039
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.
00:16:59.039 --> 00:17:03.440
You know, agility, which is why the composable concept is so powerful, right?
00:17:03.440 --> 00:17:05.680
Because agility and fungibility is important.
00:17:06.319 --> 00:17:10.319
Yeah, it's all very reminiscent of object-oriented programming.
00:17:10.319 --> 00:17:21.359
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.
00:17:21.359 --> 00:17:23.119
It all sounds very familiar.
00:17:23.119 --> 00:17:30.880
The big addition of uh composable architecture seems to have been that central repository that was updated live.
00:17:30.880 --> 00:17:34.400
Uh, but the the failure was the same.
00:17:34.400 --> 00:17:38.079
It's that it only worked if you'd already done it, so to speak.
00:17:38.079 --> 00:17:39.039
Is that fair?
00:17:39.359 --> 00:17:40.720
Yeah, there is a lot of that.
00:17:40.720 --> 00:17:50.640
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?
00:17:50.640 --> 00:17:52.640
The the number was very low.
00:17:52.640 --> 00:18:08.240
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?
00:18:08.240 --> 00:18:11.440
And we'd look for commonality and reuse of requirements.
00:18:11.440 --> 00:18:16.400
So, what would the APIs be that would comprise these applications and these use cases?
00:18:16.400 --> 00:18:23.680
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.
00:18:23.680 --> 00:18:35.839
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.
00:18:35.839 --> 00:18:38.559
Um, adoptability was the other big thing, right?
00:18:38.559 --> 00:18:48.319
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.
00:18:48.319 --> 00:18:56.400
And 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.480
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.
00:19:08.480 --> 00:19:19.440
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?
00:19:19.440 --> 00:19:36.720
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.
00:19:36.720 --> 00:20:05.039
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.
00:20:05.039 --> 00:20:26.240
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.
00:20:26.640 --> 00:20:31.440
No, and that's still challenging 2025 in certain environments.
00:20:31.440 --> 00:20:36.400
So it is becoming very interesting that you know some of these concepts are going full circle.
00:20:36.400 --> 00:20:45.759
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.
00:20:45.759 --> 00:21:34.319
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.
00:21:34.319 --> 00:21:57.839
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.
00:21:57.839 --> 00:22:05.599
Um, 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.759
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?
00:22:19.759 --> 00:22:21.759
Would say, No, we don't.
00:22:21.759 --> 00:22:32.160
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.
00:22:32.160 --> 00:22:53.200
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.
00:22:53.200 --> 00:23:06.720
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.
00:23:06.720 --> 00:23:08.880
They're actually how you have to do business.
00:23:09.119 --> 00:23:09.599
Yeah.
00:23:09.599 --> 00:23:32.160
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?
00:23:32.160 --> 00:23:40.079
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.
00:23:40.079 --> 00:23:48.559
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.
00:23:48.559 --> 00:23:50.400
But everything else can change.
00:23:50.400 --> 00:23:57.759
Because 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.759
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.
00:24:05.759 --> 00:24:14.319
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.
00:24:14.319 --> 00:24:16.559
That that shouldn't necessarily need to change.
00:24:16.559 --> 00:24:57.039
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.
00:24:58.480 --> 00:25:00.400
So that's a perfect segue.
00:25:00.400 --> 00:25:04.799
So I wanted to bring this into some of the sort of the modern thinking around this.
00:25:04.799 --> 00:25:10.799
So um let's have a candy conversation about what we're seeing with in the AI domain.
00:25:10.799 --> 00:25:14.640
So obviously, it's the hot topic for the last two years.
00:25:14.640 --> 00:25:19.200
We've seen some incredible shifts in the marketplace because of the launch of LLMs.
00:25:19.200 --> 00:25:32.160
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.
00:25:32.160 --> 00:25:58.720
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.
00:25:58.720 --> 00:26:07.440
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.
00:26:07.440 --> 00:26:12.640
But do you think that REST and the old APIs are dead?
00:26:12.640 --> 00:26:19.920
And 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.960
Um, 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.079
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.
00:26:48.720 --> 00:26:50.160
Yeah, really good question.
00:26:50.160 --> 00:26:56.559
I 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.119
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.
00:27:05.119 --> 00:27:24.720
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.
00:27:24.720 --> 00:27:26.400
I think there's still a lot of power there.
00:27:26.400 --> 00:27:39.119
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?
00:27:39.119 --> 00:27:53.599
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.
00:27:53.599 --> 00:28:04.720
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?
00:28:04.720 --> 00:28:09.920
And we've seen examples where agents have done that in a vocal world using things like Gibberlink.
00:28:09.920 --> 00:28:18.160
They 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.440
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.
00:28:45.440 --> 00:29:05.920
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.
00:29:05.920 --> 00:29:07.359
And that's an interesting thought.
00:29:07.359 --> 00:29:20.559
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.
00:29:20.559 --> 00:29:21.839
Maybe, right?
00:29:21.839 --> 00:29:23.839
That's one guess, but it could be anything else.
00:29:23.920 --> 00:29:25.839
It's it's really hard to predict.
00:29:25.839 --> 00:29:30.720
Yeah, but my guess is that's how it's been with every previous generation of technology, right?
00:29:30.720 --> 00:29:42.240
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.
00:29:44.640 --> 00:29:45.839
Very very likely.
00:29:46.400 --> 00:29:50.319
Bringing this around, I mean, every company I'm talking to is looking at AI.
00:29:50.319 --> 00:30:12.079
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.
00:30:12.079 --> 00:30:18.400
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.
00:30:18.400 --> 00:30:46.799
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.
00:30:46.799 --> 00:31:02.720
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.
00:31:02.720 --> 00:31:08.960
And Gartner talks about 70% of the AIs aren't getting out of the labs.
00:31:08.960 --> 00:31:16.880
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?
00:31:16.880 --> 00:31:33.759
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.
00:31:33.759 --> 00:31:54.960
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.
00:31:54.960 --> 00:31:58.319
Um, would you agree, disagree, challenge my point of view on this?
00:31:58.480 --> 00:31:59.839
Yeah, no, I do agree.
00:31:59.839 --> 00:32:11.200
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.
00:32:11.200 --> 00:32:18.960
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.
00:32:18.960 --> 00:32:24.079
It 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.200
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.
00:32:37.200 --> 00:32:55.200
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.
00:32:55.200 --> 00:33:08.240
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.
00:33:08.240 --> 00:33:17.519
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.
00:33:17.519 --> 00:33:27.279
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.
00:33:27.680 --> 00:33:28.880
Absolutely.
00:33:28.880 --> 00:33:32.960
Brad, as ever, um great talking to you about the topic.
00:33:32.960 --> 00:33:40.400
Um 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.119
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.
00:33:51.119 --> 00:34:17.199
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.
00:34:17.199 --> 00:34:26.000
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?
00:34:26.000 --> 00:34:47.920
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.
00:34:48.320 --> 00:34:49.599
Yeah, I I think so.
00:34:49.599 --> 00:34:52.960
I I had a you know a strong dream on this one.
00:34:52.960 --> 00:34:58.960
I 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.320
Then it became all about how does it write whole applications or games or useful utilities for you.
00:35:04.320 --> 00:35:09.679
And I think that concept is going to extend further where you'll get vibe orchestration, right?
00:35:09.679 --> 00:35:27.440
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.
00:35:27.440 --> 00:35:51.840
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.
00:35:51.840 --> 00:36:06.559
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.
00:36:06.559 --> 00:36:17.599
I 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.119
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.
00:36:35.119 --> 00:36:40.880
And there may not be a human at the wheel along in any stage of any of that.
00:36:40.880 --> 00:36:42.320
Now that's a that's a way off.
00:36:42.320 --> 00:36:46.880
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.
00:36:46.880 --> 00:36:52.000
But I I I don't see much in the way of that not happening at some point.
00:36:52.000 --> 00:36:59.679
So vibe engineering, vibe orchestration, vibe, vibe company ideation and creation.
00:36:59.679 --> 00:37:00.559
I mean, why not?
00:37:00.559 --> 00:37:00.800
Right?
00:37:00.800 --> 00:37:03.599
It's it's definitely the out of the possible.
00:37:04.559 --> 00:37:06.800
And that's a slightly terrifying thought.
00:37:06.800 --> 00:37:07.280
It is.
00:37:07.280 --> 00:37:24.480
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.
00:37:24.480 --> 00:37:29.599
The future's bright if you need documentation.
00:37:29.599 --> 00:37:32.239
But at that point, who's reading the documentation?
00:37:32.239 --> 00:37:33.920
That's a whole other question.
00:37:33.920 --> 00:37:38.559
No, this has been a fascinating conversation.
00:37:38.559 --> 00:37:58.239
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.
00:37:58.239 --> 00:38:00.719
Let's hope so anyway.
00:38:02.000 --> 00:38:02.719
Excellent.
00:38:02.719 --> 00:38:06.000
So once again, Brad, thanks for your time.
00:38:06.000 --> 00:38:14.480
And uh thank you listeners for uh hopefully what was an uh interesting conversation.
00:38:15.199 --> 00:38:16.079
Yes, indeed.
00:38:16.079 --> 00:38:24.079
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.
00:38:24.079 --> 00:38:29.119
If you have thoughts, comments, suggestions for future episodes, please do come and find us there.
00:38:29.119 --> 00:38:31.760
Uh, we would love to hear your thoughts.
00:38:31.760 --> 00:38:35.840
But for now, thanks for listening and thanks once again to Brad for coming on.
00:38:36.159 --> 00:38:36.559
Pleasure.
00:38:36.559 --> 00:38:37.199
Thank you, everyone.
00:38:37.199 --> 00:38:40.239
It's good to see you, and uh hello from Australia.