Loosely Coupled - Migrating away from IPaaS technologies

Good morning, good afternoon, and good evening to everybody watching.

I hope you have a nice refreshing cup of whatever you like to drink.

For me, it's a nice jug of coffee today.

And I welcome you to another episode of Loosely Coupled by Bridging the Gap.

My name is Karol Skrzymowski, and I'll be your host tonight.

And today, a controversial topic, migrating away from iPasses or iPass technologies.

And this already created quite a stir, because I already had some pings from people at Boomi and a conversation with a colleague from MuleSoft, like, Carlos, what the hell are you doing?

Why are you talking about that?

What's going on?

You're a community leader at MuleSoft.

What are you starting to advocate for moving away from iPasses?

Well, we'll dig into that.

But before we dig into the topic, let me introduce you, Brian Labelle, coming to us from Canada, an enterprise architect with, correctly, if I'm wrong, 40 years of experience in IT.

Welcome, Brian.

Yeah.

Thank you.

Thanks for having me.

And yeah, I think we're going to have a fun discussion, because there is controversy.

And the idea of doing this, of moving away from iPass, let's say, or Boomi, MuleSoft, that kind of threatens these large organisations, I guess, and they wonder, oh, like, we're going to lose customers.

You know, obviously, I think there's something that's sometimes in IT, you know, we think, oh, we're scientists, let's say, like, as engineers and architects, we're like, this is the logical thing that we're doing here.

But of course, any kinds of decisions around stuff like technology that we're using behind it, there's a lot of money.

There's a lot of money behind these big organisations like Boomi, MuleSoft.

And it's like, what I often tell, and sometimes I tell my kids this sometimes, is that you have to think about the stakeholder.

Who is this saying this?

Like, why would they say this?

And, you know, are they always in your best interest?

They have a stake in the discussion.

So it's not necessarily always unbiased.

And I'd like to think that something that I've always, and it goes back to my, where it came from, and how it came up.

And that's why I was going to tell you, like, maybe I'm going to go over the whole 40 years here and tell you exactly why I would come to this idea.

But I won't, I won't, we only have two hours.

So I don't think I can do that.

But I mean, I was like, oh, we actually have a bit of an echo on your side, I hear.

Because I hear myself.

So that's going to be a bit of a tricky.

All right.

So before we jump into the stakeholders and the deep end of things, you have 40 years of experience in IT.

Let's have an overview of what you've been doing.

Because you've been doing enterprise application integration with integration platforms, but that's just the only part of it.

Right?

In that sense.

Yeah, so I can tell you, and I wanted to tell you a little bit about it.

Because like I said, it's, it informs my, where I'm coming from, right?

So, and so I went to McGill University, that's a big university, it's kind of even worldwide, is one of the top universities.

So I went there, and I took, so I was there between 81 in 1981, 1984.

And I was taking computer courses.

And we were studying, there were lots of different programming languages at the time, I actually took a course, which is like a third level course, third year course in programming languages.

And we did PL1, Snowball, and APL, just to look at different languages.

So right from, you know, and so this would have been in 1982, or something.

So like 42, or three years ago, my mind was like, what language are we using?

And why?

What are the advantages of this language?

So, and then, but then, okay, so then I started working, I graduated, I was 21.

But early on, I started as a business analyst, at one of the insurance companies that, in Canada.

So it was huge, we had millions of customers, millions of dollars.

So we're working with, with big technology here, we had a mainframe.

And we even had to like, share out our mainframe to other people, there weren't that many mainframes.

But we had, we were using COBOL.

And we had a big accounting, billing, commission system.

So I was working with that, I was working with pensions, and building systems.

And then we also had, so we have COBOL, COBOL is like, if you're a programmer, you're using COBOL, right?

Like, the other stuff, there were some PCs coming in, that wasn't really considered real, I think, but, and then, but then they, PCs came in, using BASIC, people writing stuff on Excel, people writing stuff in SEED, and lots of different technologies.

So there's APL, other languages.

So, so the reason I say that is that so the first six years of my career, I was working in lots of different languages.

So it wasn't really anything set, maybe COBOL would be the biggest one.

And then also, different database, we're using vSAN.

And then so lots of interesting things happened around like the 8990, where we had DB2 came around.

So we had relational databases, we had, which was huge, and SQL, which was really fundamental.

And then, you know, there was C, C++, PCs were coming along, people were building stuff on that.

People were networking those PCs.

Anyway, so I could just keep going on and on.

But so, but the bigger important thing for me is that it wasn't, I wasn't, you know, wasn't that I was just using something.

And I think that there's a lot of people now, maybe they grew up with Mulesoft, grew up with Boomi, grew up with iPasses, and that's what they've been using, right.

But I, we had, we had the same business challenges, business requirements, and we were solving them in different ways, different technology.

And so I always see stuff, I'm thinking more of the whether the requirements, what's the technology we should use?

Ultimately, I ended up in Java.

So I did, I have a lot of Java.

So and I really like Java from the beginning.

So, you know, I say 20, but it's really maybe 25-30 years.

I know in 92, I was using it.

So, yeah, okay.

I mean, just from the perspective of the languages you're using, APL, I really have to Google that.

It's like that archaic.

I mean, if I look at, for example, my conversations with my mom over programming, because she as an engineer, she learned programming, but she was programming on punch hole cards, you know.

So that's the generation gap I experienced.

But then you go APL, it's like, what the hell is APL?

Never heard of that.

COBOL, yes, that's something I know, I've heard and understand what that is.

And that's a, now it's very difficult to find people actually coding in COBOL, they're priced really high.

But like APL.

Yeah, I can tell you a little bit about it, because it actually stands for a programming language, APL, which is funny.

And then it was, it was very mathematical.

And because I worked in an insurance company, they would do really compressed mathematical formulas.

And one of the funny things when I was at McGill, we had, like, I had a typewriter, it was like an IBM typewriter.

And I would, that was my input.

And I would type this information.

And what would come out was on the paper, it would print out the response.

So my monitor was actually the printer, something that was connected into the typewriter.

And for some characters, which were complex, I had to do backspace.

And this was this symbol, and then stuff.

And I would enter data, and it would show me print out what the result was, and to print out the result.

So yeah, really cool technology.

So, you know, it's a full language, very concise mathematical language.

And people love that.

Yeah, actuaries loved it.

Yeah, so, so in that sense, people already know you're a dinosaur, I think we all need to do a special episode of loosely coupled just invite people that have around 40 years of experience in IT for them just to reminisce of your good old times.

I have a lot of photos from the museum in Rijeka in Croatia, where there's like the first 50 megabyte IBM hard magnetic drive, it was this big.

It's the reminiscing.

But yeah, okay, all of that composes your background.

So you're basically a versatile programmer architect, looking back 40 years, you've touched upon so many languages.

And then, of course, back then, we were solving the same problems in it as we're solving now to an extent, especially in terms of interoperability, the moment we had some sort of distributed computing, and we did have already distributed computing back then to a very small extent.

The difference between then and now is, I think, only the scale of the problem.

Would you agree?

Yeah, well, what I wanted to say, and some people might say, well, why should I even listen to this guy?

But really, I am actually saying it because what we were doing then, and the success that we had, in many ways, we were writing, you know, we were dealing with, you know, millions of dollars, this was a huge insurance company, with millions of customers, we're sending out statements, and it's also financial.

So sometimes I've been working on some migrations of old technology, and they're like 30 years old.

And people are saying, oh, look at this old stuff, and who wrote this stuff?

And in my mind, I'm thinking, you know, this is 30 years old, it's probably been hundreds of millions of dollars.

With the stuff that we're writing now, will that be around 30 years from now?

Like this stuff worked, it worked, and some people are ready to change it.

It does get patched.

Sometimes I think the patching is a problem.

When I see what, like how they patch stuff, and that causes a problem.

But anyways, but I did want to say it in respect to the fact that, that yeah, I've, I've seen a lot of technology coming and going.

And I see it.

So I want, I can provide context in terms of, of what is technology now, where's technology going.

And I've often been as kind of an as an enterprise architect, brought in on what technology should be used, you know, on many contracts and consulting projects that I've worked on.

And I can provide that context, because I've seen it.

It's the same, same issues we have, how do we solve it?

What or what technology is coming?

And I wanted to, I forgot to give you a slide for this, but which was around this technology radar.

Have you ever heard of a technology radar?

Yes, I think ThoughtWorks is doing one.

That's a very nice technology radar.

And it's a, a practise for architects, at least described as a practise for architects, for every architect to extend their architectural breadth, or knowledge breadth, to build their own technology radar with similar categories to the ones with ThoughtWorks.

And basically work on, be an expert in the things you know, you know, and work on knowing more things that you don't know.

So it's kind of a bad approach to, well, I call it personally moving the borders of ignorance.

Nice.

Yeah, that's actually very good.

Like you know, that's very good.

You seem to have a lot of knowledge of it, which is good.

I really like it too.

And I was working as like an enterprise architect in an organisation.

And so I was able to implement and you can implement it in any way that you would like, right.

So, and in this case, you know, we would divide into different domains.

So there's the data, we had a data team, we had the testers, we have the developers in different languages.

And what we would do, like I would sit with them.

And it was so it ended up being about 25 meetings, and sit with them and talk about the technology that they're using.

And so that's why everyone has different technology, like the data people had would have a technology, the testers would have a technology, you know, that's why I have to do for different people.

And then, but they're the ones that are using the technology, and they would know it best what's what they hear about what they're reading about, and what they're interested in.

So what it was that the whole idea around the technology radar was, was to make sure and I think this organisation that kind of, you know, and organisations do they built code, they built stuff.

And then next thing, you know, something new has come around, and their stuff is, is out of date.

And they really weren't aware, they weren't thinking about so.

So what this does, every technology, they would say, is this technology?

And actually, I don't know the terms, not like, should we continue using this technology?

Is this some technology we should look at?

Is this technology we should trial?

Is this some technology we need to, to move towards, you know, so and if we were to move towards it, then we would do a roadmap.

So as the enterprise architect, I could do a roadmap on that new product, let's say, or should we continue building in this technology we're using?

Is it does it make sense still, you know, for us, because technology is always changing.

