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 run-up to Y2K, enterprises looked to a middle-aged software provider (it predated SAS by four years) that was 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 several forty year-olds. But generational 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.

If you ask most SAP customers as to what that generational change is, it’s likely 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 may mention the piece that represents its true underbelly of change: SAP’s Business Technology Platform (BTP).

SAP talks BTP, but the message is still confused

Call it SAP’s best-kept secret. Ever since SAP introduced it when it rebranded from SAP Cloud Platform roughly a year ago, many have 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 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 and 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 10 times 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.

At SAP’s main Sapphire event this week, an explanation was finally given. 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 hands, with the ABAP language, later supplemented by Java. So typically, most ECC implementations are likely to have a lot of custom ABAP code inside them, especially in accounting modules. And therein lies the rub.

With all that intrinsic custom code, two words may have struck nerves with 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 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 software-as-a-service (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 APIs are kept 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 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.

BTP is all about SAP app modernization

As mentioned above, SAP’s positioning and messaging on BTP is muddled. For its customer base, SAP needs to clarify what BTP actually is. It’s more than just several APIs and services. At the end of the day, BTP is really about modernizing how classic and low-code developers work with SAP applications. 

Most SAP customers adopting BTP are likely to be headed for newer offerings like S/4HANA, Data Warehouse Cloud, or Analytics Cloud. 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 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 a challenge because organizations need to revisit their development practices and in some cases, rip apart and refactor existing hard-coded modifications. At the Sapphire event this week, the account of one large SAP customer was shared that has more than 50,000 hard-coded modifications to its classic applications to make the full migration to BTP in just a year — expect that for most, the process will be a longer haul.

Progress is not always easy, but since we’re on the topic, the data community has one selfish request for SAP: Could you please use BTP to move Ariba into the 21st century?