Matt: 00:00

And I make that example often with plumbing, right? Because in the end, no one really looks at plumbing until... There's a water leak.

So you just assume that it's there. But the moment it starts dripping through the ceiling, everybody says, OK, well, we need to have a look and potentially fix our plumbing altogether. It's very similar with the data itself. No one goes into anyone's house or organization and says, well, we love your data pipelines. At the same time, nobody goes into a building and comments on the beautiful pipework.

Mark: 00:31

Welcome to the CTO Compass podcast. I'm your host, Mark Wormgoor, tech strategist and executive coach. In every episode, we meet tech leaders from startup CTOs to enterprise CIOs to explore what it means to lead in tech today. They share their stories and their lessons so that you can navigate your own journey in tech. Let's dive into today's episode. Most AI projects don't fail because the technology isn't smart enough. They fail because the company's data often, and we're going to talk about this a lot, is a disconnected mess. You're bored, they just demand AI, right? And engineering, they just put all these systems together just enough to make the demos work, the AI stuff work.

And then six months later, you still have all that spaghetti. You have compliance nightmare and nobody can actually trace where the data is coming from, what's happening along the way and how you deal with that. Matt Soltau, who's on the podcast today, spent nearly a decade fixing exactly this problem.

So turning these fragile duct tape spaghetti tech stacks into secure, traceable workflows that actually survive in production for years, not months. He's the global director of strategy and operations at IntelliPaaS, and he works with organizations across finance, government, healthcare, and SaaS to make sure that their data is trustworthy before they switch to AI.

So Matt, welcome on the show. And I would like to start with like a hard reality check. We have a lot of CIOs, CTOs, and then you look at their architecture today, What's like the most... Dangerous assumption from your perspective that they can make about their data being ready for AI?

Matt: 02:06

That's a great one. Hi, Mark. Great to be on the pod. Thanks so much.

Well, AI readiness is obviously a very interesting topic and it always just comes down to Is your data actually clean enough in order to be consumed in the right environment? You mentioned this before. There's a lot of, in the intro here, there are a lot of different AI projects that companies are working on a regular basis. And they often don't really come outside of their sandbox environment.

So what we really see here is that in the sandbox environment, it always works perfectly well because the scope is fairly defined. The outcomes for the most part are defined. The data going into it in order to deliver all of that is defined. The moment you're taking that Ferrari engine that you've kind of built outside of it, dropping it into the real world, then things often go pear-shaped. And the reality often is the clean data that sits in this confined environment in the sandbox environment obviously is perfect, right? But it's just nowhere near the reality of what's happening in the wider organizations. And as a result of it, 95% of AI pilots deliver zero P&L impact really because data readiness is not there.

So it's no fault of the models and so on. It's just the underlying infrastructure.

Mark: 03:39

Isn't ready. So if we're starting, we're at that early phase, what are the early warning signs that maybe our data foundation isn't ready for AI? It's not where we think it is, or maybe our board, our leadership thinks that it.

Matt: 03:52

Is. Well, how much exposure does your board really have to the details of it, right?

So for the most part, the board is pretty shielded with it. Obviously, plenty of agendas live on the board saying we need to get more AI ready. We want to make sure that additional AI initiatives are being pushed forward. But it, On a more rudimentary level, the AI projects obviously need to have their own data pipeline in existence, and to be honest, for the most part, they are being built from scratch all too often. You've got various different source and target systems that technically should be connected because we've Way before AI came up, there was a concept called digital transformation that people seem to be moving aside because obviously now AI can do everything, but the fundamentals, for the most part, aren't properly in place. And I think this is really where boards that read the news, potentially worry about falling behind if they don't adopt AI quick enough, in a safe manner, they often, at least in our experience, are disappointed that what works in a demo tech environment cannot really be translated outside of it. I'll give you an example.

So we've been working with an insurance company in Singapore. They've been focusing on trying to automate their customer success, well, actually customer service team, inbound calls, questions about all sorts of insurance policies.

So... Live transcript in the background, there were all sorts of basically prompts on how to answer the customer's questions.

So somebody calls about a travel program, another one calls about dental insurance, another one calls about something else. So the Call agents, actual people, not... AI agents We're basically trained to just listen to the conversation and trust what's on the screen.

