Integration Love Story with Steef-Jan Wiggers
Steef-Jan Wiggers, en av Nederländernas främsta integrationsexperter och specialist inom molnteknologier samt expert på hållbara integrationslösningar.
Om videon inte spelas, klicka här:
Youtube: Integration Love Story med Steef-Jan Wiggers
Spotify: Integration Love Story med Steef-Jan Wiggers
Följ med i detta insiktsfulla avsnitt av Integration Love Story där vi välkomnar Steef-Jan Wiggers, en erfaren integrationsspecialist från Nederländerna. Steef delar sin personliga resa, om att övervinna personlig förlust och hitta balans i livet. Professionellt går han på djupet i sin roll inom integration och molnteknologier, där han lyfter fram sina bidrag och värdefulla erfarenheter inom sport och dykning.
Steef berättar ingående om sina äventyr i BizTalk-världen, verktygen och knepen han använt, sina omfattande migrationsprojekt och sin syn på hur integration möter hållbarhetsarbete. Han diskuterar även FinOps och vikten av att vara både kostnadsmedveten och grönmedveten i dagens molnmiljöer. Missa inte hans minnesvärda integrationsframgångar och hans insikter om hur man designar effektiva och hållbara integrationslösningar.
Lär känna mannen bakom expertisen, hans bidrag till integrationsgemenskapen och hur hans personliga intressen inspirerar hans yrkesliv. Perfekt för teknikentusiaster, integrationsspecialister och alla som är intresserade av framtidens molnteknologi
Introduktion
Hello, Steef-Jan. Welcome to Integration Love Story. Thank you for joining us today.
Thank you for having me — I’m privileged.
For our audience, we have been following you for years, but can you please introduce yourself?
I’m Steef-Jan. I’m from the Netherlands. I’ve been visiting your country, Sweden, quite a while. My background is of course integration. Personally, I live in the center of Holland, near a national forest called Hoge Veluwe, so it’s pretty green around me.
I have two dogs and three kids. My wife, as you know, has passed away a year or so ago, so I’m what they call a single dad. Fortunately I did find someone new in my life as well, and she lives close by, so that’s nice to have.
My day-to-day job is integration, and I also write for InfoQ — a media site focused on cloud technology, culture and methods, architecture, programming languages, and machine learning and AI. I predominantly write about the cloud.
Thank you for mentioning your private life. You’re an amazing example of how life can go on and how to find balance despite hard times.
Yes, I’m definitely doing well.
Sport, naturen och livet utanför jobbet
You live in a green area — what do you do when you’re not writing about integration?
I’m very active in sports. I play field hockey, not ice hockey. I also run frequently — I have a half marathon and a full marathon coming up next year. And the other thing I like to do is diving. I got certified last year in Hawaii and I’ve joined a dive club. In January I’m going to Bonaire.
Do you run with or without music?
Always with music. I have AirPods and a playlist. I don’t want to hear my own thoughts, so music is very comforting.
Favoritverktyg i Azure
What’s your favorite Azure tool?
Since I’m an old man — Visual Studio. When you do Logic Apps consumption you can still pull that template off and do some things, but predominantly these days it’s Visual Studio Code. I still write some functions for my integrations and Visual Studio is still the best tool for that.
Other tools that are very useful: Storage Explorer is a great one. Service Bus Explorer — I’ve used that for many years, partly now embedded in the portal experience, but Paco de la Cruz’s on-prem version is still one of the best. And Postman, though that’s not really an Azure tool, more for testing APIs.
And Copilot for AI?
I haven’t used generative AI that much yet. ChatGPT can definitely help you jumpstart documentation, like architecture decision records — you put some input in and then revise it and add your own thinking. But that’s about it so far.
Det mest minnesvärda misstaget
Do you have a memorable mistake you can share with the community?
One bigger mistake is when you’re building an integration supporting a complex process, and you end up with one big Logic App — similar to what you could have done with BizTalk back in the day, building an orchestration that’s several pages long. That’s not correct. Because you’re so focused on solving the problem and getting the complex thing running, you tend to shortcut it by putting everything into one single Logic App. It becomes hard to debug, hard to maintain.
Eventually you realize you need to zoom out and cut up your process into smaller pieces. One Logic App can call another. Defragment it. Make it less bulky.
What you learn from that mistake is to step back, look at the problem, understand the process, and think about how to split it up. We did eventually restructure it, and the result was much easier to debug and maintain. Yes, you create some dependencies — your master Logic App needs its dependent ones deployed first — but the trade-off is worth it.
Part of the mistake was also that the process wasn’t entirely clear from the start. We began building anyway and created a monster. So the advice is: have a good understanding of the process itself before you start building, even if the customer doesn’t fully understand it yet.
Det framgångsrika migrationsprojektet
Can you tell us about the successful migration project you presented at Integrate?
We migrated a retailer’s message broker — similar to BizTalk — to a cloud solution. We started very small, thinking about how to move data from A to B.
We looked at BizTalk Server’s phases and thought about using something like a claim check pattern combined with pipes and filters — each function doing its own thing. One does validation, one does transformation, one handles the EDIFACT conversion. We leveraged Event Grid as a way of notifying the next service that it needs to do something, and the payload is always taken from a container.
That paradigm became very flexible. Besides transformations you can also do other small steps inside a function. You can chain them together in any order because each one is small — a microservice-type architecture. You can have five functions or ten, as long as each function does its own thing. Single responsibility.
The setup was very robust and able to handle large workloads with low latency. With Azure Functions — compared to Logic Apps at the time, when Standard was still in preview — we had more flexibility for dimensioning and sizing the compute under premium or dedicated plans. For big workloads where you need to process fast, that matters.
Did you deliver it on time?
Absolutely not in one go. We chunked it up into different parts based on domains — products, pricing, shelf life. We built one domain, deployed it, learned from it, then took all that experience to the next domain. Like eating an elephant in small pieces.
Team, roller och framgångsfaktorer
What made that project successful in terms of team and roles?
We had an integration architect who was also partly a product owner — in contact with the business and aligning developers on what to build and prioritize. Within the team we had engineers building integrations, one person focused on CI/CD and deployability, and someone handling the ops side because bugs need to be solved in production too.
Critically, we also had two functional consultants who were very well versed in how retail businesses work. They were available 24/7. When we were facing a retail-specific issue we didn’t understand, we could call them immediately and they’d say “oh yes, that field means this” or “this needs to be mapped because of this.” That instant access to people who understood the business processes was a critical success factor.
We also created a culture of no blame. If something went wrong, we learned from it and moved forward. That’s part of a good DevOps culture. That’s why the team worked so well.
Hållbarhet och integration
You spoke about sustainability in integration at Nordic Integration Summit in Stockholm. Can you summarize that talk?
I talked about green IT in the context of integration. When you’re building solutions and running workloads across environments — development, test, acceptance, production — you can think about which workloads need to run continuously and which can be spun up and torn down. Not wasting resources.
Consuming in the cloud means consuming compute, which means consuming energy. That energy can be more or less dirty depending on the cloud provider and data center location. Sweden, for instance, has some of the greenest data centers.
Serverless is naturally good for green IT because it scales up and down automatically. Running workloads at times when green energy is available is another lever — though of course that’s hard to do with real-time or business-critical processes. Batch processes are more flexible.
The point is to bring these considerations into people’s minds when they architect and engineer solutions.
Why should companies put this on the agenda?
Because it connects to FinOps. When you build cost-aware solutions that run only when they need to, you indirectly also become greener. FinOps and green IT go hand in hand.
Where should people start?
The Green Software Foundation — greensoftware.foundation. It’s a free website where you can read about the foundational concepts and even get certified. That’s a great starting point.
Integration Love Story
Where did you fall in love with integration?
If you’re into backend systems and processes, you start to fall in love with the fact that you’re allowing systems to communicate. I even did a session once called “Let Systems Communicate.” That’s what I love about integration — systems can exchange information with each other, and as an integration person you can make that happen. A lot of what companies face day to day is fundamentally an integration problem.
Do you have a specific story?
Yes. A project I’ll call the taxi project. The Dutch government decided that taxi drivers needed a personalized card that registered when they were driving and when they were resting — to prevent them from driving 24/7 without rest, which is a safety risk.
The process required checking whether the person actually lived in the Netherlands, whether the car was insured, whether it had a valid license plate, and whether the person had a driver’s license. If everything checked out, an encrypted message was sent to the manufacturer of the personalized card, which was then created and ready for collection.
Building that integration meant calling out to different government agencies. We also had to work with encryption that was not natively supported in BizTalk at the time, so we used third-party components for the encryption and decryption.
We got it done. And then we were ready to go live — but the certificate authority got hacked, which was big news at the time. We had to wait three months for a new one. Eventually we went live.
It was a complex, amazing project. Imagine what that process looked like before the system: someone physically running between government offices with paper forms.
Fråga till näste gäst
We’d like you to suggest a question for our next guest. What would you ask?
What integration pattern do they use the most, or which integration pattern from the enterprise integration patterns book by Gregor Hohpe did they apply in a project they really loved? And why?
Integration patterns are always interesting. I’ve actually met Gregor in London and recently again in San Francisco. He wrote an amazing book, and the patterns in it underpin so much of what we do. I’d love to hear which one resonates most with the next guest.
Thank you so much, Steef-Jan. This was an amazing conversation.
Thank you. It was a privilege to be here.
Dela detta inlägg