Before You Started Firefighting

For integration architects, IT managers, and operations leads who recognise the 3 AM page.

Why Nodinite exists, what it asks of you, and the architect who walked this road first.

 

Act 1. The Pager and the Silence

It is 3 AM on a Tuesday and a phone is ringing.

An integration architect named Anna reaches for it in the dark. She does not yet know which system has failed. She does not know whether the message that should have arrived at the warehouse two hours ago is sitting on a queue, or whether the queue has somehow forgotten the message exists.

She knows three things only: that someone in operations has noticed something is wrong, that she is the one supposed to know what to do about it, and that she is the only person at her company who could probably figure it out without escalating to someone whose Tuesday morning is about to be ruined.

Anna is not a real person. But the pattern of her night is real for an architect somewhere in the world. The customer-research corpus inside Nodinite contains fifty organizations interviewed in 2026, and the same scene appears in different costumes again and again.

The architect at one industrial group who has nearly lost their test BizTalk environment in the middle of a migration.

The twenty-nine-year veteran at a retail group who says, sitting across the table from his vendor, “or maybe it is just me who does not understand the system. I thought, what if it turns out I have sat here for years and not knowing what I am doing.”

The IT lead at a public authority who admits, “I think it is us who are lagging right now. We have not caught up with what the product supports today.”

There is a pattern in those three sentences. It is not a pattern of laziness. It is not a pattern of incompetence. It is a pattern of taking responsibility for a gap that was never yours to fill in the first place.

What people who live this way do, in the quiet hours, is take ownership for things they did not break. They learn each new tool the previous architect chose. They invent personal documentation systems because the official one does not exist. They keep mental maps of which integration depends on which other integration in their heads, and they hold those maps even when the systems migrate, even when the platform changes, even when leadership replaces the entire stack.

They are the people whose Monday morning starts with the question, “Did anything fail over the weekend that nobody told me about?”

The reason this question exists is not that the tools are bad. Most of the integration platforms in use across the customers Nodinite has interviewed are highly competent. BizTalk does its job. Azure Logic Apps does its job. MuleSoft does its job. Apache Camel does its job. IBM MQ does its job. The tools are not the problem.

The problem is that integrations live between tools. And between two tools, by definition, no single tool can see clearly. Messages flow across boundaries. Errors happen in the handoffs. A queue silently rots a message that should have been an order for thirty thousand vehicles, and the system that sent the order thinks it succeeded, and the system that should have received it does not know it was supposed to receive anything, and there is no one watching the gap between them. Except Anna, at 3 AM, on her phone, in the dark.

That gap is what this piece is about. It is also where Michael Olsson has spent thirty years of his professional life. Most of that time he was in similar situations to the one that Anna is in now.

This story is told here from the outside in, because the outside is where it matters. Michael’s biography is told in service of yours. He is not the hero of this piece. You are.

He is, in the way that the older architect in your career was when you first encountered the integration platform you now run, the person who can say with credibility: I have been there. I built something for the people who are still there. Here is what it asks of you.

Act 2. A Decade on the Other Side of the Pager

In June of 1996, the Monday after midsummer, Michael Olsson started his first professional job. He was twenty-six. The company was called Pronyx, a subsidiary of the old Ericsson group, building materials-tracking software for heavy industry. The customers were steel mills, pulp and paper plants, and energy utilities. The work was integration work, although nobody called it that yet. The job was to make the systems running a paper mill or a steel furnace talk to each other reliably enough that the mill could trust its own production data.

Michael was the solutions architect. He designed how the pieces fit together. He also, for ten consecutive years, sat in the on-call rotation. Twenty-four hours a day, seven days a week, when it was his week, he was the person the operators of those plants called at night if something went wrong.

There were no dashboards then that could tell him what had failed. There was no knowledge base that captured what a previous architect had learned. There was no map showing which integration depended on which other integration. There was no click on the error, see what is connected, restart the service tool. There was a phone, a sleepy architect, a customer who was angry or scared or both, and a notebook of accumulated experience that lived in the architect’s head and nowhere else.

In Michael’s own words:

