Skip to Content
Author's profile photo Martin Voros

Not So Simple

Not So Simple

Anyone who is somehow connected to SAP world must have noticed the new message pushed by SAP to their customers: “Simple”. Even their latest flagship product S/4 HANA has it in its name. I can’t imagine anybody who would object to this message. Nobody likes complexity. The question is that if we can really do something about this. Hasso and others from SAP argue that this complexity can be reduced with new technology that we have access to these days. Based on my experience almost every program gets more complex during its lifetime and there is often room for some improvement or refactoring.  This is also true for business processes. Hence there is definitely room for improvement and we just need to wait if SAP can deliver.

But what I would like to talk about is that the systems and enterprise landscapes are getting more complex. The systems used by users might be simpler to use with nice UI. But there is a hidden complexity that we, IT professional, need to tackle. E.g. Facebook looks like a simple app that provides value to its users but we know that there is a huge team behind that must manage this beast. So it might look simple to users but it’s not so simple to us, IT professionals.

Fiori Use Case

Let’s take a look at Fiori apps. The new Fiori apps are much nicer comparing to old GUI transactions. They represent how the users will access these new simplified apps. For some of them, you do not need HANA and almost every customer who is on sufficient release level can start using them right now. I am going to talk about the standard deployment scenario where you have a front end system that hosts the Fiori apps and is accessible from the internet. And there is a back end system such as ERP. You almost definitely want to go with this scenario. It allows you to be more agile with deploying fixes to the apps and based on my experience there are many fixes coming from SAP. It also has some nice security implications.

The following section is going to be more technical but I hope that it will help me to illustrate additional complexity introduce by Fiori apps. I am going to describe what happens when a user accesses a Fiori app. For simplicity, I am going to ignore Fiori Launchpad and I assume that the user accesses the app directly. I will also use the PO approval as an example.

  1. The user is accessing the app from external network from her mobile phone. The connection is required to be protected by TLS because the app can be accessed from external network.
  2. The user needs to be authenticated against front end system. Some of the standard methods provided by ABAP AS can be used. There might be a requirement to use two factor authentication to better protect access to the system.
  3. After successful authentication the user gets UI5 app. The app performs a call to front end system to retrieve a list of POs for approval.
  4. The front end system validates if the user has sufficient authorization to call OData service
  5. The front end system calls the back end system via trusted RFC to perform actual business logic.
  6. The back end system validates if the user has sufficient authorization to call OData service
  7. The back end system validates if the user has sufficient authorization to perform required business logic. The checks depend on application logic.

I highlighted in bold the steps that have impact on security. So what do we have here? We definitely need to protect HTTP connections using TLS. Sadly, this should be the norm even for internal systems but that’s not the case based on my experience.

We also need to be able to authenticate users in two different systems. Currently, most of the users will still need an access to back end system via SAP GUI. At this stage, the Fiori apps do not deliver all functionality. The scenario where the users have potentially two different passwords is not acceptable. There might be also additional requirement to provide two factor authentication for these apps.

Another thing is that it uses trusted RFC. What it means that we need to have a reliable way of provisioning user to multiple systems. Also different authorisation checks are being executed in different systems so we need to have two sets of different roles.

Side note: I understand that some big customers might have already solved these challenges/issues and adding additional front end system does not impose any challenge. Based on my experience with smaller SAP shops that very often use only ERP and BW this presents a real challenge.

This Fiori use case demonstrates how much new complexity is added to landscape comparing to having a simple ERP system. SAP is also pushing for hybrid cloud so you can image what the impact of introducing SaaS app in your landscape will be.

How Do We Tackle This?

So similarly to the ways of dealing with risk, you have the following options:

  • Avoid
  • Transfer
  • Reduce

Avoid – I am pretty sure that there is at least one SAP customer that decided that they will not implement the Fiori apps in their environment due to cost at this moment. The apps are for free (included in a standard license) but the cost of implementation is definitely not free. This is OK because it doesn’t create new risk but the customer is missing on benefits of the new apps.

Transfer – SaaS model offers the customers an option to transfer complexity to SaaS provider. The customer’s job is significantly reduced but there is still some stuff to do. You could argue that implementing SaaS might be taken as the third option Reduce.

Reduce – how are we able to deal with the complexity of new systems? It used be that a system administrator was responsible for handful of systems. How is it possible that these days one admin can administer 10 000s of servers? The answer is tools. We have much better admin tools that we can use to fight the beast of complexity. Do we have better tools in security space? There are definitely some tools that we can use to tackle complexity. In Fiori case it’s obvious that in this new environment with multiple systems we need to have a robust system for user provisioning a.k.a. identity management solution. The single sign on solution goes hand in hand with identity management. In this case using SAML would be good choice. So my suggestion would be to evaluate your current environment if it’s ready for the future and start implementing tools/systems that will help you to manage the complexity of the current systems.

TL,DR; there is a push to simplify user’s experience with business apps. This has impact on complexity of the systems that is hidden from users but visible to IT. So it’s simple to users, not so simple to us. The only viable way is to start building/implementing tools that will help us to tackle this complexity.

Please let me know your experience with tackling complexity in your landscape and how you are getting ready for the future.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.