How to Understand Why Fiori Most Likely Won’t be Able to Survive

Executive Summary

  • Lost in the SAP marketing of Fiori is how slow the uptake and usage of Fiori has been.
  • We cover the math of probable Fiori usage.

*This article was written in August of 2017, but it has been reviewed and updated in Feb 2021. 

Introduction

This article will discuss something that no SAP consulting company or IT media entity can say publicly about SAP Fiori. This is because the actual use of Fiori is far less than SAP says and that Fiori has technology problems related to architectural issues limiting Fiori’s usefulness. These factors work together to mean a highly probable poor outcome for Fiori’s future as SAP’s user interface. You will learn about the supporting evidence, the fact that SAP has tried to replace the SAPGUI many times in its history, and why it is unlikely that Fiori will survive.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

Background On Fiori Uptake

I recently wrote an article that used DB-Engines, which tracks database popularity, showing the HANA’s declining popularity. I have accumulated some stories from contacts where HANA was pushed into accounts where it was not intended to be used. For example, account executives have been giving the other SAP products to clients for free, but they charged for HANA. They did this even though the account was not in the market for HANA.

These shenanigans and others have led me to conclude that HANA was stuffed in at customers. Many of the HANA sales have not been real, as is covered in the article How Enlarged is the HANA Implementation Numbers?

Fiori is connected to HANA (not for any technical reason, but because SAP has attempted to use Fiori to lure customers into buying S/4HANA). Due to this unnecessary connection to HANA, Fiori’s uptake has been even more limited than it most likely would have been.

HANA now looks less prevalent than it was ever advertised. This has held back Fiori usage, as only Fiori can’t work with AnyDB.

This has enormous implications for SAP. However, before we get to that, let us segue into the technical challenges customers face when implementing Fiori.

Fiori’s Technology Issues

SAP has bet big on Fiori, putting massive development resources into it. SAP has increased the number of Fiori apps significantly in the past year. With the fanfare published about Fiori, what is lost on the typical person keeping up with Fiori but without direct knowledge of Fiori is the following items:

Issue #1: A Weak Technical Base

Fiori has an unimpressive technological underpinning.

Issue #2: Mobile First?

SAP has repeatedly misrepresented Fiori as a universal UI that works equally well on a desktop tablet and a phone — however, Fiori is a mobile UI. It does not translate to the desktop, as SAP has stated. SAP is still primarily consumed on the desktop. Putting all one’s eggs in a mobile UI basket makes little sense.

Issue #3: How Many Attempts at Mobile?

Fiori is SAP’s 5th attempt at a mobile user interface.

Before SAP acquired Sybase, in part to obtain its mobile technologies, SAP put significant resources into SAP Mobility.

But neither of these initiatives went anywhere, although they were heavily promoted in the IT media and by SAP on their website and at SAP conferences.

SAP started with ITS mobile, NetWeaver mobile, Sybase SUP, Syclo / SMP, and Fiori. At this point, one seems even to remember as recent as SMP, which was supposedly the best thing since sliced bread to solve all mobility issues, and it’s only Fiori all the way now.

Issue #4: Implementation and Maintenance Overhead

Fiori requires a great deal of overhead to manage.

For example, Fiori ships with around 80 standard apps. Once you move past this basic package, it requires more technical expertise to bring each of the additional apps up to be ready to use. SAP seems to be investing its effort into developing new apps but not making them usable to customers without a significant amount of energy. This is quite strange because it is unprecedented to use a user interface for an application to require so much effort to make it work. At this point, Fiori appears to be more of a shared development project with customers than a finished user interface.

Comments on Fiori Implementation Issues

These words are from a person with experience implementing Fiori.

“Even at this late date, it is still very painful to install and maintain Fiori.”

And from another…

“40% of SAP customers does not like FIORI UI look and feel, performance. FIORI is a copy of some of existing open source UI frameworks.

SAP just started touching the technology. They have to think beyond (what they are currently doing with Fiori).

If you will consider SAP CoPilot which SAP has decided to provide with S4 HANA 17* series with license cost. If any customer will start developing there own coPilot with extra features compared to SAP provided coPilot , it will take maximum 15 working days.”

This is not encouraging, but something else comes out when listening to those with deep expertise in UIs.  Fiori is not a leading technology and has been hugely oversold by SAP as a user interface. When you hear SAP tell it, they shocked the world with a technology that no one had ever seen and that no other vendor had yet matched. However, in speaking with people who don’t work for SAP, no one agrees with that view.