Yeah, so the phrases in the technology radar from ThoughtWorks are hold, assess, trial and adopt.

That's the these are the verbs that ThoughtWorks is using.

So for anybody who's interested in what ThoughtWorks is doing, this is the volume 33 of the technology radar, this is the QR there, you can pop it in and see what they're doing and what kind of technologies they're assessing.

Also, they have this lovely instruction, build your own radar.

So if you want to know how to build your own radar as an architect, there's there's a one way to do it.

It's on this QR code, you can look it up and have some fun to grow your knowledge breadth with it.

Yeah, so, so yeah, so yeah, thanks for allowing me all that talk about my past and that.

But then now I want to go into, well, also the kinds of things that I was working on.

So I worked on utilities, I worked on telephone companies that did, you know, where we were doing telephone number portability.

So then there was a, you know, market where you grab the information, so data transferred over and how you're going to do that.

And then I worked at a utilities company where we can resell information.

So we had to get usage statistics and grab it and then send stuff.

So and then also say, okay, now we have a new customer, we're gonna send that.

So we were doing these large scale data.

And and I built these things in Java.

And, you know, which are in, you know, integrate some somewhat integration stuff.

And I worked in like a big utility company.

And but yeah, so what's happening over time is we, we have all these technologies that we end up using in different products, different, different.

So I what I'm building up now is to the integration and why, you know, it's a good idea to have it do it, you know, we're building all these technologies and different.

And then also there's mergers and acquisitions happen with the 80s or something.

I don't remember when there was a time buying billing companies, I worked with the telephone company.

And, and one of their big objectives was they have eight billing systems for all the telecoms they bought.

And they have to like, let's put this all into one.

But they never actually accomplished that.

And so it was a big problem.

And I was working at this utility company because we had, we counted 300 different systems that we had, you know, so you have a lot of systems that I guess, to me, the most important thing to do is to do an inventory, right?

Just to know, like, sometimes I've been asked to pick something.

And it's like, no one knows about this.

No, where's the source code?

And where's this data coming from?

I think that's the usual problem in terms of what's going on in companies.

And in general, if you look at the perspective of years in IT, we're basically cyclically reinventing the wheel.

It's not about that we have a problem solved.

No, we have to solve it again.

Because some, some people just forgot that it's already solved.

And it's a matter of now, oh, we need to solve it again, because it's a problem all of a sudden.

And I see that the same thing is in interoperability topics.

We actually solved a lot of problems and challenges of interoperability.

Back in the early 2000s, service orientated architecture solved the majority of problems.

And all of a sudden,

because companies didn't know how to change, how to introduce change, how to introduce architecture

into their mix, the companies, the organisation, those projects failed, obviously, there's so many

failed ESB implementations over the years, companies, projects and whatnot, that to the

extent that ESB is no longer an abbreviation we should be using, because it brings all the red

flags in people's heads, right?

And now we're doing API led architecture, which is basically ESB in the derivative from service orientated architecture, right?

So this is not a new concept.

This is not something new in architecture.

This is exactly pretty much the same as it was.

The only difference is that now we have containerisation and virtualisation.

And back then, we did this on a bare metal in server rooms, right?

This was hosted in a server room, every company had their own server room.

That was it.

Now we have clouds, we have containerisation, we have virtualisation, all of that is available.

It's a lot more distributed.

So we have all sorts of different problems in terms of networking.

But basically, the architecture is pretty much the same.

Mm hmm.

Yeah.

Yeah.

And then and this is also where I wanted to show that that book, I guess, right, which was the enterprise.

This one?

Yeah, right.

Great.

Yeah.

Enterprise integration pattern.

But I also want to highlight the year, as you can tell, right, what I was saying, 2003.

So and just that this isn't new.

This is these are things that we have, we have these big systems, how are we going to solve this problem?

Right?

So it's important to understand the problem that we have, right.

And, and that's where I think the iPaaS space comes in.

And you can, you can tell me if I'm right, is that and then, and so that the iPaaS world, but, but I think there was another thing, to me, that, that was kind of a nice solution to this.

But, which was that, okay, so you have all the different, you have all that, what do they call them?

silos, right?

You have a different size of all the different parts in your organisation, you have your IT departments in your organisation.

And you really have so there's kind of a political it's very difficult.

And also you have it people, some people are very close and saying, I don't want to, it's really hard to get stuff.

I remember working once at this place.

And I saw this ER diagram.

And, and she had it on her desk.

And I, I said, Can I have a, because I was a contractor, I said, Can I see that diagram?

He says, No, I couldn't see it.

She wouldn't give me a copy of the ER diagram.

So I had to like, you know, it's like, we're all working together in the same company.

But yeah, so it's a anyways, yeah.

So so I think that there was also a very nice, a political problem of sharing information between these organisations.

I think the iPaaS was a way that maybe CIOs could would maybe be able to get access or to this information.

And, and then also to have a different group of developers that were just going to do this integration, so they're not connected to anyone else.

We always had like a shared services, which would be doing laptops, the network, and they might be doing databases, you know, but shared service, but they didn't have necessarily developers there.

So So then there was this iPaaS thing, which type and, and I'm not I'm not sure if even I understand it, maybe it's of its time, but it says integrated platform as a service.

So it's, I think it was, it was around the time that the cloud came out.

So I think they were thinking, okay, here's on the cloud, it's all there.

And it's no code, you know, you're not going to be writing a lot of code, apparently.

And then I, in my experience, that's not really true.

But anyway, so that you're just like, drag and drop.

And then one of the things I remember being concerned about is, you know, as an architect or enterprise architect, I'd worry about when my when the CIO was travelling, or going on these conferences, that someone was just going to drop them a leaflet and say, oh, we're going to do this.

Now we're gonna, it's gonna solve all their problems.

And here we go, Brian, let's do this.

And they, and, and that's what this is a low code, this, we're going to connect all the systems, we can see everything that's going on.

And everyone talking about get rid of duplication, right?

So, okay.

So let's put it in a perspective, because you're a jack of all trades in terms of your history of it.

I've been doing only enterprise application integration for my whole career of 14 years.

So let's put it this way, before cloud got really, really popular, and at least before we got it, like, really booming in Europe, we already had low code.

So the IPaaS, yes, that's a cloud thing, as all AAS things.

So SaaS, PaaS, IaaS as an infrastructure as a service.

But the IP from that is an integration platform.

So the equivalent of an ESB back in the day.

And those kinds of integration platforms that were low code, well, if you remember Typical Business Works, and I guess you do, Typical Business Works was at least version five and six were never designed for cloud.

They were designed to run on premise.

Then Typical went into container edition, and well, that's designed to run wherever in containers.

So my start in my career as a junior developer was Typical Business Works five, I believe the first version was 5.4 that I touched.

And that was already low code.

It didn't mean that you didn't do a lot of programming, because that was still quite a hefty deal to learn it and to actually use it.

Because you have to have that specialised knowledge, you have to understand XML, you have to understand WSDL files.

But basically, it was an integration platform.

The only difference between an integration platform on premise and IaaS is where it's hosted in essence.

So if we're looking at an IaaS just from the definition standpoint, IaaS to define it would be that a client of an IaaS doesn't really care about the infrastructure and the runtime because it's in the control of the vendor.

So whether that be Typical, MuleSoft, Boomi, Workato, whatever else, they're controlling the infrastructure, they're controlling the runtimes in the sense of upgrades, maintenance, etcétera.

And we're only putting things on the platform.

So business requirements of the business.

Yeah.

So with any platform, a platform is useless unless we start building on top of it.

That's pretty much the gist of it.

And I think that this is what Gregor Hohpe is now preaching with the platform approach and teaching about platforms.

That's pretty much what it can be dumped down to.

So now we're at a place where, okay, we have a lot of things in cloud.

I rarely get to see integration platforms that are actually on premise.

That's a very rare occurrence.

If they're on premise, that's due to like special reasons.

Like let's say we have a European Union...

Security.

Yeah, security.

Exactly.

European Union agency, there are levels of secrecy.

Yes, of course.

In every level you'll have a separate interoperability capability.

Sometimes it's an integration platform.

Sometimes there's so little there that you don't really need an integration platform because that's two systems working in that security area, right?

Security classification.

So yeah.

So on premise is not a thing for a few years.

Gartner even stopped releasing reports on integration platforms that are on premise.

They moved entirely to looking at iPasses because that's the future.

Now for various reasons, including geopolitics, it turns out it's not exactly the future.

So let's dive into the why.

And let's start with the why of customers.

So if you get projects where you're migrating iPasses to Java Spring Boot, why?

What's the why of your clients?

Yeah.

So yeah, you can see it's a long story.

I wonder even how far we are here for 30 minutes.

We went deep into history.

You can see why I went to all the back history and then where we're going.

And yeah, to understand why we would need this.

And that's important.

What's it solving?

And this is where I kind of have this thing where I get it.

I get the iPass and I think it was a good solution.

And because actually oddly the politics of it, like I said, to get all these silos to get the CIO saying, hey, I want to know what's going on and what do we have and let's get them all connected.

And also I feel it's good to have these developers now that are working for the enterprise.

You have the enterprise architect and then he's looking at the big picture of everyone.

And so I think we did need that.

And I've actually worked with MuleSoft and I've written a lot of code in MuleSoft and it's a lot of code.

It's a lot of stuff.

It's a whole technology and knowledge.

But ultimately the end result of it is you're creating APIs to connect things together.

And you have a design.

They like this three-tier design API led architecture, which is good.

I like it.

And also so it was created.

Now we've created the API.

And also there's a security around it.

We've got the security people and we've got the security pieces in there.

So I think it was good in creating all of this.

So I'm happy with that, that we brought people there.

But now what's happening in my mind and why we might not need it, in my opinion, or it's an option.

So that option would be, well, they're charging us a lot of money now and they kind of got us locked in and we're in there and they're charging us these licencing costs.

And that's what is too much.

And I always thought that would happen with the cloud too.

Everyone's going to go on the cloud and then they're just going to charge us like crazy.

But ideally you can go from one to the other.

That's kind of an oligopoly in my mind.

So then your prices will come down to some degree.

