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.
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.
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
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
- SAP Managed Tags:
11 Comments
