Integration Love Story med Dick Borglin
“Allt du gör är en produkt” – ett samtal med Dick Borglin om integration som hantverk.
Det finns något befriande i att lyssna på någon som kan integration på riktigt men ändå pratar om sitt yrke utan stora ord. Dick Borglin, integrationsarkitekt med över tio års erfarenhet, hör till de där människorna som lugnt och självklart kan röra sig mellan teknik, affär och hantverk – och som verkar lika nyfiken på nästa version av sitt eget jobb som han var när han satte sig framför en Commodore 64 första gången.
Om videon inte spelas. klicka här:
Youtube: Integration Love Story med Dick Borglin
Spotify: Integration Love Story med Dick Borglin
Från Commodore 64 till integration som hantverk
Dicks resa började som 10-åring framför en Commodore 64. Den nyfikenheten har följt med honom genom hela karriären – från dotcom-bubblans turbulenta tid, via några år på beställarsidan i Norge, till en återkomst in i konsultvärlden runt 2010. Det var där integration på allvar kom in i bilden.
För Dick var integrationslagret den pusselbit han inte visste att han letat efter. Att få system att tala med varandra, att kunna förändra ett helt arbetssätt genom att flytta data smartare – det blev hans grej. Att göra det riktigt bra blev hans hantverk.
Att bygga ordning i kaos
Integration är ofta kaos. Det vet alla som jobbat länge nog i branschen. Dicks sätt att hantera det är att medvetet bygga struktur – inte som ett tvång, utan som en plattform för att andra ska kunna förstå och bidra.
Han beskriver det som en gyllene stig. För hård struktur kväver kreativiteten. För lite struktur skapar förvirring. Konsten är att hitta balansen där människor runt omkring – kollegor, konsulter, beställare – faktiskt kan följa med i tanken och bygga vidare.
Det är också där dokumentationen kommer in. Inte som ett pliktmoment, utan som något mer personligt. Som konsult, säger Dick, är dokumentationen det enda som blir kvar efter dig. Det är ditt avtryck. Det är ditt arv. Och det är så folk minns dig – och varför de hör av sig igen.
AI som ny hammare i verktygslådan
När samtalet glider in på AI är Dick både nyfiken och avvägd. Han ser tydliga paralleller med dotcom-eran: det kommer att hända saker, det kommer att finnas förlorare, och något kommer att förändras på riktigt. Men AI försvinner inte.
Hans bild av AI är pragmatisk. Det är en ny hammare i verktygslådan – kanske en imponerande sådan, men fortfarande ett verktyg. Det fina är att den kan ta hand om de tråkiga bitarna, som dokumentation, och låta människor lägga tiden där den faktiskt skapar värde.
Han delar också en konkret berättelse om hur han nyligen byggde en lokal RAG-lösning på tre dagar genom att kombinera ChatGPT och GitHub Copilot CLI. Och en helg senare hade han byggt ett eget verktyg som tar en mappnings-mermaid, en källfil och en målfil – och bygger en service bus-driven integration åt honom. När det fungerade reste han sig upp och knöt näven i luften.
Det är där värdet ligger, menar han. Inte i mappingen i sig, inte i deploymenten, inte i sändportarna. Utan i att integrationen sätts samman – och att den som sätter samman den kan lägga sin tid på det som faktiskt kräver en hjärna.
Tänk som en produkt, inte som en lösning
En av samtalets tydligaste tankar är skillnaden mellan en lösning och en produkt. En lösning är något som fungerar just nu. En produkt har paketering, deployment, SLA:er, ett ägarskap – ett helt sammanhang.
Dick menar att integrationsarkitekter mår bra av att tänka i produkter snarare än lösningar, och i versioner snarare än slutleveranser. Version ett får vara stökig. Version två blir lite mindre stökig. Version tre börjar likna något man är stolt över. Det tar bort prestige från kunskap och från det egna arbetet, och gör det lättare att bygga vidare – både som människa och som team.
Det som inte förändras
När vi frågar vad som är integrationsarkitektens superkraft landar Dick i två saker: nyfikenhet och storytelling. Nyfikenhet för att lära, men också för att kunna hålla tillbaka entusiasmen tillräckligt länge för att fatta kloka beslut. Och storytelling för att kunna föra över både insikter och beslut till människor som inte sitter mitt i tekniken.
Det är talande att han, efter ett samtal som rört sig från BizTalk via API-design till AI-agenter, landar i något så mänskligt. Det är ungefär där de bästa integrationssamtalen brukar landa.
Introduction
Welcome to Integration Love Story. We are very glad that you’re here. We’re going to start off with the segment that we usually do nowadays. I’m going to try to do a short presentation which will probably be okay and maybe something wrong, and if something is wrong then just say “ah, not that much,” but I’m going to try.
Integration Architect. You’ve been working with integrations over 10 years, both on the consultant side and on the business side. You moved between consulting and business and you stayed on the business side, if I’m correct.
Well, it depends.
What I understand from you as a person, if we talk about tech and AI, you’re curious, but you’re still very humble about new technology. I think you’re sure that the human side of it will still be very important. Even though AI and new tech will help us do things faster, the human side will be something we don’t lose.
Skiing is something of a favorite activity if you choose your vacation. I’m not going to go through that so much more because that would be cheating since we just talked about skiing. But I know that you’re a friend of structure and clear communication.
Thank you very much. You’re absolutely spot on. I am a friend of having things structured. I love the winter games as a whole thing. One of the things with me when working as an Integration Architect is structuring the chaos that you have with integration. Integration is basically some kind of chaos for many people, and I like to bring order into that chaos. My manager used to joke about it being some kind of OCD – “you have to take care of your OCD” – and I think you can actually do something great with it as well.
When I said that I like structure, I do. But I also like that structure brings the possibility for creativity. Structure doesn’t say that you cannot be creative. It helps the other person sitting next to you to understand what you have said. If you can make it structured for that person, then you will not halt creativity. But you will kill creativity if you force structure upon some people. It’s a golden path. You have to walk it carefully so you don’t kill creativity but you don’t get chaos at the same time. It’s quite difficult from time to time, but when you succeed, it’s really satisfying.
Structure, stamina and the consultant mindset
I’d like to challenge the part about structure and how you want to enforce it in integration, because integration usually isn’t that structured. Maybe in one or two projects, but usually there’s a miss somewhere. So how do you cope with this kind of focus on structured architecture?
Well, you have to have stamina. You need to think of it as proof of concept, or version one, version two, version three. Version one is chaotic, version two is less chaotic, version three less still. Doing it like that helps me keep some kind of structure.
That’s also one of the things on the business side – not the consulting side – that you need to help out with. You pave the way for the consultants to come in and do their work, which is what they should do, since you pay good money for it. But when they leave, the integration is still there and it has to be maintainable for the business. That’s why the business needs to keep structure, and if the business doesn’t have a way of doing that, then the consultants need to provide it.
If you are a consultant and they pay good money per hour and you’re there for a few months or even a year, the only thing that stays after you when you leave is actually the documentation. That’s the only thing they remember you by. And you want them to remember you as a good person who left something good behind. That’s how they will come back to your company and buy more hours from you. That was my way of thinking as a consultant, and being on the business side I think the same way.
You can have brilliant consultants and brilliant employees, but everybody more or less hates doing documentation. I don’t like it either, but I find it even harder to go looking around in the repos and all those places just to find things. So helping with structure is good – and now AI helps with that as well. AI is so impressive in that you can do these things in so many ways. You don’t have to force documentation upon people anymore. You can let AI do it. The boring tasks can be removed.
Documentation as legacy
I really love the way you put that. I just want to frame it again, because this is one of my favorite things I’ve heard about documentation – the best way I’ve heard to motivate it. I’ve always been keen on documentation, but I’ve always talked about it as “you leave a document for the next person.” When you put it the way you put it – that’s your legacy. You are putting your memory here. People will remember you because you did these things, and they will go to your document.
That’s how I see documentation. It’s a kind of legacy.
Background and the integration love story
Before we deep dive into AI, what’s your background? You said you have 10 years in integration. Maybe that’s wrong.
It started when I was 10 years old. I usually tell that when I’ve been in interviews. When I was 10 years old, I started with computers for the first time, and from that day on I’ve been hooked. It was a Commodore 64.
When I started working for real after my studies, I started working in the dotcom era. I got into the bubble just when it exploded. So it was quite a rough start, but I never regretted it because what I learned from that period was amazing, and I still use that learning today. That’s when I started with consulting. I was a consultant for a few years in Sweden, and then I met my wife and we decided to move to Norway for a few years. I started working on the business side at one of the largest companies in Norway. I worked there for two years or so, and then I went back into consulting. That’s when I started with integration, around 2010.
That was amazing in many ways. Up until then, I had been working with different systems – one application, another application – and you always layered everything as you should. Then with integration, you get this integration layer outside of everything. You really get the missing piece. Like Maximo working with the SAP system, moving data between them. That’s where it happened for me. I realized: this is it. This is integration. You actually get the systems to talk to one another, and you can actually improve things.
That leads to my integration love story. It was around 2010 or 2011 at G4S in Oslo. By the way, G4S is one of the biggest employers in the world – 800,000 people employed worldwide.
I started working there in Norway, and they had a fantastic CTO. He and the marketing manager had figured out that it took around three to four weeks to get a prospect to become a customer. That was the standard way of doing it at the time. They challenged that and said, “Can we do it faster?”
So me and a friend, GG, were tasked with creating that.
If you went to their website and said, “I’m interested in becoming a customer” – like with Sector Alarm and similar companies – from the time you clicked “send me your prospect information” until you became a customer was three to four weeks. We got it down to four hours.
That’s when I got hooked on integration – from three to four weeks down to four hours. The alarms were also installed and checked in that time. The service technician went out to the prospect, had an iPad with a web page connected to our integration layer, which was connected further down to the alarm systems, the ERPs, and other areas.
What middleware did you use?
We used BizTalk in the middle, with a normal web application in front that the technician signed in to.
How much recognition did you get from the company and how much did you celebrate?
We didn’t celebrate as much as we should have, unfortunately. But we got recognition from the CTO and the marketing manager and the rest of the team. They were impressed. It was definitely a team effort. Me and GG were basically the craftsmen. They had an excellent project manager, super users – all the things that really make a difference – and an excellent internal customer in the marketing manager and the CTO. The team did celebrate. We went out and saw Jerry Seinfeld in Oslo. That was good fun.
A year or two later, G4S sold off the business in Norway. A big company doesn’t make as much money as they’d like in a market like that, so they sell. That’s how every company that size operates. There’s nothing wrong with that. They sold to a competitor and everybody kept their jobs. That’s my integration love story.
A regular day as an Integration Architect
If we fast forward to today, what does a regular day look like for you?
Meetings, basically – unfortunately a bit too much from time to time. But in between, you get to do some interesting stuff with your colleagues. You might have new people coming on board, and being part of that is interesting and good fun.
The AI moment and lessons from the dotcom bubble
You were around when the dotcom bubble burst. Do you see any similarities with what’s happening now with AI?
Yes, of course things will happen, but it’s a bit too soon to say. There will be casualties, that’s for sure. There will be mergers and acquisitions. The learning experience from such a bubble is tough. It really puts a scar in you sometimes. But when you’re over it, you don’t hate your scars, because you’ve learned something from them. You’ll survive – that’s what you need to learn. You will survive, even if it’s tough.
I agree. There will be casualties, but AI will not disappear. It’s going to change the world in many ways. Look at the DoD in the US talking about AI in defense contexts. There are things happening in that area. AI is here to stay. The question is how we work with it. It’s like a new hammer in the toolbox – probably a very impressive hammer – but still a hammer. We need to say when we need a hammer, or it will suggest one for us.
Adapting in a structured way
I agree – you need structure, and things can’t move as fast as AI does. But adaptation in a structured way: how do you do that?
I don’t have a perfect answer. I do think that working with markdown documents – plan.md, tasks.md, skills, agents – is a starting point to get into a structured way of working, at least to have an understanding of what we’ve created.
I haven’t explored embedding an agent in an integration workflow at home yet. We’ve used agents a lot lately for development and execution, but not putting them into an integration loop. But I can see it happening. I’m just thinking about where it will happen first. It has to bring value to customers. Someone is going to pay for it. There has to be business value. Otherwise, we’re not allowed – financial officers aren’t always easy to talk to. Jokes aside, that’s how it is. There’s a box of money that has to be spent in a way the financial officers agree to.
If innovation doesn’t have a buyer or doesn’t create value, it’s not really innovation. As a human being playing with it, sure – have fun. But there’s so much happening that the exploration of what’s actually valuable is the fun part. I find new things every week, test them, and then ask: how can this be valuable, not only for the business but for me? How can I eliminate a task I don’t want to do anymore?
It’s often about the business process – the repetitive tasks done by admins behind the integrations. The layer closer to the business users than the back end.
Mistakes worth learning from
You mentioned successful stories. What about the unsuccessful ones?
Back in the day, you could expose a receive port in BizTalk as a web method – an API endpoint. So you could have a receive port on an orchestration exposed as an endpoint. That was a crappy idea, and I’ve done it. It was really hard to work with. The mappings were out of this world, sitting in the BizTalk mapper doing all these things. It was mayhem, and it got slow because the orchestration is synchronous. Send port, receive port – BizTalk isn’t a synchronous operation. Send a message, it works, it finishes. That’s what it does. Having it used like that was tricky.
That’s not something I would like to do again. Today, if I needed to do something orchestration-like, I’d do it in Logic Apps. That’s the closest equivalent. I’d return 202 Accepted and then, when done, return 201 Created. Or use a webhook so the application itself sends the “we are done” information. That’s how I’d do it these days. Back in 2010–2011, I wasn’t that clever. It was a learning process.
The other one is APIs. I believe many integration people struggle with good APIs because it’s hard. We are message people. We think in huge messages, with claim check patterns or outbox patterns. But at the API level, smarter APIs that are less verbose – and versioning – are difficult. I’ll probably keep making mistakes there, but less and less. I’m not the only one, and I won’t be the last.
Limits are also something that gets forgotten. APIs are hard to do, and then there’s versioning. We have a huge issue killing off APIs. If you can kill off APIs fast enough, you won’t have so much legacy. But who takes the lead on killing off APIs and telling everybody to change? It’s difficult. You sometimes need to do tough love towards your users, and if you’re a kind person, that’s not easy. Then after a while you have too many APIs and no clear answer about which one to use.
You need structure. Sometimes it becomes a matter of taste, with everyone doing it their way. And when you see an API and think, “This will soon be obsolete – and now I need to do something to it,” that’s a problem.
Migration is similar. People get stuck in migration. You migrate to new technology, but the steps need to be small and agile, like your process.
The superpower of an integration architect
What is the superpower of an integration architect that won’t change? And what about the future superpower?
I was about to say curiosity – but curiosity killed the cat. Still, being curious is a good idea. Maybe not always running on the first cool thing you see. You also need to be able to hold your enthusiasm back. That’s not easy, because if you see something that will save money and onboard new clients, you want to push it. But not everybody is there with you. You have to cool down a bit and not be overenthusiastic. You have to be enthusiastic and curious, but the superpower is actually some kind of storytelling. That’s a superpower. It’s amazing how some people can do it. I’m very impressed by it. That goes for everything – not just integration. Storytelling is a good thing, and it’s a superpower for the future too.
For surviving right now, with all the workloads people have, it’s again about being curious and wanting to learn – or at least learn from others. I’m not saying you should sit day in and day out doing courses. Take the possibility to learn from where you are. If you’re in a project right now, try to think how you could do it differently.
And be able to think in versions – version one, version two, version three. Have a product state of mind. Think of everything you do as a product. A product is different from a solution. A product has everything around it: packaging, deployment, SLAs. Everything else is just a solution. If you think of everything you do as a product, life will be easier in the long run as an Integration Architect.
I really resonate with that. Especially now – I’ve started coding again, and I love creating. As you said, seeing the learning path as a product helps. I don’t have to learn everything tonight or this weekend. I can do it as a product. What do I need to learn now to get to the next version?
Then you lose the attachment. You don’t get so protective – “that’s my knowledge.” It’s not. It’s just a version, and it’s going to go away.
What I’m learning right now
You’ve worked as a consultant, and you’re now on the business side. So you have a consultant mindset – battle-hardened from the consulting world.
We’re in early 2026. What are you focusing on? What are you reading? What are you learning?
What I’m learning most right now is becoming buddies with GitHub Copilot. I’m trying to be a good friend with it, and we’re getting fairly acquainted.
Last week I prompted a RAG solution completely local. I asked ChatGPT, “I would like to create this one – how can I prompt this to the GitHub Copilot CLI?” It gave me a good start. I put the resulting plan.md into Copilot CLI and asked it to implement that. It took me three days to get something running locally. It took one day or so just to get everything up and running, creating all the things Aspire needed. It was about transcribing audio and video files. After three days I had something I could ask questions of in natural language. It was a combination of ChatGPT and GitHub Copilot CLI.
And this Monday, I created another thing. Everyone has been in mapping sessions where someone sits with an Excel file doing the mapping while several people are in the same room. I find that tedious. I created a tool that, in the end, generates a Mermaid diagram. On Monday I tried: if I take this Mermaid diagram plus the source file and the target file, can you create an integration for me? Can you do a service-bus-triggered integration that sends out on a service bus, with Aspire as the engine, so I can run everything locally without deploying to the cloud?
Yes, it did.
So you created a diagram from the business process, you had your test files – output and input – you asked through Copilot, you had Aspire, and you didn’t need a platform.
It even created PowerShell scripts. I ran one of the PowerShell scripts, sent a test file, and ended up in the mocked service bus. Then another PowerShell script retrieved the file, so I could validate that the mapping I had just done worked. JSON in, XML out, all on a service bus level. It was quite hilarious.
When you realized it worked, what did you do?
I stood up and did this. (fist pump)
I know exactly what you mean. That’s how it works. It’s good fun.
I’d love to see that. Maybe we can do another session. I’m really curious.
That’s my hate story – sitting in mapping sessions. I don’t think a developer should have to sit in those meetings just because they have access to the data map. As we said earlier, AI should help us kill things we shouldn’t be doing.
The value isn’t the mapping, the service bus, the deployment, or sending the messages. You are the brain behind all of this. You are the big orchestrator. Creating those things is part of your work. That’s why I love this.
This is the integration love story. It became a bit of a hate story too, but in a fun way. The true love is for integration itself. It’s not Azure, it’s not Mule, it’s not BizTalk. Now I’m using Copilot CLI. But this is integration.
The survival kit
Is there anything you’d like to add?
The survival kit. Three things. A proper internet connection that works all the time. An AI subscription, unlimited. And the IT team – the people I’ve been working with in the different ICCs. Those are the things I’d like to have with me when I do integration. It’s a team effort, and without that team effort, it’s not fun.
That’s the biggest thing of it all.
Three wishes – one of them unlimited tokens, please.
Thank you so much, Dick. We will keep in touch and we will probably do a next episode soon.
Thank you. It was amazing talking to you.
Good fun talking to you guys as well. Thank you so much.
Dela detta inlägg