But whereas MuleSoft is less of a, you know, it's more of a monopoly that they've kind of got you.

Now they've got all of their developers, all this technology, all this code that you've written in DataWeave.

And now you're kind of stuck with that.

So my proposal is, okay, that's one thing that you could do, convert this all into Java.

You have the APIs now.

And if you do it in Java, well, then I think you asked me that originally too, when we first met is like, why Java?

But ultimately MuleSoft is writing it in Java.

It ends up being Java.

So in order to be perfect and you don't want to make any changes, you have to make it exactly the same code.

I don't want to do any kind of change in terms of even the precision.

I'm going to stop you here because you're diving into the why.

The question is still why?

Other than licencing, why?

Because I do agree.

Yes, MuleSoft is Java.

Basically what you're doing when doing MuleSoft or Boomi or anything else, you're basically creating configuration that is understood by the engine, by the predefined libraries.

And they just run that configuration.

That's basically what the low code is in terms of bypasses.

But why?

Why would your clients consider other than licencing?

Because licencing, I get it.

OPEX costs, yes.

The licencing costs of technologies at times are, yeah, not even going to go there, but my opinions of how certain companies can be very greedy about their licences.

And I've seen them fall out of grace because of that greediness.

But apart from the OPEX costs and people looking at licences, what other why is there to migrate to?

There's a lot of whys, right?

But we have also, let's say you do a technology radar and you take a look at what is the technologies that you're using and what, and each organisation can do that.

I'm not sure if they have different iPaaS.

Usually you try to stick with one, MuleSoft, it could be Boomi or something, but you might end up with some organisations that monthly, or you buy a new one, they have another iPaaS, right?

So you have to look at that MuleSoft and say, do we still want to do MuleSoft?

Do we still want to write MuleSoft?

And it's like, and that's not, is it still the best?

Or also, what is MuleSoft doing for us that we won't get with Java?

Is there something extra that it's giving us?

I think it was good to get us to where we are, get us going, get us, but it's not doing anything extra.

It's not going to be faster.

It's going to be more expensive.

It's going to cost more.

It's going to be, we have to get MuleSoft developers, but you can look at that total cost of ownership of having a Java developer, and then this kind of economy of scale you would have, do you have Java developers already?

And you already have this technology and you're running stuff.

You can kind of also simplify the amount of languages and technology that you have.

Like if you can look five, 10 years down the road, are we going to have MuleSoft?

Or are we going to have Java?

Like I can pretty well assure you we're going to have Java, but I'm not sure about MuleSoft.

And so there is, what's it giving you?

And when you talk about an API, you still have the API, the security, you're going to have just the same, obviously the same security you're going to have in Java.

You're going to have load balancers.

You can have your OAS, like your specifications can all be written.

And so you really, to me, why would you stick with iPaaS?

Is it giving you more benefits than you would have with Java?

I mean, obviously there's a cost of switching to Java.

So yeah.

So my question is, why stick with iPaaS?

What's it giving you that Java would not?

That's I think a valid question, but I think as it states also on my lovely t-shirt, which nobody sees right now, it depends.

If we're looking at ownership, total cost of ownership.

Now, okay.

MuleSoft is a technology for integration platforms.

It's a dedicated technology.

And of course, if you are snappy clever enough and have enough money and time, everything is doable with Java.

That's 100%.

So I'm going to play the devil's advocate here.

I'm going to be, you advocate for moving to Java.

I'm going to advocate for iPaaS in that sense.

Okay.

Let's, you know what?

I'm going to just, yeah.

I think I'm going to just open dry.io and let's start putting things into, I'm just going to draft live.

Let's say, let me find my dry.io. There we go.

And I'm just going to take myself a window with my notes because I came prepared with notes.

Let me just only see how I, right.

Because now nobody sees us.

So let's make us visible to the world back again.

Hello.

There we are.

Perhaps maybe this view because then dry.io will be more visible.

All right.

So let's say we're looking at the total cost of ownership.

So TCO.

All right.

I'll make it.

It's not readable, not readable.

So let's make it somewhat bigger.

There we go.

TCO.

If we're looking at TCO, well, first thing that comes to mind that you're saying is licence costs, right?

That's the first thing that, one of the first things you said about TCO.

Okay.

If you're looking at MuleSoft, what do you think comes into the licence cost of MuleSoft?

What's there?

Yeah.

I mean, I guess, and I, I'm not sure if we're allowed to talk about licencing costs through MuleSoft.

I can't tell you the amounts and everything.

No, no, no, no.

There's a runtime cost per, per, per megabyte or, you know.

Let's, let's not, let's not talk about the, the, the numbers.

Anybody who will want to know the numbers, they'll get the numbers directly from MuleSoft or whoever is the reseller in that case.

Yeah.

They know, they know the numbers.

Yeah.

They know the numbers.

If somebody wants to know the numbers, go to MuleSoft.

They'll tell you the numbers and you can negotiate the numbers.

So that's fine.

But let's say, let's say what's, what's in the, in the licence.

So in the licence, of course, there are two models for licencing costs because since November last year or October last year, the, the, there was a change in licencing model.

So we have the model for vCores, right?

And we have the model with fixed and usage, right?

So these are two different models of, of licences.

This is what we pay for.

In both of these, we do have different things that comes, that come into the licence costs, right?

So what does, what does provide?

Because, okay, you're advocating, you're advocating that, well, you can do everything in Java.

What's, if we're looking at migrating MuleSoft to Java, what is there that you're migrating, starting with?

Yeah.

And it will, it would be in a cloud, right?

So there, it's not going to be free, right?

You're going to, you're going to have to pay.

So there is a cost.

And I think that like, without getting into too much detail, I think it can be like 20% of the MuleSoft cost, you know, and, and also with the MuleSoft, I don't know if you have the support costs, but there's like an annual fee, right?

With the, depending on which tier you are with MuleSoft, like gold tier, bronze tier, whatever, but there is a, you know.

Okay.

Support.

And that's, I think more on the MuleSoft side.

So, so let's, let's put it another way.

What does MuleSoft provide or, or any iPaaS for that matter?

First of all, we have some functional capabilities.

In that sense, in MuleSoft and any iPaaS, that would be interoperability, interoperability, right?

That's not going to fit.

Let's do it that way.

So we have interoperability because as I argue to a lot of people, well, people see interoperability, they say that's a, that's an ility.

That's a non-functional requirement.

No, no, no.

Okay.

If we're talking integration platforms, interoperability becomes the functional requirement of the integration platform.

Okay.

So this is the main functional aspect of an integration platform.

We're basically building integration flows to move data from place to place, right?

Okay.

So this is the main thing.

So this is the logic of an iPaaS.

This is the old elements that expose an API, transform the payload to get the payload to the other side, and then return a response if needed, right?

What else do we have in an iPaaS?

And this is, again, I'm going to be the devil's advocate here.

Let's see.

So connectors.

Yeah.

So we have, aside from connectors, we have also predefined libraries.

So all sorts of libraries for logging, for splitting operations and strings, operation on payloads.

We also have specific would be also DataWeave and other tools.

That's some sort of mapping tools or XPath, XSLT, these kinds of capabilities, right?

So these are predefined libraries of capabilities to work around data, data formatting, and just playing around with whatever is there that we're moving because we're moving data.

Okay.

So these are the core capabilities around an iPaaS.

All right.

If we look at this from a perspective, iPaaS also gives us infra because it's a as a service.

So this is the as a service part.

So we don't care about infrastructure because it's handled by the vendor.

If we're doing, of course, a cloud deployment, because if we're doing an on-premise deployment like runtime fabric or something else, of course we need to cater to the infrastructure.

But let's simplify that we're doing a full cloud deployment.

So they're giving infra.

Then in that sense, this is maintenance, right?

In that sense, this would be also updates.

So they're covering that within the licence.

Now, what else has been covered?

Depending on the licences, we have additional tools, I suppose.

So we have API management.

We have, well, alongside the API management, there's an API portal.

We have, what else?

Load balancing.

If, of course, if we're doing this in cloud, we have control plane.

We have logging and monitoring.

And this here, logging and monitoring, I would only argue that this is to a limited extent.

And most companies, when they do iPasses, they implement their own logging and monitoring practises that are centralised.

And it's a way to do it.

That's a very good practise to have it centralised because then logs from a domain system that initiates the communication land at the same place as logs from the iPass and logs from the other systems that partake in that communication, right?

So then we have proper traceability of communication.

We can do root cause analysis based on those logs all in one place.

So easier to operate the whole ecosystem, right?

So these are out of the box things that come with an iPass.

And I would also add to it that we also get with certain iPasses, not with all of them.

And MuleSoft here is a bit of an exception.

We get the message broker as well.

So for example, if you go to SAP BTP, they're partnering with Solace.

So underneath there's Solace running as an event broker.

If you go to Boomi, they're also partnering with Solace.

So they're running a Solace broker underneath.

They have event mesh capabilities, etcétera.

So these are things that come into the licence.

Of course, the message broker would be then optional.

API management, API portal would be something that is sometimes sold as a separate licence.

Fair.

But this is only part of it.

Security.

Yes.

Good point.

Security.

Security is part of the...

Well, that's basically API gateway.

So security policies.

All right.

So that would be that.

Anything else?

Anything I'm missing so far?

Let me check my notes that I wrote down before the stream.

Da-da-da-da-da-da.

Low-balancing tracking API management policies.

Okay.

Yeah.

That's pretty much all in my notes in terms of what is covered by a licence or could be covered by a licence.

Now, I'll give you a chance to advocate for Java.

And tell me, looking at this scope of coverage of the capabilities that are given by an IPaaS, do you think it's feasible to cover this by Java?

And in what scenario that would be feasible to cover it by Java?

No, this is absolutely everything here.

I mean, I can go one by one, but everything here is Java.

And in many ways, better in Java, let's say.

I mean, ultimately, there may be an overhead that's happening with MuleSoft.

Maybe they would be faster.

You can kind of click on.

But one thing that's also is, let's say I'm an architect.

I've been an architect on many projects.

So let's say if I'm an architect on a project, and we're going to implement, we're implementing MuleSoft.

Or let's say even we're implementing Java on both of them.

