A nine-tray integration corridor in a Munich enterprise hall under morning rack light

Platform Reviews

Your stack, judged by what it must actually do

Eight platforms that recur on German enterprise shortlists, read as fit assessments: intended use case, where each sits in a stack, and the operating model it asks you to carry.

SAP Ariba · SAP BTP · Kubernetes · Oracle NetSuite · OutSystems · SUSE Linux Enterprise Server · Google Cloud · Workday

Check integration readiness Send your shortlist question

How to read this page

Eight enterprise platforms, reviewed by fit

This is not a ranking. We cover eight platforms that appear repeatedly on German enterprise shortlists, and for each one we describe the intended use case, where it fits in a stack, and the operating model it implies. Read the entries as fit assessments, not as verdicts.

Each entry answers three questions in the same order, so you can compare across the set instead of reading eight unrelated opinions: what the platform is actually for, what has to be true in your estate for it to fit, and who ends up operating it. Where a platform carries a certification or a delivery obligation in a regulated context, we say so plainly.

Read this entry if You are choosing between two platforms that both claim the same job, and the difference is who operates the outcome.

01 / SAP Ariba Procurement and source-to-pay Large buyer governance 02 / SAP BTP Integration and extension layer Mixed legacy and cloud 03 / Kubernetes Baseline infrastructure Regulated and distributed 04 / Oracle NetSuite Mid-market ERP Growth-oriented firms 05 / OutSystems Low-code delivery Internal tools with a deadline 06 / SUSE Linux Enterprise Server Infrastructure standard SAP-certified estates 07 / Google Cloud Data and cloud-native workloads Addition to the estate 08 / Workday HCM and finance cloud People and finance ops

Five-line check

Before you call any of these platforms a fit, run the same five lines.

The rows below are the questions we use in a readiness conversation. They are the same five whether you are looking at SAP Ariba, NetSuite, or Workday — the answers decide what belongs on your shortlist.

Scope Which business process the platform is actually responsible for, in one sentence both IT and the process owner agree on.: Process ownership
Dependencies The systems on either side — master data, identity, interfaces — without which the platform delivers nothing you can bill against.: Boundaries
Evidence What you want to see before signing: a live reference in your sector, a documented exit path, a named owner on the vendor side.: Due diligence
Readiness Whether your data, your team, and your release cadence can actually absorb the platform without pausing the business for a quarter.: Absorption capacity
Fixed fee Our readiness assessment runs on a fixed fee, so the decision is a document you can schedule and a number you can plan around — not an open-ended engagement.: Predictable cost

The entries

Eight platforms, one reading order

Every entry below follows the same shape: what the platform is for, what it assumes about your estate, and what has to be true operationally for it to hold up. Read them in whatever order your shortlist follows.

01 / SAP Ariba Procurement and source-to-pay

Procurement and source-to-pay

Ariba is SAP's procurement and source-to-pay platform. It covers sourcing, supplier management, contracts, and procurement workflows, and it is commonly positioned for large organisations with complex purchasing and supplier governance.

It fits a market where procurement digitisation and risk controls matter, which describes most large German buyers. The practical question is not whether it can do source-to-pay. It is whether your supplier master and contract taxonomy are consistent enough for one system to govern them.

Runs as: A governed procurement system of record, integrated back into SAP ERP for purchasing and settlement.
Operating model: Central procurement team owning supplier master and contract taxonomy; IT owning the integration surface.
Judge by: Supplier master cleanliness and contract taxonomy consistency before any technical comparison.

A procurement review table with a closed contract and laptop, lit from a side window

02 / SAP BTP Integration and extension layer

The integration and extension layer

BTP is SAP's platform for integration, extension, automation, and data use cases. It is used to connect SAP and non-SAP systems, and it matters most in enterprises with mixed legacy and cloud estates — the normal condition rather than the exception.

It supports the move toward modular enterprise architectures, where the ERP core stays stable and the surrounding capability is built and changed at a different pace. Assess it as an architectural layer, not as a product with a feature comparison sheet.

Architectural read

Keeps the core stable. Extensions, integrations and automation live beside the ERP instead of inside it, so the release cadence of each side can differ.
Assumes a boundary. Value starts from a named integration boundary between the core and the surrounding systems, not from a feature list.
Needs an owner. An integration layer with no accountable team becomes an expensive place where interfaces accumulate.