SAP’s Perplexing Fiori Strategy

SAP’s Fiori has been a problem from the beginning. As previously stated, it seems SAP is pushing development to develop as many Fiori apps as possible — for the perception of the broadest possible coverage. But as most of these apps aren’t used, they aren’t being tested and burned in.

This brings up the question of overhead concerning customizing Fiori. This is another quote from someone quite close to Fiori implementations…

“Yes, 80-90% of SAP customer is not using SAP delivered standard FIORI app, for every app client is customizing, because standard one is not enough to fulfill the requirement.”

The problem with this is that Fiori is well known to be extremely difficult to customize. Therefore, with Fiori, one has the worst of both worlds.

  • A UI that lacks the inherent ability to satisfy users as standard needs to be customized.
  • Very low developer productivity when customized.

SAP’s Statements on Fiori

SAP’s statements on Fiori by executives show how out of touch they are and how unconcerned they are in that reality.

The following is a typical comment on Fiori…

“We want every SAP customer to run simple with a world-class user experience,” said Bill McDermott CEO and member of the Executive Board of SAP. “Judging by the commercial success of SAP Fiori, it’s clear that our customers agree. Some customers and our user groups believe we shouldn’t charge for SAP Fiori. We listened to our customers, I agree with them and now SAP Fiori is included with SAP software.” – SAP News

This has turned out to be false. First, Run Simple was a marketing construct, as we covered in the article How Accurate Was SAP on Run Simple? Furthermore, SAP did not merely “listen to customers.” Why were customers paying 22% support being asked to pay for a UI that replaced the SAPGUI? What vendor charges for its UI separately? Is SAP selling a fully integrated application or various pieces of an application?

And without any real accomplishment, SAP stated the following about Fiori.

“We’ve come a long way from the old SAP GUI,” he said. “The challenge is clear. We are no longer benchmarking against some other business software, because most of them are not very beautiful. We are benchmarking against consumer software. We’re committed to providing the most exciting user experience in the industry.” – SAP co-CEO Jim Hagemann

Can Jim Hagemann be Serious?

Jim Hagemann may have come a long way from SAPGUI, but when he made this statement, SAP’s customers hadn’t. Currently, over four years after his statement to PC World, almost every single user of SAP in the world still uses SAPGUI and not Fiori.

Therefore, this seems to be an example of SAP declaring victory before the battle occurred. Jim Hagemann made this statement around the time of Fiori’s announcement. He would have to have known that no one was using Fiori at this time and how far away anyone was from using Fiori. But his statement makes it sound like the old SAP GUI is a thing of the past, and customers have moved on to Fiori.

IDG Offers Some Suitably Compliant SAP Fiori Coverage

As usual, SAP has compliant media entities that tow the company line. In this case, IDC/IDG stepped up to the plate.

“By including a user experience based on SAP Fiori and SAP Screen Personas within SAP licensed software, SAP is making widely available a personalized, responsive, simple UX for its customers,” said Henry Morris, senior VP, Worldwide Software and Services Research, IDC.

First, SAP did not make Fiori widely available (Personas are irrelevant to this discussion as it was, for all purposes, discontinued). SAP could, of course, have done this. It could have offered Fiori for “free” to customers already paying 22%+ in support to SAP, but they decided to restrict Fiori to HANA. How is that making something “widely available?”

Therefore, Henry Morris’ statement is false.

Now, let us parse the following statement by Henry Morris.

“Users can focus on core business processes and immediate decision making for improved productivity and business success. Having access to the most critical business information via an intuitive, modern design is essential for customers to maintain an edge in today’s competitive business environment.”

The second sentence would be true if the first sentence were true. But the first sentence is false, so therefore, the second sentence does not matter.

Henry Morris Assumptions

Henry Morris seems to assume that Fiori is mature and used when it wasn’t when it was published three years ago.

It still isn’t today. IDG could have figured this out if they had checked, but they didn’t.

Thirdly, how much money does IDC receive from SAP per year? IDC is owned by the Chinese media conglomerate IDG. Brightwork covered IDC and IDG in the article How IDG Provides Inaccurate Information on IT. It is clear that IDC and IDG repeat whatever SAP says and then call that an article. IDG also owns PC World, the media outlet that published Jim Hagemann’s inaccurate quotation on how much progress SAP had made from the bad old days when people used to use SAPGUI for SAP.