Like on both of those projects, I'm doing everything here.

Like, it's not like I just pulled out the IPaaS and click, I'm going to choose option one utilities.

So if I was doing this in MuleSoft, and if you did the MuleSoft architect course, you have to look at each of these, right?

What kind of load balancing am I going to do?

What is the logging?

That's maybe more a team meet.

What's the monitoring?

What's message broker?

Which kind of security am I going to do?

What are the connections that I'm connecting that I'm going to do?

And all of that, and there are libraries in Java that do many of these things, too.

And let's say all the connectors, you know, would be like, oh, we're connecting to Salesforce.

Well, there's a connector for Java.

Like there's a, I think, that's questionable because it's Salesforce, but DB2, Oracle, everyone is going to write a Java connector library to connect into them.

And it's going to be straight.

And MuleSoft is just going, well, of course, MuleSoft is taking that code and translating it to Java, right?

So instead you're kind of getting rid of that extra layer.

But all the questions, everything like what is the password?

What's the security?

What level should we do?

Everything needs to be done regardless.

So I know it kind of gives you this feeling like, oh, it's just giving it to you out of the box or something, but it's not.

You still, as the architect, you still need to configure all of these things and you would configure it all in Java.

And there are some things like, I actually remember the logging was, it's log4j, but you couldn't actually update that if you're on a, you lose control of that logging sometimes when you're in some environments.

And then if you've ever contacted, even I'm sure I'm at the highest level of MuleSoft support, I don't find necessarily the support to be any better than my own developers telling me it's obviously, usually it's going to be a business problem.

They're not necessarily going to solve that for me.

And also I'll understand things like what's the threading going on?

What's the performance going on here?

I can do it.

And when you're doing, you're looking at a problem, let's say, and you're going to say, well, I want to do a Java garbage dump of what's going on here.

Can I see the Java code that MuleSoft has created so I can figure out what's the underlying problem here?

So really with Java you have, you're just at that level.

And I'm, I've been a Java, I'm a Java developer.

I've been a Java developer and also I've been a MuleSoft developer.

And sometimes I would, I talk to my friends and I say, you know what?

I think I can build this.

Let's, I'm just going to do a CRUD operation here from my HTTP request into Oracle, you know, and I'm just going to do the whole CRUD and boom, I can write that in Java.

And, you know, if you're a Java developer and there's 7 million Java developers, 7 million people that you can hire that are available to have that experience.

And you may have some already that can move from within your organisation.

And there's 200,000 MuleSoft developers, or fewer that know and understand that.

200,000 is only the size of the MuleSoft community that is a registered community within the space of people actually being actively participating in the community.

The approximated size of the pool of developers for MuleSoft is around five times more.

So it's around 1 million out of like 42 million of developers worldwide, looking at all sorts of developers.

So that's a big pool.

Now, I would argue here two things.

Of course, we can do everything in Java, but my argument here would be feasibility.

Because if I would want to go and build from scratch in Java, an API portal that is functional and has all the features that I need, I think that is completely not feasible from a perspective of company that's running their business.

So if we put this in the context of technology itself, yes, we can do everything in Java.

But if we could put this in the context of a company running their business, then we have the aspect of feasibility that we need to look at.

So what problem is an IPaaS solving here?

IPaaS is solving a problem of speeding up time to market.

Getting that time to market to be a lot shorter than it would be with just writing pure code.

Well, and this is where I'm fortunate enough that I've been able to build systems in both technologies.

And then I've built this stuff.

I know that I can build all of this stuff.

These are the kinds of things that one would do, regardless whether you write in Java or MuleSoft.

I might even argue it would take me a little longer to do in MuleSoft.

It might be harder to get resources.

But I can, as an architect, and my business, I have to do an estimate.

Okay, let's build me some APIs to connect stuff together.

It would take the same amount of time.

And actually, I have an interesting, I kind of did a similar situation once.

And I didn't even actually do it in Java.

So I had to do this project, and they were using Salesforce, right?

So I guess MuleSoft was an option for them.

And the company, and it was a huge, I saw they had just sold for half, one and a half million dollars US.

So that's probably close to a year, one and a half million US.

So it's a big company, right?

And then they said, they said, Okay, Brian, we need to, we need to connect because it's Salesforce.

And they had this, they had this interface, right?

And they had this company had bought, like, you know, 10 different other, or not 10, 20 different companies, they bought a tonne of companies.

And now they're dealing with customers, and they have a million different systems.

And so they bought the Salesforce.

And then Salesforce says, Okay, well, now what we need is we need to get that.

Interesting, it's called licencing, it was the licencing for each of the different, every, every different product had a different licencing term and time that it was going to come, but the customers had probably one or two of each of the different products.

So we had to get the list of all their licences.

So they said, Okay, Brian, like, we need that's, that's the need, we've got all these different places, you've got to go out there, and you got to get that data.

And, of course, well, we're gonna, and we need to, we're going to put it into Salesforce, right?

So they have the Salesforce team, but they need to get the data, they're going to do it Mulesoft and said, No, Brian, you do it.

And, and they actually were doing API's.

And they were doing API's.

And I'm not even sure, I think it was JavaScript.

And I'm not even this was like, two years ago.

So I think they were doing it in JavaScript.

So, so we're just going to write this, the API's in JavaScript.

And so I, I got the team, I had two developers, two testers, I went and I had a DevOps, just write these API's, go to each of these product teams, get the data, what's the form of that licence, you know, and then we're going to have like the data structure that's common enough, and then get that data and just send it into.

So I defined the data.

And then that changed when I got to each one of the ones.

And also, I was just getting and then I'll set to do the security for each of them.

I'll give you the password, give me access.

Sometimes it would just be right from a database, sometimes it's from another API that they have.

So it's API, API.

But I built all of that.

And for me, it was just a halftime gig I did for half a year.

And we did like, you know, 10 API's or something, and connected everything.

So, so we have that problem.

It's the problem, right of connecting information together, and just solved it in JavaScript.

I mean, the API could be botnet, it could be, it could be JavaScript, again, you know, or just lots of other languages, you can use it to use JavaScript, Java.

So for me, it's, I guess that I am converting stuff to Java.

So anyway, so that's, that's, that's where I'm saying I've actually done it.

There was the monitoring.

Yeah, so it is completely doable.

And it's not that's why and that's where I think like, I think it was one of those things that that they sold as as a solution to solve this.

But I think it's, it's more expensive than it's not, it's not necessary.

In my mind, you can do everything in Java, and, and just create your own API's.

But you need you need a, what do you need?

And what's important is, is, is to have an architect, but you're gonna have that you need that architect, regardless, that you need the security architect to have what's all the security around it?

What's the data?

How are we going to manage?

And the iPaaS not going to solve that for you.

Of course, you still need people that can make sense of it, because you can make a big bowl of mud out of integration platform.

And you can do it with MuleSoft, with Boomi, with Word Capital and doing pure Java.

If you don't have the right person that understands integration architecture, no amount of tools and technologies will help you solve the interoperability problems.

That's, that's a given.

I would argue one thing in terms of feasibility, given your background, a versatile background, right?

Wouldn't you say you have a cognitive bias towards Java, and towards high code, pure code, because your background is very much out of code, right?

So your problem solving is essentially a lot quicker in terms of thinking about solving a problem in Java, or in JavaScript, or in any other written language.

And if you look at it from only your perspective as an architect, then of course, yes, you can solve it.

But then those companies at scale, if for example, a company has around 100 domain systems, and those domain systems and applications, they are all unique, they do not overlap in functionality, and they need them to interoperate between one another, we need to exchange data, they need to reuse data, they need to limit impact.

Of course, we need API led architecture or service orientated architecture, right?

Because we need those abstraction layers.

Now, if you would start building this entirely from scratch, then you have to cover oh, so many topics at the beginning.

So if you look at this from a perspective of an average developer, not from your experience perspective, because you have the 40 years of experience, and that makes you a great specialist, but that makes you.

So if we look at this from perspective of, let's say average developer, that has a that would have to learn the company is joining the company just now, has no idea about what the company does, in details, they have a vague idea what the business is, because they, let's say they researched the company before joining, they have a vague idea of what frameworks they're using, perfect, fantastic.

They have no idea of the complexity of those systems, the complexity of the ecosystem, and they're just dumped into the middle of it.

And you say to them, all right, let's make it interoperate, right?

Let's make them those systems exchange data.

We're at the state of we're having a big ball of mud.

Those connections are point to point.

The company's screwed on the interoperability part, because they neglected that forever.

Now, if we're looking from that perspective, okay, you're a Java developer.

So you need to get yourself a framework.

Okay, if you go with Apache Camel, fantastic, right?

Because that's a Java framework for interoperability.

From the pool of seven, eight million Java developers, how many Java developers would know Apache Camel?

Yeah, that's a subset.

Yeah, that's a subset.

Now, let's dig into that feasibility of this subset.

Now, even if we choose Apache Camel, Apache Camel is a fine framework, but you need to learn it, you need to know it.

And I've seen Java developers take Apache Camel, and instead of using Camel routes, they actually omitted all of those and started just building pure Java.

So they're not literally using the framework, they're just building applications, starting with the framework and then doing just pure Java.

That doesn't speed up anything.

The framework is there to speed up things, but they don't know it, they don't learn it.

So they do pure Java because they don't know how to solve those problems.

A different problem entirely, because Apache Camel is not really greatly documented.

There are no good tutorials for Apache Camel to learn it on your own.

You have to dive into an environment that already uses Apache Camel to actually be able to learn it and be efficient at it.

Now, on top of that, I did have a case where we had a pure Java developer that actually knew Camel, and I had the chance to chat with him about his observations about moving Java developers to an integration framework in Java.

Now, this is a mindset shift.

If you're looking as an architect and as a

developer, and these are two different perspectives, at building domain systems,

you're looking at building this with persistence, with security, with dealing with data, with

operating on data, with doing all sorts of business transformations, with a UI, you need

to persist sessions, all sorts of weird stuff that I have no idea about because I'm neither a

Java developer nor a solution or systems architect, right?

I mean, I know quite a bit about that, but never done that personally.

But that's a different mindset from that perspective than a mindset of an integration specialist.