“It was me they called at night when it was my week. And then you wish you had a tool like Nodinite. Something that could help you with a knowledge base. Or just understand where the error was. Or who you should talk to.”

He did not have that tool. So he did what people like him do. He built what he could. He was raised, as he later put it, hardened to be the technical support person when colleagues could not handle the call themselves. He built templates, so that when a new flow was implemented it would not have to be invented from scratch. He built wizards, small tools that helped his junior colleagues get integration patterns right the first time, so that fewer phone calls happened later.

“I built wizards so that we would write less code to succeed,” he says, looking back. “This was long before AI. It was pure automation. Higher quality than someone sitting and inventing on their own.”

What he was actually doing, although no one named it that yet, was building methodology. He did not write essays about it. He encoded it in tools. It was the earliest form of what would become a thirty-year pattern: methodology not as a deck someone presents, but as a thing built into the thing.

He did it because he wanted to sleep. He did it because there was no other way. He did it because his colleagues were also being called at night and he had a structural sense that this was not how it should work. He kept doing it for ten years.

If you have ever found yourself, at 3 AM, building a private spreadsheet of where every integration in this company actually lives, because nobody else has one and you are the only person who can answer the question when it comes up, you have already lived a smaller version of this. The instinct to take initiative and fix it yourself is the architect’s instinct. It is also the wiring that, over decades, eats people alive. Michael lived it for ten years. It shaped what he would build next.

Note what is not in this story. He is not described here as a heroic figure who saw a market and seized it. He was a young architect who hated being called at night. He was an engineer who looked at the tools available to him and concluded that they were missing something obvious. He was, in 1996, exactly the kind of person whose phone rings at 3 AM somewhere right now, today, somewhere in Sweden.

The thing that makes him interesting, the thing that makes him worth quoting in a piece written for architects in 2026, is not what he became after Pronyx. It is what he chose to do because of Pronyx. He spent the next twenty years building, in increasingly ambitious form, the thing he wished had existed at 3 AM in 1998 when a paper mill called him about a missing message.

This is where the story changes. Not because Michael changed. Because he started doing for everybody else what he had wanted somebody to do for him.

Act 3. The Pattern He Could Not Stop Seeing

In 2008 Michael founded iBiz Solutions in Karlstad together with a partner. Two people. Within a few years they had grown into a working consulting firm, hiring more architects, taking on more customers, delivering more integration projects across more industries.

If you have ever worked in the consulting industry, you know the shape of how it works. A project comes in. You build a team. The team works hard for months. The integration is delivered. The system is handed over to the customer’s operations team. The consulting firm moves on to the next project. The team is hungry for the next challenge.

What iBiz Solutions noticed, very early on, is that this shape of work created a deeply uncomfortable problem: the most valuable phase, from the customer’s perspective, started exactly when the consultants were walking out the door.

The integration was now live. The operators of the customer’s mill or warehouse or hospital department now had to run it. The architects who had built it, who knew where every adapter lived and why every rule had been written that particular way, were gone. The phone was now in the operator’s hand. The mental map was in the consultant’s head. The map was not in the building anymore.

Michael saw the pattern repeat across customer after customer. The same scene he had lived through ten years earlier at Pronyx was playing out again, now in different uniforms, in different industries, with the same outcome. Someone was being called at 3 AM, and they did not have the tools they needed, and the only person who could really help them was somewhere else getting paid to build the next thing.

He concluded two things from this. The first was business-shaped. iBiz Solutions started selling something they called management as a service. The idea was that the consulting firm did not have to disappear after delivery. It could stay engaged, run the operations, take the calls itself, hand the knowledge across into a continuous service. That model worked. By 2018, half of iBiz Solutions’ revenue came from operations and management work, not from new project delivery. It built a kind of business that was less feast-or-famine for the consulting team and considerably more sustainable for the customers, who now had partners who actually stayed.

