Integration Love Story with Massimo Crippa

Introduktion

Massimo, please take the mic and introduce yourself to our listeners.

Hello everyone. My name is Massimo Crippa and I’m an Italian guy living in France and working in Belgium. So I’m a little bit lost between countries.

I started working in 2001 in a consultancy company, and I’ve been in the consultancy business since then — working 100% with Microsoft technology. The first 10 years I saw a lot of different technologies: I started with front end, then moved to back end, did a lot of SQL and SSIS, then the SharePoint wave — which I somehow hated. And then there was my lovely story with BizTalk.

I moved from Italy to Belgium in 2011, when the cloud trend was just emerging. Belgium, the Netherlands, and the Nordics were among the first to jump into that wave, and I wanted to operate in a market that was more open to the cloud.

I joined Codit, and at Codit I’ve done different things: integration architect, then leading the API management domain, then application innovation, and since 2020 I’m lead architect.

And where exactly are you located in France?

I’m in a city called Tours, in the Loire Valley — where there are a lot of castles and wine. The view from my window is not bad.

Kulturella skillnader — Italien, Belgien och Norden

You mentioned it was a big difference between the Italian approach to the cloud and the more northern European one. Can you tell us about those international differences?

Technically, I believe it’s the same everywhere — every country has brilliant minds and access to the same technologies. The dynamics in big enterprises or small customers are also similar. The needs are the same.

What I believe is extremely different is the cultural approach to business. What I loved about my experience in Belgium and northern Europe is a very direct, almost American-style approach. In Italy, culturally — starting from school — we are really used to dedicating a huge amount of time to context before getting to the point. It’s the way we grew up.

If you compare an email from an American colleague with one from an Italian or a French colleague, the American email goes straight to the point. The Italian one is far more formal, with much more context. It’s not better or worse — it’s just a different cultural style, and it also affects management styles.

Livet utanför tekniken

What do you do when you’re not thinking about technology?

I am extremely busy with two girls — three and a half and six years old. They really keep me busy and are responsible for most of my gray hair. I’d say 30% from my wife, 70% from the kids.

Logic Apps vs Azure Functions — när ska man välja vad?

Our previous guest left a question for you: when should you use Logic Apps and when should you use Azure Functions?

I’ll answer in a slightly sideways manner. Why limit the question to only Logic Apps and functions? There are many other ways to do integration. You could use Azure Container Apps, Dapr workflow with Logic Apps connectors, and so on.

That said, the real answer is: whatever tool fits the customer need and delivers the value. I don’t care about the tool — I care about the outcome.

When it comes to Logic Apps versus Azure Functions specifically: Azure Functions are often used alongside Logic Apps to externalize business logic where you want more control. One of the main reasons to choose Azure Functions is the serverless scaling model, and the other is the binding framework it brings. But you can achieve similar things with Azure Container Apps if you prefer a containerized environment.

The added value of Logic Apps, in my view, is first the number of connectors, and second the monitoring and observability that comes out of the box from the workflow engine. Maintainability and flexibility are also factors — in Logic Apps you can change small components more easily, whereas in Azure Functions a small change often requires going much deeper.

Vem fattar teknologibesluten?

Who should be responsible for making technology decisions?

It depends entirely on the environment. If technology decisions have already been standardized, you adhere to those standards. If you’re in a greenfield, you work from key principles — whatever principles make sense for the customer: scalability, unit of scale, security, isolation, budget. Those should drive the decision.

Normally the technology choice belongs to the solution architect, not the enterprise architect — unless the enterprise has enforced a specific technology stack for security or other reasons.

Too much freedom can be as dangerous as too little. And innovation always has to work within constraints.

Den märkligaste integrationslösningen

What’s the weirdest or most unusual integration request you’ve ever received?

The weirdest thing I ever did wasn’t integration — it was a filter for ISA Server in C or C++, which was completely outside my comfort zone. I still bring it up in conversations because it was such a clear lesson: never take on something that’s 300 miles out of your comfort zone.

For integration specifically, the strangest tool I ever used was BizTalk 2002 or 2000 — before the .NET era and the 2004 rework. I had no clue what I was doing, there was almost no documentation, just old paper manuals. I was clicking around in trial and error. That was its own kind of strange.

And something that has hit me on many integration projects: APIs that return HTTP 200 with an error inside the body. Every time. Still happens.

Logic Apps hybrid — tidig adoption och varför

You’ve been producing content about Logic Apps hybrid deployments and are one of the early adopters. What made you look into it?

First, I’m a big fan of Kubernetes. When I saw it was possible to run Logic Apps on Kubernetes, I wanted to understand how it worked and whether it was easy to maintain and scale. The first trigger was pure curiosity.