Because if you're an integration specialist, you don't want to persist stuff.

Because you're moving data, not operating on that data.

You're not creating data based on subsets.

You're not executing business logic and the understanding of creating data from data.

Right?

You're just moving that data from one place to another, transforming that data.

If we have that abstraction layer of an integration platform, we're transforming that data so that those domain systems do not have to learn each other.

Because that's what the abstraction does.

This one is in REST. This one is in SOAP.

Okay.

Fantastic.

You don't have to learn SOAP.

You don't have to learn REST. Because we have an integration platform.

That integration platform will solve that.

Right?

How much of an effort it is to teach a Java developer that has a backend experience to be an integration specialist?

Because that's a different mindset.

I have an even worse example.

How bad it is to teach a DBA to be an integration developer.

Not teachable.

Because if I put a DBA to do an integration platform, I'll end up with an MDM solution with small Azure serverless pipelines feeding the data into that MDM and feeding that data out.

That's not an integration platform.

That's an MDM.

So, if we're limiting the Java population from those 9 million to those people who actually did application integration and they understand what application integration is, so low data persistence and removing data, right?

How many of them they are?

I think that's a subset of what?

Less than 10%?

Educated guess?

No.

Anyways, I, you know, like, there are good MuleSoft developers.

There are good Java developers.

I, you know, obviously I would be biassed here.

I've worked with a lot of people.

I've worked with maybe thousands of Java developers, hundreds of MuleSoft developers.

But I really have a lot of respect for the Java developers.

I think they have a very strong understanding.

They have very strong technical skills.

Let's say for threading, like, I think that integration is low-lying fruit for them.

They have very strong design skills.

So, to me, the Java developers are really superior and able to handle...

Now, you're going to have bad Java developers, personally, so that's...

And you're going to have integration developers, as well.

That's normal.

So, but I, you know, in my experience, the Java developers are superior.

And now, if you get a student or someone who's a fresh graduate, I'm guessing they took Java at some point in time, maybe C.

And C is fine, too, you know.

But in order...

And I don't know what the curriculum is now, but I would expect that they would know Java, you know.

Whereas, would they know MuleSoft?

I don't think they know that as much.

So, I think that Java is a bit more of the...

And then, also, MuleSoft decided to implement this in Java.

They must have felt, and it's true, Java is...

Like, I know there's JavaScript, which I think is more of a front-end tool.

I think there's Python, which is used in DevOps and machine learning and stuff.

But I think for the middle layers of complex data and communication between applications, Java is kind of that enterprise.

And also, I think that it's a 90% of Fortune 500 companies use Java.

I feel like there's a Java team there.

It doesn't necessarily...

It may not be true, and that might be an issue.

But I had this other use case.

This is actually someone that's using our tool.

And they...

Can I talk about that?

Okay.

So, praising Java developers.

And yeah, I do respect Java developers.

They can do some really good magic.

But if I look at the average, and I'm always like...

If I'm talking about average and averaging over skill sets, averaging over approach towards problem-solving or approach towards doing anything, it's always a bias until you start learning something else, right?

And I don't know if you're familiar with this very...

Well, quite an old comedian from US, George Carlin.

I'm guessing you know the guy.

I absolutely enjoy the impeccable logic of his comedy sketches.

And George Carlin, in one of his sketches, he says something...

Well, think about how stupid is an average person, right?

You've got the mental picture of what an average person is in terms of stupidity.

Well, then realise that half of them are stupider, right?

In that sense, it's a very universal truth.

Of course, it's a bias truth, because every one of us will have a different view on the average, which already is a cognitive bias there.

But it's a bit of a universal truth.

So if we're looking at scale, and if we're looking at IPaaSes, IPaaSes are not existing in small companies.

They're not existing to an extent in medium companies.

We go from medium to extremely large corporate environments, basically.

And then we have two types of IPaaSes.

We either have broker architecture, so a singular abstraction layer, and we have API-led architecture, which is free abstraction layers, as we already discussed.

That's what MuleSoft used to be proposing before the composable architecture fiasco, right?

So, in that sense, there is a reason these are there, because it's a problem of scale.

If you would want to write code for every single one of these, it's a problem.

You end up, basically, doing the same as MuleSoft did, in the sense that you prepare predefined libraries and just feed them with proper configuration.

Because if you look at the basis of an IPaaS, like MuleSoft, right?

It's written in Java.

You're absolutely right.

So Java is a fourth generation language, let's say, right?

So if you look at low code, we can treat that as a fifth generation language, more closer to a natural language that we use to convey thought as human beings.

So there's a lot going on under each activity that you put on the canvas in Mule IDE or Boomi IDE or whatever else.

It's basically creating a configuration that is then executed by some sort of a Java library.

Perfectly fine.

If you want to improve your speed of delivery as a Java developer, you're going to library all the repeatable stuff, right?

You're going to put that in libraries.

If you can repeat that, if it is feasible to make it reusable, we make it reusable.

And in essence, that's what MuleSoft did.

So if we're looking at a scenario where we're having a client that has MuleSoft, and okay, MuleSoft licencing costs, let's not get into that.

That's a very problematic thing.

They give you that abstraction layer out of the box, that abstraction from fourth generation of a language to fifth generation of a language.

So we're already working on the abstraction of configuration that we just feed into predefined libraries that some Java developer wrote and we're good.

Of course, it's a limiting factor.

If you want to have a lot of flexibility in how you do it, or you have a requirement over very nitpicking of performance and catering to threads and you go in into nanoseconds, for example, in stock trading, right?

Stock trading, they look at nanoseconds instead of milliseconds.

In regular business, we look at milliseconds in terms of hundreds of milliseconds to seconds in terms of latency on the transfer.

Again, we're coming back to the universal answer saying it depends.

It depends on the context.

Now, if I would jump back to Dryo this time around and we look at the other costs of ownership.

So if we're looking at total costs of ownership, what else is there in terms of those costs of ownership?

And I'm going to just roll up my notes and these costs will be then most likely specific to the scenario that you said, migrating from an iPaaS towards Java.

So, okay.

Starting with, let's assume we have a MuleSoft platform, right?

Okay.

Perfect.

Now, how are we going to approach a problem?

Because as an architect, you're not looking only at the system.

You're looking at the organisation as a whole, especially if you're an enterprise architect.

So you're not looking only on changing a piece of software.

You're looking also at organisational changes that are required with adoption of architecture, which is usually the omitted problem, usually the problem at scale of many companies.

So we have Mule.

We're trying to move to Java.

Okay.

So we're going to have that, let's say that, oh, no, that's not going to work like that.

I got used to Mural and now I'm trying to pull out of the boxes where Mural just gives you that.

And I'm like, oh, this doesn't work in Draw.io. Okay.

We're moving to Java.

Okay.

First thing out of the box is, okay.

So we have the migration cost.

So this would be in the migration cost, we have redevelopment.

That's one, right?

The second cost would be obviously before redevelopment.

So as is state analysis.

And this one is, I think, a very crucial one because I don't know what your experience is with clients.

My experience is that most clients don't have proper documentation.

Would you agree to that?

Right.

So if we look at this state analysis, that means that we either need docs, right?

Again, not going to work that way.

Or we need another lovely thing called people.

So if we have people and those people that have the knowledge about what's going on in the ecosystem in terms of interoperability, these would be our Mural developers, right?

Okay.

So we have our Muralies.

Now, if we consider our Muralies, what's going to happen if you tell a team of Mural developers or teams of Mural developers, depending on the scale of the integration platform?

Because just one of the clients I've working with recently, that's 190 Mules of applications.

They have 14 concurrent teams working on that platform.

Each team has at least two Mules of developers.

So that gives you a team, a group of at least, well, around 30 developers, maybe a little bit more, right?

So we have 30 Muralies.

If you tell Muralies that you're going to be migrating to pure Java, what's going to happen, psychologically speaking?

Most likely they will start searching for a job, right?

So those people will be a huge, huge risk.

So what's going to happen next?

You're going to have to hire Java devs.

Okay.

So between these two boxes, you already see a problem.

You don't have knowledge retention.

So we have a large MuleSoft environment, let's say 100 MuleSoft applications of various purposes.

So we have a channel layer, well, in MuleSoft terms, the experience layer, process layer, and system layer that composes 100 apps.

We lose our development team because we told them we were going to migrate to Java.

They went like, what?

I'm not going to start learning Java all of a sudden, how to code in Apache camera or whatever other framework, because that's not what I trained over my life.

And I've been devoting three, four years of my life just to learn Mule in the way to make myself efficient in it.

And like doing things like this, right?

So we're losing all of those people, which means if we don't have proper documentation, we're losing all the knowledge about the integration platform.

Now, okay.

You might come in here and say, okay, we have a solution for that.

We're going to use automation to read the code of your MuleSoft applications and translate that to Java, right?

Because this is part of your offering as a consultant, as a company.

What happens then?

Because you still need people to run it.

You still need people who understand what's going on.

And you'd still need people who will fix it according to how it was running in the assist state.

You're still not covering the problem of knowing the assist state and knowing the business processes because MuleSoft as a product is just a platform.

The knowledge is not about the platform.

It's about what's running on that platform.

So all the integration flows built with Mule applications and this local code solution.

So even if you hire those Java developers, they will not have sufficient knowledge about the assist state.

Yes.

Yeah.

Let me tell you how, and that's, you're talking about 40 Muleys, like 500 APIs.

So that's a big, that's a big shop.

I mean, we can do a smaller one.

It might be easier to calculate, but let me just go with the 40 because that's, but yeah.

So on the project, on these teams, you have, you have the, the business analysts, you have the architect, you have, you know, you have all the, all the surrounding people and, and they can take, they have a lot of the business knowledge to be honest.

The business knowledge is also technically it should be in the RAML.

It should be in the OAS.

That is the logic.

And you have the business requirements person.

It's been implemented in MuleSoft now, and those are Muleys and they know how that technology works.

Now that knowledge that they have in MuleSoft, well, it's true that we don't really need, like if they are just straight developers.

Now, if there are architect or like there's opportunities, like, or they know the business more, I could see them wanting to stay, but there's a few things we can do with those 40 people.

