Skip to Content

Fiori arrives – first impressions and thoughts

I was fortunate enough to be invited to participate in the Bloggers Program at SAPPHIRENOW in Orlando last week.

One of the more interesting announcements (at least for me) was “SAP Fiori” which was demonstrated during Vishal Sikka’s Thursday keynote by Sam Yen. Vishal spent some time explaining that “Fiori” means “flowers” in italian and why that name was chosen. The Fiori apps were also being demonstrated on the show floor and are available now.

Sam Yen has the job of “changing the perception of usability at SAP”. Not a trivial task. You can refer to my blog about this from SAP TechEd season last year.

Part of Sam’s strategy is to identify the most common SAP transactions used across the SAP customer base and “renew” them. When I was talking with Sam last year he suggested that this would be around 20-50 scenarios. The initial release of Fiori apps number 25.

In the latest SAP User Interface Technologies Road Map document SAP use the terms “Top use scenarios” and “Core use scenarios”.


The same road map document shows that over time SAP will renew “top” and “core” scenarios progressively.


All this is good news for SAP customers. Let’s face it – any initiative to get the SAP delivered user experience closer to what the end-users desire is to be applauded. Fiori apps are built using the SAP UI5 framework on the front end which calls backend functionality that is exposed using NetWeaver Gateway services. This should mean that Fiori apps can be ported to any version of ECC 6 – and potentially even further back. I look forward to hearing how easy this is in reality. (*Important – SUP – now known as the SAP Mobile Platform – is not required.)


If nothing else the Fiori apps are a good demonstration of how to build web applications from both an architectural and user experience perspective. The clear separation of user experience and backend functionality is a principle that all architects and developers should have grasped by now. The screens are simple and in many ways quite minimalist. Most liked them and even the worst criticism I heard was pretty subjective. The responsive design seemed quite good although I didn’t get a real chance to try it out on a smartphone to see how usable it was on that form factor was.

The bundle of 25 Fiori apps are priced at 100 Euro per user. There are plenty of people who believe they should be free and there was a robust twitter discussion about this. I also had many people seek my opinion on this aspect both directly and indirectly. Personally I believe that they should be free but I am not militant about it. SAP could use the goodwill that such a move would provide and I think that it would reinforce the message that fixing the user experience is SAP’s problem not their customers’. But I also understand the argument that by putting Fiori on the price list the SAP field sales force will be motivated to position it within every customer. The continuation of this argument is that it will increase visibility of the Fiori apps within the customer base and therefore adoption. Time will tell I guess.

What I am sure about is that the availability of NetWeaver Gateway for all SAP customers without additional licensing costs greatly simplifies the Fiori licensing discussion. So if nothing else SAP can be happy that the change in pricing policy for Gateway helps simplify the Fiori pricing discussion. 🙂 (Ref: )

On the exhibition floor I was incorrectly advised that if additional apps are added to the Fiori bundle they would be covered in the license cost. This didn’t sound right to me so I tested this with Sam Yen and he confirmed that wasn’t correct. The problem here is that if more apps are “renewed”, as indicated in the roadmap slide, then SAP will have their hand out again for more Euros. This would not be a good look. SAP need to sort this out quickly. Of course I needn’t point out that this problem goes away if Fiori apps are free.

Another source of confusion came from a SAP source that asserted Fiori apps were targeting so-called “occasional users”. This flies in the face of every message we have received since this initiative was started last year. On the Fiori overview page it clearly states that they are “for broadly and frequently used SAP software functions” – pretty plain to me. I understand that sometimes people get the messaging wrong but the people that were responsible for this snafu did themselves no favours at all.

As to the Fiori apps themselves, they are catalogued as Manager Apps, Employee Apps, Sales Rep Apps and Purchasing Agent Apps. They include…

  • eight different workflow approval apps as well as a baseline app you can use to create your own approvals
  • an app for budget and spend information for departments and projects
  • employee apps for leave requests, time sheets, travel requests, pay slips, benefits
  • shopping cart apps for purchasing
  • sales support apps for pricing, availability, sales orders, shipments, invoices

