Your next obsolete skill: UI5 development

On the horizon changes are manifesting. And these will turn UI5 development into a rather obsolete skill.

For many developers, freestyle UI5 development is the preferred approach to create a new UI5 app. It is a popular choice among UI5 developers for several reasons. First, freestyle UI5 development is the original way of creating UI5 apps. Another reason is that the overall developer experience for freestyle apps increased drastically over the last decade. The tooling available today helps enormously. A lot of tasks that made UI5 development once rather complicated are almost eliminated. This makes freestyle UI5 development rather enjoyable. An important reason is the quality of the OData service provided by the backend. Or the lack of quality. Associations to entities might be missing, filter, sorting or reading an entity directly, batch or deep insert are not implemented. In such cases, the UI5 developer was able to cover up the lack of quality in the backend. Yet, the lack of quality on the OData services is coming to an end. The ABAP RESTful Programming Model (RAP) is overcoming many problems that SEGW based development allowed to happen. RAP and CAP ensure that the developer follows a framework more closely. For Fiori development it aligns the frontend and backend app closer together by making Fiori Elements the first choice to use for the app.

The changes in the tooling, frameworks and the roadmaps will have an impact on UI5 development.

Constant Changes

Technology constantly changes and so are the skills needed. Web site development evolved from basic HTML and CSS to dynamic apps. In the early 2000’s it was common to develop enterprise Java apps using J2EE. Today Java apps are deployed to some cloud, including high availability, without having to own a deep knowledge of infrastructure. JSP was once an important skill for web apps. Today web apps are developed using Angular, React or Vue. SAP technologies may be subject to a different rhythm here but are of course not immune. Basic NetWeaver technology will still be part of S/4HANA in 2040, just as other technologies like SOAP web services or even IDocs. You could witness in the last 20+ years how technologies were hyped, adopted, used, and later declared obsolete. Technologies that focus on the user have a higher change frequency. For instance, Web Dynpro Java, Visual Composer, Duet, SAP Portal, SUP, Kapsel, SMP, etc. Just think of all the JavaScript frameworks that are available and promise to make it easy to develop apps.

Having to learn something new is not bad and at least outside the SAP universe common. This constant renewal is proof that there is innovation. Old technology gets assimilated or replaced. Rarely it gets completely obsolete at once. Change takes time and normally the ideas, or basic assumptions, of what will be replaced, will carry on. Early low code apps like Visual Composer did not survive the changes in web technology. The basic idea to let a user build its own app based on services, did. Others like the SAP Portal rather evolved over time into modern products like Work Zone. The idea of providing a single point of entry with a transparent access to apps to end users is still important.

Demand for Fiori Apps

What does this have to do with UI5 development? There are many UI5 apps developed to meet the user requirements and to offer a modern UX. Why should UI5 development become obsolete? Companies need to deliver Fiori apps and depend also on UI5 to do so. Everywhere you can see the demand for UI5 apps and developers. Companies are moving over to S/4HANA and an easy way to prepare for this is to offer Fiori apps. The thing here is: developers believe that UI5 skills are needed to deliver on the company demand for Fiori apps. And that’s where the error lies: users want an app that helps them to solve a task. Companies want that those apps work with SAP. Therefore, those apps should be Fiori apps. The demand is for Fiori apps. Not UI5 apps.

UI5 is one of many alternatives to deliver a Fiori app. There are other ways to deliver an app that follows the Fiori design guidelines. From SAP you get MDK, Fiori for iOS/Android. There is SAP Build Code or SAP Build Apps. Here the focus is on the result, the app, not on the how to get the app. Maybe in a few years, sketches, notes and requirements serve to get an AI generated Fiori app. As long as it works and can be enhanced and maintained, companies won’t care if the underlying technology is a UI5 freestyle app or something else. Contrary to this, currently mostly UI5 freestyle apps are delivered by developers. This won’t change soon, as developers that learned Fiori and UI5 development in the last years did so by mostly by writing freestyle UI5 apps. Smart controls made the development of UI5 apps easier. Not only do they make development faster, but also automatically aligned with the Fiori guidelines. And: the missing quality of OData services is revealed. While smart controls are an accelerator for freestyle development and help in having better OData service, the developer still must take care of a lot of things like navigation, page layout, placing information, action flows, etc. Tools help, but in the end, it is still the task of a developer to ensure the app works and follows the Fiori guidelines. This is a work intensive and time-consuming process.