And that is, yeah, they could, I'm assuming their, their computer, they went to school and have a computer degree.

They would know some Java, but you could send them to retrain them.

And that's are they interested?

Do they want to do that?

Maybe.

And then that's up to them, but you will, there will be definitely people will leave.

And I'm sorry about that.

But then, like I said, I've been in this business for 40 years.

If that technology changes, they will leave at some point in time, technology will change.

You need to update, but they have integration knowledge skills.

There's, there's stuff that is transferable and it's worth having them.

So some of them will leave and that'll cost.

And then, so then you might have to hire some, you may have Java developers already, you know, so that, that depends, or you have to hire Java developers.

That's the, so there, there is the cost of that.

But, but let's say if you had, if you have like, you know, 500 APIs or something, that's like, that's a lot of money.

Like I, and I, you know, and I'll leave it for people to figure that number out.

But to me, that might be, that's many millions of dollars.

That's like, maybe I'll just say $5 million a year in licencing costs.

Right.

So that's just about, you know, that might be more.

So to me, in my mind, what I'm seeing is that let's say it costs $5 million in licencing costs.

Now you're still going to have to pay a million, right?

Cause I still think it's 20, 20% less for Java.

You're still going to have to pay a million dollars and work to AWS, Azure, whatever your cloud is.

You still have to pay a million.

So, but you also, you do save like $4 million, but I find, and I find that the, the migration costs might be $4 million.

So it's going to take you maybe one, one year to two years to, to do, to, to recover your costs.

But then in the future, of course, like that's a great investment because obviously now you're saving $4 million a year.

You can maybe hire more people, but, but the other thing is that these are the built, but then yeah, of course it's, it's an organisation and continue to grow, continuing to build APIs.

You can build your APIs and whatever you're going to need a few people to support these existing APIs.

So that's how it kind of works.

I mean, it's not, it's not free.

It's not, it's not nothing.

And I do feel bad, but I feel bad, but then it's, it's just kind of just capitalism, unfortunately.

It sucks.

And I feel bad and I've, I've, you know, for 40 years, I think I've, I've, you know, kind of led to a lot of people losing their jobs and that, you know, that's the end point.

Okay.

Let's dig into the TCR again, right?

So, okay.

We have Java developers, but those Java developers most likely are doing backend, right?

So in that sense, we need to retrain them.

Yeah.

Yes.

People will be trained.

People will be trained and they need to learn this.

Yeah.

Okay.

Yes.

So we'll, we'll need to do that.

If we hire from the market, we'll still need to retrain those people because they're probably unless you get like a specialist that are actually Java developers specialising in application integration, which is again, we'd be looking at let's say these Apache Camel, or some other framework.

Perfect.

Yeah.

And actually, you know, once I was, once I had that situation, I was like, hi, I was asked to work as a team lead and learn Java Camel to write APIs.

And of course I would add to that sometimes.

I don't think it's, it's such a, you know, whenever you're going somewhere, whenever you're moving somewhere, you're learning new stuff.

You're, you know, it's, it's, it's not the, there's a cost, but it's the cost you're going to learn.

You need to learn the business you lean to learn.

That's, that's always going to be the cost, right?

So this is, this is the, this aspect.

Now, if we look at the availability of application integration specialists within the Java community, that's probably going to be a lot lower availability than Java developers in general.

Would you concur to that?

I agree.

Well, I think you can hire a Java developer and I feel like knowing Java development and knowing, you know, integration stuff like, and knowing Camel.

I don't think there's a, there's a big jump there and maybe I'll take a course.

I'll grab the book.

Okay.

But, but if we're looking at retraining, right?

You're going to be looking at organised, organised training, right?

Now, if we compare organised training as an actual availability of materials from iPaaS vendors versus pure Java.

So all the vendors have actually a lot better training materials.

They have courses.

They, some of them are even for free.

You can just learn and get certified without any cost for that, right?

While if you're looking at the open source communities or Java community, it's scattered.

It's not centralised.

It's not organised.

From my perspective, whenever I tried to learn anything from pure Java, it's always a nightmare to find answers, to find a proper course that covers everything sufficiently and not assumes that people would know.

So even if you're making people from whatever background, right?

And you assume they know Java and you try to teach them, if you don't know yourself and you try to make them learn Apache Camel and okay, you know Apache Camel, they don't.

Perfect.

You can teach them.

If you don't know Apache Camel well enough and you are put as an architect or as a team leader in a position where, okay, there was a decision made by the architecture team.

We're downgrading from MuleSoft and going into Apache Camel.

That's a problem, right?

Because you're not able to teach them.

You have to learn yourself.

There is not a sufficient availability of good materials to train yourself from the web.

What then?

And this is...

I think, and we can agree to disagree, but I feel like in this global economy, you're going to find a trainer that has Apache Camel and also the streaming functional programming, threading, various things like that.

I think if you don't have those skills, you need the team lead that has the skills at least, in the least, you know?

But yeah, I think that can be learned, but once again, maybe it's harder than I think, but then also I know with the MuleSoft, it's true that MuleSoft will give you some free training.

They'll send people over that they want you to learn.

But you have to pay for that too.

Yeah.

That's part of their business model that they will give you some things for free and then you pay for the trainings within or outside of the licence.

Yeah.

And that's perfectly fine.

But then if you look at the feasibility of things, of course, if we look at this exercise from the perspective of pure on paper exercise, yeah, you can do all of those things.

But going back to the core business, we're not in a context of doing IT for the art of doing IT.

We're in a context of helping a specific business run their business.

So business is not waiting because the business is constantly changing and moving on.

So they require the integration platform to be operational.

Any technical migration is, from the business perspective, is a cost and an unwanted delay, right?

So if we're moving from an iPaaS, which is well established and has proper training materials and has a certification path and has trainers, all of that packaged, composed, let's not delve into the quality of materials from different vendors because that differs, of course.

But it's somewhat established and they actually cater to that.

And you compare that to just the randomness of training materials available on the web.

And you rely on having the right people to ask the right questions.

And okay, you as a consultant would go there and tell them, you need this, this, and this, right?

Fair.

You know your stuff.

You'll tell them what skills they need to look for, what people they need to bring in.

You'll help them interview, for example.

If a company goes, okay, we're going to drop Mule software or drop Boomi and go into building this in pure Java, how much of a chance you would say that the hiring process will work correctly and they will know who to hire if they don't know exactly what they're doing in terms of a framework and just a team leader was pushed into the position, you've got to learn Apache Camo now.

They will know, okay, we need to hire somebody for Apache Camo.

All right.

That's our criteria.

How many people have Apache Camo written in their LinkedIn profile?

That's a very small subset.

As a team lead, let's say if I was a team lead and I'm hiring people, yeah, I wouldn't necessarily need to look for that.

I want them to be able to thread, maybe be familiar with functional programming, and then the Apache Camo is a library.

I don't think that that's a huge jump.

It's pretty straightforward in my opinion.

I wouldn't be worried about it.

I don't think it sounds...

I don't need to have, you know, like I said, I'm sure you can get any good Java developer.

It's all a matter of getting good Java developers.

Right.

But you see, you're still looking at it from a perspective of your own expertise.

So you're still looking at it from a perspective of your own cognitive bias that you know this stuff and you will be able to teach them this stuff.

So you'll be looking for people who have a specific skill set because the rest, you'll teach them on the job.

But there's only one of you and so many businesses.

Well, there's 7 million Java developers, but there's good Java developers I would expect.

I'm not going to be, I'm not doing it.

I'm going to certainly delegate that to a Java developer, but I would be confident that I can find people like that just as much as, like, let's say, like I said, I've been in both positions as a team lead of Java developers, as a team lead of MuleSoft developers.

To me, they're both the same.

I might yeah, have like a more for the Java developer might be better, but still it's like, I'll put it as equal.

I mean, you're still like, as you're growing, you're hiring Muleys, you have to train them, you know, they have to, it's, it's, but then the other thing is that now we're saving $4 million a year, like just money.

Yeah.

But then if you look at it from perspective of other costs, how much will it cost you to retrain?

How much will it cost you to hire,

run those hiring processes with the assumption that for most cases, if I look at the hiring

processes and job postings, and I do look at job postings quite a bit, just even for the

fun of it, or just get pulled into those discussions by various recruiters approaching

me on LinkedIn, those job postings for most of the times, they're absolutely ridiculously badly

written.

So the chances of getting the right talent for the right job, when you're writing a job posting that actually describes half of your IT department, right?

It's, it's, it's a lottery.

There are so many factors into it.

And it all kind of dumps down to what is your IT maturity?

So if your IT maturity is high, you could probably pull it off.

If your IT maturity is low, I would argue it's not feasible.

I wouldn't say it's not feasible.

But I, yeah, I was, actually, I spent a year, I did 50 interviews of MuleSoft developers, or MuleSoft developer or MuleSoft architects.

I've done a lot of interviews, and there are people out there, it's a process, it's, you can, like I said, you delegate that to, or, you know, people do it, they'll hire the people, and then they're gonna, and then there's going to be some training involved.

But that to me is, there's a cost to that, of course, but I don't think it's, it's not a, an impossible thing.

Like, and ultimately, like, when you did this MuleSoft project, you had to hire people, like, and you had to train people.

And, and, you know, in any project, like, let's say, I'm often, I also come in as a solution architect, sometimes, oh, you got this project, and you're gonna have to hire these people, or we can get them, you can get them from consulting companies.

And then, and then let's go, this is going to cost you this much.

But we don't go too much to, okay, we're gonna hire, will we be able to hire people to do this job?

It's, it's almost a given that it's part of the cost of doing a project, that you're hiring people, and they're gonna do it, you know, you're gonna get.

Yeah, but, but then you have the additional cost, which is the cost of getting those people through consulting companies, or through body lacing companies, whatever that may be, right?

So this is, these are proxy companies, so they profit from giving you those specialists.

So the margin on a specialist at times can be even 50-60% for those companies.

I've seen that happen so many times.

So it's, you know, it's saving maybe those $4 million in the short term, but how does that later go on into the costs occur over the transition, because you have to replace people, you have to get those people from somewhere, the fastest way will be, yes, consulting company, body lacing company, hello, cha-ching, different cost.