The first thing that occurs to me is that there is significant overlap with existing web/mobile solutions that SAP provide. I wonder how SAP will position the Fiori Employee Apps against Employee Self-Service? Between the Manager and Employee Fiori Apps a significant proportion of what is currently in  ESS/MSS is covered. And every SAP Mobile pitch I have seen puts plenty of focus on workflow approval apps. There seems to be a school of thought that workflow approval is the mobile “killer app” – something I strongly disagree with.

As for the apps themselves they look pretty good. We all have different tastes so they won’t be for everyone but the good news is that there is a theme builder that allows you to change their appearance to suit yours. The apps all look and work consistently which is important so the users can figure out how to drive quickly.

SAP have recognised that many customers, maybe all customers, will need to modify at least some of the delivered apps to suit their particular needs. There is already documentation available that shows ways of doing this. In the future the Applications Designer tool has a part to play here but unfortunately this tool has been delayed and is not yet available.

So all in all I would have to say that the Fiori Apps are a good initiative. They look good, they are simple and easy to implement, and they are targeted at a clear need in the SAP community. I now wait to see how quickly and how widespread the adoption of these apps is. And returning to the roadmap slide I am reminded that the “renew” slice is targeted to grow over time. If SAP can come up with 25 apps in the 6 months since last SAP TechEd season can we expect another 25 for the next SAP TechEd? I hope so.

