Considering where SAP Fiori fits depends on how you define it within your technology footprint. In an earlier post on the SAP Fiori strategy I explained that while Fiori is certainly a solution to many mobile challenges, it’s not a mobile platform at its core. It’s a user experience platform with a mobile-first framework.
It’s still a great solution for mobile, but it can be so much more. However, I’ll save the use case discussion for another post on choosing SAP Fiori use cases. How you are planning to use it doesn’t change how you’ll need to work SAP Fiori into your technology footprint. Here I’ll explore Fiori as part of your architecture footprint, and part of your mobile software footprint.
SAP Fiori as Part of an Architecture Footprint
If you have a traditional SAP landscape, you’re dealing with multiple environments. Your first decision is to what degree you want to deploy Fiori. In our experience, we generally lead with either a standard install (full environment) or a “light” install – for just one environment. This is because deploying Fiori throughout your entire landscape is not the best option if you’re just running a feasibility pilot, as an example.
The great news is that because there are minimal pre-requisites to installing Fiori, Gateway being one, we can usually stand it up in a matter of days for a test environment. Throwing in your Dev and Prod environments extends that a bit, but it’s still not a huge time consumer. Getting Fiori up and available is something we can realistically achieve in days or weeks, even for a more complex environment.
At a minimum, you need to be sure you either have installed or are ready to install ABAP, Gateway, and UI5, and of course, ERP Business Suite, or other backends that you want to leverage like CRM, SRM, or PLM.
From a backend standpoint, you may be connecting to ERP, but you can also choose SRM, CRM, others. Be sure that you know which backends will be required for the apps you are choosing for your initial use cases (see next post), especially if you’re choosing a custom or enhanced app.
The good news is that Fiori offers out of the box connectivity to SAP backends, so choosing to connect to future backends will be something we can achieve quickly when the time is right. The even better news is that there are truly no limits to what you can connect to Fiori.
if you want to connect it to SalesForce or some other application, that is possible. Did I really just say that?
Sure did, but it’s not likely something SAP will encourage, of course.
SAP Fiori as Part of a Mobile Footprint
I’ll put my feelings on Fiori as a user experience solution aside, because the pressing question for most is how it is going to fit into a mobile strategy. We have a great matrix slide that compares Fiori on a number of different levels to other mobile technologies, but I’ll keep it a bit briefer than that here.
There are three different approaches to integrating Fiori into your mobile strategy.
Leading with Fiori is most suitable for anyone who hasn’t already purchased SAP Mobile Platform (SMP) or legacy mobile licenses – that is obvious. It’s a way to test out the “free” product to see if you’ll need to spend money. However, this scenario is the most likely to fail early if the wrong use cases are chosen.
Use case is absolutely imperative here. Read my next post on choosing the right use case for more details, but at a minimum, the use cases have to meet the following criteria:
- Users are always connected
- Roles are clearly defined
- Limited data processing is needed
- Use case is simple
I’m not suggesting that Fiori can’t meet more complex use cases. In fact, I’ll talk about that more in the final post in this series. However, if you’re looking to deploy Fiori as a pilot for enterprise-wide mobility, you have to get a few wins under your belt, and the simpler, better defined scenarios will render the best results.
In reality, a hybrid approach to mobile delivery is going to be the solution that best fits most companies. Why? Because of the limitations I laid out previously. The limitations of Fiori are beautifully supported in the SAP Mobile Platform, as one option.
For example, consider the connectivity limitation. Odds are, if you have some users that are infrequently connected (like field service), you also have some users that are only disconnected in very rare situations (executives, office employees). In that situation, you have an opportunity to deploy Fiori for the connected users (as long as they meet the other criteria) while only licensing SMP for the disconnected users. This saves money in licensing, and allows you to really utilize the strengths of each solution.
However, there are some major challenges to this approach. For one, you’ll be supporting multiple applications and experiences, which certainly costs. Also, you will have to deal with the shared use case obstacle – when there is a use case shared across both connected and disconnected users, how will you deploy that use case? Just on Fiori? Or twice, once in each product? This is something you’ll have to deal with early.
A hybrid solution approach does not differ in licensing or technology from hybrid footprint, but it differs in delivery. Consider this an advanced approach that may address some unique situations.
Hybrid solutions are ones that allow us to leverage a native or SMP application with Fiori-delivered content. What that means is that we can utilize containers within native or SMP apps to deliver other Fiori apps or features. The two real challenges this solves are the “build once” challenge, in which you have features that you want to deploy and manage within Fiori, but you have users that need to utilize the SMP capabilities, and the “UI” challenge, in which you want to resolve some major usability issues by leveraging the Fiori themes.
This is an advanced approach, and requires a strong strategy and support system. However, it’s a method you can use if you’re targeting the hybrid footprint for your enterprise.
Want even more information? Watch the SAP Fiori video by SVP Pete Lagana now.
Leave a Reply