A lot of companies are struggling with the question how to unlock the vast resources of their SAP installation for mobile development. Should we wait for the technologies SAP promises in its roadmaps or are there alternatives?
SAP has been around for a long time and during its time it has proven to be a secure, reliable and robust transactional system. Frankly, it is unrivaled as a system-of-record and will stay that way for many years to come. The technology behind it is mature and has proven to be able to guarantee data integrity and avoid data loss, while its performance is fully scalable to any size operation.
But however sound the technique behind their transactional system, SAP has been struggling with its UX strategy for years. New technology after new technology has been heaped up on the stack year after year, some of them developed in Waldorf, others acquired. If you are a typical SAP shop that has been around for a couple of years, you will now have at least developed web pages in ABAP Webdynpro, Floorplan Manager, Adobe Interactive Forms, WebUI – including BOL and GenIL –, and probably some more. Almost all of you will have at least one portal and possibly a federated portal. And when it comes to mobile, you might have done something with SAP Gateway and SAPUI5, but chances are you don’t have an app that is linked to SAP directly.
As you can see there is a plethora of technologies and tools you need to have on your team to support all this. Resources with these skills are pretty hard to find, but if you do happen to find the right people, having such a big team is on the expensive side and inevitably adds complexity to projects. A bigger problem is that SAP can be quite erratic in their choices of tools. Sometimes web and mobile technologies that had been presented as their new flagship technology were abandoned a couple of years later again (e.g. Webdynpro for Java), making your investment in these technologies useless: the code created was completely locked into the tool and you had to simply start over. Examples like these show that you can’t blindly trust SAP’s roadmaps when making your technology decisions.
This lock-in is a serious issue. All the technology tools SAP offers have some form of lock-in, meaning you can’t simply take the code you created and use it independently. The result of this is a reduction of flexibility: if you would like to develop for a new device, for instance Microsoft Hololens, you would have to wait until SAP comes with an update of their library to support this. Because of your investment, you will not walk away from the SAP tool, but will wait for the update. But if this takes too long or SAP has no plans to support the new device, what you really want to be able to do is to pick up your code and move to a platform that does support all of your business scenarios. The same goes when a great new platform comes to the market that clearly outcompetes your current one: you want to be able to pick up your current code and move it to the new, better platform.
It is clear that SAP is an excellent system-of-records system. And that is exactly what it should focus its attention on: to stay the best system-of-records system on the market. However, the matter of the fact is that SAP has proven that it can’t currently meet the high standards for omnichannel development to create beautiful user experiences on all devices. This is a problem, because research shows that mobile phones are now the prime window shop for customers, while also becoming the preferred choice of connecting to the network for enterprise workers. If you are not out there with great apps that fully use the latest technological possibilities you are losing business. And that app should be tied directly into your backend transaction system for the best possible responsiveness to the people using it.
The current fast pace of online application development asks for a whole new way of development. There is a large demand for fast delivery of mobile applications that are both performing well, are easy to change to new demands or technologies and that captivate the customer with a great online experience; but on the other hand there is a similar demand for a slower moving, but extremely reliable transactional system-of-records system to administer the business. Because of their contradictory nature these two are incompatible on one system, so the only possible answer is to separate them and adopt a two-tier strategy.
What this allows you to do is leave SAP as your transactional backend and stop developing frontend applications on it. This will leave your SAP environment cleaner, faster and more stable, so it can be what it is supposed to be: the transactional system that crunches your numbers. At the same time you have a tier 2 platform on which you can rapidly develop and deliver applications to your employees and customers that will delight them. If you only use standard SAP objects this will not only keep the SAP code stack clean, but also free your application development team from the rigid release schedules that most SAP systems are subject to, meaning you can deploy your applications to production independently, allowing for true agility and Rapid Application Delivery.
There are many RAD platforms out there, but only two have reached the maturity that allows for very robust and performing integration with SAP: OutSystems and Mendix. While Mendix is well suited to create your BPM and Workflow, it lacks capabilities in terms of rapid omnichannel application development and has limited capabilities when it comes to solution deployment and DevOps. OutSystems on the other hand has evolved into a complete RAD platform with intuitive code-less application development with seamless SAP integration. Also, OutSystems has invested heavily in Application Lifetime Management and has included mature deployment and monitoring options in their system. Currently OutSystems is the only RAD Platform capable of connecting to SAP natively and possesses all the features needed for developing for all devices imaginable. It also allows for developing a clear architecture for building your apps using SAP functions, to keep your platform maintainable and scalable. Your new technical SAP stack would change dramatically.
Separating your application development from your transactional backend does not limit your SAP investment. On the contrary: it unleashes the SAP system, so you can make full use of its data and functions without being held back by SAP’s technology decisions. You get the best of two worlds: a transactional diesel that does the math and adds the accounts in combination with a Rapid Application Delivery platform that allows you to develop agile applications for great user experience on any device.
Question? Remarks? You can contact me at my LinkedIn account or send an email to r.vandekerkhof@novioq.com.
You must be logged in to post a comment.