Sounds pretty good on paper, right? Because you've got immediate training potential, everybody can go to become an expert out of the gate. In reality, it fell over simply because updates were happening to some policies, etc. They weren't adequately fed in. And as a result of it, the entire project was put on ice, which now is funny because that's exactly what I believe it was Gartner predicted. They said that 80% of projects, AI projects, would be scrapped actually by the end of this year. And that came out sometime mid last year or so. Simply because of non-readiness of data.

So the data is there at day zero, but it doesn't constantly evolve with it. And as a result of it, the AI can't.

Mark: 06:49

Evolve. Wow, 80%. That's... It's a very saddening number. I hadn't read it, but I do believe that that's going to be true, very likely.

So let's talk about the data foundation. What do you think needs to be in place to make that happen?

Solid to make it properly like the insurance company what do we need to do to make it the way to make it ready for AI?

Matt: 07:09

First of all, look at your data pipelines. Do you actually know where your data comes from? Is that readily accessible? Does it work comfortably together? How many data silos do you currently have in your organization? You don't actually need to look very far to find out that sales, marketing, operations commonly don't talk to another, let alone finance on top of it. And now if you've got multiple different, yeah, companies as part of a larger conglomerate Plus international entities on top of this as well.

I mean, Mark, you know all about it. You've got companies not really knowing what's happening across the group in real time.

That's why there's quarterly reviews and not weekly reviews, simply because there's no data readily available for it. And... Ultimately it's a debt that's really coming to Live now. In the era of AI because you want to have access to that information. You could technically get a lot of benefit from it, but you just need to make sure that your data pipelines, as I said earlier, are completely clean really to ensure that the end-to-end connectivity is 100% warranted.

Mark: 08:31

And that's why I love that insurance example, because I would think that the project is going to fail because of maybe the customer data quality, but the example you gave, it's not the customer data itself, it's having the right policy or insurance policy that applies to that customer quality. Make sure you have the right version of that. And that's like, it's not... It's not just one set of data. It's just something that's related to it, but not - Exactly, customer data. It was.

Matt: 08:58

Actually incorrect advice. Yeah, it was actually incorrect advice that was given. And that's obviously dangerous in such a setting.

So therefore it was put on, yeah. On ice for the time being to then, well, be rolled out now that we're involved. But yeah, that's one of these examples, right? It needs to constantly evolve. It needs to be compliant, of course, as well, which is a major topic when it comes to it. Not just in Europe, but all across the world. And in special jurisdictions on top of that as well. But yeah, this entire orchestration needs to be carefully managed.

Mark: 09:37

- Yeah, and I love this. You're working in data integration.

I mean, yeah, I've seen it in some large organizations. But it's complex because as technologists, we just love putting in place pragmatic solutions, point-to-point connections, point-to-point interfaces, and that's good enough. Why is that not good enough over time, just application to application interfaces?

Matt: 09:59

Well, Mark, the average organization has over 80, and we're talking more on the enterprise side now, has over 80 different organizations. So tools for whatever reasons.

So you've got the best of breed and that's the next trend, best of breed. You've got various different tools already in the tech stack. And on top of that, you've got best of breed coming on top of this. Now, AI... Adds further pressure to that.

So now if you've got the average organization with 80 different systems. If you really wanted to connect them all with another, that would be over 6,000 unique connections that you need to make in order to ensure that everything actually works together. And to be honest, I mean... That doesn't take much knowledge here to know this is unmanageable. First of all, it's extremely difficult to deploy. It's difficult to maintain. Now, every single time when a new application joins that, let's pick AI for example, the latest, greatest, shiny thing makes sense, needs to be added. If that now needs to connect to just 10 or 20 different endpoints, that 20 different unique connections that need to be built. And that still means that all the other systems that might benefit from that particular connection as well are ultimately locked out.

So that's then where integration platforms, for example, come in that end up managing the entire end-to-end flow. Rather than having multiple different point-to-point connections, you ultimately connect once to the platform.

So that's kind of like your main connectivity as a connector. And then from there, you've got countless amount of integrations that you can build There's various different platforms that do different things. We've got a drag and drop connector that does it. We've got AI descriptions of that coming in soon. There's other platforms that do something similar to that. There's various different approaches to this. But ultimately, what it is at its core is almost like a hub and spoke model rather than a spaghetti architecture of multiple different endpoints all together. And you look at it in the bowl and you don't know where the start and where the end is. You want to make sure that you've got a hub and spoke architecture a scenario where the data gets orchestrated, flows, gets transformed in a central environment. The important part here is that this environment is exactly where the customer needs it to be. Either for internal reasons or for other sort of jurisdiction compliance reasons. And that's why it's very important that you choose platforms that allow for data residency as well, where you can have full deployment flexibility wherever you need it to be.

