Which two platforms should run your Nordic SAP business?
Every vendor in the SAP market wants to be where your AI lives. But the real decision is not which agent to buy, it is which platform they run on. Sveinung Gehrken on why Nordic SAP customers should name their two business operating systems, deliberately, before drift makes the call for them.

Which two platforms should run your Nordic SAP business?
There is no shortage of information in the SAP market about what AI and agents can do. There is a shortage of clear thinking about where they should live.
TL;DR
Every software vendor is adding AI and agents to its product. Each offer quietly asks to become another place where your business logic, identities and data-access rules live.
The strategic question is therefore not how many AI capabilities you can deploy. It is which platforms will form your business operating system.
For many Nordic SAP customers, the natural answer is SAP and Microsoft. Other combinations can also be valid, but the choice must be deliberate. The real risk is platform drift: several data platforms, identity models, integration layers and agent frameworks accumulating without a clear decision.
Name your two. Write them down. Then check whether your last five technology investments agree with you.
In this article
Look at who is doing the pushing. Software vendors with large installed bases (low-code platforms, integration tools, data tools, CRM, ticketing, OCR, HR) are all adding AI and agents to their products. That is rational. It protects their revenue and deepens the customer relationship. Hosting and open-source providers are pushing architectures that keep the workload inside their private cloud. Also rational, for them.
None of it is dishonest. But none of it is neutral either. Every one of these offers quietly asks to become a place where your business logic, your identity model and your data access rules now live. That is not a feature purchase. That is a platform decision, made without being called one.
The protocol lesson
I have spent almost 30 years in enterprise technology, and this moment has a familiar shape.
When HTTP and the web arrived, the market was full of proprietary answers to a question that turned out to have an open answer. The companies that bet on closed stacks spent years unwinding that bet. The open protocol won, because it let everything else connect.
MCP is in that same early phase now. Rough edges, fast movement, and a clear direction: this is becoming how applications, data and agents talk to each other. That is good news, because it means the connection layer is not where you need to place a strategic bet.
The strategic bet is the platform underneath.
What a business operating system actually is
You need a place to orchestrate. A place to integrate in and out of. A place that answers the boring, unavoidable questions:
- Who is this user, and where does their identity come from?
- What are they allowed to see and do?
- How does an external party get in, and how do we cut them off?
- Where do agents run, and who governs what they are permitted to touch?
- What does the semantic layer say a customer, an order or a cost centre actually is?
- Where is the audit trail?
Any system that answers those questions for part of your business is, in practice, an operating system for that part. Most organisations have collected several without ever deciding to.
The two nobody counts
Two of these are almost always underestimated, because they are filed as applications.
CRM. A CRM owns customer master data, customer identity, and a meaningful share of the commercial process. It has its own security model, its own integration patterns, its own extension platform and now its own agent framework. If your CRM decides who a customer is and what the sales process must look like, it is an operating system. Calling it an app does not change what it does.
The data platform. Warehouse, lakehouse, whichever word you use. This is the one that matters most and gets decided most casually. Your data platform holds the semantic layer: the definitions of revenue, margin, customer, product, cost centre. Those definitions are what your agents will reason from. An agent grounded in an inconsistent semantic layer does not fail loudly. It produces confident, wrong answers at scale.
In an agentic world, choosing your data platform is choosing where your business logic actually lives. Treat it accordingly.
For Nordic SAP customers, the natural answer, and why it still has to be a decision
For most Nordic SAP customers the two platforms are SAP and Microsoft. That is where the core processes run, where the people work, where identity already lives, and where both vendors are investing heavily in exactly this layer.
But that answer has to be reached, not assumed.
Because I see real movement in other directions. Some SAP customers are moving data and innovation to Google: BigQuery, the analytics stack, the model estate. Others are investing seriously in open source and private cloud on Linux, often for good reasons: cost, sovereignty, control, avoiding lock-in.
Both are legitimate strategies. But both force a question that most organisations have not answered out loud:
Is Microsoft your core business operating system, or is it your platform for business applications and communication?
Those are very different answers, and almost everything downstream depends on which one is true.
If Microsoft is your core operating system, then Entra is your identity backbone, Azure is your control plane, Fabric is your data platform, and your agents run and are governed there. Everything else plugs in.
If Microsoft is your business apps and communication layer (Microsoft 365, Teams, Office, the productivity estate), then that is a perfectly respectable position. But you have just made yourself responsible for finding a different answer to identity, integration, agent governance and audit. Those questions do not go away because you moved your data somewhere else.
You need to decide. Deliberately.
Drift is the actual risk
The failure I see is not a wrong choice. It is no choice.
It looks like this: half a data platform in Fabric and half in BigQuery, with two semantic layers and no agreement on which is authoritative. A CRM running its own agent framework that nobody has mapped to the enterprise authorization model. A private cloud strategy on Linux while the organisation still assumes Microsoft is handling identity and security. Three integration platforms. Two agent runtimes. One risk register that does not mention any of it.
Nobody approved that architecture. It accumulated. And the cost does not appear as a line item; it appears as slow projects, unexplained security exposure, and AI pilots that never reach production because there is nowhere solid to put them.
The failure I see is not a wrong choice. It is no choice.
Why fewer platforms means more innovation
The common objection is that limiting yourself to two platforms constrains innovation. In our experience the reverse is true, and the arithmetic is simple.
Solve identity once instead of five times. Solve integration patterns once. Solve agent authorization once. Agree one semantic layer. Every hour not spent rebuilding that foundation for the next tool is an hour available for something that actually differentiates the business.
And because the connection layer is now open, a disciplined platform choice does not close doors; it is what makes the doors usable. A well-governed two-platform core can connect to almost anything, quickly and safely, without a new governance project each time.
The companies that get real value from agents over the next three years will not be the ones that bought the most AI. They will be the ones that had somewhere sensible to put it.
So name your two. Write them down. Then look at your last five technology investments and check whether they agree with you.
Can you name your two business operating systems?
S5 helps Nordic SAP customers map their current platform landscape, define the role of SAP, Microsoft and specialist platforms, and turn that decision into a practical architecture and delivery sequence.
Frequently asked questions
What does “name your two” mean?
“Name your two” means identifying the two strategic platforms that will form the primary operating foundation for your business technology. These platforms should have clearly defined responsibilities across processes, identity, data, integration, security, audit and AI-agent governance.
Why should an organisation limit the number of strategic platforms?
The goal is not to limit the number of specialist applications the organisation can use. It is to avoid rebuilding identity, integration, data definitions, governance and audit controls separately for every product. A smaller strategic core provides a consistent foundation to which specialist systems can connect.
Are SAP and Microsoft always the right two platforms?
No. SAP and Microsoft are a natural combination for many Nordic SAP customers, but other strategies can also be valid. Google Cloud, open-source platforms and private-cloud environments may play a central role. What matters is that the choice is deliberate and that responsibilities are clearly assigned.
Can CRM be considered a business operating system?
Yes. A CRM can function as an operating system for the commercial side of the business when it owns customer master data, customer identity, sales processes, authorisations, integrations, extensions and agent capabilities.
Why is the data platform so important for enterprise AI?
AI agents reason from the data and definitions available to them. The data platform often holds the semantic definitions of customers, products, revenue, margin and costs. If those definitions are inconsistent, agents can produce incorrect answers while still sounding confident.
What is platform drift?
Platform drift occurs when technologies with overlapping responsibilities accumulate without an explicit architecture decision. Examples include competing data platforms, multiple semantic layers, several integration tools and separate agent frameworks that are not governed through one consistent model.
Does choosing two platforms create vendor lock-in?
Any strategic platform choice creates dependencies. The objective is not to pretend those dependencies do not exist, but to manage them deliberately. Open protocols, defined integration patterns, portable data structures and clear architectural boundaries can preserve flexibility while maintaining coherent governance.
How should an SAP customer begin the platform decision?
Begin by mapping which systems currently own identity, business processes, integration, enterprise data, semantic definitions, security, audit and agent governance. Then define which two platforms should be strategic, document their responsibilities and review whether current investments reinforce that model.