Skip to Content

If you are currently evaluating a migration from ECC to S/4HANA, you surely know that a significant part of the process involves custom code remediation. When our team delivers preliminary results, customers are always astonished by the number of errors coming from third-party ABAP add-ons.

This should be no surprise. The commercial open-source nature of SAP’s software platform and the complexity of combining regional, industry, corporate functions, and changing regulation requirements has generated an ecosystem of third-party solutions supporting tax calculations, product pricing, software integration, mobility, and so much more.

Traditional Architecture: ABAP Add-On

For these so-called “3rd party solutions”, the traditional architecture relies on slapping a small add-on of ABAP code in the customer namespace of the SAP Business Suite. If this was the norm 10 years ago, it just can’t work with cloud technologies, especially S/4HANA Cloud. So why are software vendors still relying on an already outdated architecture? To change practices, we will need to see enough changes in three key areas: the software, the customer, and the ecosystem.

Future Architecture: Cloud and APIs

Readiness of the Software

SAP has come a long way in recent years to convert its business suite into a business platform. The S/4HANA Cloud was introduced together with the API Hub and the corresponding SDK. The whitelisted APIs are guaranteed to work with both S/4HANA and S/4HANA Cloud since they share the same codebase.

But there’s a catch: developers used to program practically anything in their ABAP code. With the APIs, however, the list is limited, even if it’s growing with each quarterly release.

The business logic also must be handled somewhere else, ideally in the SAP Cloud Platform. This requires a significant refactoring of the program with a different language and process. Software vendors must consider the cost and risk of this redevelopment project with the benefit for the customer.

Readiness of the Customer

Let’s face it: during their software vendor selection or license renewal process, how many SAP customers have explicitly asked if the solution was compatible with S/4HANA Cloud? Why not?

Just like moving to S/4HANA is inevitable, the future will be S/4HANA Cloud. This might take 5 or 10 more years. It will take investment from SAP in terms of scope or data center or pricing. This might not apply to the headquarters, but only to subsidiaries, especially with the growing capability of the two-tier ERP offering. It will take time, but S/4HANA Cloud will become the standard soon. So why not ensure that the solutions we’re selecting today and the architecture we’re implementing are compatible with that future? If customers are not making this a priority, there’s little incentive for software vendors to deliver.

Another hurdle is the delivery mechanism: most SAP Basis teams are familiar with receiving / downloading a package of ABAP code and implementing it to enable access and features for 3rd party applications. They can even easily get the code reviewed by the internal ABAP teams if in doubt. Security is easily handled with existing processes.

Connecting web services into an ERP environment is another type of project altogether. During a recent project where a Central Finance instance was hosted in a public cloud, a significant part of the installation time was spent finding the right port numbers to open and getting authorizations to make changes to the firewall configuration. And that was standard SAP to standard SAP. Imagine the same scenario with a 3rd party vendor.

Readiness of the Ecosystem

Every new technology requires a tipping point to become standard practice. This is of course the case with APIs, micro-services, and developing for S/4HANA Cloud. But more topics need to be taken into consideration.

SAP has recently made the news with high-profile lawsuits related to licensing. The so-called indirect access has consequences on the partner ecosystem: an ABAP add-on in an ECC system executed by a licensed user doesn’t impact the SAP license cost overall and provides more opportunities for that user to get value out of the SAP investment. However, the situation is different is APIs are used to remotely read or trigger transactions. This is especially the case with applications related to mobility, workflow, or reporting. Even if SAP is offering new pricing models, would customers really want to come back to the negotiation table with their SAP account representative over a few licenses?

Some vendors, though, already see the writing on the wall and start converting their codebase. Vertex, well-recognized for its tax calculation solution, shared their experience during the SAP TechEd executive keynote. In short, “our transformation journey was shorter than expected: weeks instead of months.”

Conclusion

The future is cloud-based. It’s not about IF, but WHEN. With that in mind, 3rd party vendors should start reengineering their solutions, while customers should start requiring future-proof solutions.

Recommended Reading: the 5 Golden Rules for Implementing SAP S/4HANA Cloud, Single tenant edition

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

      1. Michelle Crapo

        Nice add to an already nice blog.     I can see the need to start building for the future.  Third party vendors will probably invest for the cloud version.

        (1) 
  1. Joachim Rees

    Hey Julien,

    nice read, thanks for sharing.
    One small aspect, I would like to comment on:

    For these so-called “3rd party solutions”, the traditional architecture relies on slapping a small add-on of ABAP code in the customer namespace of the SAP Business Suite

    “customer namespace” (Y* + Z*), really? I guess and have heard some 3rd party vendors actually do that, but I don’t know why. The “clean” solution for this very case is to get a “proper” Namespace (e.g. /XYZSOL/ ).

    Otherwise, how could you avoid collision (importing my zz_report into your system, overwriting your existing zz_report) or confusion (“let’s see what we(customer) have developed” -> search for z* ).

    So I would add that this (proper usage of namespaces, instead of invading customer namespaces), is also something  customers should start requiring!

    best
    Joachim

    (1) 
    1. Julien Delvat Post author

      Changing the naming convention from {Y* or Z*} to {/XYZ/} is only a band-aid on a wooden peg. Relying on on-premise ABAP for add-on solutions is not forward-looking.
      That’s the core message here.

      (0) 
  2. Jelena Perfiljeva

    Yes, somehow finding a port to open and firewall changes tend to become the most challenging part of an integration project. 🙂

    I agree with you that if the customers don’t demand future-proof solutions then there is no incentive for the vendors to deliver them. Sometimes we’re in a Catch-22 situation though. If a customer is, say, running ECC EHP6 ABAP 7.31 system right now then what degree of “future-proofing” could they realistically expect from a vendor? Could architecture is totally different.

    Even in our internal ABAP development this can be a challenge. For example, at some point we had 4 different SAP ECC installations, all on different release levels, from EHP1 to EHP7. When new corporate overlords took over, we had to create an interface for all 4 systems to send a file to some global application. To do that, we had to do all the development in the lowest release system, to make sure the program can run in all 4. If there was no coordination and, say, someone wrote a program in ABAP 7.4 syntax then we’d be in a pickle trying to implement it in the lower release systems. Likewise (although this happens less and less, thankfully) if you bring some code from an ancient system to a newer Unicode one quite a few things would light up too.

    Compatibility is not an issue unique to SAP though. That’s where we need to learn from the rest of the IT world. I believe that adherence to good development practices (which have existed for many years already way before Cloud or HANA) will be beneficial in the long term for all parties: customers, vendors, and SAP as well.

    Thanks!

    (2) 
    1. Julien Delvat Post author

      I like your point about internal development teams. These teams should also future-proof their coding with connections via Cloud Platform.

      (0) 
      1. Jelena Perfiljeva

        We could start some degree of future-proofing. I don’t think using Cloud Platform would make a lot of sense though or even be technically feasible (talking about ECC 6.0 ABAP 7.31 here). Just being realistic. I’m still working on BDC and user exits in MV45AFZZ. Cloud Platform? LOL.

        (2) 

Leave a Reply