So we've got customers in Asia, for example, and that data must not leave Korea, for example, South Korea, that is. And it must not travel outside of it. No problem. Earlier, I was on a call with one of our main partners in Hong Kong, and they say as well, look, you know, we want to do more in the Hong Kong market. None, you know, in some cases, there's still deployment on physical service with customers, by the way.

So it's on-prem deployment. We've got... The technology is actually used for the customer in... It's a NATO customer, NATO partner. They deploy it in an air-gapped environment.

So again, here, the platform itself needs to be flexible enough to ensure that all the connectivity can be done exactly where it needs to be, where the customer needs it. But at the end of the day, the entire framework obviously needs to eliminate the need for creating 6,000 unique connections in that particular example.

Mark: 13:43

Yeah, I like that. I love that.

So, and... Very quickly, I think that's exactly what... Tell me just two seconds, what is IntelliPaaS and... How do you solve that problem?

Matt: 13:55

So we're in telling iPaaS is an integration platform as a service with full deployment flexibility. And that's important because again, customers need to have the flexibility to deploy it anywhere. Your organization might want it in Holland.

Someone else wants it in Germany and you could argue, and that's what often vendors do is, well, it's the European Union and therefore it should be all good. However, It really needs to be deployment flexible.

So deployment flexibility is the big one. We've got hundreds of out-of-the-box connectors that allow seamless connectivity. In fact, we're the only iPaaS provider that allows native STDIO MCP connectivity as well.

So it's not just connecting the dots today in a traditional business transformation level, but really getting this AI readiness in place, making sure that obviously other agentic workflows that then might be triggered through MCP servers of sorts that they are 100% covered as well, whether these are HTTP ones, STDIO, etc.?

Mark: 15:08

Before we jump back in, here is something that I've learned from over 30 years of working in technology. The hardest part of leadership, it's not the technology and it's not even the people or the teams. It's often that you're added alone by yourself. There's no one in the room that fully gets what you're dealing with. There's no one that you can trust to discuss your decision with. If that sounds familiar, find me on LinkedIn. Mark Wormgoor, and tell me what's in your mind. There's no pitch, just a discussion with somebody who's sat in a chair as well. Let's get back to it. And let's get it. You already mentioned a bit of, well, customer demands, but I think a lot of that comes from compliance as well. How important is compliance in all these.

Matt: 15:48

Integrations? It's the underlying framework, right? Compliance across the board is obviously a major topic, whether you're looking at AI compliance or anything else with it. Now, depending on each particular industry, that changes a little bit. The healthcare industry, defense, as I mentioned earlier, and this one particular example, and others, they're obviously living in a completely different Yeah. Bucket when it comes to compliance altogether. But, There are obviously various compliance... Laws that especially recently and very much introduced by the European Union as well and or other countries that can do it quite well. One example is Korea.

So I think you've covered probably enough about Europe. I'll give you an example from Korea because maybe your listeners don't. Don't know too much about that. There is the AI... The Readiness Act that's over there, which ultimately, underlyingly, requires companies to know well, in its first state, it's about labeling is something AI generated or not. But really what it's about is labeling and understanding all the data that comes into your AI, how it goes into it, how it's processed. How it's transformed ultimately end-to-end, the entire lifecycle of it before it reaches the, let's call it the final consumer of it. And that's actually remarkably difficult because it's a little bit like asking, where does the Internet get its information from? It's, you know, and it's that is remarkably difficult.

So what we've done is we've built an integration layer. We're working with one of the largest companies in Korea on that particular challenge, actually.

So we've built an integration layer where the incoming customers Data comes in and a little bit like in a post office scenario where each particular letter that comes through gets a stamp, you know, on the letter itself. We can do that as well with incoming data, making sure that it gets categorized. We understand from a compliance level where does it go so that at a later audit. You can go back into it and ultimately say this particular information here was coming from internal sources. This information here was processed from external sources. That information might then have to be cleansed.

So PII violations have to be avoided. Therefore, no personal identifiable information, first name, last name, addresses, for example, etc., dates of birth, they have to be cleaned before they then can be analyzed, for example, by local or foreign AI tools.

