Integration Love Story med Martin Abbott
Martin Abbott, Program Architect för myndigheten för vatten och miljö samt mångårig Azure MVP
Om videon inte spelas, klicka här:Integration Love Story med Martin Abbott
I den här intervjun pratar Ahmed och Robin från Contica med Martin Abbott, programarkitekt för myndighet för vatten och miljö samt mångårig Azure MVP. Stor vikt läggs vid AI:s roll i integrationslösningar och hur verktyg som GitHub Copilot kan öka produktiviteten för utvecklare. Martin delar med sig av insikter från sin långa erfarenhet inom integrationsgemenskapen och pratar om realtidsintelligens och hur meddelandehantering förblir en central del av integration. Det är bland annat en av många delar i den bok han skrivit som fortfarande är relevant och sant.
Stor vikt i samtalet läggs vid just AI med fokus på den session han hade på Integrate tidigare i år som handlade om att bygga en integrationslösning med hjälp av GitHub CoPilot. Martin berättar också hur BizTalk spelade en stor roll i hans kärleksrelation till integration.
Lyssna på hela intervjun för att höra mer om Martins tankar kring produktivitetsverktyg, integrationens framtid och hur dessa framsteg förändrar industrier som sjukvården.
Introduktion
Welcome, Martin, and thanks for joining us today. Can you tell us a little about yourself?
Sure. I live in Western Australia, in Perth — apparently the most remote capital city in the world. I’ve lived here for 13 years, previously in the UK, as you can probably tell from the accent. I’ve been in IT for about 25 to 30 years, in the integration community for most of that time. I know a lot of people in the community — it’s nice and small and everyone is very friendly. My background is very much in integration, IoT, data management, and data engineering, and obviously AI now because you can’t do anything without it.
Perth och Little Creatures
I was in Perth about 10 years ago and remember a local brewery called Little Creatures in the harbor.
Still there. They do a really good mid-strength hazy ale called Little Hazy — possibly a little bit too fantastic. They’ve also recently introduced a very good non-alcoholic beer. Great food, great pizza, great nachos. The location is still amazing.
Boken — Robust Cloud Integration
Tell us about your book.
It’s called Robust Cloud Integration and it’s a little bit out of date now — I’m unlikely to write a second edition. It was me and four other authors through Packt Publishing. Packt brings together thought leaders from around the world to co-write books. I worked closely with one of the authors from New Zealand and a couple from India.
It was six months of my life. I haven’t entirely paid off my advance yet. But it was a great experience because it forced me to concentrate deeply on areas I hadn’t focused on as much — particularly Logic Apps. Coming from a BizTalk background I understood orchestrations and all that, but writing the book meant relearning those things in the new way. That was really valuable.
The three key areas the book covers: messaging, orchestration and workflow, and large-scale high-volume real-time data — IoT, Event Hubs, event-driven architectures. It has a BizTalk-ish lens because myself and James from New Zealand were both BizTalkers. But the fundamentals are timeless. You can’t do integration without messaging, without handling large volumes of real-time data, and without some kind of orchestration engine.
Integrate 2024 — GitHub Copilot Chat och verklig integration
At Integrate 2024 you spoke about building an integration solution with GitHub Copilot Chat. Why this topic?
I used to work at Microsoft and was involved in selling GitHub. When Copilot came out, most demos were very orchestrated — here’s a piece of code, here’s how we fix it. I wanted to try something different: a real-world scenario where maybe the person doesn’t know how to code the integration, and see how capable Copilot actually is.
The conclusion was that you can get some places but not others. Orchestrations and workflows are a good example — you can’t really build them easily with Copilot. But for a lot of code-based tasks, you can do some very interesting things.
Co-pilot är biased — varför det spelar roll
You mentioned early in your session that Copilot is biased. Can you explain why that matters?
Copilot is trained primarily on public repositories. There’s a lot of C#, JavaScript, Python in those repos — and less of other languages. As an example, if you ask it to write an Azure function to read and write to a Service Bus queue, the first output often uses the old namespace, not the latest one. That’s because a lot of the code in those repos was written with the old namespace.
Being biased doesn’t mean it’s broken — it means you have to know enough to guide it. Once you understand the bias, you can use it in your favor. Tell it which namespace you want, which patterns you want. The responsibility doesn’t go away.
And that’s the point about the name “co-pilot.” I like it and dislike it. I like it because it says: this thing is here to help you — you’re the pilot. It doesn’t remove your responsibility. But I also know from my aeronautical engineering background that it’s often the co-pilot who actually flies the plane most of the time. So co-pilot can also mean the most active person on the flight deck. Either way, the responsibility still rests with you. You still have to look at what it produces before you click send.
Produktivitetsverktyg, inte läroverktyg
What’s your advice to new developers about using AI tools in the most balanced way?
AI will never be as smart as us — at least not large language models trained on what we’ve said. AGI is a long way off. What co-pilots are really about is productivity. They help you get more done in your day, which means less frustration and better outcomes.
Think of it like the no-code and low-code revolution — Power Platform is great for solving specific business problems without writing custom apps. It didn’t remove developers. It just changed what developers spend their time on. Co-pilots are the same: they help you get to where you need to be faster. Write tests for me. Describe this inherited code. Give me a starting point for an MQTT message broker. They get you to a starting point — but you still have to learn, read around the edges, and validate what comes out.
As a learning tool, it’s okay but not perfect. If you can get to a point where you write code, run it, debug it, and see the outcomes — that’s the golden path. Whether the code is perfectly object-oriented is less important at that point, because the debugging and reading is part of the learning process.
The one thing I’d always say: it doesn’t devolve you of the responsibility to learn. You still have to understand what good looks like. Otherwise you can’t validate what it produces.
AI i healthcare — nyanserna som kräver mänsklig inblandning
You work a lot in healthcare. How does the AI wave affect that area?
Healthcare is a really interesting case because there are things you absolutely cannot do with AI alone. You can’t prescribe. You can’t diagnose with 100% certainty. And you have to be 100% sure when you do either of those things. The litigation risk in many jurisdictions makes this very clear.
But there’s a lot AI can do that doesn’t require that certainty. A patient filling in a form before a consultation — AI can summarize that and send the doctor a note that says: this person has presented with these conditions, it could be one of these five things. That gives the doctor a head start. It’s a productivity tool.
On the back end: GPs use codes when they write summaries. Those codes are standard across the world. AI can translate that into something meaningful and readable for the patient. And automation of follow-up appointments, reminders, referrals — all of that is integration and automation with a layer of intelligence on top.
What we’ll probably never get to is AI as the sole doctor and diagnostician. Pilots are not being removed from planes even with extensive automation systems. Automated vehicles still crash. Humans aren’t out of the loop anywhere we actually need reliability. Healthcare is the clearest example of where you need that human in the loop.
Spännande ny teknik — API Center och real-time intelligence
What are you most excited about from what was shown at Integrate 2024?
Two things.
First, API Center. I grew up working in a large IT services company whose approach was essentially a service catalog — discovery of what services exist and what they do. We had UDDI back in the day, which seemed like a great idea but was clunky. API Center feels like a powerful evolution of that. Open API specifications, ability to test, AI-powered discovery on top of it — it’s a supercharged developer portal. And if you start to imagine globally distributed cataloging of services with AI-driven recommendations and cost-based brokerage and automatic rewiring — that’s a fascinating story for integration’s future.
Second, real-time intelligence and large-scale data volumes — Event Hubs supercharged, moving beyond batch and into real-time decision-making. You can automate 80% of decisions and only escalate the 20% that are exceptions. That intersection of real-time data flow and AI-driven intelligence is where I think the integration community has enormous opportunity in the next five to ten years.
Integration Love Story
Everyone in the integration community has a love story. What’s yours?
It goes back to early in my career. I was working with a big grocery store in the UK on a fresh produce testing problem. The buying managers were waiting three months for test results because everything was handwritten and had to be manually transposed into a database.
The solution was ruggedized PDAs with standard forms — a person fills them in, docks the device, it FTPs the data to a location, and a bunch of intelligence runs off the back of it. That was around 2002, using BizTalk. It was one of those moments where you go: this thing that was almost intangible before — getting data out of the field and into the system reliably and quickly — suddenly just works.
Then at a bank shortly after that, 2004 came out and I spent time building integrations in and out of a Unisys mainframe. That had been incredibly difficult before. Developers were thrown at it for weeks, months, years to solve what was essentially a straightforward problem. With BizTalk 2004 and the early version of Host Integration Server, it just worked. That feeling — you go: that’s amazing.
And more recently — Clemens Vasters posted on LinkedIn about Azure Relay and I commented that it looked a lot like what the old Internet Service Bus was doing, tunneling from one place to another. He confirmed it’s essentially the same product, ten years old. And you think: that is still one of the core things in the Microsoft integration suite. That durability, that ability to reach through to the other side — those are the things that sparked love in me for what we do.
Fråga till näste gäst
What question would you pass to our next guest?
I’m really keen to hear other people’s ideas about the intersection of AI and integration more broadly — not just the tools like Logic Apps and Service Bus, but integration as a concept: how do we bring data from disparate places in ways that AI can make sense of and act on? Building management systems and environmental policy. Healthcare systems and patient outcomes. The data is in the integrations. We can’t make those intelligent determinations without it.
That’s the question: where do you see the intersection of AI and integration taking us — and what does that mean for the role we play?
Thank you so much, Martin. This has been a great conversation and we’re already looking forward to the next session.
Thanks for inviting me. Looking forward to it.
Dela detta inlägg
Fler avsnitt att sätta tänderna i
Integration Love Story med Taylor Poindexter