Racks and aisles in a modern German data centre under cool overhead light

03 / Kubernetes Baseline infrastructure

Baseline infrastructure

Kubernetes is the dominant open-source orchestration layer for containers. It is widely used for cloud-native and hybrid enterprise applications and is relevant to modern application platforms, including regulated and distributed environments.

It has become a common foundation for enterprise software delivery and operations. The honest framing: Kubernetes is not a differentiator by itself. It is the layer everything else assumes, and the decision is about who operates it and to what standard.

04 / Oracle NetSuite Mid-market ERP

Mid-market ERP

NetSuite is Oracle's cloud ERP for growth-oriented companies. It is often used by smaller enterprises that want a unified finance and operations system, and it is especially relevant for companies scaling across entities or countries. It sits between lightweight accounting tools and a large-suite ERP.

For a German mid-market firm weighing it against a full SAP suite, the useful test is how much of your process reality fits the standard model before customisation starts.

Entities: Single to multi-entity
Geography: Common multi-country
Customisation: Standard-first, then config
Vs. full suite: Cost follows complexity

05 / OutSystems Low-code delivery

Low-code delivery

OutSystems is a low-code platform for enterprise application development. It supports rapid delivery of custom business apps and portals and is often compared with Mendix in enterprise modernisation projects. It fits organisations that need faster delivery than traditional custom development allows.

Where it earns its cost is process apps and internal tools with a real deadline. Where it creates a problem is ungoverned app sprawl, so the governance model matters as much as the platform.

Sits well for

Process apps with a real delivery deadline and a named business owner.
Internal portals that replace paper or spreadsheet workflows, where speed of change beats product depth.
Adjacent to a stable ERP core rather than inside it, so customisation does not touch the system of record.

Watch for: ungoverned app sprawl

06 / SUSE Linux Enterprise Server Infrastructure standard

The infrastructure standard

SUSE is a German-headquartered enterprise open source company, strongly associated with Linux for enterprise and SAP environments. It is used in hybrid and regulated infrastructure settings and is a standard infrastructure choice in many enterprise estates.

It rarely wins a procurement argument on features. It matters because operating system and support choices set the ceiling on what the rest of the estate can promise about stability and certification.

What it actually decides

The operating system is the top of the stack for support and certification. If your platform vendor only certifies against a set of OS and patch levels, that set is what everyone downstream has to plan around — including change windows, audit evidence, and the pace of your own patching.

07 / Google Cloud Data and cloud-native workloads

Data and cloud-native workloads

Google Cloud is one of the major hyperscale cloud platforms used by enterprises. It is often chosen for data, analytics, and cloud-native workloads, and it participates in the same hybrid and security-driven selection criteria as other large clouds. It is part of the enterprise cloud shortlist in Germany.

Data teams tend to see it differently from ERP-centred stacks, and that difference is the point: it is usually an addition to the estate, not a replacement for the system of record.

An analytics workspace desk at dusk with a monitor glow plane and coiled cabling

08 / Workday HCM and finance cloud

HCM and finance cloud

Workday offers cloud HR and finance software for enterprise use, known for cloud-native architecture and depth in HR and process. It is commonly shortlisted by firms modernising people and finance operations, and it fits organisations that want fewer on-prem dependencies.

In a German context, the evaluation usually turns on payroll, works council requirements, and reporting, and on how much of that fits the standard model versus configuration effort.

German evaluation lens

Payroll fit with German requirements and the boundary to any external payroll provider.
Works council and co-determination requirements before configuration is signed off.
Reporting and data residency paths for people data across entities.

A Swabian plant procurement office at shift handover with monitors and a parts tray

One case, in a Swabian plant

What a shift-handover snapshot tells you about fit

A mid-market manufacturer asked us to look at two of the platforms on this page at once: a mid-market ERP for finance and operations, and a low-code delivery platform for the internal tools around it. The two monitors on the desk were running both sides of the same procurement cycle.

The interesting part was not either platform. It was the print-out between them — the shift handover sheet, still printed because the boundary between what each system agreed to own had never been written down. Two platforms, one daily artefact, and no interface contract.

The work was to define that contract, not to pick a winner. Once the ERP owned the process of record and the low-code layer owned the process apps around it, the print-out went away on its own.

