Should I use Fiori Elements for my app?

Developing Fiori apps isn’t as easy as it once was. When Fiori was announced, it was a new and simple approach to design enterprise apps. Was, because the approach met reality. Reality regarding customer requirements as well as SAP specific requirements. With a customer base reaching from small to very, very large companies and a backlog that goes back decades, even before the world wide web was born, it is naïve to think that a new design fits every use case. Even fitting most use cases is a challenge as there are simply so many of them. The Fiori Design Guidelines and the evolution they did over the last years (rather a decade) show this in all clarity: started for web apps and a few floorplans and patterns with some UI controls is now a design guideline for many different scenarios. As a side effect, the number of UI controls available grew significantly. In the current version (1.100.2) it is 296 entries in the sample list, while for 1.30.8 it only have been 181. And before 1.30 there were even less. The growth is based in customer and project requirements. For instance, draft handling was introduced to fulfill basic customer requirements. To be able to cope with all these new requirements and challenges that come with appifying the backlog, SAP introduced Fiori Elements. This is the most drastic change in the whole Fiori development process since Fiori was introduced.

Rough start

Change is not necessarily bad. Au contraire: based on the quality of the first waves of Fiori apps from SAP, change is highly welcome. At that time, not every Fiori app did work. Navigation between items in the master list might have worked on a desktop browser but was broken on mobile. Lists were not loading, views not displayed because of coding issues. Clearly not every app was tested. Nor every app was driven by customer demand. The number of apps delivered in a wave was more driven by management order then by real demand or quality. SAP promised new apps every quarter, and that’s what was enforced. It was not uncommon to find out that the Fiori app available for your SAP system was already outdated as the SAP team moved on to the next release. Or that an app available since over a year just did not work out of the box because of a bug, that was never found as you were the first one to use the app. Quality initiates were announced, some mea culpa at SAP events, but it was clear that the common way to develop apps is not fitting SAP’s reality. Not only regarding quality, but the sheer number of apps SAP needs to deliver. A first indication that SAP has capitulated before the task was the visual harmonization project (2016). If you are not familiar with that name: the outcome was that SAP took 7.000+ SAP Gui for Web transactions, made a new theme and branded them as Fiori and added them to the Fiori Apps Library. Filtering today for SAP Gui apps in the list reveals 14860 apps. This clearly shows that SAP has a problem.

Too many apps to handle

SAP has ten of thousands of transactions in their ERP system. As Fiori is not the first take on making SAP look good, there are also Web Dynpro apps. If you leave SAP’s core ERP system, then you find CRM apps, and other solutions. And that’s just what you get from SAP. Partners and customers developed their own apps based on frameworks once recommended – if not using their own frameworks. How to bring this to Fiori? One approach, and one I think should get more visibility is SAP Screen Personas. Perfect approach if you want to deliver great UX without having to redevelop your working and proven “legacy” apps. Problem: the Screen Personas approach works for customers, not so well for SAP. SAP delivers standard apps that can then be adjusted or enhanced by customers. A Screen Personas flavor would already be a customization and not standard (the underlying transaction being the standard).

What SAP makes great at customers is that people with business understanding create apps. The typical SAP developer is an ABAP dev that creates full stack apps deeply aligned with the business area. That person might know better the business domain than the functional consultant. With “little” effort an ABAP dev can create an app with a basic UI. That’s the secret why SAP is successful and why there are so many transactions available: from SAP, partners and from customers. Making all those devs learn Fiori and how to code web apps is not realistic. That’s a lesson learned from Web Dynpro. Also, these people get their money to be productive and solve business problems in code. Letting them develop Fiori apps by coding implies that the app also needs to be developed and maintained. Additional effort to the already existing backend work. While this fits the full stack developer role, it is not providing the same level of productivity as ABAP and transactions provides to these developers already today. While a custom developed Fiori app delivers the best UX, this is rarely what customers need. They might ask for it, but what they need is apps that help them solve a problem. At the same time, the app must be maintained and enhanced at low costs. That’s hard to achieve, if not impossible. One of the reasons that transactions are still developed en masse. Not because it’s fun, but because there is not a viable alternative available. This problem is shared by SAP and customers. For SAP it is exceptionally complicated: how to bring thousands of transactions to the web? How to deliver them to customers? How to let customers adjust these apps? And be able to support them?