You must be Logged on to comment or reply to a post.
  • Nice recap of the details - thanks Robbo.

    Worth noting that the pricing is a one off payment - not an ongoing subscription. Which is certainly a different approach (and makes one wonder about how support for the product will be funded). But certainly makes one think that there would be additional cost for any additional functionality.

  • Hi Graham,

    Good write up of what fiori actually is and how there has been some confusion, even started by people who should know their stuff. (Occassional users only??!).

    I also saw the discussion on Twitter and how some people had the opinion that SAP should give these apps for free. I still don't understand that. Pricing is clear and you get a nice package of apps for a reasonable price. You are free to customize the apps as much as you like and you don't have a recurring fee. Perhaps maybe only a standard maintenance fee. If we as a partner build a new solution on top of netweaver_gateway or smp, why wouldn't we charge for it? So does SAP. I cannot see why not. New product, new price. All necessary fees included (NW Gateway, sapui5).

    For now: I am gonna install these on our demo landscape next week and share my experiences on #SCN_Mobile space. I am eager to find out if our internal test users will be as enthusiastic as I am.



    • I think the biggest win of these apps for customers is that they work on 90% of ECC6 systems using just SAINT add-in for installation, then configuration.

      For any SI's large or small this is by far the biggest selling point.

      Customers have VPN, and their own Network security protocols. The removal of SUP from the equation is probably the biggest win possible.

      Pricing is an issue, yes. But the massive simplification of the technical architecture makes the pricing look more attractive than the SUP based suite of mobile apps imho.

      Which all had the "hidden" cost of the installation, configuration and maintenance of a SUP platform, which is highly specialised knowledge.

      As a relatively experienced basis person i could install the components required for Flori within a week on a core ECC system. The best solution would be a ABAP application server, but H/W requirements would stop a lot of customers.....

      But that HAS to be a huge positive, and one thats being hidden away. Oddly.


    • I am one of the ones that most definitely thinks the Fiori apps should be free and should even be bundled into the next sp. Customers are already paying per user licence fees for SAP ERP - I would expect that any changes to the visualization (UI) should be free. This is SAP trying to fix what is perceived to be a clunky old UI - yet they are going to charge to fix this - I don't get it.

  • Good job with this Graham. I wonder how this fits into SAP's strategy alongside Personas, HR Renewal, SuccessFactors, and SAP Mobile. From a HCM perspective the number of UI options must be overwhelming for some customers. The comparison of licensing options can also not be so easy and I wonder how much that will affect the take up of a number of these options with the SAP customer base.

    Best regards,


  • Thanks for great blog, Graham!

    The offering is much clearer now, though I have some questions relating Fiori cost and availability:

    Could you please clarify changes in Gateway licensing? Earlier it usage was free for only users that already have appropriate SAP application licence. Has anything changed?

  • Great sharing Graham,I not yet used the SAP Flori,  of course lots and lots of questions moving in my mind, some are,

    But I wonder, SAP already providing some mobile apps along with the package, ex:- SAP Travel onDemand, where we got info from license price includes all together, include mobile app for the solution. In such cases, SAP Flori would not include those apps inside?

    Is there any trail version available ( out of 25, min apps are available as trial out version).

    Best regards,


  • Tnx graham, Some timezone overlap here. Posted my Finding aswell.

    I'm also curious on new Gateway pricing models. My lastes insight was 3 models:

    • Light user models (named user, limited fee)
    • Heavy user models (named user, sightly higher fee)
    • Consumer model (anonymous user measured by calls to backend)
  • Congratulations on being included in the bloggers program - your readers get the benefits of your insights and questions.

    I didn't see the Fiori apps first hand last week, and now I have similar questions re: ESS/MSS - we already enter/approve time now with the SAP portal, do we need Fiori?

  • Honestly I still think SAP UI strategy can't be taken seriously until they can answer yes the following three questions:

    1) Does this replace the SAP GUI for all business functions?

    2) Will this user interface technology stay around for more than five years?

    3) Will this be offered as no-additional cost beyond the time and effort to install the new UI as part of my system?

    If the answer to any of those questions are no, then I don't consider the new UI offering a strategic long-term offering.  Like it or hate it, when SAP introduced the PCUI and CRM Web Client UI for CRM there was a legitimate attempt to answer yes to all three questions.

    SAP has had ten years 😯 to get rid of SAP GUI and the fact that most folks using ECC EHP6 will still be stuck using it for core business functions just proves a lack of long-term focus on user interface.  Again ten years, so seriously why should anyone be excited buying SAP latest flavor of the week UI improvement solution? (BSP, JSP, WDJ, WDA, HTML5, etc).

    That being said thanks for providing a great overview of your observations on the new tool.

    Take care,


    • +1 Lack of credibility is here something SAP execs are not seeing.

      What happened to Web Dynpro ABAP as the strategic UI technology?

      After the last UI try-outs were "free", now you have to pay money to see if it works out or not. At least the approach of Fiori with HTML5 and responsive design is right this time.

      All the UI approaches SAP tried out over the last 2 - 3 years bind you to a SAP technology (WD, Gateway) instead of decoupling it. At least the UI is getting less dependent on a specific SAP release, but how many are already using Gateway or planning to use NetWeaver 7.4?

      btw: what is now going to happen to Personas?

        • But why should I spent money for Personas (that won't run on a mobile device, thanks to Silverlight) when Fiori gives me a modern (HTML5, responsive) UI? The end-user group of fiori (+ future sites) and personas should be almost identical.

          And paying first personas (do it yourself, chose your most needed dynpro) and later again for getting the site for fiori (SAP identified together with customers 100 more most important applications for fiori) makes no sense ...

          • Hi Tobias,

            I think you can be pretty confident that a future version of Personas will be all HTML5. Of course that doesn't guarantee it will work on mobile platforms though. 😉


            Graham Robbo

          • Hi Graham,

            My problem with a 'future version of Personas will be all HTML5' is how long will that take?  I remember when Web Dynpro was going to 'future proof' your UI investment and we were to trust SAP to deliver rendering engines for future UI technologies beyond HTML.  So for instance there was always talk in the old days of a Flex rendering engine for Web Dynpro .... we waited years, but it never arrived.  Instead SAP fell back to a embedded island (Flash / Silverlight) for Web Dynpro which was cheating somewhat.  Even when SAP are working on a dedicated HTML5 tool (AppDesigner) from the ground up, without needing to bind it to some Web Dynpro rendering engine, SAP has realised it isn't such a quick and easy task ... see the delay in getting AppDesigner to market.

            Just some somber thoughts on this miserable Winters day in Melbourne.



          • Hi John,

            I was just thinking the other day about the whole "Web Dynpro Promise"... wasn't one of the major benefits the ability to provide different rendering engines... surely this could still be done and SAP could provide a HTML5 rendering engine for Web Dynpro...??? Or am I missing something? Visual composer had both a Web Dynpro and Flash options for rendering I think.


          • FWIW I think HTML5 Personas will be sooner rather than later. I have no special inside information, just that I don't see it as a particularly difficult development task.

            If adoption of Personas is encouraging then ver 2 will come quickly.

            Web Dynpro change of focus is, I think, a different issue. UI technology moved pretty fast so promised rendering engines like Flex turned out not to be worth investment.


            Graham Robbo

          • If adoption of Personas is encouraging then ver 2 will come quickly.

            The problem with that is that it doesn't seem to be priced for quick adoption, unfortunately.


          • And while customers are waiting for Personas v2 with HTML5, SAP wants them to spent money for Personas v1 with Silverlight, that is: install Silverlight, manage it, hope that v2 of Personas will be reality at some time in the future (if) and then hope that migration is done automatically to HTML5, if not: additional costs. This gives you: fiori, Screen Personas v1 & v2, custom HTML5 sites, WDA and WDJ, BSP, JSP and some VC (what happend to VC for HTML5 Kobi Sasson?) applications. That's quite some UI zoo to manage.

            Until then: Fiori is a set of nice looking responsive sites. At least SAP should also publish these "apps" also for SUP/SMP and show how to integrate these sites into other web pages / portals like SharePoint. Because that "new" design of the fiori web pages is not what you can put into your existing sites - like NWBC or Portal - as the design differs drastically (which reminds me: how does someone log on to a fiori web site? Comes fiori with a new logon page)?

            Get the impression SAP is solving the UI problem as always: throw a lot of different approaches at customers, watch what get's adopted, and then decide to use this (or something else or invent a new go-to technology).

            I hope that fiori  raises the awareness of HTML5 for SAP applications at customers.

          • Hi Tobias,

            Good point regarding Logon. I haven't seen a Fiori logon page either (yet). Since Fiori apps are delivered out of the ABAP stack you could use all existing logon methods available in ABAP I suppose. In mobile apps I find that login is particularly cumbersome (small keyboard, big fingers etc...), from a user perspective I am prepared to set up my login once and then never again (hopefully).

            This Architecting an SAP Fiori deployment by Steffen Schwark touches on deliver mechanisms for Fiori too.



          • Maybe we haven't seen the logon page because ... its the standard ITS mobile logon page 😯 😯 😯 (if SCN only would allow me to attach a picture ...)

            Fiori can bring superior UX, but when the logon (and logoff) is difficult, it will be hard to make end users happy. In the above blog Steffen talks also about SSO2 cookie, which basically means: SAP Portal, and that implies that you should implement Portal on Device too. At least then you get a portal framework between end user and backends.

            Maybe SAP should but fiori in a bigger picture with (reasonable) implementation alternatives with plus/cons.

        • Seriously SAP UI's strategy has not changed much beyond shuffling the deck chairs and picking a new set of UI technologies.  If I picked "older technologies" and eliminated some technical options that weren't possible, we still have an half-executed 10 year UI simplification strategy.

          The UI strategy is clear, there is no interest in making the core products more user friendly unless you want to pay SAP $$$ to fix something that they have had 10 years to fix.

          Take care,


          • I am not in full agreement. Even if I am sometimes frustrated with the pricing model of SAP I have seen concrete examples where the recent UIs for ERP Business Suites have been an enabler for chaging the end-user perception. It is not perfect yet but it is enough to get some end-user feedback like "I want this SAP application".

            Even if I do not like to refer to technologies I would say that WDA/FPM/POWL/NWBC/SidePannel are enabler for improving the situation.

            I say I do not like to refer to technologies because I believe that one of the issue is that customers do not like to perform "User Centric Design".

            In order to be successful most of the solutions have "engineered for the orgnisation" and not designed for the end user. Recent SAP technologies enhancement allows to design for end user.

            The last technology that I have not mentionned as an enabler is Gateway.

            For me "one size fits all" is a myth in terms of User Experience.  

          • Hi Patrick,

            I prefer the expression "One size fits none"! For most things I find this saying applies well but esp. when it comes to user experience!



          • OK. I'm going to regret this, but here goes.

            Its easy to "rant" on a blog. Its harder to solve a problem which is actually hard to solve. "No silver bullet".

            First of all - there is a ton of effort in renovating existing apps, AT NO COST. Just see Jarret Pazahanick blogs about HCM renovation (and more coming). See the improvements in WDA, FPM & Side panel. See the change in the licensing of Gateway (based, btw, on Mentor feedback such as Graham Robinson)

            Are there things which cost money - sure. But that is a larger discussion. I honestly dont believe (my own personal opinion) that giving stuff for free is the best way to get them introduced to the market (esp. not the LE market).

            Should personas have been written in HTML5 from the get go? My own personal opinion is YES. But does that mean that it does not have value to customers? Does that mean that we are just throwing stuff at customers? NO.

            (And BTW - VC5 is still in the works, Tobias Hofmann - They are past the beta phase with customers and are now working hard to try and deliver this before the end of the year).

            Again - my two cents.

          • The problem is that some of us have way long term memories and have lived through several UI changes and promises of SAP GUI being replaced and still haven't seen it happen.

            I'm going to state this again that SAP has had at least TEN years to fix the user interface problem and keeps repeating the same approach that with limited success.  I'm not saying that it's not a difficult problem, and expecting it be resolved overnight, however ten years would have been more than sufficient to entirely rewrite every standard major ERP screen as an example.  It's been done before(think enjoy controls) and how long did that take: two or three years at most?

            If I wanted to be picky we could argue that SAP GUI has needed an overhaul/replacement since around Y2K, but I will pick the birth of Netweaver as a fair starting point given the technology available.

            Take care,


          • Hi,

            Some of us also have long memories and actually tried to implement these changes from within 🙂

            I think the problem is more difficult than you are describing it.

            Lets assume that Shai Agassi had his way with the birth of NetWeaver and the entire 300,000 screen of plain vanilla ERP screens had been re-written in what was then the most modern UI technology SAP had - Web Dynpro for Java. It would have taken customers 3-5 years to get all those new UIs (this is based on actual surveys, not just throwing a number) and adapt all of their custom screens from Dynpro to Web Dynpro for Java. By that time - Adobe Flex/Flash and Microsoft Silverlight would have been the technology de jour. Again - SAP would have invested in re-writing everything in Flash (as some customers were actually asking, back in 2008). 3-5 years for adoption and what do you know? Here comes the iPad which killed Flash with one fell swoop. What now? Again?

            Now - Its not enough to just re-write the controls. You also need to adapt to different screen sizes, you need to adapt to new browsers and most of all - you need to adapt to different users. What worked for "Enjoy" (i think there was an exclamation mark there 😉 ) is simply not relevant for the current scale of SAP screens multiplied by 25 industries multiplied by 100 and something countries. That doesn't mean that there aren't efforts to improve the UI/UX. Lots of effort is going there, its just a hard problem, IMO.

          • Yes, but there's the fundamental problem, that SAP never invested in using SOA or putting a semantic layer of your technical choice inside of the ERP side of the suite.  The problem is that if we assume the UI layer contains the business logic for model(which in ERP it does to a certain point), then each UI iteration becomes more and more diffcult and waste.  A common BOL style layer for business logic if it was built could have solved most of these issues.  That style of technology has been available since say 2006, so seven years would be sufficient to build a true common semantic layer covering the 80% needed.

            The problem is all the solutions to fix ERP keep ignoring the fact that SAP failed within 10 years to deliver a consist semantic API layer for all ERP functionality.  Thus things like gateway, and every other external solution is needed to try to overcome a fundamental design problem for the core ERP solution.  I only mention ERP, because CRM does not have this issue because the system was designed from the ground-up to receive and exchange data.  Not all the API's in CRM are pretty, but it's much easier to build new UI layers on top of CRM rather than ERP.

            I guess once again I see these approaches as treating the symptons of the patient instead of addressing the cure.

            Take care,


  • Really great blog Grahram and kudos for taking the time to pull it together.

    Several of the Fiori apps are HR based for their onPremise customers and while $150 USD per app might seem reasonable for some modules and their use cases it is extremely high for HR in which every employee would need the payslip app for example. On of my current customers has 84K employees so to buy ONE Fiori payslip app the list price would be 12.6 Million dollars for something that duplicates functionality they already have and are paying for inside of SAP.  There must be something I am missing as if not they are pricing it in such a way there is no chance for adoption which is what is happening in the the SAP HCM Mobile space as well.

    Guess if you are an HR OnPremise customer that wants mobile and UI/UX be prepared to pull out your checkbook or move to a vendor that has it as part of their offering (such as SAP owned SuccessFactors) 🙂

    Update: Jon Reed confirmed from Sam Yen that the $150 USD is for ALL 25 Fiori Apps and future updates to those apps which changes my example above as that $ amount would be for all the apps (and assume a healthy discount off list).  It is definitely a more affordable option than mobile but at the core still strikes me as something that with all the maintenance dollars SAP customers pay the type of thing that should be free. 

    • Jarret, where do you see the $150 per app? I believe the one off price per user is for all of the current 25 "app" collection. Also that is a list price for the collection - if you had 84K employees I'm sure SAP would be more than happy to negotiate with you.

    • Dear Jarret,

      I have read your blog regarding HR Renewal which is also UI5 / Gateway based if I am correct... Don't you think there's a bit of functional overlay ?

  • Hi Graham,

    i think i like Fiori (which in my mind is an extension of SAP Workflow to mobile), but since thet "Test drive" button failed on me, i'm getting a mixed feeling.

    Thanks for clarifying Fiori to the community.



    PS $150 is not a problem unless it's only the first in a series...

  • I am highly disappointed on the "pricing model".
    SAP has not learned from the past (non relevant pricing model prevents technology adoption ... remember SAP Interactive Forms by Adobe).

    Let's assume a company with 10.000 users doing some 'workflow' approval activities for 4 or 5 type of workflows. They obviously have already a userid.

    It means 1 MUSD !

    At that price I would recommend customers to build their own "workflow UIs" and do not purchase SAP ones (knowing all the required webservices are available).

    Myself at best I would estimate the price about a couple of USD (for not saying free of charges). In fact it should be free ... as it is solving a bug : current SAP User Interface delivered by SAP is from the last century. Customers are paying maintenance fee for a couple of years.

    Note : it is the same story with SAP Screen Personas.

  • Graham Robinson I asked Sam Yen if he could clarify SAP Fiori’s intended audience in regards to the “casual user debate.” I have posted his response on my Sapphire diginomica blog and also on yours here. Take it away Sam:

    “Fiori is for what I call the most broadly reaching scenarios and the most frequently used scenarios.  Wide and deep if you will. I generally don't like the terms casual, core, or executive to describe user roles, but Fiori certainly goes beyond the "casual" user.

    Graham gets it right in his response.  We have outlined an overall UX strategy of New, Renew, and Enable.

    "New" is the category of New SAP solutions such as cloud, mobile, consumer apps, etc… where we are investing to bring a much fresher consumer grade user-experience to our solutions. "Renew" is finding the existing transactions that 1) touch the most number of users and 2) that are used most frequently.  This is how we chose the 25 apps in the Fiori portfolio. The term "casual user" is very misleading and causes unnecessary confusion. Broadly used scenarios include things like vacation requests, workflow approvals, benefit checks. 

    These are things that everyone does. Frequently used scenarios are things like sales order create. As Graham said, the overall intent is to help our customers roll out a set of solutions that can quickly and broadly make an impact and hopefully change the perception about SAP's usability,”

    • Good work Jon.

      This pretty much answers my queries about SAP's strategy. The message seems quite clear for customers, which is something that worried me given the mixed messages customers feel they are getting over on-premise v Cloud in general.

  • Hi Graham,

    Thanks for sharing your thoughts.  Just one thing ... did you manage to get clarification from SAP on browser support?  In particular for desktops .... and lets assume most Enterprises are using Internet Explorer still.  SAP appear to indicate that SAPUI5 supports IE8 'with some degradations'.  However, where I am at the moment the HR Renewals 1.0 landing page for HR Professionals (which is based on SAPUI5) simply does not work with IE8 ... there was no indication in the installation guides about this.  SAP support then responded that you need IE9.

    With the Fiori apps, I've looked at the installation guides (available here I can't see a reference to browser support for these apps.  Did you get any sense of what desktop (IE) browser releases are supported? 



    • Hi John,

      the discussions around this issue were more generic than what specific browser versions are supported. Sam mentioned a signiifcant number of SAP users still on IE6! My reaction to that was #wtf! This occurs where some sort of old, but important, application will only run on IE6 and so they are locked into having it installed.

      When I heard that I realised that there are browsers in use that simply cannot be supported.

      What SAP are seeing is that there are more occurrences of users having two (or more) different browsers installed. And corporate IT are accepting of this and making it part of their SOE.

      I know that doesn't exactly answer you question - but it answered mine. 😏


      Graham Robbo

    • I saw this information in "SAP Fiori Prerequisities_May 16_2010.pdf ( --> Use Cases & Whitepapers --> SAP Fiori Prerequisites_May 16_2010.pdf)

      • Device and Browser Support

      • Desktop
      Microsoft Windows 7

      Microsoft Windows 8
      Microsoft Internet Explorer 9 and above with the exception of “My Spend”, “My Timesheet”, and “Create Sales Orders” which do not support this

      o   Google Chrome

      • • Mobile
        o Apple iOS 6 and above

      • o Apple iPhone 4 and above o Apple iPad 2 and above
        o Apple iPad Mini
        o Apple Safari

  • Nice blog Graham - thanks for sharing your thoughts, as expected this topic has legs and certainly provokes a response from many people.

    Regarding the price I think you have the right approach (although part of me would also like it to be free). The two best arguments I have heard for charging for it, rather than making it free are firstly like you stated, if it is not on the price list then the sales guys won't be motivated to promote it (which might hamper adoption) with customers and secondly that it is not just a nicer UI for existing functionality but that it adds mobile support to existing apps. I wonder however if "the price is right" - will it be enough to motive the sales guys, certainly in Jarret Pazahanick example it would be, in others maybe not. If it fails to motive sales and yet the cost still proves to be too much of a hurdle to adoption then it will fall into a no-mans-land, which I would hate to see.

    I think the other thing worth noting is that IE support looks fairly limited I think. I know a lot of companies who only support IE on the desktop and many still run IE8 or older (shudder!)... that could be a hurdle to adoption too.

    Only time will tell I guess, I hope we look back on this and see it as a fundamental shift in the UX for SAP and not just another UI technology that falls by the wayside. The architecture and open(ish) nature certainly look promising.



    • Hi Simon,

      I am sure if I went to SAP looking to license 84K users we could come to a suitable agreement. 😉

      See my response to John Moy comment regarding browser support.


      Graham Robbo

  • First, I think unless I had a customer with tens of thousands of employees, even the list price for this functionality is attractive - with higher volumes and even lower ones no doubt comes discount too. But it would be hard to build and support such a wide selection of tools at that price point (although I'd love to see what Jo I could build using $300k and free reign!)

    But I do think it is worth pointing out the required infrastructure/security for such apps to work. If you want the app to function outside of your corporate firewall, you are likely to have to invest a little bit in infrastructure (reverse proxy setup, holes in firewalls, etc) - not to mention how to ensure that users can securely authenticate to your network externally.

    I've not heard about how a Fiori "app" authenticates itself with the Gateway server it uses, perhaps via certificate, or perhaps username/password? in the former case one must consider how these are distributed to users (an MDM platform make sense for mobile, but what about desktop?) and in the secondary use case is this really secure enough and is it in keeping with the user experience that we should be hoping for? Or does it use a central IDM and heaven help me SAML authentication 😉

    Would love to know more about this Robbo - so please chime in if you have an understanding! As per all enterprise mobile experiences, the cost of the app is just a part of the puzzle and understanding the requirement for authentication is a great part of the sky part of the puzzle (those blue bits with bits of cloud are always the hardest bit of a puzzle to put together.)


    Chris aka Mr Wombling 😛

      • Thanks Robbo, the linked blog does explain a great amount and certainly great further reading on this topic. Recommended!

        What the linked blog does clearly show is that one should not think that a single user licence payment is going to mean that you can access your leave approvals from the gym! There's a reasonable amount more to do. And wrapping these "apps" in SMP to allow deployment using Afaria with associated certificate distribution isn't a small infrastructure problem. Although I agree it is one that every organisation that is looking to use mobile application should be thinking about and position themselves with a strategy (even if it as pragmatic, try it out on case by case basis strategy).

        Thanks for the link, it helped my understanding.

        BTW, what do you think about calling an HTML page an "app", it's certainly an application, but think the terminology is perhaps confusing for some and makes one think that the work to do to wrap it to become a deployable app has already been done.

        I'm not going to go into my thoughts about how there should be different user experiences for different application platforms (beyond the responsive design that Fiori currently offers).

        • Not sure I see the benefit of wrapping these user experiences in a binary like phonegap. I must admit I am far from convinced extra hassle is worth it just for the deployment. Surely the simplest deployment is "hit this URL"? Of course phonegap does more than give you a deployment option - and combining it with something like Mocana could be really compelling.

          As for the term "app" I'm not entirely comfortable calling a HTML/ECMAScript/CSS only experience an "app" - but I am willing to go with the general flow.

          p.s. Notice the ECMA 😀

          • If I could give multiple likes for the ECMA I would 😉

            Remain to be convinced about Mocana - but that's another blog altogether. 🙂

          • Couldn't agree more, Graham. I run the dev platform for Mocana. In addition to the organic benefits of securing a cordova wrapped fiori app, the new auth sdk we offer to developers allow you to simplify & consolidate auth. Have had a customer do this & they love the ux benefits in addition to security benefits.

    • Thanks, Chris, for making the points I'm usually making 😉

      Graham , the SMP wrapping would allow you to manage mobile devices / services throughout your user base instead of simply exposing a URL to everyone on the internet.

      Chris, I agree on Mocana - I'm sure it can add an additional layer of protection, but it certainly won't be able to make insecure applications secure by applying magic dust. All the secure coding topics like validating input (buffer overflows, SQLi) and not exposing data to the world still remain important.


  • Hi Graham,

    Thanks for a comprehensive overview of the Fiori announcement.

    Do you know if this will also be resold through partners, or whether it is only a direct (credit card) purchase via the site linked above?

    It's an interesting decision if it won't be resold through the partner channel, as then SAP may find some partners reluctant to introduce it compared to them selling their own custom apps they've built.



  • Nice recap of the Fiori apps. When i first saw them @ SAPPHIRE , my first reaction was wow, its my favourite BSP with my new found love SAPUI5 library.

    But was taken back when the licensing thing came up. Do you know whether Fiori license would also cover the GW piece license as well?


    • Hi Raja,

      I assume there really isn't a gateway licensing piece for Fiori. That is because the Gateway license is already included in the existing user license.

      But you do raise an interesting point. Does my 100 Euro per user for Fiori include user license for back-end functionality? Therefore if we do not have ESS/MSS licenses for all employees does Fiori license cover them for this? I need to find this out.


      Graham Robbo

      p.s. See the last few comments to this blog where I describe the changes in Gateway licensing that happened in October last year.

      p.p.s. Great to finally meet you in Orlando

  • Graham -- just a quick one: I don't see the snafu between "occasional user" and "frequently used SAP functions".

    I'm the living example: I basically only use one core SAP function -- expenses -- around six times a year, yet it's clearly one of the most broadly, frequently used systems in the company....

    • Hi Timo,

      my "snafu" comment was meant to refer to an inconsistency in the messaging from SAP.

      The Fiori apps are targeted at the "broadly and frequently used" functions just like the expenses application you mention. The kindest way to explain what I heard is that someone from SAP attempted to position Fiori as for "occasional users" and therefore, by implication, other SAP offerings in this area for "professional users".

      For me it wasn't a good look.


      Graham Robbo

  • The comments in the blog have become more interesting than the blog itself for me. Just reading through an educating me on the pricing model for Fiori.