The second conclusion was more interesting, and it is the one that matters for the rest of this story. To run operations work at any scale, iBiz Solutions needed a tool that did not exist. They were taking on customers who ran ten different integration platforms across ten different companies. If each platform had its own monitoring tool, and they had ten customers, that was thirty tools they would need to train every consultant on. The mathematics did not work. The mathematics had never worked. Nobody else’s mathematics worked either. The whole industry had been building point-to-point monitoring on a point-to-point basis for two decades, and the cost of that approach was paid every night by the architects whose phones kept ringing.

“How do you scale that service?” Michael asks, recalling that period. “If I have ten customers and they each pick one of three different tools, I potentially need to know thirty tools. With one tool, no matter how many customers we have, we have one onboarding cycle. We can guarantee quality. We can suddenly quantify what we are selling.”

 

Around the same period, iBiz Solutions also formalized something they called the Integration Framework. This was methodology, sold as workshops to customers, structured around a deeply familiar shape: where are you now, where do you want to be, what does the journey between them look like, what are the architectural layers you will need to think about, what is the roadmap.

“We had workshops with the customer to help them understand,” Michael recalls. “Okay, this is where we are. What is the desired target picture. And here is the smorgasbord of components.”

Then, with characteristic dryness:

“It was a way to get paid for educating the customer to be a better buyer.”

That sentence is worth pausing on. A way to get paid for educating the customer to be a better buyer. The whole posture of how iBiz Solutions worked is encoded in it. The customer was not assumed to be wrong. The customer was assumed to be under-equipped. The job was to bring the methodology that would let them stop being under-equipped. The methodology was not a thing the firm hoarded as a competitive moat. It was the thing the firm transferred deliberately, so that the relationship could mature.

That methodology did not disappear when Michael eventually sold the consulting side of the business. iBiz Solutions became part of what is now Advania, today around two hundred people, still operating in the same general space. The Integration Framework, the workshop discipline, the architectural-layer thinking, the as-is-to-be-roadmap pattern, all of that lives on in how that firm still operates and how its alumni continue to work. That is one way methodology survives. It stays in the people. It walks with them when they move companies. It propagates through an industry.

But Michael had noticed something else. As carefully as the methodology was transferred through workshops, and as deliberately as iBiz Solutions tried to keep its consultants trained, the methodology kept walking out the door whenever an individual consultant changed jobs. A piece of it would arrive at the next employer. Another piece would not. The customer who had been carefully taught how to think about their integration landscape would, three years later, find themselves dealing with a different consultant who had never been through the workshop, and the careful work would slowly erode.

So Michael did the most ambitious thing he could think of. He started building the methodology not into the heads of consultants, but into the thing itself. Into the product.

That is the transition that produced Nodinite as it exists today.

Act 4. Same Thread, More Coverage

Nodinite was co-founded in 2012 by Michael under a wholly different name. In 2018 Michael and his partner Henrik bought out the remaining shareholders and stood on their own feet for the first time. The product needed a new name. The company needed a new name. They settled on one word, deliberately chosen. Nodinite is built from the Latin word for node, nodus, joined to the word unite. Read together it means the node that unites your systems.

That is the architectural commitment, not just a marketing line. Nodinite is not an integration platform. It does not compete with the platforms its customers run. It is the node that connects them, the layer that lets an architect or an operator or a business user see what is happening across all of them at once. Born late in the era when BizTalk dominated. Designed to be the layer that does not have to change when the platforms underneath do.

That commitment has been tested repeatedly. Most of Nodinite’s customers, over the past fifteen years, have eventually changed integration platforms at least once. The platforms moved. The visibility layer did not. The architects responsible for those integrations did not have to learn a new way to see what their organisation was running every time the platform was replaced.

A nordic industrial company, has said that they save somewhere between ten and twenty million Swedish kronor per year because Nodinite lets them keep what Michael in private calls the digital bloodstream alive. The number itself is less important than the mechanism. They save that money because the time between a fault happens and the right person knows about the fault has collapsed. The fault does not become a problem because it does not get a chance to.

At a Swedish regional healthcare authority, nurses receive alerts from Nodinite when patient-critical blood-test results have not arrived at the intended destination within the time they should have. Not architects. Nurses. The person who needs to know is the person who knows, and the alert reaches them in time. The architects upstairs sleep through Sunday night because they have built the alerting in a way that makes the human in the lab coat the person who acts.

