This blog is about SAP’s Fiori, a term that embodies SAP’s focus on user experience. It isn’t so much a blog about technology, it’s more about faith, belief, and trust: faith that SAP is serious about renewing the user experience of its applications; belief that it will continue to invest in doing so, and trust that it will actually deliver. Why? Because history tells us SAP hasn’t had a positive track record in this arena.
Firstly, let’s turn back the clock …
I remember the late 1990s when SAP sought to reinvigorate customer belief in its user interface with the ‘EnjoySAP’ initiative. Here’s an excerpt from an Infoworld article published in March 1999 about the launch …
Unfortunately adding a new theme, rewriting some SAPGUI transactions and making the formerly horizontal line in the letter ‘A’ in the ‘SAP’ logo bend like a smile (anyone notice that?) didn’t significantly shift the levers of customer satisfaction.
At that time SAP had some clever technology to ‘scrape’ the classic screens into a browser (HTML) format using an Internet Transaction Server, and later that morphed into what we now know as SAPGUI for HTML (more on this later). In fact, I worked as a consultant for SAP in those days, and one of my technology competencies included advising customers on that very approach.
Then in the early 2000s SAP took a sharp turn by declaring that ‘Java is the language for the user interface’ (championed at the time by SAP executive Shai Agassi). With this new mantra we trusted that SAP would build new user interfaces using it’s ‘Web Dynpro’ technology running on a new SAP Java-based platform under the branding of ‘NetWeaver’. And so SAP did, for some time at least.
Then, the mid-2000s saw the ‘return of the ABAPer’ as SAP re-pivoted new user interface efforts towards an ABAP-based variant of ‘Web Dynpro’. This meant that in some areas such as HR, user interfaces were written in Web Dynpro Java then re-written back to Web Dynpro ABAP. This constant retooling heralded what I consider the ‘lost years’ in SAP’s UX evolution (not to mention, the subsequent shift with HR to SuccessFactors, rendering those rewritten user interfaces obsolete). Either way, whether it be new Java-based or ABAP-based user interfaces SAP fell well short of replacing all the original SAPGUI transactions despite an engineering effort that spanned over a decade.
This brings us to the advent of ‘Fiori’ in 2013. The introduction of Fiori was different, because Fiori was not a technology but an ethos, a set of principles focusing on UX (user experience). It was a loud and proud statement of intent by SAP that it understood the customer and their UX needs. Importantly, SAP published Fiori design guidelines to reinforce these principles with practical application in how Fiori apps would and should be designed. And to underpin the focus on UX, Sam Yen was appointed to an executive position as SAP’s global head of design and user experience (UX). He introduced a new UX strategy and other initiatives such as a focus on ‘Design Thinking’ followed by new UX design tools such as ‘BUILD’. Many of us took a breath, forgave SAP for sins of the past, and backed SAP with our own encouragement and faith.
Now is probably a good time to reiterate the Fiori core design principles …
Whilst Fiori in its purest sense sought to be divorced from any particular technology, SAP did write its original Fiori applications using its new HTML5-based technology, dubbed SAPUI5. To illustrate how Fiori is a design concept decoupled from the underlying technology, SAP and Apple subsequently announced the Fiori for iOS initiative in 2016. This introduced an iOS SDK (software development kit) conforming to Fiori design principles, built using Apple’s own native Swift language. Interestingly this did raise the question of how an iOS-specific solution would comply with the Fiori principle of being ‘Adaptive’. As per SAP’s own words: ” SAP Fiori enables you to work how and where you want, regardless of the device you use”. Perhaps we should add the suffix ‘…. as long as that device runs iOS’ to the design principle.
And so imagine the reaction a few weeks ago when SAP decided to overload the Fiori Apps Library with thousands of re-themed classic SAPGUI for HTML transactions (under the new ‘visual harmonization’ initiative introduced in Fiori 2.0).
We had seen some classic Web Dynpro apps added to the library earlier, but nothing like the magnitude of what just occurred. With this we saw the number of apps appearing in the Fiori Apps Library leap overnight from around 1200 apps to a whopping 7500+. Many of us immediately came to the conclusion that the marketing folks at SAP had hijacked the library with the intent to bloat the numbers by adding in all these legacy transactions. That was backed by the fact that the newly added classic transactions also only appeared against S/4HANA systems, giving the impression that implementing an S/4HANA system would deliver substantially more apps.
Key SAP representatives however sought to explain the move, including Michael Falk (SAP Product Manager for User Experience and SAP Fiori) and Sam Yen.
As it turns out, SAP’s blog here tells us that S/4HANA customers actually asked for this change. They requested it to help them configure their Launchpad roles and make sense of what was available. In my mind the library has now been re-purposed from being a showcase of all Fiori Apps to being primarily a library of ALL the apps SAP considers are potentially relevant for an S/4HANA implementation. Fiori apps now make up only 15% of all the content in the library.
Whilst SAP has a plausible explanation for this change, the level of reaction I saw from members of the community indicated to me a deep-seated anxiety with SAP when it comes to perceived shifts in UX strategy. Does re-purposing the Fiori Apps Library herald a softening of SAP’s commitments around the renewal process in replacing transaction codes with Fiori Apps? After all, when you trace the historical shifts in SAP’s user interface strategies (described earlier), it’s no wonder that the SAP ecosystem is hyper-sensitive to any moves that might signal yet another turn in direction.
At time of writing (Dec 2016), the Fiori Apps Library holds around 1140 true ‘Fiori’ apps delivered since the announcement of the original 25 apps in May 2013. By my calculations, that translates to a delivery velocity of approximately 27 new apps per month or 324 per year.
Interestingly, the addition of ~6500 classic GUI transactions linked to S/4HANA implementations telegraphs to us how much work might be remaining in the ‘renewal’ backlog. We are taught fundamentally that the relationship between old SAP GUI transactions and Fiori apps is NOT one-to-one: one SAP GUI transaction might eventuate in multiple Fiori apps, or in other cases multiple similar SAP GUI transactions might have their capabilities consolidated into a single Fiori app. Using a simplistic calculation, if we assume a one-to-one relationship and the same rate of app creation going forward (a big assumption), this gives us a projection of 20 more years (6500 / 324) for SAP to complete the renewals process. That’s quite a backlog, and it highlights the conundrum facing SAP.
This explains why SAP is in parallel providing tooling for customers to do some of the heavy lifting themselves. Tools such as SAP WebIDE to create new Fiori apps or to extend existing ones. Other tools such as SAP Screen Personas (the roots of which can be traced back to the original internet transaction server technology) which enables customers to simplify the classic user interfaces themselves.
So where to now?
Here’s what I’d like to see from SAP …
Reaffirm commitment to Fiori and the renewals process. Not just in words, but in actions. We’d all like to see the ratio of Fiori apps in the Fiori Apps Library be much more than 15%.
For every new underlying user interface technology introduced, please try and deprecate at least two. I know, that is much easier said than done. But the long tail of technologies and technical debt which runs in SAP systems these days must bring a tremendous weight to SAP’s ability to be agile. And its lack of commitment to this in the past explains why SAP has so much renewals work in its backlog for the future.
And advice for customers …
Understand that whichever S/4HANA system you are implementing, you should consider the potential need for performing some renewals work yourself. Don’t assume that the system will be 100% Fiori. Consider the need for extensions or custom development for targeted scenarios where it makes business sense.
Ensure that your implementer has the appropriate skills to enhance or build custom Fiori applications, or to refine and simplify classic user interfaces using SAP Screen Personas. This in its own right is a treacherous area, given the lack of available implementers with the necessary experience. I’m already hearing of some poor outcomes at customers where the consultants were not suitably skilled.
Whatever the case, Fiori is clearly a long journey, not (yet) a destination for SAP. Let’s pray we see SAP keeping the faith with Fiori.