The fact that a Fiori app is not necessarily an UI5 app is more and more accepted. After all, UI5 freestyle is only one alternative to develop a Fiori app. Looking a few years into the future, Fiori Elements will be the default for Fiori App development. Fiori Elements will replace UI5 freestyle apps.

Fiori Elements

There are two components involved that work together and depend on each other: Fiori Elements in the frontend (UI5) and the OData service in the backend (RAP). Both frameworks evolved drastically over the last years. It is possible to develop complex Fiori apps just by using annotations. A Fiori Elements app enforces some rules on both frontend and backend that make it easy for companies to benefit from it.

• Backend: the service must have a high quality. The data model must be complete. The provided annotations should be good enough to deliver a working app. Meaning that things like value help, tables, object pages or editing do work and show all the information needed by the end user.
• Frontend: a good thing about Fiori Elements is: in the best case, the app is realized on the fly by using the annotations from the backend. The app follows automatically the Fiori guidelines. Updates get a non-event. The less changes are done by the frontend developer, the better. Which implies: changes demanded by the business must be justified and unnecessary changes can be declined by referring to Fiori Elements.

Let’s take a closer look at some of the reasons and assumption for the shift to Fiori Elements.

OData

The quality of the OData service will increase. OData v4 services will be common. Services will offer advanced features like draft handling. OData v4 is the best choice for Fiori Elements apps. OData v4 is currently not as used as OData v2. Again, this is due to the past. When UI5 development started, the only option was OData v2. In earlier releases of S/4HANA, OData v2 was used. The same for RAP: OData v4 is only recently (in SAP terms) available and recommended. This was different for CAP where OData v4 was the default way to go very early. But then CAP lacks adoption and most Fiori apps at customers are ABAP based. OData v4 is the future way for services. Realizing OData v4 services with RAP is easy. The quality delivered by a RAP service is normally higher than with SEGW. While OData v2 services will be available for years to come, new implementations should use OData v4. This comes with some changes for the backend developers and their SEGW skills will become obsolete. The commitment from SAP to RAP is a reality. Considering the life cycle of SAP products – here: S/4HANA or NW ABAP – and the support cycles, RAP will stay with us until 2040. Looking at the cloud, in the last years SAP brought us many different options to develop something with OData. The latest iteration here being CAP. My advice: choose RAP as the way to develop services (or extensions), especially when your developers are mostly ABAP devs and you have an S/4HANA system available somewhere or have access to BTP Steampunk.

Data model

Related to the OData service is the data model. The most important task is to define the data model. With it, the rest comes almost automatically. The time where OData services were just exposing a BAPI are coming to an end. Rigorously starting the service from the data model, CDS (entity) views, associations and building from there up the service. This will close many gaps in the quality of the OData service built on the data model. A side effect of this: the OData services will be easier to consume in other frameworks, like MDK or low code.

RESTful Application Programming Model

RAP is the ABAP counterpart of CAP. From both frameworks you should expect a high-quality OData service. Both ensure that the developer follows closely the framework results in a high-quality service. RAP, however, comes with several benefits out of the box that CAP cannot offer. The most important one being: RAP runs on ABAP. The main benefit is simply: every SAP customer using S/4HANA has access to RAP. Companies and their developers get RAP with S/4HANA, and with BTP, ABAP environment. As the likelihood that an S/4HANA customer has ABAP developers available is higher than having CAP developers available, serves as a reasonably good indication that these customers will adopt RAP. Developing Fiori Elements apps with RAP is super simple. Especially on-stack. No account setup, connectivity or deploy configuration needed. Just use it. Accessing data via RAP and annotate the service is done by the person that defined the data model and normally has a very good knowledge of the business process.

Annotations

Annotations are part of a RAP or CAP project. Instead of having them in the SEGW project or overwrite them in the coding, they are better visible in the project. It is also “easier” for the developer to write them. Important here: the developers that defined the data model, the implementation, are also writing the annotations. They get to be the owner. The scenario where the UI5 developer writes them in the frontend will be get less and less. Or only be used for small adjustment.

These changes will solve an old problem: quality of the service. Companies will benefit from this not only in faster Fiori apps development. As mentioned above, there are several tools provided by SAP to create apps. When the service offers the features needed, it gets easy to build apps on top of them. Be it a mobile, low code, AI generated app, or a Fiori Elements app.

Fiori Elements

It was already mentioned several times above: the future of UI5 development is Fiori Elements. Many tasks needed for a UI5 freestyle app are not needed. Most of the work is done by the Fiori Elements framework and the annotations.