What links these two customers, and the eighty or so others Nodinite serves across the Nordics, is not that they all run the same platforms. They emphatically do not. BizTalk. Azure Logic Apps. MuleSoft. IBM MQ. Boomi. Apache Camel. Friends. Containerized integration runtimes. On-premises deployments. Hybrid architectures. Sovereign-cloud setups. AI agents starting to take their first integration actions inside production environments. All of those platforms are good. The right platform for a given company depends on what that company is trying to do, what it already runs, what compliance regime it lives under, and what its operating model looks like.

What links the customers is that across all of those underlying choices, they have wanted the same thing: an independent layer that lets them see what is happening, decide who is responsible when something breaks, and know where they stand without depending on any vendor’s pitch.

This is also where Michael’s pattern of building methodology into the thing becomes most visible. The product has expanded over fifteen years in a way that looks, from outside, like new features being added. Repository for documenting what integrations actually exist. Business Process Monitoring, often called BPM, for tracking end-to-end business flows across systems. Mapify for visually mapping an integration landscape so you can see what is connected to what. C4 architecture diagram support, aligned to the C4 model standard, so architects can document their landscape in a way the rest of the industry will also recognise. These look like features. They are not features.

They are answers to root causes that customers themselves often have not yet articulated. The customers know they are tired of writing manual Repository entries. They also know they cannot easily see end-to-end business flows. They do not always know that the architecture of BPM, the thing that lets a business owner see the lifecycle of an order from creation to fulfilment to invoicing, is the answer to a different question, which is why does every audit conversation start with a fight about whose data is right.

A good architect sees the symptom. A visionary architect sees the root cause and builds for it before the customer has named it.

This is the trade-off Michael makes consciously. The risk of building for root causes that customers have not articulated is that the customer initially has to be educated to understand why the feature matters. Mapify is the universal exception in the cohort: every customer who sees Mapify intuitively wants it. BPM is harder, because BPM only makes sense if you already think in terms of business processes, and many integration organisations do not yet. C4 is harder still in some accounts, because architectural documentation discipline lives unevenly across the industry.

But once a customer takes the next step on the integration journey, whatever step it is, Nodinite is already there. The methodology is already encoded. The Repository concept already exists. The BPM architecture already exists. The visualization layer already exists. The customer is not waiting for a feature roadmap. The customer is, more often than they realise, waiting for themselves.

This is what the node that connects everything else actually means. It is not a slogan. It is an unchanging architectural job, performed for fifteen years across four eras of integration architecture, that keeps doing the same thing while the world around it changes.

Act 5. What This Asks of You

If you have read this far, you have probably noticed that this story is not really about Michael Olsson. It is about you.

It is about the architect, somewhere, whose phone has been ringing for too long. It is about the IT manager whose annual review keeps surfacing the same complaint, that the team is reactive when it should be governing. It is about the operations lead who is tired of explaining to senior developers what just broke at 4 AM. It is about the long-tenured veteran who keeps wondering, quietly, whether the reason things feel hard is something they are doing wrong.

Michael is, in this story, the person who walked the same road and concluded, over thirty years, three things that are worth carrying out of this piece.

The first thing is that the people who feel this way are not failing. They are responsible. The instinct to fix it yourself because no one else can is the same instinct that built every integration that works today. It is the architect’s instinct and the operator’s instinct and it is precisely the wiring you want in the people running the most critical flows in your business. The problem is not the people. The problem is that the visibility layer above the platforms has not historically existed in usable form. The right response to that absence is not to work harder. It is to install the layer.

The second thing is that methodology travels. It travels through people, who carry it from one employer to the next. It travels through workshops, where one person teaches another the as-is to-be journey-roadmap-layers way of thinking that lets you see your own landscape clearly. It travels through partners, who carry shared methodology across multiple customers. And, increasingly, it travels through products that have methodology baked into them, so that the way the product works is the way the work should work. Michael spent his early career building methodology into wizards. He spent his middle career building methodology into workshops his consulting firm sold to customers. He has spent his recent career building methodology into a product. He continues, today, to push methodology out through release notes, through monthly product webinars, through roundtables, through written content like this piece. The medium changes. The methodology continues.