Now, if you look further, okay, we're migrating to Java functionally, okay, we run all the applications in Springboard.

Perfect.

We have the functional coverage.

What about the non-functional coverage?

So by non-functional coverage, we have the security of API gateway.

The decision is, are you going to re-implement an API gateway from scratch or not, right?

Time to market is a matter, because if you're going to re-implement that from scratch, that means that, okay, you're going to be in either a configuration nightmare where you'll have to maintain and configure all those proxies that provide you that security, or you're just going to take a lot of time, which is again, impacting time to market and the feasibility from a business perspective.

So API gateway, you will probably get an API gateway from Azure, AWS, Google Cloud, or get one from any other vendor, whereas in your iPaaS, you already have that API gateway.

Yeah, yeah, you totally, you will get one and it will, one, it's nice that because we have all these security requirements, so you know exactly what you need, do you need, you know, what level of security you need for each API.

And the nice thing is that you can, you already have the API, it's nice to transfer over because you can just, you build that API and then you can test it and you can have both of them running in parallel.

One of them works, boom, you put it in.

You can do one by one, which was the most expensive or which one is the easiest.

So it's a very easy migration and you can just do as many as much as you need to do as time goes on until you're finally done with them.

But like I said, it might cost you, yeah, it might cost you a million dollars to do something like this.

And, or I mean, or four million, I guess, depending on the size of the project, it'll cost you money.

And, and then, but ultimately you'll be saying, like I said, I think you can recover the money in almost a year, a year and a half, you know, so, but there is cost, there's work involved.

It's not, it's not free, but all these things need to be done.

All of them can be done and all of them will be less expensive than what you're currently paying because you're paying an overhead for it, given to you, repackaged to you in their own, but the functionality is basically the same.

You may have not more, more ability.

Okay.

Yeah.

I would only argue that there's one very key difference in doing this by yourself.

Now you need to tend to all of these.

Now you need to offer this also operationally, where if you have this as a SaaS solution, half of the operations is outsourced within the licence fee, right?

So now you're also incurring operational costs, right?

So this is all going into OPEX basically, right?

Now, all of these are OPEX costs that you will have to cover with, with your Java solution.

Mm-hmm.

Yeah.

This is where I say, this is where I say it's like, so you were paying 5 million, but now you're paying a million.

So it's the million dollars.

Yeah.

That's the cost that it's not free, but you still have to, you know, you'll be paying a million, but now you're paying it and you're, you're having some economies of scale, you're having control.

All of your Java stuff is being done together now.

So, so I think there's a scale, scalability that you're doing it all together with your own, your own team.

And also there's kind of a security to it because now you, you know, what's going on, what you're doing and where, you know, I think you were talking earlier about EU concerns about, about things running in the US and, and now you have, now you can run it yourself in your own and have your own security.

So, so this is another benefit of, of, of having it yourself.

Yes, of course.

If we consider this from a data sovereignty perspective.

So if you're looking at US Cloud Act you probably know about the US Cloud Act a lot more than I do in that sense.

But basically what US Cloud Act says is that if the US government tells Microsoft to give any company data to them, Microsoft must comply over the US laws first and then look at any GDPR data privacy international laws, right?

So in terms of data sovereignty, yes, this is a huge problem, but this is also a problem of not only the iPaaS technologies, but it's a problem of most cloud technologies.

And now, okay, we see those, those problems being resolved.

For example, AWS is building a data centre.

Well, they already have it built actually.

I think in Germany that is under a completely independent entity, legal entity that is EU based.

And of course, if we move all of that to that particular entity, yeah, okay.

We're at a place where our data sovereignty is better because then that data centre is in Germany.

Germany has to adhere to EU laws.

So it's a bit of a different situation than US dictating laws where US is represented as a sole entity on the international arena, right?

Whereas EU countries are not represented as a sole entity on the international arena.

They're usually represented as European Union.

And that's fine.

That's a good reason to migrate to a technology that is not US based.

Perfectly fine.

Especially if you're trying to run this at in that technology cloud.

I do agree on that.

That's a valid reason.

Would that be a reason to go to pure Java?

Given that in EU we have very few iPaaS, so one of this is SAP having their integration platform.

Would I argue that you want to go to SAP, their stack to do application integration?

Wouldn't be my first choice probably, right?

You have what?

You have Friends, which is a kind of BPMN, kind of a iPaaS, like very close by to Camunda.

Yeah, okay.

Might be okay.

You have open source projects like We Are Frank.

Well, sorry, Frank Framework.

We Are Frank is the company that created Frank Framework.

Yes, that's open source.

It's very close to low code, a lot closer than Apache Camel and better at it than Apache Camel in that sense of the ease to get into it.

Otherwise, a few minor players that are integration platforms that specialise, for example, in healthcare.

There are a few like that.

But that's not an offering that's comparable to the US-based offering, and that's the biggest challenge in terms of these kind of things.

I absolutely agree on the data sovereignty part of these kind of things.

That's a good reason.

Yeah, and also, like in the case of MuleSoft, you're kind of locked into MuleSoft.

They have a monopoly.

You're kind of stuck with them, whereas with your Java, you have a little bit more flexibility.

You can be on a different cloud.

That's why I thought, like my original thought was, oh, clouds are going to really charge us a lot of money at some point.

But because they have different ones, there's Google, there's Azure, and you kind of have to, but we do get locked into each of these classes.

It's hard to move from one to the other as much as you'd like to.

But you do have a, the cost is not quite as bad as it has been for these iPasses that kind of lock you in a little bit more.

So it gives you, I think, a little bit more flexibility and also security control data, and you're just open source.

Yeah, and that's fair.

If this is a driving requirement, if there's a driving factor there, and if you need that kind of a, that rigidity of control.

Most companies, I would argue they don't need that level of control because their business is not strictly IT.

They just have IT to facilitate for their business.

And in those cases, it's probably not feasible and not a good idea to migrate away.

Of course, you're absolutely right on the vendor lock-in.

Yes, if you have pure Java or JavaScript or whatever other programming language, and you just deploy it on a cloud, yes, you can just go to a different cloud and deploy there.

It's just a matter of changing the DevOps pipelines, right?

So that's less of a lock-in, but then again, it depends on what kind of other products next to it you're actually using.

Because if you're looking again at the part that is the non-functional coverage, right?

You need an API gateway.

Okay.

You're having an API gateway that's Azure native.

Now you have to move all of that and migrate that to whatever is in the AWS or Google.

That's already a problem.

You have a control plane.

Okay.

If your control plane is self-built, because you could do that, then it's less of a problem.

Monitoring?

Depends what product you're actually using for monitoring.

If you're using cloud native from that particular vendor, you're already in a lock-in and you'll have to migrate your whole monitoring.

Now, if you have a legal requirement to keep logs for a certain amount of years, that might be already a problem, right?

So there's nuances to that that I would say they need to be explored.

It's just not only about the functional coverage when migrating an iPaaS.

There's actually a lot more to it, many more factors.

And from your perspective being in Canada, some of the factors might be of a different view than from my perspective being in the Netherlands, because we have completely different markets.

We have completely different specialist availability.

Also, business mentality is a bit different, right?

And that all factors into the architectural decisions over which technology do we use and how we implement sovereignties, how we implement the...

How we have...

What kind of drivers we have to start off?

But in my mind, all those decisions and ideas, like all that architecture design, it's already done for all those APIs and just migrating it.

So it's not even a matter of thinking about it.

It's just implementing it.

Like now we're going to...

Okay, we have the documentation.

We should have all that stuff.

Now we're just going to do it.

This is the retention period.

This is this and that.

All of it is...

And you need those architects.

They're still there.

We need those guys just as much as we did before.

I absolutely agree.

If you have a properly established integration platform in an API-led architecture, the architecture part is done.

It's copy-paste.

The problem is the solutioning.

That's the challenging problem, right?

So basically...

Because...

And then again, this is a very important note here because people often do not differentiate architecture from solutioning.

If we put it in these terms, architecture is the blueprint.

Solutioning is the instantiation of that blueprint with a technology or a framework or a language, right?

So you're absolutely right.

Architecture is already there.

It's a matter of doing a copy-paste of that architecture.

The problem is with solutioning towards that architecture and how we want to change that.

And this is not only about the MuleSoft apps, right?

Or the Boomi flows or whatever else.

There's the surroundings to that.

The whole ecosystem of different functions that are required to be covered.

Yeah.

And let's say...

And we haven't talked about it as much, but you've got the environments or you've got the testing.

You've got your QA.

And you can just...

Once again, your QA can just come right in.

If they're using Postman, let's say, to be testing and running those tests and they have automated tests, everything is a Jmeter, let's say.

All of that's the same.

So you can just carry that over.

That's not going to change in any way.

Okay.

Fair point.

What does not change?

Let's put this kind of a title.

So if we just...

One more box.

So we already established.

Architecture is not changing.

That's a given, right?

Solutioning, that's changing.

That's the problematic part.

It's like you're...

I don't know if you put that under architecture, but your security design, that's all should be the same, but the implementation of it is different.

Yes.

You're right.

Security design.

You're absolutely right.

That doesn't change.

But what does change is the security implementation.

You're absolutely spot on here.

So that does change, right?

That's the problematic part because we need to redo that to an extent.

Okay.

What else we would say does not change there from that kind of static perspective?

So the environments, like CI, CD, like all of that DevOps, and that depends on how you've implemented your iPaaS.

Are you doing it yourself?

Or because they have...

Which environments you have and the passwords and the setup and it's just the space.

But you could have, like I said, and I actually am forgetting the terminology now, but you can either use Cloud Hub or you can do it through Kubernetes and you have your own space.

Yes.

So if you already have it set up, that's not going to change, but if you're using Cloud Hub...

I think if we look at this from a perspective of the logical steps that happen in the DevOps pipeline, I think those steps will not change much or at all, but the implementation of those steps will certainly change between those different solutions.

Because for Cloud Hub, you would probably use a CLI of Cloud Hub to do some actions from a DevOps perspective.

That's perfectly fine.

You use all sorts of secret vaults, configuration management on all that.

