The majority of large global enterprises run their businesses on SAP and have done for decades. When SAP released R/3 in the 1990s, customers embraced the idea of using SAP as one monolith IT system that ties their different business units together.
Then, as customers customized SAP functions to meet their specific business requirements, the general approach was to build all extensions and customizations into SAP itself, using the ABAP programming language. Other extensions like front ends were added directly into SAP as well, using SAP GUI, Webdynpro, BSP, AIF, GuiXT, Fiori, and others.
And it worked – for some time. But now, the cracks are starting to show.
The trouble with legacy SAP customization
Past or present, SAP customizations come with high costs and long lead times. Some companies have accumulated hundreds of millions of lines of custom code over the years, adding to their technical debt, and upgrades have become complex and time-consuming due to all that custom code.
Now, however, times have changed. Modern architecture trends are the decentralization of functionality and open landscapes, where systems are composable, and functionality is accessible through API libraries. Companies buying SaaS solutions, like Salesforce and ServiceNow, have learned from their past mistakes: they want to keep these new systems as close to the standard as possible. SAP is following suit with the call to migrate to S/4HANA.
But what do you do with your legacy SAP systems, with all its custom code, in this new architecture?
S/4HANA migration: When adopting a greenfield approach is your best option
For enterprise customers that have heavily extended SAP systems, the only way to migrate to S/4HANA is to go greenfield.
A greenfield approach means not migrating to S/4HANA at all–or just migrating your data. You retire legacy customizations and build anew to streamline processes.
Why? When an enterprise has a decades-old SAP implementation that has been patched and customized to keep up with the market and tech trends, the business case to upgrade to S/4HANA simply is not there financially.
However, doing a greenfield S/4HANA instead makes sense.
You can rebuild your core system from scratch, eliminating the vast majority of your custom code and getting your global IT in line with new principles – cloud-first, composable, microservices architecture, good-is-good-enough – all so you’re ready for the challenges of the next 15-20 years.
But then the question is: what to do with all that custom code that is in the current R/3 systems?
If you plan to keep your platforms as close to the standard as possible, then you will have gaps; you need additional functionality that makes your company unique, but that can’t be bought in the market.
What are your options? Because SAP preaches to its customers to “keep the core clean,” OutSystems is an excellent way to start.
It is the only low-code platform in the market that is fit for building large, complex applications that connect to any other system in your landscape.
To reduce your dependency on one vendor, it is important that your white-space solution is an independent platform. There’s additional value as well.
Using an independent low-code solution also gives you the ability to create cross-system workflows. For instance, you can start in Salesforce and end the workflow with sales order and project creation in SAP. Or you can start in ServiceNow, and connect dynamically to different SAP backends, depending on the region and business need.
OutSystems has already proven this at several Fortune 1000 clients.
We ourselves, at NovioQ, have built dozens of OutSystems applications reading and writing SAP data, for production planning, global purchasing, reseller portals, financial services, field services, material master creation, and more. These applications are processing large amounts of transactions in a secure and performant way and are proving their worth every day.
By using OutSystems, our clients can deploy new solutions faster, and because it’s outside the SAP environment, development and deployment are not impacted from starting new initiatives during lengthy SAP upgrades or rollouts.
Having a separate development track next to the traditional SAP track gives them the freedom to develop independently and to bring new functionality live in a matter of weeks instead of months.
If you want to know more about how OutSystems can help you change the way you build your extensions, contact us for an introduction.