The third thing is that the journey is not lonely, and it is not blame-laden. Across the customer interviews Nodinite has done in 2026, roughly half of the customers, unprompted, said some version of we are the ones lagging, not the product. That sentence comes from a generous place. It is also a misreading of the situation in one important way. The customers are not lagging. They are doing exactly what responsible architects do in environments where the visibility layer was not built into the platforms they were handed. They are working harder than the situation should require, because that is what responsible people do. Michael’s view, after a long career, is gentler than the self-blame: this is a journey, you level up, you do not do it alone, the right partners help, the right tools help, and the right methodology lets you take the next step without having to invent it.

He has, in different forms across thirty years, done that for his colleagues at Pronyx, for his consulting clients at iBiz Solutions, for the firm that became Advania, and for the customers who now run Nodinite. The job has not changed. The medium has expanded.

Which is what this piece, finally, asks of you. Not to buy anything. Not to schedule a demo. Not to fill in a form. Simply to recognize, if any of this story sounded familiar, that you are not the first person to live this. You are not the only person living it right now. There is a body of methodology, encoded in a product, supported by a community of partners and customers and a founder who personally remembers the 3 AM call, that exists for precisely the situation you are probably in. It is here. It has been here for fifteen years. It will be here when the next platform replaces the current platform, and the one after that.

Nodinite is the node that connects everything else.

That is the line Michael settled on with his partner Henrik in 2018, when they renamed the company. It is, after fifteen years of building, accurate. It is also an invitation. The node connects what is already there. It does not replace it. It does not displace the architect. It does not displace the consultant or the partner or the operations team. It augments them with the visibility layer they were missing, and it asks of them only one thing: that they take the next step on the journey, knowing that the methodology will already be waiting for them when they do.

That is the founder story behind Nodinite. It is also, with the names changed, your story.

Michael Olsson: A Timeline

From the Pager to the Product

• 1996: Joins Pronyx (Ericsson group) as solutions architect. Begins 10-year on-call rotation for steel mills, pulp plants, and energy utilities.
• 1996-2006: Builds templates and wizards to reduce on-call incidents. Encodes methodology into tools for the first time.
• 2008: Co-founds iBiz Solutions in Karlstad. Grows from two people into a working consulting firm.
• ~2012: Nodinite is co-founded under an earlier name. The internal tool Integration Manager is the first version of the product.
• ~2013-2017: iBiz Solutions launches management as a service. By 2018, half of revenue comes from operations work, not new project delivery.
• 2018: Michael and partner Henrik buy out remaining shareholders. Firm and product renamed Nodinite, from nodus (Latin: node) and unite.
• 2024-2026: Nodinite serves 80+ organizations across the Nordics. Customer research corpus of 50 interviews shapes ongoing product development.

Nodinite Across Fifteen Years: What the Numbers Say

Across the customers Nodinite serves today, a consistent pattern holds. Organizations that install the visibility layer do not just fix the 3 AM call problem. They change how their entire integration operation runs.

Implementation from Start to Success
• Timeline: Started documenting in May 2024, went live in July 2024.
• Progress: 450 integrations documented by September 2025 (out of 1,800 total).
• Goal: Complete documentation by end of 2026.

This is what the journey looks like in practice. Not a rip-and-replace. Not a six-month paralysis. A start, a live date, a measurable target, and steady progress toward it.

About Michael Olsson

Michael Olsson started his career in 1996 as a solutions architect at an Ericsson-group industrial-software company, building materials-tracking systems for steel mills and pulp plants. He spent ten years in the on-call rotation, learning what integration architects need at 3 AM because he was the one being called.

He went on to co-found iBiz Solutions in Karlstad in 2008, where the team built the Integration Framework methodology that customers still use today. In 2018 he and his partner Henrik renamed the firm Nodinite, where he continues to build methodology into the product.