no-code SAP AppGyver Ruum [shutterstock: 760704667, Susan Schmitz]
[shutterstock: 760704667, Susan Schmitz]
Blog SOH and S/4

SAP’s Zoo Of No-Code Tools

I have used no-code tools in three areas: case tools where the UI is generated out of database tables and user intent; as various types of data integration tools; and for UI development.

The goal in all use cases is to create a solution more efficiently and with less technical knowledge. Business users sketch what should be done, the execution plan or code is generated automatically.

Against this backdrop, I looked at various tools proactively offered by SAP to better understand which one to use in which case, and validated my findings with SAP.

Which no-code tools to compare?

For better clarity, I would like to separate each tool into three areas:

ad_banner
  • Context. What business problem is the tool trying to solve?
  • Efficiency of the tool. Looking at the entire lifecycle of the product, what are the cost savings?
  • User-friendliness. What can business users accomplish on their own, and what are the limitations?

This only leaves the question of which tools to pick. As is often the case, marketing jumped on the bandwagon of no-code tools; everything that has a UI to configure something is labeled a no-code tool nowadays. Is the SAP Cloud Platform Integration Suite a no-code tool, because it allows to draw a sequence of API calls? If so, we would have to call any graphical ETL tool a no-code tool as well, as it allows to draw dataflows with Extraction/Transformation/Loading flows and executes them afterwards.

UI builders for ERP

Let’s limit ourselves to tools aimed at creating applications with UIs for regular users. This is the area with the most overlap between SAP’s tools. Example: We want to build an application that highlights if a sales order is marked as in-doubt (“Do you really want to order 1 million cars in this single sales order? I doubt that!”) and requires a business expert to decide if that order is forwarded to the manufacturing line or if it would be better to talk to the customer first.

For such typical ERP applications, the tools labeled as low-code/no-code by SAP are:

  • Business Application Studio. Used for any application, the initial setup is cumbersome. Even though code can be generated based on templates, you will be confronted with hardcore programming after setup. This shouldn’t even be considered a low-code tool, not to mention a no-code one.
  • AppGyver. Used primarily to configure UIs, it is limited to combinations of elements and data. Based on provided graphical elements, business users create new UIs and integrate data. It does not use Fiori or SAPUI5 and custom code is not supported.
  • Mendix. A third-party tool used to configure UIs. It allows users to build any application they want, but is neither using Fiori nor SAPUI5.
  • Signavio. Primarily limited to workflows, this tool provides the functionality to add UI screens to display data and decide what the outcome of the current workflow task should be (for example, to accept or decline an order).
  • Ruum. Based on SAPUI5, it allows users to augment existing S/4 Hana processes.

There are more tools, but they did not make the final cut. Those include:

  • SAP Intelligent RPA. Used to automate repetitive tasks, it would be a stretch to call it a development tool.
  • SAP Workflow Management. Used to draw workflows, it is decidedly not an application development tool.
  • SAP Cloud Platform Integration. It is primarily used to create chains of API calls, so it is not a general-purpose development tool.
  • Mobile Development Kit. It is a tool to build mobile apps faster, but it is too limited in scope and typically not leveraged by business users.

SAP provides multiple tools, sometimes even for the same area, e.g. Ruum and Signavio for workflows or AppGyver, Business Application Studio, and Mendix for UI development. Each tool has its unique pros and cons and often is part of one specific larger application. For example, Signavio is primarily a process-mining tool which happens to offer the option of creating workflows and, because workflows often include a manual component, the UI builder is part of it, too.

One tool for all?

Another way to look at the above list is in the hierarchy of product contexts. A tool to build Signavio workflow screens is limited to just this one task. A tool for any kind of UI applications can do more, including displaying workflow screens and calling APIs of workflow engines. A tool that covers not only the UI development but also the backend would be even more flexible – in the overview I provided, this tool exists in the form of Business Application Studio. However, Business Application Studio is the weakest link, since it does not offer any graphical UI editor. From an objective point of view, it most certainly is not a no-code development tool.

A better architectural design would be to have a graphical UI editor based on SAPUI5 to get the Fiori style into the applications. Then all UIs would look and feel like the ERP system. While this is technically possible, as long as the responsible SAP team does not acknowledge the possibility, there will be no change.

Another design rule: no matter how powerful a UI editor is, there will be cases that require programming. Such editors must therefore allow for manual intervention without breaking. AppGyver explicitly does not, which limits it to very basic UIs. SAPUI5 is such a beautifully built framework, it would be very simple to allow both directions: generating UIs from the graphical editor and enhancing them manually or taking custom-built or modified code and visualizing it in the graphical UI editor.

Conclusion

Which leaves us, the SAP users, in the dark, with no idea which tool will be enhanced the most or the fastest, as it mostly depends on the political climate within SAP. Consequently, some customers will pick one or the other, some will look at third-party solutions (there are quite a few nice products specifically for SAP available!), and the majority will not invest at all due to the uncertainty.

One day in the far future, SAP will do the right thing and have one powerful UI editor in BTP which can then be used for all use cases. In the meantime, we have to use different no-code tools for different projects. A Signavio-centered project builds UIs with this tool, S/4 Hana customizations require the S/4 Hana Extensibility Framework or Ruum, and simple UIs can be built with AppGyver or any other third-party solution.

About the author

Werner Daehn, rtdi.io

Werner Daehn, former SAP employee, is an expert on big data and smart data integration. He is also the CEO of rtdi.io.

Add Comment

Click here to post a comment

Social Media

ad_banner
Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "[email protected]", "[email protected]" or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .


After submitting your contact details you will receive an email containing our media kit.

Please select an optionMr.Mrs.
Our Authors