The second trigger is that I’m not a big fan of the standard Logic Apps unit of deployment and unit of scale — specifically the App Service Plan and how you manage density. I wanted to see if moving the workload to Kubernetes gave more flexibility.

From a business perspective, hybrid solutions will stay relevant for a long time. Industries like manufacturing have specific on-premises needs. Banks and insurance companies have mainframes that aren’t going anywhere — they work, and they’re hard to remove.

Logic Apps hybrid also addresses a fundamental integration principle: integration should run close to the systems it integrates. This model allows that, while also giving an answer to other vendors that already offer hybrid solutions. Microsoft was previously only offering something that ran in the cloud, and this achieves a kind of feature parity.

Molnet, reglering och offentlig sektor

In Sweden, there’s a lot of interest in this from government and public sector — but everyone seems to be waiting for someone else to take the first step. How does it look from your side?

It’s the same story in every country. Highly regulated sectors like law enforcement have real needs for local data processing — not just residency, but truly keeping things in their own data centers with the ability to disconnect if needed.

The benefits of the cloud are clear: instant infrastructure, security, performance, continuous updates. Building all of that yourself costs a huge amount of money. Those are the classic drivers to move to the cloud since day one.

But if companies are still reluctant, there’s usually something blocking them — regulation, or a specific business requirement. Not everything has to go to the cloud. Some applications are better in the cloud, and some are better where they are. There’s no business value in migrating everything just for the sake of it.

Det mest minnesvärda misstaget

What’s your most memorable mistake in integration, and what did it teach you?

Let me answer from a soft skills perspective, because we’ve talked a lot about technology.

Years ago I was assigned to assess a very old integration application — integrating obsolete systems. Nobody wanted to touch it. No documentation, completely a black box, but a huge amount of business transactions flowing through it. And it was summer, so everyone was at the pool. Just mentioning the name of the application made people run away.

My assignment was to understand what was there, assess the risks, and figure out how to replatform it. And with zero technical support around me, I started asking myself: if nobody cares about this application, why should I?

That was not a good approach, and it was a failing approach. The lesson I learned is that leadership is not about following the crowd. It’s about getting the bigger picture, taking responsibility and ownership of the situation — even if it’s messy, even if you’re alone, even if everyone else is at the swimming pool. Roll up your sleeves and drive the change.

Integration Love Story

Do you have a story — a specific project or moment — where your love for integration sparked?

My story with integration started a long time ago in Italy, when I first encountered BizTalk and enterprise integration patterns.

One of the things I remember, even if it might not sound the most romantic, is working with ANSI X12 and EDIFACT. It was challenging — almost no documentation, just the early days of Microsoft in that space. You got the challenge, you had to get it done, tested, and rolled out.

That experience brought me close to the integration world. And at that time, BizTalk was emerging — there weren’t many technical people working on it. So it was rewarding to work on something niche. There were only a few people in the Nordics and a few in Italy doing this. We were building the community. And it’s really nice to feel like you’re part of a community that’s being created.

And the EDIFACT experience — at first it looks completely incomprehensible, just codes and signs. But then something clicks and all of a sudden you can read it. You see an error, you look at the EDIFACT message, and you know exactly what it is and where the problem is. Like the Matrix — you learn to read through the code.

The downside is that after a long time on those kinds of projects, you start dreaming in EDIFACT.

Integrate 2025 i London

You’ll be speaking at Integrate 2025 in London. What’s your session about?

I’ll be doing a session about API management and Microsoft Fabric — specifically how to do fraud detection using those two tools together. I have a long history with API management, so I had to bring a topic connected to it.

The integration community is something special. In other communities — data, cloud, general Azure — they tend to be more regional. But the integration community is one global community. You start knowing people in Gothenburg, then Sweden, then the Nordics, then Europe, then you talk to someone from Australia and you’re discussing the same things: EDIFACT, BizTalk, the same patterns and challenges. It’s a small pond, but it connects the whole world.

Förberedelse inför ett föredrag

What do you do in the 24 hours before going on stage?

The preparation is done well before — building the session, refining the message, making sure it’s properly put together. The 24 hours before, everything is ready. I just enjoy the journey to the conference. And if there’s a live demo, I check that everything works and ask the demo gods kindly to cooperate.

Fråga till näste gäst

Who would you suggest as our next guest, and what question would you challenge them with?

I’d like to invite my great friend Toon Vanhoutte to the show. And the question for Toon would be: should we create an API-based solution on top of messaging — for example, an HTTP interface on top of Service Bus or Event Grid — or should we continue to use brokers directly using their SDKs?

Thank you so much, Massimo. This has been a really nice conversation and we’ll definitely see you at Integrate in London.

Thank you everyone. It was a pleasure to be here.