Depending how you solution to your secrets and configuration management, that could be entirely transferable because these are certain functionalities that do not come out of the box with an iPaaS, so you probably solution for that either way yourself.

And that's fine because, great, that's a win.

But then again, you have to redevelop your DevOps pipelines because you're now working with a different stack, so you have to redevelop your build and deploy.

If you're moving from Cloud Hub to Kubernetes, well, these are two different deploy modes completely.

So this is a change in the implementation.

So this is, again, another cost incurred with that kind of a migration that you have to redo that per your DevOps team.

Would that constitute a rehire or retraining of said DevOps team?

Probably not.

Yeah, you just hire.

But as an example, we work with the DevOps of the new team saying, here's the new code just implemented.

Put it into an environment and give it an URL.

Sure, it's the same.

But yeah, usually you might have to build out, but then...

Yeah.

And then infrastructure, I would put infrastructure specifically here in yellow, not red.

Because if you've been running your iPaaS in a hybrid mode, then you already have kind of that infrastructure provision, especially if you run it as containerised, then that should be fine.

But if you run it completely in the cloud, like if you run Boomi completely in the cloud, you don't have that infrastructure.

If you run MuleSoft in Cloud Hub, you don't have that infrastructure.

You'll need to build that infrastructure.

You need to build all those let's say infra-DevOps around that infrastructure.

So all the Terraform scripts, everything around that to get that going, to provision new pods on your containerisation platform.

That's a lot of work.

So that's another cost that may be or may be not an interesting cost to look at.

Although I'm guessing that the organisations already have some DevOps people involved in those MuleSoft implementations.

So they're just going to need to run these other scripts.

So it might not be an expert, but it's a...

Yeah.

But then it's a matter of having...

Do you have your DevOps team or infra-Ops team?

Because not all DevOps specialists will do infrastructure.

So if you had Cloud Hub or just iPaaS in the cloud, fully in cloud, those DevOps will be focussing on build and deploy or build test deploy, depending on what's your policy on automating things, because you can do regression tests in a DevOps pipeline as well.

And this is another step of maturity.

So basically then this will incur, from that perspective, additional costs on the organisation to either train or hire your infra-Ops.

Unless of course that organisation was mature enough and they already had these kinds of infra-Ops for other topics, then you just repurpose.

But that might be a stretch in scaling that team in terms of scope of responsibility.

So that would probably mean hire.

Yeah, possibly.

Okay.

Anything else we're missing in terms of what does not change, what does change, these kinds of perspectives?

What does not change is also your business analyst.

Your knowledge of your business.

Yes, that does not change.

The SMEs.

Yes, knowledge of your business.

But what does change is the knowledge of how that's implemented, because there's a difference between looking at the business process and knowing how it actually runs.

If we're looking at a client that doesn't have sufficient IT maturity or doesn't use domain-driven design to create ubiquitous language, well, most likely the business has no idea how it's actually run underneath in terms of technology and the actual implemented processes.

They just see the UI and that's the extent of their knowledge.

What's happening beneath, there's going to be very few people that actually have any knowledge about that outside of IT.

So we're assuming by that, this knowledge would be there, but that's usually not the case.

And that's also the problematic aspect and another cost inherent in that sense.

Yeah, that might be your network diagram.

I'm not sure if it would change or not, but it's okay.

Network, yeah, that would have to change.

No, that would have to change because, well, your domain systems are, well, they're set in the network.

They don't move around from that perspective of the migration.

But if you move your iPaaS somewhere else, entirely different, well, that's going to be a problem.

That's redoing the network.

So I think in that sense, network is something that will change.

So I'm just going to put it here.

But luckily, I'll give it more of an orange thing than red because network is the, let's say somewhat the easier part because we already know that those systems are there, they're behind this and this firewall and this subnet, whatever that is.

Again, not the network engineer.

I might actually now speak bull crap, but we know where they are in the network, right?

So from the infrastructure perspective, that's actually easier because we're just moving one part.

And then we just need to burn the holes in firewalls in different places for that one part, right?

So that's the, let's say, slightly easier part from that perspective.

All right.

I see that Stefan has been commenting like crazy in the chat.

Network is constant.

Well, that's a fallacy of distributed computing.

Network is not a constant.

But yeah, Stefan, thanks for the comments.

Yes.

Some of them are, yeah.

I don't know what, which point, to which point you're commenting at times because we have a bit of a delay from the studio to the actual feed.

So that's problematic to just weave your comments into the stream.

But yes, network is a constant.

That's a constant problem of the fallacies of distributed computing.

There's always the latency, right?

Yeah.

Our network is lagging.

That's the usual problem.

All right.

You know what?

I think this, we can start wrapping up this discussion here.

I think we covered quite a large extent of total cost of ownership of an iPaaS.

And if somebody has been listening, I think people would pick up on when to or when not to migrate from an iPaaS towards pure Java or pure code.

And I think everybody would get the idea that this is not a binary decision and you cannot do it just based on the opex cost of licences.

You need to calculate that for yourself.

Yeah.

Well, absolutely.

Like I said, I mean, I'm ballparking where I'll say, you know, and I think you were talking, that was a big example, that $5 million a year in licencing cost.

I think a bigger example like is, you know, maybe someone has 25 APIs, they're spending a million or 2 million, and then it's going to save them, you know, a million a year, but it'll cost them a million to convert it.

And it might take six months to a year to do it, but you can gradually do a little bit at a time.

But ultimately, I feel that will give you more flexibility in the future.

And then we'll save you costs in the future.

A hundred people are to do it.

I think this is a perspective of scale, personally.

If you went into MuleSoft when having five to 10 domain systems that beat to interact with one another, I think somebody gave you really bad advice, right?

Because that's a humongous cost that your business didn't need at that point in time.

So that means somebody architected an overkill for your business.

If you're at the stage where you're growing and you have over 30 business systems and they have a lot of interactions between one another, well, probably it's a bit insane decision to go into an API led architecture and implement that.

If you already have MuleSoft, that may be debatable to migrate.

But if you're just going from broker architecture or from spaghetti architecture, it may be quite feasible to go into Java and just do it in Spring Boot.

Yeah, if you have Java developers.

I want to bring up a particular use case, which is, I don't know how common this is.

So it was a smaller organisation, which outsource a lot, most of their IT, but they said, okay, we're going to go with Salesforce.

So Salesforce came in and said, oh, great, we're going to bring in Salesforce.

And that looked great.

That was good for them.

And then all of a sudden, Salesforce, I guess they wanted to connect.

And I guess that's what Salesforce will do.

We need to connect into all your systems.

How are we going to do that?

And in this case, they brought in MuleSoft, and then they just put in MuleSoft.

And all of a sudden, they're like, oh, there's like this bill that we're getting every month for half a million dollars that is MuleSoft.

Like, why are we paying for that?

And we've got Java developers here.

And then the Java developers are like, oh, we can't fix or change this.

So they said, I just want to get rid of MuleSoft.

So Brian, get rid of MuleSoft.

And just give us Java, and our Java developers will be able to do it.

We'll have to pay it.

But just MuleSoft, our Salesforce wanted us to connect in.

How are we going to connect in?

It doesn't have to be MuleSoft.

You can do it.

You can do it in Java.

You can .NET, whatever your own thing is.

But this is a way to kind of free you from those costs.

And this is one of the possibilities.

In that kind of scenario, I would argue that there was a lack of properly trained architect in that business to actually cover that and make a decision.

And somebody in the business just went, oh, they're giving us MuleSoft with Salesforce.

Oh, yippee, let's do it.

It's free for six months or free for one year.

And then the next year, it's like, we got you.

But that's a business practise that has nothing to do with architecture in that sense.

A lot of stuff is political.

A lot of stuff is financial.

Precisely.

So from the novelty perspective of psychology, oh, that's a lucrative deal for the business.

We get a licence for free for a year.

And then you have to pay.

And did that make any sense from a perspective of architecture and their ecosystem?

Possibly didn't.

That's just the case.

And yeah, in that kind of case, it's a very nice use case to actually migrate away.

Because that was cost that was incurred not through proper architecture, but through decisions of a business that were not based on a proper set of information and understanding of what they're doing.

And that happens all the time.

And this is where salespeople get a little bit tricky with these kind of things like, oh, we're going to give you something for free, or we're going to give you a discount, or we're going to give you that.

Yeah.

This is all to convince the business.

If the business is not listening to their architects, well, that's what you get.

And then we get a big ball of mud or spaghetti architecture, or companies with three or four integration platforms inside that company, not coming from a perspective of acquisition, but just living on their own because of the pure scale of problems and that the business forget, oh, we can actually solve it by getting a new technology.

You will not solve organisational issues with a new technology.

It is what it is.

All right, Brian, parting words.

It was great talking to you.

And it's good to go over all this stuff in detail and very thorough.

It was a fun conversation.

And I enjoyed talking to you.

That was actually a very fun sparring session.

I enjoyed it as well.

That was really cool.

All right.

Before we jump off the stream, I'll just do some small announcements.

So, next week, we're doing something completely different.

We're going to be talking about collaborative modelling and API definitions in the age of AI.

And on the stream, the speaker will be Dr. Annegret Juncker, chief software architect at CodeCentric AG.

That's going to be quite an interesting conversation to be had because, yeah, well, AI is now everywhere.

And it's insane how people use AI with the vibe coding and all that.

So, we're going to look at it, how we can use it a little bit saner, so to speak.

So, that's going to be the fun part.

And now, if you're here, new, you haven't seen the stream, you don't know what bridging the gap is, well, here are some QR codes.

Jump into bridgingthegap.eu.com.

This is our website where we write about integration architecture, integration patterns, and whatnot.

You can subscribe to our sub stack, although it's a little bit dead at the moment.

We're going to get back to that soon when we have more time on our hands.

And then subscribe to our YouTube channel to get to be notified about all the lovely live streams we're doing.

And we're doing about three live streams a month on various topics related to interoperability, IT, but also psychology, cognitive loads, psychological health in IT, and the impact that this may have on adoption of architecture.

So, that's it.

Thank you all for joining.

Thank you for listening.

Thank you for the comments.

And have a lovely day, night, evening, wherever you are, from wherever you're listening, from whatever the time