How is IDG Paid by SAP to be Their Parrot?

Does IDG get paid on a single invoice from SAP to distribute inaccurate information, or are there separate invoices per month? There are invoices; the only question is whether SAP is invoiced separately per IDG publication.

Thoroughly evaluating the inaccurate statements made by SAP would be a separate article, so I will leave it there for now.

It was not only SAP and IT media entities that provided inaccurate information on Fiori, but quite a few SAP consulting companies. As shown in A Study into S/4HANA Implementations, some of these consulting firms exaggerated their S/4HANA experiences to promote their ability to obtain Fiori implementations services.

What Fiori’s Coming Irrelevance Means for S/4HANA

SAP has used Fiori to motivate customers to move to S/4HANA. However, if Fiori does not survive, investing anything in Fiori from the perspective of bringing it up to having users acclimate to it is an utterly wasted effort.

For instance, the push for S/4HANA, which is not ready anyway, can be delayed as one of the motivators for S/4HANA was to get Fiori. Now that is gone. Here are some essential facts that relate to S/4HANA.

  • HANA is not a logical motivator for S/4HANA.
  • Fiori is not a logical motivator for S/4HANA.

This means that S/4HANA gets pushed as an implementation initiative. It also says that companies currently paying support on S/4HANA, where it sits unimplemented (which is the vast majority of S/4HANA sales), need to begin asking why. A frank discussion is necessary that starts something like this…

“I get that you needed to move S/4HANA to meet your internal incentives, but we are not paying support on something that looks far further out than when you sold it to us.”

Fiori is but one piece of a problematic puzzle in the argument for S/4HANA.

  • I now receive frequent reports that HANA has poor performance under S/4 that I never hear when the topic is BW on HANA. (HANA is nowhere near as good at transaction processing as SAP had proposed).
  • Fiori will have to be transitioned away from if any time or effort is invested into it.
  • The functionality or the application layer of S/4HANA is still not ready.

Time to Jump off the SAP Fiori Bandwagon

In the previous articles on Fiori SAP, such as Time To Jump Off Fiori Bandwagon, I brought up some of the issues that have prevented Fiori from being used by SAP customers. And how Fiori SAP was leveraged as a cynical marketing ploy to keep companies from exploring real options in the market for user interfaces.

These limiting factors on Fiori SAP include the following:

  • Tying Fiori SAP Unnecessarily to HANA
  • SAP and its Partner Network misrepresented Fiori as a Complete Replacement for the SAPGUI
  • SAP and its Partner Network Misrepresented Fiori as a User Interface That Works Equally Well on Computers, Tablets, and Phones
  • SAP and its Partner Network Misrepresented the Effort Involved with Fiori

Tying Fiori SAP Unnecessarily to HANA

SAP first attempted to charge for Fiori. When unsuccessful, it decides to use its investment in Fiori to tempt customers to buy Fiori. There has never been any reason to restrict Fiori to HANA. I heard that because Fiori SAP was so report-oriented it would have to have HANA. This is untrue; most Fiori screens are quite low in data density.

Nevertheless, SAP thought it was quite clever to restrict Fiori SAP to HANA. The major problem is that there are so few S4 instances live in the world. Thus it has been an essential part of limiting Fiori’s use to a tiny market segment.

SAP and its Partner Network misrepresented Fiori as a Complete Replacement for the SAPGUI

In actual reality, it is a series of apps. The development of Fiori apps seems to be slowing. As I checked the Fiori app library, the library is now up to 1015 apps. At one point, they were adding 15 apps per month.

SAP and its Partner Network Misrepresented Fiori as a User Interface That Works Equally Well on Computers, Tablets, and Phones

Yet, Fiori’s heritage is actually a mobile app. It is not designed to show the data density of a computer screen for complex transactions. It is a “lightweight” user interface. Fiori can be displayed on a computer, but this is not the same as saying that Fiori is a user interface designed for computers.

SAP and its Partner Network Misrepresented the Effort Involved with Fiori

