Integration Love Story with Bill Chesnut
Från BizTalk-födelse till morgondagens Azure plattform – Integration Love Story med Bill Chesnut
Om videon inte spelas, klicka här:
Youtube: Integration Love Story med Bill Chesnut
Spotify: Integration Love Story med Bill Chesnut
Lyssna när vi pratar med legenden Bill Chesnut, en riktig ikon inom integration! Med 21 år som Microsoft MVP och smeknamnet BizTalk Bill är han en av de mest respekterade experterna i branschen.
I detta spännande samtal delar Bill med sig av sina erfarenheter från integrationens frontlinje – från utmaningarna med envisa BizTalk-servrar till de senaste verktygen i Azure. Vi utforskar även strategier för BizTalk-migrering och får höra om de lärdomar han samlat på sig under sin långa karriär.
Med en unik mix av Kentucky-charm och Melbournes innovativa anda bjuder Bill på berättelser, tekniska insikter och värdefulla tips. Missa inte detta avsnitt!
Introduktion
Welcome, Bill, to Integration Love Story. We are really glad to have you here today. Please introduce yourself to our audience.
Thank you very much for inviting me. My name is Bill Chesnut and I’m living in Melbourne, Australia — but I have a slight Kentucky accent, which is a different story.
Från Kentucky till Melbourne via scubadykning
How did you end up in Melbourne?
I started university as a photojournalism major but switched to computers about halfway through. I got involved in a co-op program with the US government and ended up spending 11 years as an IBM systems programmer working on mainframes. Part of that was a posting to Australia, where I met my wife at a scuba diving club in Melbourne. That’s how I ended up back here.
So 11 years on mainframes, then in 1994 I decided it was time to move on. I started doing Visual Studio programming and SQL Server work, then some consulting. I moved to Australia in 2000 and got involved with a company doing Dynamics before Microsoft actually bought them. That led to some integration work using SQL and SSIS.
Then a client came along — a retail store that wanted to collect all their transaction data from Dynamics. Their parent company gave them point-of-sale terminals that didn’t have that capability. I was reading about BizTalk 2000 and thought: it uses message queuing, that’ll handle stores with bad communications — things can queue up if the connection is down. That was how I got started with BizTalk.
BizTalk Bill — ett varumärke föds
How did the BizTalk Bill name come about?
After I came back from the BizTalk 2004 partner training in Seattle, a couple of colleagues convinced me it was time to get on Twitter. They said “BizTalk Bill” and it just clicked. I registered the name and that’s basically been it ever since.
I’ve got a few more years to work, but I’ll probably retire about the same time BizTalk does.
BizTalk 2004 — träningen i Seattle
Tell us about that 2004 training.
Microsoft had approached our company because we were doing .NET training, and there was a BizTalk 2004 partner training in Seattle the following week. It was one of the rooms at the conference center — that big theater room — and it was full. Three or four days of in-depth BizTalk training for the 2004 product, which had been completely rewritten in .NET. A lot of the people who are still involved in the community today were there.
After I came back, Microsoft wanted me to go around and train all the partners in Australia. We put that training material together and went around doing that. Then I did a lot of BizTalk work, a little .NET training, and eventually joined the company I’m with now — Six Pivot — where I’ve been for nearly nine years.
BizTalk i dag — uppgraderingar och migreringens utmaning
How much of your day today actually consists of BizTalk?
Probably a couple of days a month at most. The majority of recent BizTalk work has been upgrading from older versions to BizTalk 2020, because companies’ security teams decided that the old SQL Server and Windows versions were no longer supported. I still have one client I’m deploying BizTalk applications for, but I’m working to get them onto Azure integration.
Varför integration förblir intressant
How do you keep integration interesting when some of the tools are aging?
One of the things that’s kept me involved is that every integration you approach is different. You’re dealing with different systems every time. Companies have moved to best-of-breed products — different ERP systems, different CRMs, different accounting platforms — and someone has to connect those together. As a consultant going into different environments all the time, you’re always solving a slightly different problem. That’s what keeps me enthused.
And actually, the first time you looked at BizTalk — it wasn’t about the technology itself, it was about solving a problem.
Exactly. It was about having built-in queuing. The client had NT4 servers at each store with slow ISDN lines. We needed to pull transactions in and handle situations where communications were down for a couple of days. BizTalk with MSMQ was the right fit for that.
Mappning — det eviga problemet
What’s the hardest ongoing challenge you see in integration?
Mapping the data. I’ve been on a recent project where we’re up to version 14 of the mapping specifications, because the customer keeps changing their mind. And the reason it becomes so time-consuming is that when you’re pulling data from SaaS products, everything is deeply interconnected in ways the customer didn’t expect. They think things are connected one way, and when you dig into the data they’re connected completely differently. And that comes down to how well companies know their own systems — they know how to use them, but they don’t understand how the data is structured underneath.
The first thing integrators should do is go in and ask whether the customer truly understands their data. Map the full picture together before you touch anything else.
Den märkligaste integrationslösningen
What’s the weirdest integration request you’ve received?
One of the consistent challenges I see — rather than a single weird request — is customers who insist on ordered delivery of messages. The real problem isn’t the ordering itself, it’s how to handle failures without stopping everything. In high-throughput systems, you can’t let one failed message halt the entire flow just to maintain order.
One approach I’ve used lately is to pass just the ID of what changed, and have the receiving system call back to get the current record. That way, even if you’ve had five or six changes processed out of order, it always gets the latest version. But convincing customers to accept that model rather than sending all the data in the message is its own challenge.
The genuinely strangest thing I worked with was pulling data from a system that was never designed to be externally referenced — no API, nothing. Someone from the company built a stored procedure to expose the data. It was 50 pages long. When things broke, you had no idea where to look. And occasionally they would change a field that was common across all items, so instead of getting a few hundred changes a day, you’d suddenly get 600,000.
BizTalk-migreringens verkliga utmaning
What’s your take on the challenge of migrating away from BizTalk?
I think this is the most underestimated challenge in the industry right now. If BizTalk 2020 is the last version, we have roughly five years to move that workload somewhere else — probably less, when you factor in the surrounding systems going out of support too.
The biggest problem I’ve seen is that when companies announce they’re migrating off BizTalk, the BizTalk people leave. And then they have no one who understands what BizTalk was doing. BizTalk is so good at what it does that it just sits in the corner running. No one touched it because it worked.
A one-to-one migration doesn’t make sense in many cases. You really have to understand what BizTalk is doing first, and then match that to the right Azure tools — Service Bus, Logic Apps, Functions, or something else entirely. And you also have to look at the newer systems being integrated, because some of them have absorbed functionality that BizTalk used to provide.
What’s the first step a company should take?
Document what you have. That’s the critical first step. Once you know what BizTalk is actually doing, you can start seriously evaluating whether Service Bus solves part of it, whether Logic Apps handles the orchestration, whether Functions covers the file movement. But without that documentation, you’re flying blind — and that’s exactly what got some companies into trouble.
There’s good news on that front: recent additions to Logic Apps standard — support for maps, map helpers, XML as a first-class element, AS2, EDIFACT, and X12 — are making many of these migrations more realistic. But you still need someone who understands what BizTalk was doing in the first place.
Integration Love Story
Do you have a moment where you actually fell in love with integration?
Pretty much from when I jumped into the PC world. I worked for a company doing shipping systems — a customer would tell you where the package was going, you’d scan the barcode, and the system would find the cheapest carrier. It wasn’t called integration at the time, but that’s what it was. You loaded all the different carrier data in and brought it together.
With BizTalk, especially the 2004 release, it was just a much more featured environment. It was easier to do things. What’s kept me here is the problem-solving side of integration. Every problem is slightly different, and that’s what I enjoy.
Integrate 2025 i London och Hamburg
You’ll be speaking at Integrate 2025 in London. Can you give us a hint of what you’ll cover?
EDI — AS2, EDIFACT, and X12 with Logic Apps standard. I’m going to show a system I built in Logic Apps consumption that uses Key Vault as a configuration store. When a message comes in, it goes to Key Vault to look up the sending partner, the receiving partner, and the message type — and from that it determines what maps to apply, where to send the message, and how to send it. It’s all configuration-driven, so you build one system and just add to it with configuration and maps rather than creating point-to-point Logic Apps for every scenario.
And then I’m going on to Hamburg the following week, where I’ll talk about using Liquid Maps outside of Logic Apps — in Functions, websites, and other contexts.
For me it’s a 16-and-a-half hour flight from Perth to London direct, plus three-and-a-half hours from Melbourne to Perth. If I’m going that far, I’m staying more than two days.
Livet utanför integrationen
What does BizTalk Bill do when he’s not working with integration?
I used to do a lot of scuba diving, though not as much lately. We’ve got a fairly large property here in Australia with the backyard planted in natives, so there’s always work to do around the house. I grew up on a small farm in Kentucky, so I’m used to that kind of work. I’ve just bought a new four-wheel drive and I’m fixing it up for trips around Australia. When I was here on my US government posting, I did a 30-day camping trip in the Northern Territory. My wife wants me to take her back to all those places.
Fråga till näste gäst
Who should we talk to next, and what question should we ask them?
Have you talked to Mick Badran yet? He’s a BizTalk guy who started around the same time I did, based in Sydney — and he’s doing Azure integration work now too. Shout out to Mick.
And the question I’d challenge the next guest with: how do you work with your customers to get them into the Logic Apps designer experience? Because a lot of development teams don’t like the visual designer and immediately default to Functions. Net developers are used to writing code, and it was the same challenge early on with BizTalk — drag and configure instead of writing code. That tension between visual and code-first is one of the real challenges in integration right now.
Thank you so much, Bill. We’re looking forward to seeing you in London.
Definitely see you in London. Thank you.
Dela detta inlägg
Fler avsnitt att sätta tänderna i