Issue

Several processes at Syensqo benefit from the use of mobile devices either as a core part of a business process, or to provide an alternative interaction mechanism to Desktop PCs for convenience purposes. Typically several different options exist for the implementation of mobile access mechanisms and SAP do not provide a generic/native standard that caters for all scenarios as a default.  This document seeks to provide a decision-making framework for the choice of mobile application or mobile application platform to be used. 

Recommendation

Where no suitable pre-built application is available on a public App Store, solutions using the Neptune DXP platform are preferred over alternatives. Commercial off-the-shelf applications developed by Neptune partners are preferred over in-house developed applications provided a reasonable functional fit is attainable, and the applications offer extensibility mechanisms compatible with Clean Core principles. Should this not be available, a "build vs. buy" decision should be evaluated using Neptune DXP as the preferred development platform for the custom-development option. This recommendation thus embodies an explicit preference for the use of the Neptune platform due to its proven track record at Solvay/Syensqo, and in recognition of economies of scale in licensing, development, and support. The principle of Simplicity also guides this recommendation by limiting the number of development platforms in concurrent use. 

The following decision tree summarises the decision-making process: 

Background & Context

Syensqo has experience in the deployment and management of mobile devices and applications in a range of contexts. For example, specialised industrial mobile devices (i.e. ruggedised Zebra devices running Android OS) are used across several GBUs for the Nereid solution for inventory management, while both off-the-shelf and custom-developed mobile apps are available for Syensqo-owned and employee-owned devices through the Ivanti mobile device management solution. Many of the enterprise systems planned to be deployed by the ERP Rebuild program also provide mobile interfaces either via native mobile applications available in public app stores (e.g. for Concur and SuccessFactors), or mobile-capable web UIs. 

Assumptions

• It is not possible, nor is it desirable from a usability perspective, to have a single mobile app through which all users access all of the functionality provided by the ERP Rebuild program. 
• Although browser-based UIs are the main method of interacting with systems in scope of ERP Rebuild, the limitations of mobile browsers and web technologies mean browser-based UIs cannot be the sole access mechanism for mobile users. In some situations, e.g. for warehousing applications, native integration with hardware features such as barcode scanners might be required, while some SaaS applications will provide native applications as the sole supported mobile UI. 
• Both Android and iOS are considered to be primary mobile device operating systems with which native apps must be compatible. 
• For Android, reliance on Google services should be minimised or eliminated. Google services are generally blocked in China. Although devices connected to Syensqo's internal network can communicate with Google's services, run-time reliance on Google services may limit the ability of apps to be used outside of the Syensqo network in China (e.g. while using a mobile internet connection). 
• Syensqo's mobile use cases are internal and employee-facing, rather than provided for the general public.
  • At the time of writing, Syensqo does not publish any apps on the Apple iOS App Store or the Google Play Store for the use by customers, partners, suppliers, etc. 
  • Use cases do not exhibit the graphical, latency, and performance requirements which are typically met through the use of native development tools (e.g. gaming apps coded in Swift or Java). 
  • Apps do not need to pass the quality games imposed by Google and Apple for apps published to their respective public app stores. 
• Mobile applications can be pushed to Syensqo-managed devices using Mobile Device Management regardless of how they were developed. 

Constraints

• The decision-making process is primarily concerned with mobile applications interacting with applications from the SAP ecosystem. Neptune DXP does support non-SAP backends as well via the Open Edition of the product. Being built using Node.js and SQLite or SQLServer, it can be deployed on a wide range of application hosting platforms including on SAP BTP if required. 
• The decision tree precludes the use of SAP's own mobile app development platform. At the time of writing, this does not deliver any capabilities which cannot otherwise be obtained via Neptune DXP, nor any commercial/licensing advantages. 

Impacts

• Syensqo should continue to invest in the maintenance of technical skills for the Neptune DXP product, including in skilled UI5 developers. 
• The application of this decision tree makes it unlikely that native mobile programming skills (e.g. in the Swift language) will be required. 
• It may be possible to reuse existing Neptune developments in the future ERP landscape. 
• Beyond the ERP Rebuild program, ongoing enforcement of this decision tree via IT Architecture governance is required. 

Business Rules

N/A - this document is primarily concerned with technology choices and does not impose business rules. 

Options considered

Option A: Use SAP Mobile Services as the primary platform

SAP Mobile Services is an umbrella platform composed of a number of distinct but related technologies integrated via runtime and management tooling on SAP BTP: 

• SAP Mobile Development Kit - a low-code toolkit for development hybrid mobile apps
• Native SDKs for iOS and Android - libraries, extensions, and building blocks for native app development on iOS (using Swift) and Android (using Java), deployed as add-ons into the respective native development tools
• BTP-based backend tools which act as the server-side components for mobile applications, providing OData APIs for apps to interact with data, communicate to back-end systems such as S/4HANA, etc. 

In this option, SAP's own mobile development platform is used as the primary platform for mobile apps in the future ERP Rebuild landscape. Many of SAP's own mobile applications such as SAP Service and Asset Manager, are built on or migrated to this platform. Of note is that SAP's strategy in this domain has been quite fluid over the past decade; and that various different products and platforms have at times been designated as SAP's preference, from NetWeaver Mobile, to platforms acquired via Sybase, Syclo, and AppGyver. As of 2024, SAP Mobile Services is also the second iteration of a PaaS option which is hosted by SAP. 

Option B: Use Neptune DXP as the primary platform

Neptune is a Norwegian company focused on mobile-enabling SAP systems via a development platform that is tightly integrated into SAP's ABAP stack and aims to minimise the learning curve for SAP developers. The core product has remained consistent since the company's founding in 2011, and is focused on hybrid mobile app development (rather than fully native apps). Reuse of functionality, code and data models provided by SAP systems is a priority, including use of the same UI5 front-end libraries also used by SAP Fiori. Over time, Neptune's offering was extended to non-SAP backend systems via the Open Edition that can be deployed outside of an SAP stack and was designed to interact with non-SAP systems, but provide a similar developer experience and tooling. Neptune provides a library of pre-built modules to speed up development of complex but business-agnostic functions, such as offline data sync, authentication, barcode scanning, etc. A rich partner ecosystem provides a significant number of pre-built applications running on the Neptune platform to address specific business requirements. These applications can also be extended using the Neptune platform. 

Option C: Avoid designating a primary platform

In this option, the designation of a primary target platform is avoided, leaving this instead to individual implementation projects to choose based on their individual requirements and available choices at the time. This option prioritises functional fit and implementation convenience over architecture concerns, and acknowledges that a multitude of mobile development platforms will co-exist at Syensqo. 

Evaluation

See also

Mobile Device Management

Network architecture for China

KDD036 - User Access to Enterprise Systems

KDD025 - Mobility Solutions in Logistics and Warehouse Management Processes

KDD016 - Mobility Solution Direction for Enterprise Asset Management

Explanation of Clean Core, by SAP Learning

Change log

Workflow history