Even for companies that purchased S4 because SAP’s marketing tricked them. Or because they were somehow connected to Hasso Plattner. (Hasso Plattner remotely controls purchases of many companies in Germany and other businesses with some interest; this is why most S4 implementations have been in Germany.) It isn’t easy to justify going to effort even to bring up Fiori. Fiori requires a parallel technology and training pathway. It requires many resources to migrate some transactions to a user interface with little chance of survival. Honestly, at this point, why would a company invest the effort to do this, knowing that Fiori is not the future of SAP’s user interface?

SAP misrepresents Fiori and its applicability and uses it to “UI wash” its SAPGUI. Max Favillon points this out on his blog.

“Browse SAP websites and try to figure out what its user interface looks like, you will have a hard time, no screenshot whatsoever, a lot of beautiful picture of smiling business people using laptops, smartphones and tablets, but not even a glimpse of what SAP applications UI looks like.

SAP Marketing

In SAP marketing’s eyes, the UI that SAP customers use is not the real user interface or SAPGUI but some combination of Fiori and stock photography pictures of people smiling at laptops. Why use an alternative like AppsFreedom or LiquidUI when everyone is laughing and looking at their laptops?

I also brought up the article on SAP using indirect access to block companies from purchasing alternative user interfaces. This is where SAP requires customers to buy Fiori copies that they will not use to connect another user interface to SAP applications.

Fiori has the following problems that have prevented its uptake.

  1.    Who Recommended Fiori?
  2.    Why Did They Recommend It? (hint — it’s related to money)
  3.    Why is SAP now so Silent on Fiori?
  4.    Why did certain people look at Fiori and think it would work?

Offering Advice on SAP from a Position of Bias

Many people offer advice in SAP that does not look critically at what SAP is offering. They should not be listened to.

If you have an advisor like Deloitte or IBM that only parrots what SAP’s marketing literature says, these entities should not be relied upon. One should remember the limitations placed on partners.

  1. SAP monitors all messages presented at SAP conferences or produced by the partner marketing department.
  2. SAP can edit or block any material that a partner provides on SAP. Not that SAP partners tend to care about disseminating false information.*
  3. *(I do not mean to give the impression that SAP partners struggle against SAP’s influence. If anyone working for a large consulting company is for a split second thought, I propose they may attempt to communicate information. I apologize for my clumsily worded sentence, not in line with SAP marketing and that they have even a sliver of independence.)

Debate on SOA with Deloitte

This reminds me of a recent debate with a Deloitte consultant about SOA or service-oriented architecture. I made the point that SAP would never support SOA in actual practice. While SAP may put SOA on their PowerPoint sales presentations, SOA was about open systems. At that point, SAP had used the difficulty of integration as a strategy for blocking out vendors that have better functionality than they have.

They have done this for decades. So why would SAP embrace SOA? SOA would give customers greater freedom and restrict SAP’s ability to use its monopoly power.

At this time (around 2006), SAP was promoting SOA in its marketing literature.

The Deloitte consultant with whom I was speaking became visibly frustrated with me. At one point, I had enough and said

“What I am saying is that SAP is saying that they will support SOA!”

I seemed to make him angry for whatever reason.

Deloitte Consultants Designed to Repeat SAP

For this and many other consultants, there is no interpretation of what SAP says. SAP makes a statement, and an army of consultants will repeat this statement as SAP marketing lives in a permanent fantasyland. This means that these consultants spend much time repeating false statements.

And by the way, guess what happened with SAP and SOA?

  • SAP never did anything to support it.
  • SOA finally flamed out as a concept as it had always been a pipe dream.
  • SAP moved on to promoting something else.
  • No one, not SAP nor SAP’s partner network, ever admitted they were wrong about SOA.
  • SAP did not issue an apology for taking up something they never supported.

That is how trends and information dissemination work in IT. And so it will be with Fiori.

Fiori SAP, “Part Two.”

As soon as SAP switches to a new imaginary user interface, Hasso Plattner will announce how revolutionary it is. The slavish consulting companies will begin repeating whatever Hasso says as the future direction. Beautiful PowerPoints will be created, heralding the new luxurious SAP user interface.

Hasso Plattner is one of the least reliable people to listen to on technology matters. His projections around Fiori have all been proven not to pass. When the new SAP UI is announced, he will wind up his smoke and mirror machine.

The entire process will repeat itself.

More deep analysis from SAP partners like Deloitte, IBM, and Infosys on Fiori. 

For the math on my estimate of Fiori’s usage, see this article.