Fiori Elements

Hiring thousands of Fiori developers is not a solution. And would send out a wrong signal to customers. SAP came up with a solution to these problems: Fiori Elements (FE). The backend developer can focus on the backend and on the data modelling, making the best out of the business and domain knowledge: knowing how entities relate and their constraints. This gets incorporated into the service metadata and annotations. Correctly annotated by the developer, the service is transformed into a Fiori App. This is low code Fiori development for OData / ABAP developers. Instead of having to learn JavaScript and how to create a Fiori App, this is done automatically by FE. The same, if not even higher level of productivity a customer is used to from their ABAP developers is retained and brought to Fiori development. This is a relief for the SAP universe: upskilling instead of having to hire and train new people at scale.

Problem solved for SAP

Fiori Elements puts SAP into the position to be able to deliver a high number of quality Fiori apps to customers. Instead of having to cope with frontend development for all these apps, this effort is minimized and sets resources free to work on other topics. Many problems SAP had in the beginning of Fiori development and shipment are solved. Quality gets automatically to a very high level as basic coding issues are eliminated. No more time wasted with repeating Fiori development problems like master / detail navigation, showing the item count, semantic coloring, etc. FE does this for you, the information is retrieved from the backend. As the Fiori app is not really developed, rather generated on-the-fly by Fiori Elements, updating an app is easy. Design related questions are eliminated as the app is using what FE provides. For a detail page, the object page floorplan is used. The impact of frontend developers and how they interpret Fiori is eliminated. FE transforms Fiori development into a fabric. Instead of having to code variant management, table filtering, sorting, draft handling, navigation, it is “just” annotating a service. All of this frees up a lot of developer resources and lets developers focus on what is important: business logic.

For SAP creating FE solved a huge problem. It allows them to deliver standard apps that met a high level of quality and let customers adopt / customize them and being able to support the FE apps. All at low effort – compared to writing everything as a freestyle Fiori app. Effort can now go into improving the business solution (that’s what customers pay SAP for) while at the same time deliver Fiori apps without having to care too much about the frontend. SAP can deliver a standard app for everyone, and use the FE and FLP features to let customers adopt or customize the app. Previous situations of badly coded Fiori apps are almost eliminated. Updating a FE app is transparent, as only the FLP and SAPUI5 components must be updated (as long as the FE app wasn’t customized via coding). Switching from on premise to cloud or to new S/4 version is easy. This also frees up resources at SAP and customers (support, consulting, implementation, testing, etc). Of course, still not 100% perfect. The available floorplans are limited. FE is receiving constantly new features, you need to update your FLP, have a recent S/4HANA release to get the most out of FE. Most important here is: FE works for SAP.

And for you?

And that’s where customers need to take a closer look if FE works for them too. For the standard apps, the decision is easy. This is what you get from SAP, use it. You are not going to develop every app on your own again. (you might be able to reuse the OData service for your own apps, but that is a different problem.) Using FE for your own custom development? The important question is: does the app delivery model that works for SAP fits your own use case and works for you? Is this how you can develop apps? Can you maintain apps like this? Do your own customers accept this for custom apps? For most of your apps, the answer should be: yes. As I already stated, most users want an app that helps them to get the job done. It does not have to be a perfect app. Many times, the costs for developing a perfect app are too high: not enough users, impact is too low, only sporadic usage. UI5 developers are still a rare resource. The biggest vantage of FE is: experienced ABAP developers can bring modern Fiori apps to the users. These apps might fit 80% of your use cases. The FE apps might not look super cool, but better an app that works now than having to wait 6+ months for the Fiori development to finish or not having a Fiori app at all because of budget, time and team restrictions. For all other apps investing into additional effort might be the better choice. Those apps can be hand crafted Fiori apps (freestyle), or native apps, or not Fiori related at all.

Remember that there is not easy rule to apply. An app that today is best developed in FE might turn into a freestyle Fiori app, then a native app and maybe back to FE over a 5+ year journey. Don’t be too committed on one approach. You should nevertheless be aware that Fiori Elements solves a specific SAP related problem. If this is your problem too, use Fiori Elements.