SAP’s key to generational change is its best-kept secret

SAP is no stranger to generation change. Turning 50 years old this year, it wasn’t until SAP reached middle age that it grabbed its original claim to fame as the leader in enterprise software applications. In the runup to Y2K, enterprises looked to a middle-aged software provider that was (it predated SAS by four years) to represent a new generation of enterprise business system.

In the past few years, SAP’s top management underwent a generational change with much of the current executive team populated by a bunch of forty year-olds. But generation change goes beyond showing off young faces. It’s the inconvenient truth that cloud and the disruption caused by the pandemic have pushed SAP and its customers into yet another transformation wave whether they like it or not.

But if you ask most SAP customers as to what that generational change is, in all likelihood they will point to S/4HANA, which is the successor to SAP ECC and Business Suite. Or they might think of SAP’s various cloud offerings for HANA, data warehousing, and analytics. Few will guess about the piece that is represents its true underbelly of change: SAP’s Business Technology Platform (BTP).

SAP talks BTP, but the message is still muddled

Call it SAP’s best-kept secret. Ever since SAP introduced it when it rebranded from SAP Cloud Platform roughly a year ago, we’ve been confused as to what BTP is.

And it’s not for lack of content, promotion, or verbiage. There’s the requisite technology stack chart showing all the latest APIs, data sources, and programming languages. There are web pages devoted to BTP, but they pinpoint what BTP can do rather than what it is. Addressing application development, integration, automation, AI, and planning & analysis, BTP offers nearly a hundred prebuilt cloud services covering the waterfront. It includes a “Discovery Center” where customers can assess business outcome missions from the perspective of the implementer. And with roughly a third of the portfolio offered on a freemium basis, SAP is certainly serious about getting BTP services in developer’s hands. Other content on the website shows selected customer success stories, such as Farys, a Belgian wastewater utility, that was able to get reports 10x faster and build a customer self-service portal that automated over 90% of interactions, all with BTP.

But nowhere does SAP clearly put its cards on the table and flatly state what BTP actually is.

Spoiler Alert! BTP’s about SAP app modernization

At SAP’s main SAPPHIRE event this week, we finally got an explanation. BTP is the technology foundation that changes the way companies develop and extend their SAP applications.

Part of the confusion is that a key part of the message behind BTP is not new. From the days of S/3 and up through ECC, SAP warned customers not to customize inside the application. However, with APIs still another 10 – 15 years off in the future, customers would have had to custom-build their own interfaces to extend SAP to keep the core application code pristine. But SAP also provided tools for customers to take the law into their own hands, with the ABAP language, later supplemented by Java. And so typically, most ECC implementations are likely to have a lot of custom ABAP code inside them, especially in financial accounting modules. And therein lies the rub.

With all that intrinsic custom code, two words ended up striking terror into the hearts of ECC customers: Version Upgrade. Updating versions or instituting patches inevitably meant checking countless interfaces to ensure that functionality would not be broken. Some of SAP’s largest customers had up to tens of thousands of customizations in their own implementations.

APIs to the rescue

By the time SAP introduced what is now known as BTP, APIs became established practice and popular with developers. The guiding notion behind BTP is to abstract all the customizations outside the core code through APIs. Reliance on APIs is a rule of thumb for cloud SaaS applications, which would otherwise constantly break if they let their customers mess with the innards. With BTP, SAP is telling its customers that they should adopt these practices, regardless of what generation SAP software they are running, or regardless of whether they are running in the cloud (or not).

The theory is that if you keep the APIs stable, the core application should be well protected and the extensions should interoperate with them. While APIs are generally associated with integrating applications or connecting applications to different data sources, they could also be used for the purpose of protecting the core code. And while BTP is often described as a collection of reusable services, at its heart, BTP provides APIs enabling SAP customers to wean themselves off years of bad habits, keeping modifications away from the SAP app. Given that APIs are the default mode of interoperating with SaaS applications, it’s not surprising that BTP initially surfaced as part of the rollout of what used to be known as SAP Cloud Platform.

Let’s cut to the chase

SAP needs to clarify what BTP actually is. It’s more than just a bunch of APIs and services. At the end of the day, BTP is really about modernizing how classic and low-code developers work with SAP applications. And we’re not just talking about the current generation like S/4HANA.

Nonetheless, most SAP customers adopting BTP are likely to be headed for newer offerings like S/4HANA, Data Warehouse Cloud, or Analytics Cloud, but there is also an important bridge play for customers who may still need to have some assets on ECC. And in fact, it has also been back-ported to legacy SAP solutions such as Business ByDesign.

BTP is also about SAP broadening outside the ABAP developer base, and for that matter, also reaching out to citizen developers. With BTP, they can write apps or changes in the language of their choice, which is pretty critical given that ABAP is a legacy language that is not attracting many developers these days (akin to COBOL). And that extends from traditional coding to low code/no code tools that SAP is starting to promote. It’s a portfolio of prebuilt cloud-based services for common capabilities to give developers jumpstarts that can be run against SAP (and for popular sources, non-SAP) data in the cloud or back on-premises.

For SAP and its customers, BTP represents both challenge and opportunity. It’s an opportunity to make customer SAP implementations less brittle, and enable customers to become more agile by overcoming the fear, not only of upgrades, but of adding new functionality. During the course of the pandemic, businesses have had to embrace change, from hybrid workplaces to accelerating digital processes, new approaches to resiliency, and more recently, paying more attention to sustainability. Upgrades the old fashioned way just won’t keep pace.

But it’s also challenge, because organizations need to revisit their development practices, and in some cases, rip apart and refactor existing hard-coded modifications. At SAPPHIRE this week, we heard about the account of one large SAP customer with over 50,000 hard-coded modifications to its classic applications make the full migration to BTP in just a year (yes, SAP does have an extensive modification checker, but we digress). We expect that for most the process will be a longer haul.

Progress ain’t easy, but since we’re on the topic, we have one selfish request for SAP: Could you please use BTP to move Ariba into the 21st century?