I will take credit for calling out Fiori’s limitations early, but it was not that difficult. I spoke to several people with far more experience than me in user interface development who predicted Fiori would fail. They could not say anything publicly. Unlike me, they are not unaffiliated, independent consultants. The only complicated factor is whether you have a mental or financial bias towards SAP. I don’t. Therefore, it is an easy conclusion to reach.

So What is Next for SAP and Fiori SAP?

Fiori is not a sustainable user interface for SAP or SAPGUI replacement. It is a mobile application with limited applicability to most SAP transactions. SAP already invested mightily in SAP Mobile. After SAP Mobile failed, they purchased Sybase, partially for its mobile offering, Sybase Unwired Platform. After the Sybase acquisition, SAP purchased Syclo. Years later, SAP has done nothing with these purchases, and no one uses SAP Mobile.

One SAP account manager told me SAP couldn’t compete with mobile application development. This type of development is at an entirely different price level than SAP is accustomed to. Android and iOS produce mobile development environments. Developers for these OSs can be found relatively easily, and their development productivity is quite high. Higher than the productivity of anything that SAP offers. They have nothing to do with SAP, and it is not an area where SAP can compete. Mobile is doing great without SAP.

SAP does have its app marketplace.

These are primarily brochure-ware apps that were developed and that I have never seen on a single project. Here is one example. It follows the Tableau school of making analytics seem around twenty times easier than in real life.

The Reality of SAP Apps

I have never seen anything approaching this on any SAP project. Most SAP projects are just trying to get through a long queue of uninspiring reports from the SAP BW.

I have seen companies set up their internal development using iOS as a platform that has nothing to do with SAP. The data is integrated into SAP. It works great, and mobile is not an area in which SAP has a chance of being involved, so SAP should probably stop wasting its resources to “make it happen.” There are segments that you don’t necessarily have to provide an offering.

While SAP has been wasting time with Fiori, SAPGUI keeps getting older. With Fiori losing credibility, it may be time for SAP to pivot to a new user interface offering!

SAP has been bringing out some new, sexy user interfaces for decades now. Those with a good memory may recall Duet. A partnership with Microsoft that failed. I don’t have the list I once saw that showed all of SAP’s new user interface introductions over the past 15 years, but it was pretty lengthy. SAP has had. SAP did this already when they pivoted from the highly touted Personas to the highly touted Fiori. Both of which never existed for most customers on anything other than PowerPoint presentations.

Have We Seen This Story Before?

SAP has a history of promising new UIs, and then those UIs go by the wayside. Fiori is just the next on the list.

This happens when executives and marketing get so far out of the product’s capabilities that it becomes ludicrous. Hasso, McDermott, Hageman, Sven Denecken (another frequent SAP commenter on Fiori), and others don’t appear to feel the reality of what is happening with Fiori and are stuck in permanent convention/press release/promotion mode.

Now, there is more reason than ever to believe that Fiori is merely another transitory and overhyped UI that SAP attempted to replace SAPGUI with. This also means that after all the pomp, the promises, the press releases, and SAPPHIRE presentations…..customers are still left with SAPGUI and will be left with SAPGUI for the foreseeable future. The following UI will need to be developed, and internal battles at SAP will be fought over between those who bet big on Fiori and the realists who recognize that it is time to move on.

Conclusion

Fiori has had a chance to catch on, but it just hasn’t. And it hasn’t because:

  • It is Uncompelling: Fiori is not compelling as a user interface.
  • It is Not What it Says It Is: Fiori is not a universal UI that works equally well on all devices (i.e., smartphones and tablets as PCs). Instead, it is primarily a mobile UI. And this point is not debatable; skeptical people can merely check the Fiori technology underpinnings.
  • Fiori as Starter Kit: Perhaps for an even more significant reason, Fiori is not a user interface. It is a “starter kit” that puts an enormous burden on customers to both stand up for Fiori and address various shortcomings. Fiori has an exceptionally high overhead.

Fiori, the “new SAP user interface.” For which Hasso Plattner declared that.

“SAP now had best user interface in enterprise software.”

All before anyone had used it. A user interface slathered over SAP marketing materials, SAP conferences, etc.. is failing. It is failing for some important reasons that are presented in this article. These reasons are unlikely to change. The people that uncritically supported Fiori look foolish as Fiori is nowhere to be found on SAP projects.