Skip to main content

Integration Love Story with Michael Stephenson

I detta avsnitt pratar vi med Mike Stephenson, en av världens främsta integrationsexperter och Produktägare på Kovai.

Mike Stephenson, en av världens främsta integrationsexperter och Produktägare på Kovai.

Om videon inte spelas, klicka här:Integration Love Story med Mike Stephenson

I den här episoden av Integration Love Story välkomnar vi Mike Stephenson, en av världens främsta integrationsexperter och Produktägare på Kovai. Mike delar med sig av sin inspirerande resa från de tidiga dagarna med BizTalk till att bli en ledare inom Azure-integration och berättar om de utmaningar och framgångar som har format hans karriär. Han diskuterar sin övergång från konsultverksamhet till produktutveckling och hur det är att leda inom Turbo 360, ett verktyg som för hans praktiska kunskaper till produktdesign.

Under samtalet ger Mike insikter om Azures utveckling, integrationens betydelse av gemenskap och vikten av kostnadshantering. Hans passion för innovation sträcker sig också till hans fritidsintressen, där han berättar om hur golfdata väcker hans intresse för teknik.

Transkribering

Introduktion

Welcome, Mike, and thank you for joining us today and giving us your time. Can you please tell us about yourself and let the audience know more about you?

Thanks for having me. My name is Mike Stevenson. I’m based in the northeast of England, in Newcastle — about 100 miles from Edinburgh and 300 miles north of London.

From a technology perspective, I’m a long-term integration person. My first integration project was with BizTalk 2000. Over the years I developed working on BizTalk projects and got to know a lot of the BizTalk community — people like Saravana, Yosi, Dawn. We all worked on a huge project in the UK together, which really got me into the community side of things, blogging and everything that came from that.

Then I moved to do a big integration project with a customer in London — that was where I first got into Azure when it was still in preview. Being tech lead on one of the first big early adopters in the UK got me a bit ahead of the game. We were doing real-world stuff when other people hadn’t even started hearing about it beyond user groups. That accelerated my career significantly — being in the right place at the right time.

From there I kept going with the community work and have pretty much done Azure integration ever since. I did a lot of advisory work with Saravana and Kovai for a few years, helping with product direction and helping their customers understand how to use what Kovai builds. Then last year I moved from consultancy to product — I’m now the product owner for Turbo360. It’s brought a lot of new things: product development, sales, marketing, more business focus. But I still get to keep a foot in consultancy and the real-world integration questions customers have.

Golf, data och simulatorer

The previous guest, Kent, passed a question to you: what’s your favorite shot in golf?

Let me give some background first. At school I never touched a computer — I was much more into football and golf. Around 16 to 18 I was quite a good golfer, played at regional level. Then university, life changes, and I drifted away from it.

I came back to golf about two years ago. Post-COVID, I needed a hobby. But what I really discovered I loved was golf simulators. They add a whole new dimension. Every shot I hit, I get a visualization on screen. There’s a radar device that scans the shot and gives you around 50 statistics per hit — clubhead speed, launch angle, spin rate, everything.

What I found is that the data completely changes how you learn. I used to hit a bad shot a certain way and always thought I knew why. When I started using data with a pro, I realized the reason was the opposite of what I thought. That’s actually very similar to what we do in integration — the data tells you the real story, not the assumption.

Golf as a sport is all about compensation. Unless you’re Tiger Woods, you don’t swing the club perfectly — your body compensates. You learn from the data what your compensations are and how to manage them. I also know exactly to the yard how far I hit every club, which means I can play tactically even if my swing isn’t what it used to be.

I’ve also got a wrist device that monitors pronation and supination as you swing — it connects to a phone app, which connects to the cloud, where they have big data analysis of tour players. The app also connects to Trackman for shot tracking. It’s all integration. But it’s integration you can physically see and feel.

My favorite ever shot — I was on a par four, my second shot, with an eight iron. I holed it for an eagle. On one of the hardest holes on the course. I’d just had pars and a birdie on the holes before, so I went 5-4-3-2 over four holes. That’s probably my favorite shot.

And a course I’d love to play — either with Kent in Banff near Calgary, which I remember from an old Arnold Palmer golf game as a kid, or the golf course next to the pyramids in Egypt.

Att kommunicera integrationsvärde till verksamheten

Kent’s second question: what would your advice be for integration teams to better position the value of integration?

The first thing is know your audience. The value of integration is really difficult to articulate. No customer ever says “I want to do an integration project.” They say “I want to deliver some business value and it happens to need integration.” So you have to remember: the customer doesn’t really want to do integration. And a lot of the time they have a negative experience of it — it’s hard, it costs money, they always hear about the errors.