So there's an entire process from an infrastructure point of view that we put in place. And one is to keep compliance in place, but it's to make sure that AI can be comfortably used in larger organizations. Because I heard on one of the other pods that you did, you know, AI often is not enterprise ready or People are scared about it. And that is really because these layers of compliance aren't adequately in place.

Mark: 19:15

So, and then from my understanding with all that stamping and preparation, does that almost mean that for every request that you do, let's maybe take the insurance company again. So if I ask for specific or provides specific customer information with policy information, It's almost like for every single request that happens by the customer service team, it can be traced back to the sources that were used as input for that specific request.

Matt: 19:41

Yeah, in the end, it's in an audit environment, right? You wouldn't want to do that every day, but...

So external or internal auditors need to have the ability to really take a look at what's been going on, which AI decisions have been made, which data was exposed, have there been PII violations or not, because then either that needs to be stopped or in some cases it needs to be reported for, you know, other legal reasons. So I think what's really important when architecting this is that all the internal teams are adequately working together on that as well.

So the legal team obviously needs to be involved. That needs to talk to the technical sides. The operations guys need to be involved. Because back to the boardroom, it's very easy to create a mandate and say, we want to have X amount percent of AI adoption, et cetera.

And then in the end, it fails on the use case. It turns out, in our experience at least, that The most exciting use cases are actually probably the most boring ones from a board perspective because they solve one little thing that currently is completely manual in its entire nature.

So I think these are really the low-hanging fruit for organizations to look at as well. The other day, we were talking to a company, they were literally Creating. Invoices in SAP, printing it, physically printing it, scanning it again, and then sending it to...

And then sending it to partner suppliers and so on. Quite a large company. I couldn't believe it. Literally couldn't believe it. And the reason this is in place, still in place, is because nobody actually had the guts to tell leadership that this is their process. Leadership was not aware of that. It was, frankly, it was embarrassing.

Mark: 21:37

I can imagine. I've worked with SAP for quite some time and I haven't seen this process.

So most of the SAP world that I've seen is fully automated and just invoices get sent to email or interfaces or wherever it needs to go. So, but I can imagine if you still have this process, I'd not maybe want to tell my leadership about it.

So.

Matt: 21:55

Yeah. So, and we work with SAP a bit as well. And that is usually not the case. A hundred percent. Usually it's automated and so on, but yeah, In such a use case, you may not even need AI for it. This just comes down to digital transformation and making sure that your data pipelines are in place. That 100% should be automated. But on top of this here as well, the AI readiness can stall exactly at these levels.

Mark: 22:28

No, I understand. So, and if we didn't take it down, I think we've talked a lot about enterprises. If we go and take it back to startups or small companies, right? It's almost every company that I see starts with just spaghetti interfaces, just application to application. When does it actually become a problem?

Yeah. What is a transform from very pragmatic point to... Maybe being spaghetti or problematic.

Matt: 22:55

- Yeah. Smaller organizations or startups have a unique advantage, and that is they have very limited to no technical debt. As a result of that, they can make better decisions quicker and ultimately set themselves up for you know, the current age and what's coming ahead.

So, yeah, Obviously, organizations are going to be much leaner. In some cases, they don't have any on-prem systems at all. Often, organizations have everything in the cloud. That makes things a little bit easier, no doubt. But In the end, still, they need to think about where How does my data scale with the organization itself and or are we creating bottlenecks if we don't address it immediately?

So, Compliance is the other thing as well, right? So especially when it comes to use of data, smaller organizations often don't have data officers and so on that monitor these activities there so it's a little bit easier to internally easier to accidentally almost upload the wrong information onto public LLMs, for example.

So that shouldn't be underestimated, but from a pure connectivity point of view, The less endpoints you have, unique applications that you're using, the less endpoints you have, the easier it's going to be to set up an end-to-end integration, which then helps you down the line anyways. And I make that example often with plumbing, right? Because in the end, no one really looks at plumbing until there's a water leak.

So you just assume that it's there, but the moment it starts dripping through the ceiling, everybody says, okay, well, we need to have a look and potentially fix our plumbing altogether. And it's very similar with the data itself. No one goes into anyone's house or organization and says, well, we love your data pipelines. At the same time, nobody goes into a building and comments on the beautiful pipework.

So it's always overlooked up until the point where it really bites. And... I guess my encouragement is to any organization, especially the small mid-sized starting ones, is start with the integration layer first because it allows a lot of automation potential as well that otherwise would require ultimately a higher.

