Integration Love Story med Mats Iremark

Introduktion

We sit here with Mats Iremark in today’s episode of Integration Love Story, live at our office here in Gothenburg. First and foremost, thank you so much for joining.

Thank you. Nice to be here.

We saw in the questions we sent earlier that we asked you when you were in Seattle, so it’s been a while. You’re a hard man to get.

We tried to get this recorded before the summer, but for various reasons we had to postpone it. We’re glad to have you.

We always start with you introducing yourself to the audience — both from a tech perspective and who you are outside of tech.

My name is Mats Iremark. Right now I work as the CTO of Hedin IT. Most people don’t know Hedin IT — they know Hedin Bil or Hedin Automotive. Hedin IT is the IT company within Hedin Mobility Group. We have a presence in 14 European countries. It’s a company within the group, employing around 12,000 employees.

Before that I’ve been working at SKF and Volvo Cars. I was at Collector Bank a couple of years ago. I have a background in system integration — I worked at a company called EAN, specialists in system integration. That was my first work in integration.

And I also know some people here at Contica from my background as a professional poker player.

Professionell poker och vägen in i tech

Few people have played professionally.

Yeah, few people. And I’m never invited to the friendly games. I wonder why.

Was there something particular that directed you to Hedin IT?

I was contacted by Hedin. I had some previous colleagues working there and they wanted me for the role I have today. It sounded really interesting. I had been working in various roles in traditional engineering, architecture and system integration, but I had never been the CTO of a company before. I wanted to test what was different in that role.

And what is different?

I like the role because I have a lot of freedom. I get to do both technical work and connect that to business, management and people — involved in a little bit of everything.

One follow-up on that: it’s quite a complicated role, because the technical choices you make affect a lot of things. How do you approach the question of whether a choice is right for the business versus just something you personally like?

I always choose what I like.

No — but I do have that internal discussion. You have to be really careful not to fall into the trap of choosing something just because you personally like it or have worked with it before. It’s really hard to put yourself in that neutral perspective. But in the end it’s people combined with technology that makes something succeed. If you choose the best technology but the people don’t know it, it won’t go well.

How often do you feel like you might not be choosing the right thing?

I try to question my decisions every day. These days I use GPT to get feedback and look at things from other perspectives — you get a lot of that for free. But in general, you need to revisit choices continuously.

One fundamental thing in both software engineering and decision-making is the ability to embrace change. The first criteria for a design should be: is it easy to change? Sometimes you make choices that are hard to change — those need to be really carefully thought through. But if you make choices that are easy to change, your road ahead will be so much easier.

BizTalk, Azure och systemintegrationens historia

You have a history with BizTalk and were yourself in Seattle when they launched Logic Apps. Tell us your story with Microsoft technology from a system integration perspective.

I was studying physics at university. I dropped out and started playing professional poker — did that for six or seven years. Then I got bored of it, it didn’t pay as much as it used to, and I looked for a job. I ended up working with system integration.

I hadn’t been coding anything for six or seven years, but I got a job at a system integration specialist company. From that time, and from working with system integration, I learned things like event-driven architecture, message-based systems and loosely coupled systems — principles that have been invaluable lessons. I got those right from the first day.

I worked with BizTalk. That was the way to build software for me — I hadn’t seen anything else, so if you were going to build software, you did it with BizTalk. And it was really fun. A little bit of drag and drop, some code, some configuration — quite easy to get started with.

Then Azure came along. At the company, we started using Azure to set up test environments for BizTalk, because it was hard to get virtual machines at customer sites and run test environments on your own laptop. We started exploring Azure cloud and running BizTalk on servers there.

Then it jumped to: what else can you do in Azure? We started using Web Apps and particularly Web Jobs for building microservices — small components handling all these integration patterns. We put that into a kind of factory mode: standardized components in Web Jobs with a deliberate choice to copy-paste code to new components, thinking a bit like pipelines. Together with Service Bus.

Over time those services matured, we built bigger systems and moved toward more traditional software development. Today we mostly build containerized applications as the standard way of packaging and building systems.

Integration som systembygge — inte en produkt

Do you still see integration as its own discipline, or has it merged with general software engineering?

Today I see integration as nothing particular. Integrations are often small systems that you build. I take the same principles as general software engineering and apply them to building integrations.

I like that you call them systems. Not solutions — systems. Isolated systems doing certain things.

Microservices came along a couple of years ago and kind of exploded. It meant that people could work in parallel on smaller, simpler things. But after some time you had the problem of how to orchestrate everything — you just moved the problem to another level. You solve a lot of problems using the microservices pattern, but you get new ones. Keeping track of how processes flow through all these services is one of them.

Centraliserad loggning och plattformarnas död

The problems that a product or platform like BizTalk solved back in the day — I would say those problems don’t exist anymore. Back then, you had flows of data going in and out of your company and you needed one way to keep control of that. You put the BizTalk box in the middle, connected everything to it, and you solved the problem. You could see all your data flows.

But you ended up with one box in the middle that everybody was really afraid to touch.

One technology that came along was centralized logging. Your systems could log to one place regardless of where they ran. You could put your systems wherever you wanted but still see what they did in one place. That basically solved the same problem as having one central platform.

I would say centralized logging killed platforms like BizTalk.

Low code, Logic Apps och kvalitetssäkring

What’s your take on low-code tools like Logic Apps?

I’m using some low-code tools today. I’ve used Logic Apps before and now I use N8N, which is a tool that’s really AI-integrated. It’s powerful for spinning up prototypes or showing something quickly.

The problems with most of these low-code platforms are the things you run into on day two or day three. You come back and it’s a spaghetti of boxes connected. Why did I change this? How does this really work?

