One does not simply implement Fiori Apps (without patching ahead of the implementation)

Two different approaches to implementing Fiori

A combination of the Fiori Launchpad, Fiori apps, and Personas is a big part of the the future for your SAP Enterprise software; however the journey is not a simple one for a customer.  There’s really two common ways an existing, non S/4 customer will get into Fiori which are:

• “That Fiori app is just what we need; let’s implement it”, and
• “I see the power that Fiori is going to give us, let’s build a vision, and build a UX strategy and plan on how to get there”

The problem with the first step is you may feel you are stepping into Fiori carefully, but realistically, you’re not going to be prepared and the ROI on your investment is going to be far from ideal.

Why you may ask?

Well it’s because the dependencies just to get started efficiently are not there.  See every Fiori app will typically require:

• minimal versions of certain components;
• will definitely require additional add-in’s you may not have, including some that may be required on your core ERP system which may require you to do large coverage regression testing if you’re a very touchy change managed organisation (e.g. Fiori My Inbox typically requires several notes to be applied to the workflow pieces of your connected ABAP stacks);
• will require training for your developers;
• will require licenses to be purchased for WebIDE on HCP (the SAP recommended development environment for Fiori web development);
• will require installation and security approval/set-up for the HANA Cloud Connector (the software which provides a tunnel from on-premise to HCP where WebIDE is hosted
• will require software versioning (usually based on Git)
• will require authorisation and authentication design
  

And on top of this; how does the Fiori Launchpad and/or Fiori app you want to deploy fit into your current user experience? Do people expect this to work on Mobile devices like SAP advertise it does with no changes (business interpretation of messaging)?

In short, you get the TCO that supports a new User Experience but only receiving a single Fiori app deployment. That and you’ll probably take short cuts since it doesn’t make sense, for example, to set-up the HANA Cloud Connector or the Git repository for a single app; which leads to an environment less than ideal to implement more Fiori apps in.

But there’s another way

But taking the 2nd approach, things can play out quite differently.

First, you have a plan to understand how Fiori will, over time, fit into your users’ UX. This will include understanding where mobility fits in, which will hit the hurdles that your security & governance hoops you need to jump through. You can also get your licenses in place early (there’s actually a free 10 user/developer license that can be used for WebIDE which takes a bit over a week to get which can drive setting up HANA Cloud Connector too (which is another security & governance hoop for you to jump through).

Your developers can also start taking open.sap.com courses to get up to speed because they know Fiori is coming.  And if you’re outsourced, it does not mean you can’t suggest strongly that you are expecting them to start upskilling in this area. BTW – Starting this week is Developing Web Apps with SAPUI5 –   which should be a really good follow up to Build Your Own SAP Fiori App in the Cloud – .

The big advantage of planning ahead (the main reason for this post)

While there’s lots more to state about the benefits of having a vision, including ratifying the vision with peers within the SAP ecosystem before realising you’ve gone down a rabbit hole of unsupported scenarios, the important point I wanted to make is:

• If you research the Fiori apps that you think may benefit your business; you can then apply the required add-on’s, notes and update your Gateway back-end “bits” when you do support packs for these apps!

If you do do this, and have some of the other pieces in place also, then within a single day, you can test out 15-20 Fiori apps in a single day with very little effort and see how well they actually work “out of the box”.

The only catch to this is the pace of change within the Fiori space so unlike with Support Packs, 6 months is a long time so you may want a newer release than you have installed, but it doesn’t mean the version you have is not supported still so not all is lost.

Now how to know what Fiori apps to prepare for? Well that’s what the Fiori Apps Library and the Fiori Trial is for.  You obviously have to filter out the incompatible apps but send these out to your SME’s or SAP minded functional owners to review; get their input; then use the installation information for each app to identify the prerequisites for your Support Packs which you pass to your Basis team to take care of during support packs.

The perfect customer to be asked to implement Fiori apps at

So just to come from a different angle to wrap this post up; the following is what I’d like to see if asked to implement a few Fiori apps at a customer:

• A UX Vision and Strategy that incorporates Fiori, mobiilty, etc; and understands where Fiori Launchpad fits in (though thisdefinitely evolves if it’s your first set of Fiori apps).
• A company that runs at least IE11 (or even better – Chrome) since there is no support for <IE11 any more.
• A back-end system (or systems) with all the required add-on’s for the apps requested in place already.
• All back-end systems have a suitable patch level of Gateway on it.
• Licensing for WebIDE with a HANA Cloud Connector set-up, either talking to an on-premise Gateway/Fiori server, or the HCP Fiori Cloud Edition.
• If running HCP Fiori Cloud Edition, confirmation the Fiori apps are supported on that platform.
• If running an on-premise Gateway/Fiori server, preferably installed with UI Add-On 2.0 and patched fairly recently (and as this is the innovation layer, the ability to update this relatively quickly with updates to the UI add-on’s, and UI5 versions).
• A Git Repository for “Fiori” (aka UI5) code.
• Chrome browser available on development PC’s.
• Developers who are passionate to learn UI5 and have done their homework at open.sap.com already 🙂

Feel free to add further “perfect customer” requirements below in the comments as I’m sure there are many learnings out there…