SAP has spent the past few years making a public case for event-driven architecture. The argument, laid out in SAP's own explainer on the topic, is a good one: systems should react to changes of state as they happen, communicate asynchronously, and stay loosely coupled. SAP's integration guidance goes a step further and connects event-driven architecture directly to clean core maintenance.
We agreed, and built Arkyn's FastApps on exactly those principles. What still surprises people is the gap between that guidance and how data actually moves in most SAP mobile maintenance deployments today, including in SAP's own product for the job.
This post covers how synchronization typically works between SAP Plant Maintenance and mobile devices, why the standard model strains at enterprise scale, and how we designed FastCloud, Arkyn's SAP integration platform, to run event-driven synchronization on SAP BTP with no modifications to the SAP core.
The standard model: client-initiated delta sync.
SAP Service and Asset Manager (SSAM) is SAP's mobile application for plant maintenance, and its synchronization model is well documented in SAP's own implementation materials. It is an OData V2 application built with the Mobile Development Kit, running on SAP BTP Mobile Services with the offline OData feature. The backend side runs through the Mobile Application Integration Framework, delivered as the SAP Mobile Add-On on the SAP system.
The sync cycle works like this:
- The device opens a sync session against the backend.
- SAP Gateway calculates what has changed since the last session, using delta tokens to work out the incremental changes per entity set.
- The response is written into the offline store on the device, and queued changes from the device are played back to SAP.
There is nothing wrong with delta sync as an optimization. It moves far less data than full replication, and SAP has tuned it carefully. But it is a pull model and nothing reaches the device until the device asks, and every time a device asks, the SAP system does the work of answering.
Where pull-based sync struggles.
Run that model with fifty users and you shouldn't notice it. Run it with thousands and three problems show up.
The first is load concentration.
Shift start is the worst case: hundreds of devices open sync sessions inside the same fifteen minutes, and the SAP system computes delta responses for each one.
The second is staleness.
Between sync sessions, the device holds a snapshot. A planner reassigns a work order at 09:10, and a technician who synced at 09:00 is still driving to the wrong job. The data on the device is only as fresh as the last pull.
The third follows from the second, and it is the one that kills rollouts: trust.
When technicians find stale or conflicting information often enough, they stop relying on the app, start calling the planner again, and revert to paper.
Building event-driven sync on SAP BTP.
FastCloud runs natively on SAP BTP, in a dedicated subaccount, on the Cloud Foundry runtime, using standard BTP services: SAP Event Mesh, the Connectivity Service, SAP Cloud Identity Services, and the Authorization and Trust Management service.
For work order changes, the model is the opposite. When a work order changes in SAP, the change is published as an event through SAP's NetWeaver Event-Enablement Add-On, routed through Event Mesh, processed by FastCloud, and pushed to the apps that need it.
The clean core part matters just as much as the real-time part. There are no SAP core modifications and no custom ABAP to maintain. The Event-Enablement Add-On is SAP's standard component for event-enabling ECC and S/4HANA systems, and Arkyn's backend components are delivered in a separate namespace, isolated from the core.
One big benefit of this design is migration continuity. Because the integration depends on SAP's standard event and connectivity services rather than custom code in the core, the same setup works on ECC, S/4HANA, and hybrid landscapes. When a customer migrates, the integration migrates with them.
Offline is still the hard part.
Events solve freshness from server to device, but they do not solve all the complications of the frontline, where technicians work in basements, on pipelines, and inside steel structures with no signal at all.
Our apps are built to handle offline scenarios so technicians keep working without connectivity, with data syncing automatically and reliably to SAP once they are back online.
What the architecture adds up to.
Architecture choices show up in adoption numbers. Across Arkyn deployments, FastWork averages an 85% adoption rate, and most deployments go live in 2 to 6 weeks because integration starts from pre-built SAP PM and CS process coverage rather than a blank slate.
At Energy Transfer, a Fortune 500 pipeline operator, more than 8,000 SAP technicians work from Arkyn's iOS apps.
Intuitive design earns the first week of usage. The synchronization architecture, the part nobody sees, earns the weeks after that, because it keeps the users' trust.
If you are evaluating mobile maintenance for SAP, ask one architectural question early: when a work order changes in SAP, how does it reach the device? If the honest answer is "when the device next asks," you should understand what that means for load, latency, and trust at your scale before you commit.
About the Author.
Rune Durhuus-Andersen is co-founder and CTO of Arkyn. He has spent over 20 years building enterprise SAP software, including 13 years leading engineering at Invokers, now Trifork Smart Enterprise. He is currently leading Arkyn's innovation in AI and technology.