What you want to get to is a place where integration is seen as a key differentiator from the competition. If you can do integration cost-effectively and with quality, there’s a good chance your competitors can’t. The value is in time to market, flexibility, the ability to change as requirements change.

But none of that matters if nobody knows what you did. That’s where communication comes in. You have to tell your stakeholders about the things you did that added value — because all they ever hear is the complaints. I remember a BizTalk example: we had a massive unexpected spike of messages. Instead of throwing new servers at it, we redistributed host instances across the group, processed the backlog in a couple of hours, and then put everything back. No downtime, no extra hardware. But I had to sit down with the customer and explain what had happened — because the non-technical people had no clue what we’d done. Once I explained it, their view of the integration platform completely changed.

The equivalent in Azure would be the burstable plan on Logic Apps — it scales out, handles the load, and scales back in. Microsoft has made that almost invisible. But if you don’t tell anyone what happened, all they ever hear is the negative.

Tell people about cost savings too. When people only ever hear that the bill is getting bigger, it becomes the thing they don’t like. But if you tell them “we identified this and saved you X per month,” they start asking how they can do the same thing elsewhere.

Kostnadsmedvetenhet och integration

You focus a lot on cost now. What’s your advice for integration teams to get on top of costs?

Most people review costs only when senior management complains about the bill size — and even then, they look at it at such a high level that it doesn’t mean anything. “We spent 100,000 this month” — okay, but that’s spread across how many teams and applications?

What I’d suggest is making cost a regular part of the sprint retrospective. At the end of each sprint, look at current running costs for dev, test, and production. Can we take any items into the next sprint to optimize?

One thing I’ve noticed is that people deploy something and never come back six months later to check if they deployed the right size. The team that built it might not even exist anymore. And you find apps running at 10% of what they were scaled for.

If a customer spends 100,000 a month on Azure and 20 to 25% of that is inefficient — that’s 25,000 a month that could be reallocated to building new integrations. But you need to surface that conversation, and you need to frame it in terms of value: “here’s what we saved, here’s what that means you can do with the money instead.”

Integrationen som ett val av rätt verktyg

You’re well known for your content on “where do I use what.” Why does that resonate?

Because there are always lots of people talking about how to do a specific thing with a Logic App, but fewer talking about why you’d choose a Logic App over a Function — or when to combine them with API Management. Those are the decisions that really determine whether a project is successful.

A developer might focus on what they’ve done before or what skill they want to learn. But they’re just one stakeholder. Someone else has to run the solution for five years. Someone else will change it in two years. Someone else will test it. You’ve got to think about all those people when you make an architecture decision.

The answer always depends. But if you can rule out options — for instance, “we have no .NET developers so let’s use Logic Apps” — you narrow it down. Then it becomes consumption versus standard, and so on. Working through that decision tree is what I find interesting.

Integration Love Story

Do you have an integration love story — a moment where you actually fell in love with it?

I’ll tell you about the time I made myself redundant.

On that big UK NHS project where I first met Saravana and Yosi, one of my jobs was HL7 messaging. We had to parse and transform HL7 messages in BizTalk. Every few days we’d get an updated specification document and a large XML extract of all the message definitions, and we’d have to go and manually update all the maps, parsers, and everything. It was incredibly tedious.

One day — I think it was in the shower — I had a moment. I went in the next day and said to my colleague: I’ve got this crazy idea. Tell me it’s stupid or tell me it’s genius.

Instead of building maps to transform the messages, we built a transform tool that took the specification document and the XML extract as input, and the output was: maps for every message type, parsers for every message type, sample messages for every possible combination, and NUnit unit tests for every test scenario. Automatically. Click a button, two minutes later you have 2,000 sample messages, 2,000 unit tests, a complete new set of maps — all passing. Deploy and you’re done.

We went from spending days doing repetitive manual work every time a new spec came in, to a click of a button and a deployment task. We called it “the one map to rule them all.”

And then we got moved onto other, much more interesting projects.

The love moment for me was the idea itself. Just thinking about the problem differently. We were so focused on how to solve the thing in front of us — but when I stepped back and thought about the problem at a different level, the solution became obvious. That was a real level-up moment in my career. I realized I could think bigger than I had been.

Frågor till näste gäst

What questions would you pass to the next guest?

Three questions.

First: what is your favorite thing in Azure to use and why? Second: what is your most memorable mistake that you’re allowed to share — as an integrator, what happened and what did you learn from it? And third: what is your most memorable success story that you’re allowed to share — why did you enjoy it and what stood out?

Thank you so much, Mike. Always a pleasure and definitely not the last time.

Yeah, great to see you both. Take care.

Dela detta inlägg


Post author image.

Författare: Robin Wilde

Sales and Marketing

Fler avsnitt att sätta tänderna i