Mark: 25:47

Headcount. I love the plumbing analogy. In my own days, I've spent quite a bit of time trying to convince leadership trying to get budget approvals for integration layers it's hard and i think it's exactly because of what you said it's plumbing nobody sees it i think that Value isn't there, right? Even until it starts to leak, until you have an issue, until it suddenly stops this big program that you want to do, or it stops AI, or there's something else that really goes wrong. Any advice for people that are trying to convince their leadership that maybe an integration layer is a good idea?

Matt: 26:24

To be honest, Mark, it's there is often no one person or no team completely responsible for this. And... First of all, they deserve a seat at the table. But.. The amount of education we actually have to do with customers who very often are still using point to point because it's, seemingly convenient in the moment, right? There's another, and this goes back to the siloedness, especially of larger organizations. People only look at their particular project. They're not really looking outside of it because It's none of their business to an extent. They only want to cover this one use case. Obviously, budgets might come into that as well, but It seems in the moment like the path of least resistance. You just want to integrate with these two or three different systems and that's it. Let's forget about it because at some point when it comes to fixing it, then that's.. Possibly another project and or somebody else's problems.

So as a result, you've got a lot of Legacy. Patchwork when it comes to that, which often is not even documented. And that realization is simply not there. And that's what I meant with the pipe's got a leak in order for somebody to take a look at it. Now, the obvious fix to that is you're just going to get some duct tape and fix it rather than looking at the entire pipework at large. But my biggest... Biggest recommendation would be have somebody or a team who is empowered to look basically to be the integration officer, so to speak. Because That person will help unlock a number of use cases, whether it's from the business transformation or in the future AI projects as well, because they are going to be much closer across countries. They are probably the only ones, in fact, that will have knowledge about what's really going on across all the departments. Not just what's happening in one particular department, because that's currently the case, but really how that interaction between these different departments is taking place. That obviously requires other skills as well, other than technical, because you need to have personal skills too on top of it as you're navigating different priorities in different.

Mark: 28:58

Departments. And it sounds like...

Yeah, I mean, I've seen integration teams, but integration teams are usually very hands-on, technical. I like that you're adding that they should be talking to all these different departments. They should understand the functional side of the data. Where does the data come from? Where is the data stored? What does the data actually mean? How do you see this working with enterprise architecture? Is it one? Are they working together? How does that sit normally in organizations.

Matt: 29:25

I'm curious on your feedback here, but for the most part, each to their own... We see Even in integration scenarios, we often start in one particular department to then grow outside of that into others as well. And the larger the organization, the more difficult it becomes. Another example in a manufacturing customer in Southeast Asia. They... Are going through an SAP transformation project at the moment from ultimately ECC6 to HANA. Now... You can imagine, given they're still using ECC6, as to how old some of the other systems are. Very manual processes on top of that as well. Anyways. It turns out that obviously with the new move to HANA, there's a little bit of a mandate slash pressure on top of that as well with support running out. Ultimate... Challenge that this organization actually has is besides data integration is making sure that all the other departments which are affected by this change from ECC6 to HANA, whether it's the procurement guys and they import a lot of products from overseas as well. That team... The finance team, of course, the sales team, you name it. Everybody suddenly wants to have their voice heard on this What makes... It should be non-negotiable in terms of what they're going through at the moment. It should be very clear. It should be very straightforward. It's in everyone's best interest. But even in such an obvious use case where everyone really should be on the same page with everything, you will see that different interest groups are trying to overpower another, And on the integration layer, this gets amplified even more, right? Because we could help with I guess... We could help with streamlining the entire data, which actually would result in all the departments talking better with another. But the flip side of that is there's going to be more transparency. And not everybody enjoys more transparency. And as a result of that, you find that sometimes you... Up against pushback that at least doesn't make commercial sense. Your thoughts, Mark?

I mean, what's been your experience? Yeah.

Mark: 32:15

So, Mike, I mean, I've been in the enterprise world for decades. I always advocate for I mean, I've seen the silos, right? The silos exist in almost every large organization. And technology is just another one of the silos right next to finance and HR and marketing and sales and supply chain and procurement and everyone else. And I think that's just, it's absurd, right? Because I mean, maybe 30 years ago, absolutely. But it's 2026 and all of these departments, I mean, they don't work if there's no technology, right? There's no way that marketing or sales or supply chain can do that work without all of these underlying technology systems.