Fiori Elements is possible already with an OData v2 service. Therefore, for several years. Yet, Fiori Elements usage was not widespread. Not even at the SAP shipped Fiori apps. The problems mentioned above regarding the quality were one the reasons. The tooling, and features Fiori Elements with OData v2 offers were nice but came fast to their limits. This changes with Fiori Elements and OData v4. The flexible programming model (FPM) allows to developer a Fiori Elements app and still be able to adjust it where needed. And with the FPM Macros, complex UI controls can be used and controlled via annotations. The starting point for a Fiori Apps with UI5 will be Fiori Elements. The focus of the knowledge will shift. From freestyle UI5 to Fiori Elements with FPM. This shift is what will turn UI5 development knowledge into an obsolete skill. Following the stricter approach of Fiori Elements means: less time needed for an app, better aligned with Fiori guidelines, better services, more feature out of the box. With Fiori Elements as the basis, the Flexible Programming Model will be the foundation of custom app extensions. Knowledge of UI5 controls like responsive table, input field, panel, etc. will be replaced by knowing how to use the FPM Macros. The knowledge on how the responsive table works will still be used, but the first thing to know is how to use the Macro for table in an FPM enhanced Fiori Elements app.

The adoption of OData v4 will also make UI5 freestyle development less attractive. Using OData v2 in UI5 is super easy. As smart controls only work with OData v2, developing a freestyle UI5 app with OData v4 that uses the UI controls is cumbersome. OData v4 demands additional work from the developer as its usage is not really intended in freestyle apps.

Does this now mean that UI5 development is an obsolete skill? Of course it won’t turn completely obsolete. The basics will still be needed. Adjusting Fiori Elements apps still needs UI5 development skills. But do not mistake this that the same level of UI5 skills and knowledge for a UI5 freestyle app is needed. Writing a controller extension or view fragment is not the same as creating an app from scratch. Deep knowledge of how the rooting works, how to apply a page layout, working with FCL, etc. won’t be needed.

Next level UI5 development

The change to Fiori Elements skills will free resources on the app frontend development side. Today, many times creating a UI5 app from scratch, even with the wizards and tooling, is a time-consuming task. And freestyle always comes with the “of course we can” risk. Freestyle is great because the app can be developed in a way that does everything the functional consultant wants. It is hard for a developer to reject a requirement when it is possible to implement. After all: technically it is possible and there is a requirement, so why not do it? And everyone is happy. If budget is available, why not use it to implement these wishes and later on in maintaining these apps? Adding draft handling, collaborative editing, view management, it gets complicated. With Fiori Elements it is easier. Therefore, the focus of UI5 development will shift. Maybe to validating better if apps follow the Fiori guidelines? More on the end user and the apps, independent if a UI5, Fiori Elements, MDK, Low Code, whatever app? More on the testing? Or just in delivering more apps? One thing is for sure: for the UI5 developer, things will change. The demand for UI5 freestyle won’t go away completely. There will be always demand for some apps that demand to be freestyle. However, it will be only a very small percentage of the overall Fiori demand.

UI5 developers need to learn Fiori Elements. Focus is on Fiori Elements with OData v4 and FPM. The amount of Fiori Elements apps with OData v4 shipped by SAP will increase. They need to know how to adjust these apps. What are the possibilities and limitations. Learning annotations and best practices on where to put them: better in the backend or in the frontend, and why? Validating “old” UI5 freestyle apps and check if they are really following the Fiori guidelines. Testing will be important. Using tools that allow to test apps from the end user perspective. As well as mock data and how to manage it. The OData service will be consumed from maybe not only one app, but from many. These apps will depend on annotations and demand a high quality of the service. This is a change for the backend developer, but also for the UI5 developer, as the task to cover up for errors the backend will be gone.

Fiori Elements development skill seems to be the same as UI5 freestyle. But is not. Fiori Elements comes with a different mindset. With a different approach to the whole app creation process. It is more disruptive than you might think.

Web Components

One area where UI5 freestyle skills might be considered important is for custom UI controls. Currently you need to know how to develop a UI5 control, and this includes a good understanding of how UI5 works. The future for UI5 controls is Web Components. With this, the UI5 development skills get substituted by knowing how to developer Web Components. And with this, the focus of the developer changes. From a UI control for UI5, to a UI control for a wide range of frameworks. This will be more than interesting. If SAP does it right with Web Components, this has a great chance of changing how Fiori is used and adopted in a company. And not just for the SAP area. I’ll write about this in a future blog post.