I had a fascinating discussion with a potential client this week. The head architect’s simple question stopped me in my tracks – “How can you support approving SRM shopping carts from version SRM 4.0 but Fiori requires the backend to be SRM 7.0?”, “What secret sauce are you doing to make that happen?”

Confession time on our secret sauce – there isn’t any. When we designed our mobile approval solution we found we required only one variance to support any version of SRM - if you are on SRM 7 use rfc ‘FU_WF_RFC_DECISION’ otherwise use ‘BBP_PDH_WFL_DB_UPDATE’ when approving. Everything else we needed was identical – to read the cart details, get attachments, display the work queue, highlight changes, authentication etc. It was all pretty straight forward.

So SAP – what was your technical reason for forcing customers to upgrade to SRM 7 to get the Fiori love? Could you have easily delivered your SAP Fiori functionality to support your customers on older versions of SRM?

In my role as a solution architect I understand there are always some underlying compelling reasons to force customers to upgrade but was this question pushed hard enough? Wouldn’t the SAP chiefdoms objective be to offer Fiori to as many customers as possible? If so, these technical issues must have been insurmountable to not meet their goal. At the end of the day all Fiori is doing is replicating existing SAP GUI functionality in a more modern, user friendly experience.

If SAP had successfully abstracted the introduction of Fiori from the core business suite the uptake could have been quite spectacular. I wonder if it was ultimately a technical or business decision?