So I think it's, at least that's what I'm advocating in technology, it's time for the silos to go. So I don't think technology should be this little standalone separate department. It should be absolutely close and very close to each of these different silos and It probably is in this day and age. It is the connecting factor between all of those different departments. But it's, especially in organizations like the one that you just described, it's a very political game almost because everyone has their own interests that aren't necessarily the company's best interests. And yeah, I have a very strong personal opinion of that because I don't think you should be in any of those departments, whether it's technology or sales or supply chain. If you're not fighting for the company's best interests, but that's a personal opinion.

So I do think that technology can be that connecting factor or should be that connecting factor between all of the different departments. But I fully realize how hard that is, especially in these big migrations. I do think, and I've seen a lot of these really large transformation programs like Migration to HANA or just big SAP transformation programs. They are like the perfect opportunity to make all this happen.

So it is, I mean, for the company you just talked about, it is the perfect opportunity to bring it all together because you don't have a choice. You have to get on board. And if we move on from that, you've talked about some of the regulations that are in place. You talked about Korea.

I mean, of course, we have the EU. There's different regulations across the world. A lot of the companies that you must be dealing with, they operate not just in one of those regions, not just in Korea or not just in the EU. How do they deal with the complexity of all these different compliance and audit regulations is just exists everywhere where do you start how do they do it.

Matt: 34:45

Yeah and here that's why all the consultants are stolen in the games, right? Because... Obviously, in each particular country, jurisdiction, region, you've got different Yeah, all sorts of different law.

I mean, let's pick the EU, for example. And I think the EU is a good... Global standard because a lot of compliance that's come out of the EU has kind of become a de facto global standard.

So obviously there's a few other ones that are regionally important, but I think EU is probably a good starting point. With the EU AI Act, for example, which comes into place, it's early August, 2nd of August, I believe. The focus really is on risk management, on the data lineage, on ultimately... Human oversight to an extent of AI. And making sure that To the other point that I mentioned with Korea, automatic logging is mandatory.

So that really makes sure that a compliance layer needs to be put in place and obviously that due date is coming up pretty fast. That's That has implications outside of the European Union, because if you're an overseas business wanting to do business in Europe and or have some interest there, you're going to be subject to that.

So as a result, that's probably one example of a de facto global standard. Yeah. Takes this with some initiatives to another level, which then is more of a regional issue. GDPR is obviously still alive and kicking. We've got various other global variations of that, whether these are you know, Like local ones in Australia, for example, and so on. But overall, again, the EU has managed to create kind of a standard that if you're GDPR compliant as an organization, you often take many of the other compliant boxes globally as well.

So I think... Yeah, it's the EU... I must say, really has created the stricted, I travel a lot, right?

So I like to make travel analogies. It's created really the strictest border checkpoint when it comes to compliance And I think if you can pass... That particular compliance check in at Skiffle in Amsterdam, then you can literally travel almost anywhere.

So Yeah. Organizations should always prepare for the hardest border first.

And then they're going to be compliant for everything else. Another recommendation I always give is always prepare for the absolute worst scenario that could come out of a compliance scenario or two, If you then, literally, if you're prepared for that, you're going to be very credibly prepared for anything else on top of that.

So that can often be a good North Star scenario. In trying to be very tough internally and then hopefully the reality is a little nicer to you.

Mark: 38:08

So prepare for EU regulations first and if you can meet those regulations, then the rest becomes... Doable. - Yeah. - Or almost automatic.

Matt: 38:18

- Ballpark, right? Because again, you've got different industries, different regulations on top of that.

Yeah, from a de facto point of view or global law, It's a good starting point.

Mark: 38:32

Yeah, and I agree with you as well. That's why the consultants are there. I've spent... Time in my past actually trying to figure out what specific regulations, IT regulations were across 40 countries. There is no way of finding out.

I mean, the only way that you have is just calling up law firms in each of the 40 countries and asking them because there's no one that can actually tell you what the regulations are across the globe. It's almost impossible to figure it out. This was encryption specific, but I think the same applies to compliance, to data privacy, to there's just so many different rules across the world. It's really hard. A quick one before we continue. If you're getting something out of this conversation, please hit the subscribe button below. That way, other tech leaders can find us as well. I would really appreciate it. Let's get back to it.

Some more stories then. You've seen quite a lot of companies. You've given some nice examples already. What are some of the worst, maybe most expensive integration mistakes? That you've seen? What should people absolutely not do? Where can we learn from?

