Integration Love Story with Robert Mayer

Introduktion

Robert Mayer, welcome to Integration Love Story. We’re pleased to have you here. Our listeners want to know who you are and what you do — and also, what is that light in the background?

My name is Robert Mayer. Professionally I work as a solution architect, integration architect, and application architect across different areas. On a private note: father of three kids, two dogs, one wife, one house.

The light behind me is my kebab sign — a souvenir from Greece. The last night of the trip I realized I had no souvenirs, and on the way home I spotted a kebab sign. My wife said no, so I installed it in my office. The fun thing is you can actually see it from our living room while watching TV. She hates it. But I have the key to the office, so it stays.

Vägen in i integration

Can you tell us about your history in the integration area?

I started as a web developer. During my computer science studies I got in touch with a company focused on system integration, and that became my first real job — developing NoDenite, which is a product for integration management. That was my first step into integration.

I worked there for a couple of years, then moved to a company with 10,000 employees where I had the opportunity to work not just on product development but with different customers of different sizes. I got to see how you convert business ideas and challenges into integration solutions. That was one of the best periods of my professional life — working closely with the business side to develop integrations.

From there, integration has become more mature and my current focus area is integration observability. It’s interesting because I started looking at integration from the outside, then dove deep into the world of different solutions and different businesses, and now I’m coming back to observing integration from the outside again.

Minnesvärda misstag

Do you have any memorable mistakes you’d be okay sharing?

I love mistakes — I think it’s the only way I learn new things.

The first one: I was responsible for installing BizTalk and felt something was wrong with the firewall. So I turned the firewall on. Suddenly Remote Desktop stopped working. I thought it would just sort itself out — but it became quite a significant incident. The infrastructure team got involved, consultants were brought in, and nobody knew what had happened. It cost a lot of money, and I wasn’t even fully aware of the scale of what unfolded because I was only the person who had installed BizTalk. I didn’t take it seriously at the time, but it made me aware that a small action on my side can have enormous consequences and costs for others.

The second one was before I even got into integration. I was developing apps for large companies on Facebook — when that was still a thing. I designed a competition where people could win seats to something. I developed it incorrectly, so there was a logical flaw that only one person figured out. He won all 20 available seats by himself because of my mistake.

At the time I didn’t take it seriously. A couple of years later I realized this had cost real money. The lesson I carry with me: something that feels small to me can be enormous for someone else.

Both of those moments are things I think about a lot now when I work with observability.

Affärsvärde och varför integratörer behöver komma närmare verksamheten

You moved from web developer and application developer to being much more business-oriented. How do we as integrators take steps toward the business side?

It takes confidence and trust. The business needs to understand what you’re doing, and that means investing time in understanding their domain. It goes both ways — neither side usually has enough time — but once you earn the trust, the value you can add is enormous.

The upside is that you start creating solutions based on business needs without them needing to spell out every detail. You become proactive. And I think one of the most frustrating things for the business side is having to go to the integration team and tell them what to do. What they actually need sometimes is someone who can tell them what they need.

No one cares how fast you write code or how clean your pipelines look. What matters is the value it creates. Once you’re genuinely interested in that value, a lot of other problems solve themselves.

And right now with AI — everybody wants to invest in it but doesn’t know where it will create value. If you understand the customer’s domain, you can show them exactly where AI adds value. That’s where you become indispensable.

Open Telemetry — det stora intresset

Where does your focus on integration observability come from, and what is Open Telemetry?

Open Telemetry is a unified, standardized way for you to get control of your application performance. Think of it like your car dashboard — you have a speedometer, a fuel gauge, warning lights. Open Telemetry gives you the same kind of control over your applications: response times, number of requests, error rates, whatever you need to measure.

The important thing is that it’s a protocol, not a visualization tool. It’s the data layer underneath. And for the first time, we have a standard for this — similar to how REST APIs became a standard that we started requiring from all software.

Before Open Telemetry, every platform had its own monitoring tool. Azure has Azure Monitor, BizTalk has BizTalk 360 or No Deni, Mulesoft has its own analytics, AWS has something else. When you choose a platform, you’re also choosing its monitoring ecosystem — vendor lock-in.

With Open Telemetry, you’re not locked in. You can send your observability data anywhere: Splunk, Grafana, Datadog, whatever the business is already using. You don’t need to teach them a new tool. You send the data to where they already work.

This matters especially in multi-cloud scenarios — where data might start on-premises, flow through Kafka, enter Azure, and be processed by multiple microservices. Looking only at Azure doesn’t tell you the full story. Open Telemetry lets you observe the entire flow across boundaries.

In Open Telemetry there are three core signals: metrics, logs, and traces. Metrics are like counters — number of messages received, number of failed messages. Logs are what we’re already familiar with. Traces let you follow a single message or transaction across multiple systems and services to see exactly what happened.

Sesspionen på Nordic Integration Summit

Your session at Nordic Integration Summit was about monitoring integrations using Open Telemetry. What was the main message?

The main point was simply to make people aware that this exists and what it means. Integration has been a black box for so many years. Open Telemetry is a way to open that black box and expose that data — to a tool the business already uses, in a standard format, without vendor lock-in.

The response was great. For many people it was an eyeopener.

And importantly: if you’re paying tools like Splunk or Datadog, they charge for data ingestion. They want you to send everything. Open Telemetry gives you the ability to filter — you decide what data is valuable enough to send, and you control the cost.

Var du börjar med Open Telemetry

For someone who doesn’t know where to start?

Start simple. Set up a visualization tool — Grafana works and you can run it locally on Docker. Then send it something: a simple counter. Number of messages received. That’s it. Add the meter to your integration, let it send data, and visualize it. A simple graph showing how many messages you’re receiving per day.

It doesn’t need to be complex. Take a small step, see how easy it is, and build from there. The complexity is always tempting — we want to solve the world’s problems immediately — but start with one metric and make it visible.

Integration Love Story

Do you have a moment where you actually fell in love with integration?

When I realized that with the right integration strategy, you can decouple systems completely — feed multiple systems with the same data, add or remove subscribers without touching the source system.

The specific moment was working with a company that pushed content to social media. We had a system that published on Facebook when a certain event occurred. When the time came to add LinkedIn, the point-to-point approach would have meant another direct connection from the application. That’s when I thought: if we had the right integration pattern, LinkedIn would just subscribe to the same event. The application wouldn’t need to know where its data ends up.

When I realized that the same data can create value in multiple places simultaneously — without the originating system knowing or caring — that was it for me. That’s when I fell in love.

And it’s not just about decoupling. When requirements change mid-project and you’ve built on a topic-based model, you just add a subscriber. No problem. That feels like magic when you explain it in a meeting and the business realizes how simple it actually is.

Fråga till näste gäst

We’d like you to challenge our next guest with a question.

When will you start using Open Telemetry?

The reason: we’re not quite there yet from a tooling perspective — Azure Monitor doesn’t even have native OTP support — but there’s no reason to wait. The train is moving. Microsoft is already pushing it with Aspire, where it’s built in. From a professional standpoint, go ahead and start using it. If you don’t, you’ll miss the window.

So the question to the next guest is: when will you start using Open Telemetry?

Thank you so much, Robert. We’re very glad you were here and we’ll definitely have you back.

Thank you. Great being here.