Back when I had been working with BizTalk for a couple of years, I moved to Collector Bank, which had a much more traditional high-end software development culture. I took the good things from system integration — event-driven, message-based, loosely coupled — and met with good practices from software engineering. Suddenly we were talking a lot about unit testing and integration testing.

At our previous company, our approach to testing was: put the file in a folder and see the output in another folder. The platform was doing all the heavy lifting for you. But you still needed to verify that your mapping, your translation, handled all the edge cases.

If you’re writing code these days, you’re doing unit testing, integration testing at different layers — that ensures quality. The problem with low-code platforms is: how do you ensure quality and robustness for mission-critical production scenarios?

At the bank, we had a system that needed to talk to the place where the actual money is, and tell it to send hundreds of millions to different bank accounts. It did not cut it to do that with drawn lines between boxes. When we made changes to that system, we wanted tens of thousands of green dots lighting up for unit tests. For that case — 100%. That’s how it should be.

Logic Apps is powerful, but it has its place. It’s an orchestrator. But you can’t run an entire choir with only the orchestrator. There are other instruments.

När ska man använda vad?

As an engineer — whether system integration or software — you need some tools in your belt. Logic Apps being one, Azure functions being another. It doesn’t always have to be the perfectly right technology. The strength of knowing one technology well is that 90% of what you build fits really nicely there. The last 10% you might have to shoehorn in — and that’s okay. It’s good to have most things within one technology.

For someone working mostly with Logic Apps, it would be good to learn one or two technologies next to it — put a few more tools in the belt.

There is no single right way. You have to get back to: when to use what? Everything works, apparently — that’s why you need the conversation.

AI, determinism och MCP

It’s really hard today knowing when to use AI, because it’s so extremely powerful. But you have to be aware: you can’t really use it when you need something 100% deterministic. If I’m going to send a file of hundreds of millions to be paid to bank accounts, it’s not acceptable that in one out of 10,000 cases something goes wrong. There it needs to be code. But in many cases today, AI is so easy to implement and it will be right in enough cases.

Someone compared it to the autopilot on an airplane: there’s a pilot sitting next to it, and in some edge cases the pilot takes over.

Can you tell us about a scenario where you’ve seen real business value with AI?

We’re doing a lot of automation using AI. We use AI as a kind of integration engine. Every system we build or have today, we try to get an MCP interface up for it. And then you sit at the prompt, connect your systems to MCP, drop in a file and say: “I need this inputted into this system, then take the output and send it to the other one” — and it just does it.

Yesterday I booked a tire change for one of our cars using MCP, from ChatGPT.

Earlier today I tried to book a tire change for our second car and something went wrong with the longitude and latitude. The LLM didn’t catch it, and the confirmation email I got was that my appointment was booked in Stockholm.

Things like that — humans would catch it. But you have to iterate. You have to give clearer instructions next time. That’s the skill: asking the right questions, writing good prompts, knowing what context to provide. And that skill has been, and still will be, super important.

Naturligt språk som affärslogik — vad som ersätter plattformarna

You said centralized logging killed BizTalk. What’s killing the way we see system integration today?

How we work right now is that we hook up the prompt to different systems. The LLM is basically where we describe the business process.

We have a process today where we manage a catalog of millions of parts that can fit onto cars. Those parts have to go through a process before we can sell them individually or as packages — checking values, setting prices, publishing to the web, bundling as packages. The individual actions are exposed as MCP endpoints. They can be implemented as Logic Apps, Azure functions or plain code. But the process itself is described in natural language — in steps sent to some kind of AI agent.

What’s so powerful about this is that it’s not code. It’s written in natural language that everybody can understand. What you put in version control today is: “First we do this, then we do this, and if this happens you have to double-check.” That’s your business process.

Råd till nästa generation

What would your advice be to the next generation of system developers, system integrators — tech workers?

You need to be good at some tech. You need to be able to offer a company something you’re genuinely skilled at. But after some time you also need to understand: where is this technology used, and is it the right fit for the problem?

With AI doing so much coding today — both real code and in low-code platforms — if you just write code without understanding the broader context, you’re going to struggle on the job market fairly soon.

You need to stay curious. Keep up with what’s happening in the world. Don’t get stuck in technologies you’re familiar with and like just because you’ve worked with them — things are moving. You have to put yourself in that neutral perspective and take a look at things for what they are.

Integration Love Story

When was the moment that integration really got to you?

Pretty early in my career. Our customers were quite big companies, and it was funny — having worked for just a couple of months or a year, you’re sitting in a meeting and realizing: this company stands still if this integration is not working.

The fun thing about integration is that you’re doing quite tiny things, but the effect is really big. One plus one becomes four. You can create real business value just by making the connection — adding something excellent by connecting things.

And compared to being down in the basement writing tasks and user stories, you’re closer to the users. You get to understand business processes much more directly. That’s what made me stay.

Avslutning

One question we ask: if you could kill a technology, what would it be?

I sometimes joke that if someone puts XML in their resume, I throw it out. It’s a structured format — but if you’re leading with that today, then you’re out.

Who should we invite next, and do you have a question for them?

I think you should invite a close friend of mine, Dan Kamvski. He worked at Collector Bank when I started there. I came in from the system integration perspective and he stood for the good software development perspective. We kind of met in the middle and learned the best from both sides.

And what question should we ask him?

Ask him what he thinks about me.

What advice would you leave for other CTOs — people who are running the backbone of a business?

You have to keep up with what’s happening in the world. Don’t get stuck in the technologies you know and like, because things are moving. Put yourself in that neutral perspective and take a look at things for what they are.

And not every day do we meet other passionate people like you.

Thank you so much. Thank you for inviting me.