Matt: 39:32

Yeah, that's a great question. Well, mistakes obviously happen. For the most part, they often happen when the projects aren't properly thought through and ultimately it just results in significant professional services undertakings. And that's where... I guess the enthusiasm for integration can very quickly fade as well because if A common misperception is that the integration players know even though they have connectivity problems Options. To a certain ecosystem, it's often assumed that they are actually the ones that know the platform end-to-end, subject matter expert.

So let's say if standard example, obviously you want to connect something from your favorite CRM system to some ERP system or a marketing tool, for example. The common assumption is that only because you can integrate with it. You know the end-to-end details and everything about that particular system. In fact, these two systems and all the mapping and so to it. The reality is, yes, obviously the common ones most vendors know. However, there is so much configuration detail that's really happening on each particular instance, no two sales forces are the same, no two SAP systems are the same, no two and so on, right? The list goes on because the configuration details of that, the custom fields, the business logics behind that are fundamentally different across various different companies and or then obviously again, industries. Now, if subject matter experts aren't added to these projects early enough that's when integrations often take longer than needed. There's obviously ways to mitigate that and so on, but for the most part, it just comes down to decent project management. If managed correctly, Go lives can happen as early as a couple of weeks, depending on complexity, of course. For the most part, on average, I can just speak about our experience here. It takes... Again, depending on complexity, between six, eight weeks and everything should for the most part be up and running, at least for mid-sized sort of projects. If you don't have the subject matter experts involved, though, it can take three times as long. Because then you need to have various meetings about the same thing again. You need to make sure that the mapping is accurate. You're ultimately never moving out of a staging environment. And that ultimately has cost to the business, not just because you're paying for an integration solution that you're not using. But on top of that as well, we've got customers that are completely different. Relying on the entire integration with it.

Some of them are German car manufacturers and or their suppliers. And their entire supply chain, especially when it comes to the management of their own suppliers on top of that as well depends on our infrastructure.

So, If that's not adequately planned, you've got production stand stills in the worst case. And that has a business impact that significantly outweighs any subject matter experts, whether you have them internally or externally, they need to be available. What have you seen?

Mark: 43:23

I've seen everything. And I think everything you said, right, integration is just hard. In manufacturing environments where you just have all these standalone factories all across the world that all need to integrate, that are all different, right? I think that's what you see. It's easy when you have standardized systems like an SAP and a Salesforce. And yes, they're heavily customized because not every Salesforce is the same. They're all configured different. Customer data, custom fields, whatever. I think when you get into manufacturing, it's just you have 30 factories. They all have their own systems because they were acquired at some point. They have different manufacturing systems. There's not there's they're never the same. And I think that's a really interesting environment to be in. I think probably what you said about the car manufacturers, they have. They've probably... The strength to mandate to their customers or to their suppliers that they have standard interfaces, which makes it slightly easier. I just think the complexity can get really hard at times, just because there are so many different things. I think the other thing that I see quite a bit is these legacy applications. It's easy when you have an application where you have all the knowledge and the skills and you know everything. But when you get to these older applications where nobody really understands anymore or doesn't understand all the custom data and the custom fields or the interfaces, it can get really complex very.

Matt: 44:49

Quickly. And that's an interesting topic actually on the legacy applications. Another fantastic use case for AI. Where especially in organization, we work with closely in, yeah, ASEAN is very much focused on deploying AI for exactly that because the people have left, there's no documentation to it, and in the end it lives in its own environment guess what, a certain siloed department is still relying on it, not on a daily basis, but nonetheless. And that's then when it moves beyond data integration, of course, right?

So it just becomes down, it really then comes down to reviewing the entire organization at large, what's working, what isn't, which potential do we have to modernize? And yeah, are we ready for the future?

Mark: 45:53

Yeah, and I've seen those examples. I've read recently about that they've trained an ai model and i forgot which company it was so actually fully understands cobalt which of course i mean cobalt is running everywhere still on the mainframes in most financial institutions but the people that can actually understand and program it are retiring at large and i just love how we can use ai for systems like that to understand it but just to reverse engineer all their systems i've seen them do that which is incredible to use ai for that so I think, for the legacy. If we wrap it up a little bit.

So if I'm a CTO, CIO, and I realize indeed that maybe my data foundation isn't as good as I would want it to be for AI, where do I start? What are the two, three steps that I take to at least start getting some control?

Matt: 46:42

