Enterprise Platforms
SAP
Integration and extension work around SAP — not a full ERP re-implementation.
Overview
SAP is the enterprise resource planning software that runs the core operations of a large share of the world’s biggest companies — finance and accounting, supply chain, procurement, manufacturing, sales and HR, all sitting on one shared data model. Its modern incarnation is SAP S/4HANA, a rewrite of the ERP suite that runs on the in-memory HANA database; a great many organisations are still on the older SAP ECC and working through the migration. Around the core sits the SAP Business Technology Platform (BTP) for building extensions and integrations, ABAP as the traditional in-system programming language, Fiori as the modern user experience layer, and a large surface of APIs, OData services and middleware for getting data in and out.
We want to be precise about what we do here, because it is easy to overclaim. Yarqat is not a full SAP implementation partner. We do not compete with the large global consultancies who run multi-year, multi-million-pound programmes to configure and roll out the core ERP across a business — that is a genuine specialism with its own certifications, and pretending otherwise would be dishonest. Our value is at the edges of SAP: integrating it with the bespoke systems and custom applications you already run, building modern web and mobile front ends over SAP data, developing extensions on BTP, exposing SAP through clean, well-documented APIs, and automating the manual work that grows up around any large ERP.
That edge is where most of the real friction lives. SAP holds the authoritative record of a business, but it rarely holds it in the shape a modern customer portal, a mobile field app, a data pipeline or a partner integration actually needs. Bridging that gap well — safely, with the right data contracts, without destabilising a system the whole company depends on — is careful engineering, and it is the work we take on. If what you need is a first-time core ERP implementation, we will say so and point you toward the right kind of partner rather than take work we are not the right shop for.
Best for — Large enterprises already running SAP who need it integrated with bespoke systems, fronted by modern applications, or extended on BTP — not organisations looking to implement core ERP for the first time.
Why teams choose SAP
SAP data where your other systems need it
We expose the authoritative records held in SAP through clean APIs and integrations, so your custom applications, portals and analytics work from the same truth as the ERP instead of a stale copy someone maintains by hand.
A usable interface over a powerful core
SAP’s standard transactions are built for depth, not for the occasional or non-expert user. A purpose-built web or mobile front end turns a process that needed training into one a field engineer, customer or partner can complete unaided.
Extension without destabilising the core
Building on BTP keeps custom logic outside the digital core, so you gain new capabilities while your SAP system stays clean, supportable and safe to upgrade — the opposite of the heavy in-core customisation that traps so many organisations.
Why businesses choose SAP
- You already run SAP and the problem is connecting it to the rest of your estate, not replacing or re-implementing it.
- You want the parts of your SAP world that touch customers, partners or field staff to feel modern, without a risky change to the ERP core.
- You value a partner who is candid about the boundary between edge integration work and a full implementation, and who will route you to the right specialist when the work is not ours.
- You want extensions and integrations built to survive upgrades — engineered on BTP and through supported APIs rather than bolted into the core where they will one day break.
What we build with SAP
The capabilities this technology is genuinely strong at — and what we most often build with it.
SAP S/4HANA and ECC integration
We integrate with both the modern S/4HANA suite and the older ECC systems many enterprises still run, working with each on its own terms rather than assuming everyone is already migrated. Where a migration is under way, we build integrations that survive the transition.
BTP extensions
We build side-by-side extensions on the SAP Business Technology Platform — custom services, business logic and applications that consume SAP data and events while living entirely outside the digital core, so the core stays clean and upgrade-safe.
OData and API exposure
SAP speaks OData and a range of REST and SOAP interfaces natively. We expose the specific data and operations your other systems need as clean, documented, versioned APIs, so integrating with SAP stops meaning wrestling with the raw system every time.
Fiori and custom front ends
We build user interfaces over SAP — whether in the Fiori design language for consistency with your SAP estate, or as fully bespoke web and mobile applications where a tailored experience matters more than visual conformity.
Middleware and integration flows
For anything beyond point-to-point, we design proper integration layers — using SAP Integration Suite or third-party middleware such as MuleSoft — with mapping, error handling, retries and monitoring, so data moving between SAP and the outside world is reliable and observable.
Automation around SAP
A great deal of manual effort accumulates at the edges of any ERP: rekeying, reconciliation, report shuffling, swivel-chair processes between SAP and other tools. We automate that work through APIs and event-driven flows, removing the human copy-paste rather than papering over it.
Use cases
Customer and supplier portals over SAP
A modern, self-service web portal where customers or suppliers see and act on SAP data — orders, invoices, deliveries — without anyone giving them SAP access or handling the requests by hand.
Bespoke system integration
Connecting a custom application, a legacy system or a niche third-party tool to SAP through a governed integration, so the two stay in sync on shared master data and transactions instead of drifting apart.
Mobile apps for field and floor staff
Native or web mobile apps that let field engineers, warehouse teams or sales staff read from and write to SAP on the move, through a purpose-built interface rather than a desktop transaction squeezed onto a phone.
SAP data into analytics and pipelines
Extracting SAP data reliably into a data warehouse, lake or downstream analytics platform, with the right contracts and scheduling, so reporting draws on the authoritative operational record without hammering the production system.
When SAP is the right choice
- Right when SAP is already your system of record and you need to connect it to something else — a bespoke application, a customer or supplier portal, a data warehouse, or a third-party service — through reliable, well-governed integration.
- Right when you want a modern front end over SAP: a Fiori-style or fully custom web or mobile experience that gives users a clean interface instead of raw SAP transactions, without touching the ERP core.
- Right when you want to extend SAP on BTP rather than modifying the core — keeping the digital core clean and upgrade-safe while custom logic and new capabilities live outside it.
- Wrong for a first-time ERP implementation. Standing up SAP’s core for a business that has never run it is an enormous, specialist, expensive programme measured in years, and it belongs with a dedicated SAP implementation partner, not with us.
- Wrong for most small and mid-sized businesses full stop. If you are not a genuinely large, complex enterprise with the scale, budget and internal team to justify it, SAP is the wrong tool — and we will tell you that before you spend anything, because the cheapest SAP project is the one you correctly decide not to do.
SAP: pros and cons
Strengths
- It is the definitive system of record for large-enterprise operations — one integrated data model spanning finance, supply chain, procurement, manufacturing and HR, with decades of hardening behind it.
- S/4HANA’s in-memory HANA database makes real-time reporting and analytics on live operational data genuinely fast, which older ERP architectures struggled to do.
- BTP gives you a sanctioned, upgrade-safe place to extend and integrate, so you no longer have to choose between customisation and a clean core.
- A vast ecosystem of standardised modules, APIs and OData services means most enterprise processes have a well-trodden path rather than a bespoke invention.
Trade-offs
- The cost and complexity are enormous. Licensing, infrastructure, implementation and ongoing specialist support run into figures that only large enterprises can absorb, and the total is routinely underestimated.
- Implementation timelines are long — core programmes are measured in years, not months — and the migration from ECC to S/4HANA is itself a major undertaking many organisations are still working through.
- Heavy customisation is a trap. Modifying the core to fit every local process makes the system fragile, expensive to maintain and painful to upgrade; disciplined teams keep custom logic out at the edges for exactly this reason.
- It demands genuinely specialist skills across a lot of surface area, and it is simply the wrong tool for most SMBs — the platform’s power is inseparable from a scale and complexity most organisations do not have and should not take on.
Architecture
Our guiding principle around SAP is to keep the core clean. The digital core — S/4HANA or ECC — holds the authoritative business logic and data, and the more you modify it directly, the more fragile and upgrade-hostile it becomes. So we architect our work as side-by-side extension: custom applications, services and integrations run outside SAP, on BTP or on your own infrastructure, and interact with the core only through supported, well-defined interfaces. This is the difference between an extension that survives the next upgrade and one that has to be rebuilt after it.
Concretely, that means designing clear data contracts at the SAP boundary — which OData services, APIs or events we consume and produce, what each field means, and how ownership of master data is settled between SAP and any other system. For anything more than a simple connection we introduce an integration layer rather than wiring systems point-to-point, so that mapping, transformation, error handling and monitoring live in one governed place. The result is an architecture where SAP remains the system of record, the edges do the shape-shifting, and neither side is entangled with the internals of the other.
Performance
S/4HANA runs on the in-memory HANA database, which is what makes real-time analytics on live operational data feasible where older ERP architectures forced a nightly batch and a separate reporting system. When we build over SAP we design to take advantage of that — reading aggregates and computed views the platform is good at, rather than pulling large row sets across the wire and doing the work ourselves.
The performance risk in integration work is nearly always the interface, not the core: chatty API calls, unpaged extracts, and synchronous flows that block on SAP under load. We treat SAP as a shared resource that other people depend on, so we page and batch appropriately, cache reference data that does not change every minute, and move heavy or bulk work to asynchronous, event-driven patterns. The aim is a front end or integration that feels immediate to its users without putting avoidable strain on a production ERP the whole business relies on.
Security
SAP holds some of the most sensitive data an enterprise owns — financials, payroll, supplier terms, customer records — so anything we build around it inherits a high bar. Access to SAP through our integrations is authenticated and scoped tightly: service identities with the minimum authorisations needed, secrets held in a proper vault rather than in code or configuration, and every interface respecting SAP’s own authorisation model rather than bypassing it with a powerful catch-all account.
On BTP and in any front end we build, we apply the same discipline we bring to any system handling regulated data: enforce authorisation on the server, never merely hide it in the interface; encrypt data in transit and at rest; and log access so it can be audited. We are also careful about what leaves SAP — an API or portal that over-exposes data is a breach waiting to happen, so we expose the specific fields a use case needs and no more, and treat data minimisation as a design decision rather than an afterthought.
Scalability
The SAP core is engineered to run the operations of some of the largest organisations on earth, so raw ERP capacity is rarely the constraint in the work we do. Scalability in edge and integration work is about the layer we build: an integration or extension that handles ten transactions a minute comfortably can fall over at a thousand if it was designed synchronously and point-to-point.
We plan for that from the start. Integration flows are built to be horizontally scalable and asynchronous where volume warrants it, with queues and event streams absorbing spikes rather than passing them straight through to SAP. BTP extensions scale as independent services, decoupled from the core’s release cycle, so we can grow, change or re-deploy them without touching the ERP. The consistent theme is decoupling: because the edges are separated from the core by clean contracts, each side can scale — and change — on its own terms.
SAP integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We begin by drawing the boundary honestly. On day one we establish what is genuinely edge work — integration, extension, front-end, automation — and what would be core ERP change, because those are different disciplines and we only take on the former. If the real need turns out to be a core implementation or configuration programme, we tell you plainly and help you find the right kind of SAP partner rather than stretch to fit.
For the work that is ours, we map the SAP interfaces involved before writing much code — the OData services, APIs and events, the data ownership, the volumes and the failure modes — because integration bugs are far cheaper to prevent at the contract stage than to chase in production. Then we build in thin, working slices against a real SAP environment, keeping custom logic out of the core and on BTP or our own infrastructure. The engineers who design these integrations are the ones who run them, so we favour patterns that stay supportable through SAP upgrades rather than clever ones that break at the next release.
The service behind it
Delivered throughDigital TransformationWhat we build with SAP
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use SAP in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Enterprise Platforms
Why teams choose us for SAP
Honest about the boundary
We do not pretend to be a full SAP implementation partner. We do edge work — integration, extension, front ends, automation — well, and we tell you plainly when what you need is a core programme that belongs elsewhere.
We operate what we build
The engineers who design your SAP integrations run them, so we build for the upgrade eighteen months out, not the demo. That means supported interfaces and a clean core, never fragile in-core hacks.
Senior engineers only
Touching a system the whole business depends on is not a place for people learning on the job. The people designing your integration have done it before and understand what a mistake against production SAP costs.
Clean-core discipline
We keep custom logic out of the SAP core and on BTP or your own infrastructure, so your ERP stays supportable and upgrade-safe — the opposite of the heavy customisation that traps so many SAP estates.
Typical timeline
- 01
Discovery and boundary-setting
One to two weeks confirming the work is edge integration or extension rather than core ERP change, mapping the SAP interfaces, data ownership and volumes, and agreeing the architecture.
- 02
First integration slice
Two to four weeks delivering one real interface or feature end to end against a real SAP environment, proving the data contracts and the approach before scaling up.
- 03
Iterative build
Interface by interface, or feature by feature, in short cycles — each shippable — with error handling, monitoring and security built in as we go rather than added later.
- 04
Hardening and handover
Load and failure testing against realistic volumes, monitoring and alerting on the integration layer, and documentation so your team can operate and extend what we have built.
How pricing works
- Fixed-scope integration or front-end builds — a specific portal, a defined set of SAP interfaces, one bespoke application over SAP — quoted once we have mapped the interfaces and data involved.
- Monthly senior engagement for ongoing SAP edge work, where a programme of integrations, extensions and automations evolves and you want continuity rather than a single deliverable.
- Focused discovery and integration audits — assessing an existing SAP integration landscape, a stalled BTP project, or the feasibility of a proposed connection — priced by the assessment.
Hire SAP engineers
Need SAP capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire SAP engineersCommon questions
Do you implement SAP from scratch?
No, and we will not pretend otherwise. A first-time core ERP implementation is a specialist, multi-year, multi-million-pound programme that belongs with a dedicated SAP implementation partner. Our work is at the edges of an SAP system you already run — integration, extension on BTP, modern front ends and automation. If your real need is a core implementation, we will say so and point you toward the right kind of partner.
What is the difference between S/4HANA and ECC, and does it matter for our project?
ECC is the older generation of SAP’s ERP; S/4HANA is the modern rewrite running on the in-memory HANA database, and many organisations are still migrating from one to the other. For edge work it matters because the available interfaces and data models differ, and because an integration built during a migration needs to survive the switch. We work with both and design accordingly.
Should our SME be using SAP at all?
Almost certainly not. SAP’s power is inseparable from the scale, budget and internal expertise of a genuinely large, complex enterprise. For most small and mid-sized businesses the cost and complexity vastly outweigh the benefit, and a lighter system serves them far better. If you ask us and the honest answer is that SAP is wrong for you, that is the answer you will get.
Why build on BTP instead of just customising SAP directly?
Because modifying the core makes SAP fragile and painful to upgrade. Building extensions side-by-side on the Business Technology Platform keeps custom logic outside the digital core, so you gain new capability while the ERP stays clean and upgrade-safe. It is more disciplined up front and far cheaper over the life of the system than in-core customisation you have to rework at every upgrade.
How do you get data out of SAP into our other systems?
Through SAP’s supported interfaces — OData services, REST and SOAP APIs, and event mechanisms — rather than by reaching into the database behind its back. We expose the specific data and operations you need as clean, documented APIs, and for anything beyond a simple connection we put a proper integration layer in between, with mapping, error handling, retries and monitoring, so the flow is reliable and observable rather than a brittle script.
Building on SAP?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.