Check integration readiness Review compliance constraints

What was on the desk: A financial system of record, a low-code process-app layer, and a paper handover between them.
What we framed first: The boundary — which process each system was accountable for, before any capability comparison.
What changed: The handover moved into the low-code layer; the print-out stopped being the interface.
What you should take from it: Two platforms are never the problem — one unnamed boundary is.

Where the real cost lives

How experienced buyers judge quality

They look at exits and interfaces more than at dashboards. What does the data model assume, what happens at the integration boundary, what is the documented path off the platform, and who is accountable when a cross-system workflow fails.

A platform that answers those questions concretely tends to hold up over a five-year horizon. One that answers them with marketing language usually does not.

Common beginner mistakes in platform comparison

Feature lists before a stack map

Comparing capabilities before the existing estate is mapped. The document you end up with is not a fit assessment, it is a shortlist with the wrong shape.
Deferring the integration work

Assuming integration is a detail to be handled later. It is the largest fixed cost of the decision and the hardest to move once a platform is live.
Reading the reference architecture as your architecture

Treating the vendor's reference diagram as a description of your environment. It is a description of the vendor's assumptions, and yours may differ.
What to do instead

Define the boundaries between systems first, then read the platform documentation against those boundaries, and only then look at capability.

The join between systems

Most of the cost of a platform decision is not the platform — it is the four or five joins around it.

When you have a favourite, the next useful question is what it has to sit next to. The frames below are the joins that come up most often with these eight platforms. None of them is a product.

Procurement ↔ ERP

System of record boundary

Where the sourcing and supplier workflow hands over to purchasing, settlement, and the finance master. If this join is not drawn first, both sides will keep re-implementing each other's work.

Supplier master as the shared source
Contract taxonomy and version ownership
Where the receipt is closed and where it lands
Who is paged when a workflow stalls

Integration ↔ Core

The extension layer keeps the core stable precisely by owning the shape of every interface. Define who decides what an interface is allowed to mean before you build the third one.

Platform ↔ Operations

An orchestration or OS layer turns into a live dependency the day something real runs on it. Patch cadence, on-call rota and audit evidence all follow from that.

People ↔ Finance

HCM and finance platforms often cross works council boundaries, payroll providers and multi-entity reporting. The join is a governance question before it is a technical one.

Apply it to your estate

Using these reviews without treating them as a ranking

We deliberately avoid a numbered order, because the right answer depends on your estate, your sector, and your timeline. Use the entries to narrow your shortlist and to write better questions for vendors.

If you want the assessment applied to your specific stack, that is a separate conversation, and it starts with what you already run.

Bring one of these to the conversation

Your existing stack

The systems you already run in ERP, procurement, HCM and infrastructure — even if the list is longer than you would like.
Your shortlist and its reasons

Which platforms are on your shortlist, and why — a sector reference, a vendor relationship, a board-level expectation.
Regulatory context

Anything binding on your selection: data residency, audit obligations, works council requirements, sector-specific rules.
A realistic timeline

What has to be live by when — a budget cycle, a replacement window, an internal audit — because it changes which platforms are viable.

Talk to us in München Send your shortlist question

Short answers

Questions we get before a shortlist

Is Kubernetes an alternative to an ERP system?

No. Kubernetes is an orchestration layer for containers, used to run and operate applications. It is infrastructure underneath business systems, not a replacement for a system of record such as an ERP.

Can SAP BTP replace custom development in the ERP core?

It is designed to extend and integrate rather than to rebuild the core. The usual pattern keeps the ERP core stable and builds extensions, integrations, and automation on the platform beside it, which is what makes modular architectures workable.

How do we choose between Oracle NetSuite and a full SAP suite?

Start from the process reality rather than the product tier: how many entities, how much multi-country complexity, and how much customisation the requirements force. NetSuite is the common shortlist entry for growth-oriented firms; a full suite earns its cost when the complexity is genuinely there.

Where to go next

Read the entries, then ask us about your stack

InnovaTech Solutions GmbH advises German mid-market and large organisations on enterprise software selection and integration. Königsallee 45, 80539 München. Monday to Friday, 9:00–18:00.

+49 30 2009 5341 [email protected]

Check integration readiness Review compliance constraints Talk to us in München