Ask your team for the first step. Ask your team whether...

So, other way around. The... Most CTOs know which particular AI systems are being used. However, very few actually know which data really flows into that.

So without looking at the screen and or doing a complete analysis of it. I think that is certainly one of the important bits is really knowing where the data is sitting because that's where you can map identify well first of all that's where your mapping comes in as well and you can really map your the data opportunity as well from an AI priority perspective. From there you can work backwards.

So I'm a big fan of starting with use cases if that's possible because that keeps the scope a little narrow and this kind of addresses some of the issues that we're seeing moving out of the sandbox environment. Again, with the example of the insurance company, they moved a little bit too quickly going from sandbox directly into a full environment where they really wanted to create value across the board with all their insurance products. What they really should have done, and that's what we're working on obviously right now, is that they're starting with one particular product here in a small environment. You A-B test your incoming customers. Your incoming load.

And then from here, you expand to another product and so on. So that would really be the quick win, I think, would be pick one particular... Ideally cross department workflow, Make sure it's observable, it's governed, And that... You're Prove that the model works. From there, you can expand into other ones.

Mark: 48:39

So not a large transformation program, just taking one small use case, building that one out, making sure that it makes it to production. I'll have all the compliance, the governance, everything in place, and then building on top of that.

So just a gradual improvement.

Matt: 48:54

And don't rip and replace, right? It's a journey. Don't rip out what's broken. Really build your staircase a step at a time where you have one integration layer building on top of another, making sure that you've got more endpoints coming into it. That's really going to be allowing a lot of use cases, whether it's on a digital transformation side, on an AI journey side, it's really going to provide the foundation that you need And moving away from this spaghetti part to just having well-orchestrated data pipelines that are going to serve you in the future.

Mark: 49:35

Yeah, and it gets easier. The more use cases you have, the more applications you have connected, the easier the next integration becomes.

So it starts... Difficult, it just gets easier and easier as you go along. What does the other side of that scale look like?

So if I've done all of this, I have this really nice integration layer, this AI-ready architecture fully in place and governed. What is that? Ideal model look like or feel like?

Matt: 49:59

Tranquility, right? Everybody... No, I mean, the benefits of that, I think, are obviously key. You've got a single source of truth across all departments. You'll be able to answer questions. Any key business question that comes up with it. You will fly through any audit in probably... Rather than weeks with going back, etc., everything that comes with it. It's a nervous system you're building, right? When your nervous system is fully healthy, it's fully functioning, you've got the brain sending signals to your hand and arm movements instantly, you know, you can feel You know in real time what's going on. You've got your... You kind of like in sync with yourself as a body, right?

So in that same way, feeling needs to be taken into organizations making sure that In the chore integration process, doesn't just feel seamless in the end, but it really just allows in the future and or where necessary, it allows AI to make independent decisions or semi-autonomous decisions, where then the entire organization can ultimately decide benefit from it. First of all, they feed it in real time, no lag. Nope. Broken connections, but everybody ultimately benefits from that as well.

So, yeah. Yeah, I think you know your data foundation is really mature when the biggest AI problem is kind of choosing which opportunity it is that you want to go up after next.

Mark: 51:54

And all the data is just there. And I love the analogy. And I'd love that it doesn't matter if you're Maybe even still in that startup scale-up phase, if you're a 100-people company or if you're a 10,000, 50,000-people company. I think in both cases, I think this analogy makes sense and people understand what that's going to look like, what that's going to feel like and how to get there. It's incredible. Matt, If people want to know more about you or IntelliPaaS, where do we go?

Matt: 52:24

Yeah, thanks. The easiest way is to go onto our website, intellipass.io. You can find me on LinkedIn. Feel free to connect with me. That's Matt Soltau spelled with an S. And other than that, You'll find me on this podcast here with you, Mark.

So thank you so much for having me.

Mark: 52:43

Thank you. We'll put everything, we'll put the links in the show notes, of course, so people can find you there. Matt, thank you so much. It's been absolutely incredible. Thank you. Thank you, Mark. As we wrap up another episode of the CTO Compass, thank you for taking the time to invest in you. The speed at which tech and AI develop is increasing, demanding a new era of leaders in tech. Leaders that can juggle team and culture, code and infra, cyber and compliance. All whilst working closely with board members and stakeholders. We're here to help you learn from others, set your own goals and navigate your own journey. And until next time. Keep learning. Keep pushing and never stop growing.