In my previous blog post, I introduced the first element in our BEANS framework: Business intelligence. Today, we’ll take a look at a more scalable alternative approach to enhancements in the SAP space: Extension apps.

(Re)Introducing the Side-by-Side Extension Concept

Developing enhancements for SAP solutions has never been easy. Even back in the halcyon days of SAP R/3 when there was only 1–2 ways of building enhancements, developers still had to come up with clever ways (cough, hacks) to surgically enhance existing transactions/applications. For some ABAP developers, this has become an artform which requires as much arcane knowledge about the inner workings of SAP standard apps (some of which are close to 30 years old now) as it does programming ability. Put simply, this is definitely not the kind of work you hand off to a junior developer.

Despite SAP’s best efforts to define customer exits (and then eventually Business Add-Ins or BAdIs and enhancement spots) to provide the right “hooks” for customers/partners to build on top of, the reality has been that many of these user exits have never quite worked the way the business wanted them to. As a result, we frequently encounter “enhancement” solutions in the wild where some useful bit of data is exported out to shared memory in one user exit, picked up and embedded in another, and then processed with a third. Although such solutions may work today, these sorts of enhancements are a house of cards waiting to fall at any moment that SAP decides to change up even the tiniest pieces of standard functionality/process flow.

Even if you manage to get all this right from a technical perspective, there’s also the topic of user experience. In many cases, limitations in existing apps requires developers to shoehorn functionality into a custom tab or button buried deep within the UI. Although modern enhancement tools like SAP Screen Personas can smooth out some of these rough edges, it’s rarely a seamless fit for the end user.

Fast forward to today, and SAP customers face an even bigger challenge. Although they may continue to build enhancements on top of their on-premise ABAP-based systems (e.g., SAP ECC or S/4 HANA), there’s also a number of non-ABAP systems in the mix to account for: SuccessFactors, Ariba, Hybris, and so forth. When you combine these systems with other systems that might exist within the overall enterprise landscape (e.g., Salesforce, Workday, Dynamics 365, and so forth), it becomes clear that enhancement strategies need to change.

Recognizing all this, SAP has introduced a “side-by-side” extension concept in recent years focused around their SAP Business Technology Platform (SAP BTP) — formerly known as the SAP Cloud Platform. As you can see below, this concept shifts much of the extension development away from the satellite systems onto a common Platform-as-a-Service (PaaS) that provides modern tools and services to facilitate extension app development. Using open APIs (primarily OData), developers can build all kinds of extension apps using a “Bring-Your-Own-Language” (BYOL) approach to development. Here, while ABAP is one of the BYOL options to choose from, customers can also choose to leverage other popular programming environments such as Node.js, .NET, Python, Java, and so forth. This, in turn, unlocks the opportunity for customers to leverage existing development staff to build extension apps.

Although SAP BTP is naturally SAP’s recommended option for all this, there’s nothing stopping customers from just leveraging their preferred PaaS provider solutions (e.g., Azure, AWS, or GCP) — either in isolation or in tandem with SAP BTP via the Cloud Foundry marketplace concept.

This side-by-side extension concept can even work in a pure on-premise/private cloud scenario using existing tools/systems. Although modern PaaS technologies offer tremendous opportunities for accelerating innovation, this isn’t really a conversation about the merits of adopting cloud technology, per se. Instead, the focus is on:

• Reducing reliance on proprietary technology (e.g., ABAP/obscure enhancement concepts)
• Unlocking a wider audience of developers to work on SAP enhancement projects
• Improving user experience
• Accessing tools to level up functionality (e.g., using Python for machine learning scenarios)
• Enabling developers to create “mash-up” experiences that streamline business processes that cross over multiple apps (e.g., SAP + Salesforce)
• Broadening access(e.g., mobility scenarios)
• Eliminating technical debt & simplifying upgrades
• Lowering the total cost of ownership (TCO)

What are Extension Apps?

For the purposes of our BEANS conversation, extension apps are apps that build on top of SAP APIs to fill in functional gaps within SAP standard products. These apps could be interactive web and mobile apps or passive apps that facilitate workflow/integration with other systems.

While these extension apps could certainly be built using SAP-centric technologies such as ABAP and SAPUI5, this is not strictly necessary. Indeed, for customers struggling to find or afford quality SAP development resources, we see tremendous opportunity here to tap into more abundant, lower-cost development resources.

To put this concept into perspective, consider a requirement to build a warehouse shipment route monitoring app on top of an on-premise SAP S/4 HANA system. Here, instead of building a custom Fiori app using SAPUI5, we could alternatively leverage available web developer resources to build the app (e.g., Angular or React resources, for example). We even have the option to give these apps an SAP-centric look-and-feel using UI5 Web Components technology. Much like SAPUI5, the custom web app is positioned as a responsive web app that simply consumes OData-based APIs.

Although SAP/ABAP knowledge is definitely required to locate and/or develop/enhance the target APIs, there’s no reason why the app itself couldn’t be developed in a variety of different ways. Teamwork is definitely required to map the APIs, but we see that exercise as being necessary/valuable even in scenarios where we’re building a purely SAP-centric solution. Today, we see far too many “half-baked” SAP APIs that get thrown over the wall to UI developers. These APIs are typically throw-away APIs that can’t be reused in other app scenarios — a phenomenon we’ll explore in further depth in my next blog post.

Besides the more common UI-centric extension apps that interactively pull data out of SAP, we can also develop extension apps that listen for business events such as the creation of a sales order. These apps can serve as triggers for more complex business processes — especially those that cross over multiple business systems and/or departments. In a future blog post, we’ll see how these types of extension apps pair nicely with serverless integration technologies such as Kyma and Power Automate to create low-cost workflow solutions with near infinite scalability. Such scalability can unlock powerful app scenarios where (on-premise) system capacity has constrained us in the past.

Striking a Balance

Despite their many benefits, extension apps are not a silver bullet that can be used to solve every type of gap requirement within an SAP system. Sometimes, we may require a level of precision that can only be accomplished using in-app extensions (e.g., enhancement spots in ABAP-based solutions). This is particularly true for surgical enhancements that call for custom fields/functions on a very specific app screen, etc.

If we’re just talking about tiny tweaks, then extension apps may be overkill. After all, we don’t want to reinvent the wheel. If the SAP-provided Track Sales Orders app does 95% of what the business wants, there’s probably enough value there to justify adding to the proprietary enhancement inventory.

On the other hand, if an enhancement requirement does not call for in-app extension capabilities, we think that extension apps make a ton of sense for customers. This is particularly true for legacy extension apps that were unnaturally absorbed into SAP’s gravity well just because it was easy/convenient. We see many “Z-apps” like this out there all the time where an app was developed on legacy UI technologies like classic Dynpro just because they tangentially touched SAP data in some way. These apps are a nightmare to upgrade and have no real business being in SAP.

Closing Thoughts

At the end of the day, much of this comes down to opportunity cost. If we look at this at the enterprise level, there’s tremendous value in consolidating as much of this type of work onto a common platform where we can manage costs, reduce technical debt, and unlock new capabilities — concepts I’ll be expanding on further as move along in this blog series.

Thanks for reading — look forward to hearing your thoughts in the discussion thread.