Behind SAP’s Business Technology Platform (BTP)

Josh Greenbaum, a renowned SAP industry analyst with Enterprise application consulting, takes a deeper look into SAP’s Business Technology Platform (BTP), its impact on customers and hyperscalers, and its role in SAP’s vision for innovation in the enterprise 

When technology gets complex, software vendors tend to roll out acronyms. This is particularly true in the case of SAP’s Business Technology Platform, or BTP. Underneath this simple three-letter acronym is a lot of moving parts: There’s a ton of technology, tools, concepts, and services all crowded under this one overarching umbrella, and it’s sometimes hard to keep track of the different components that can be found inside SAP BTP. 

Why the moving target? The Business Technology Platform isn’t just something SAP sells to customers, though that’s clearly a primary purpose. SAP BTP also exists to help SAP compete with its erstwhile hyperscaler partners – Amazon AWS, Microsoft Azure, and Google Cloud Platform. So it’s sort of a given that as the hyperscalers’ SAP offerings evolve, and they do so constantly, SAP and its BTP offering will try to stay in step. It’s a strategy that also closely links BTP to SAP’s RISE initiative, which is intended to help bolster SAP’s efforts to move its customers to the cloud while reining in – or at least trying to rein in – the hyperscalers. 

What is SAP BTP?

But before I sketch out the geopolitical landscape of these competing cloud platforms, it’s important to first understand SAP BTP as a set of tools and services that are intended to play a role in customers’ business innovation and digital transformation strategies. The BTP bottom line is simple: if you can’t find what you need in the fit-to-standard, out-of-the-box functionality from SAP S/4HANA, SuccessFactors, Ariba, Fieldglass, CX, or any of the components of SAP’s Intelligent Enterprise suite, then your next step is to take a look at what SAP BTP has to offer. This is particularly true if your company plans on moving towards a pure cloud-based fit-to-standard environment while still counting on deriving a distinct competitive advantage from your enterprise software infrastructure. As this is pretty much a solid YES for any company still hoping to be in business in the next five years, SAP BTP, or its equivalent, is heading your way.

SAP BTP’s role as an innovation platform is pretty unassailable. Indeed, there seems to be little in the way of innovation that BTP can’t handle, even if your company needs to continue to operate in a hybrid cloud/on-premise environment for the foreseeable future: Custom application development and deployment? Check. Deep integration with non-SAP apps and data and support for heterogeneous end-to-end processes? On top of it. Build and run cloud extensions? Definitely. Get moving with AI and ML functionality? Sure. IoT and RPA? Got it. Next-generation database management and analytics? Covered. 

In each of these categories SAP has thrown some pretty solid technology into the BTP mix: Robotic process automation, IoT, AI, and machine language services, process mining and orchestration, application integration, and data management and governance. All that’s apparently missing is a kitchen sink or two, and I’m guessing if I looked hard enough I could find one of those too. (For SAP history buffs, the late great NetWeaver technology stack was unofficially nicknamed “the refrigerator,” a nod to the fact that the marketing image SAP created for NetWeaver resembled the shelves of an open refrigerator. So maybe looking for a kitchen sink inside SAP BTP isn’t that far-fetched a notion after all.) 

As if that weren’t already enough, SAP BTP also includes some of the stalwarts of SAP’s solution landscape that we all know and love: HANA, SAP Cloud, SAP Analytics, SAP Data Warehouse Cloud and BusinessWarehouse (BW), Adaptive Server, and Business Objects now fall under the BTP rubric. 

SAP's BTP’s competitive landscape

It’s these myriad, disparate moving parts that actually beg the question, what is really going on here? The answer, like many of SAP’s initiatives, reveals a lot about how SAP is using technology to both advance its customers’ migrations to the cloud as well as to position itself as favorably as possible in a market defined by the growing importance of the aforementioned cloud hyperscalers. 

The hyperscaler to BTP angle is a prime example of Silicon Valley’s infamous coopetition phenomenon. SAP is counting on these hyperscalers to be the staging ground for a significant number of SAP cloud instances, primarily the pure-SaaS public cloud variety as well as the managed service private clouds that dominate among the members of SAP’s installed base that have moved to S/4HANA Private Cloud. Without these hyperscaler partners, SAP would be unable to meet the growing demand for staging public and private cloud services with its own SAP Cloud. That would cause all heck to break loose with Wall Street and its expectations for SAP’s stock price. According to the diktats of the Street, SAP has to grow like a pure cloud company, even if that means partnering with companies that compete directly with SAP Cloud. Or else.

But that’s not the only competitive threat from the hyperscalers. All three have extensive developer environments, advanced AI, ML, and IoT tools and services, as well as their own databases, data warehouses, BI tools, and on and on. And, when it comes to AWS and, perhaps more importantly, Azure, there are huge swaths of the enterprise software developer community – inside IT departments, startups, and other software companies – that make extensive use of these platforms’ tools and services to build net-new applications that connect to SAP’s on-premise and cloud systems. 

SAP can see the writing on the wall in terms of what these tools and services mean: When I talk to people whose job it is to build new apps and extensions, they tend to immediately default to AWS and Azure as the staging ground for their new functionality. There’s also a contingent that head right for Salesforce.com’s extensive developer and platform tools as well. While developers living deep inside an SAP shop generally still work with SAP’s native developer tools and services, the rest of the developer community, whether they hail from internal IT or are part of the vendor and partner community, are definitely not defaulting to SAP’s offerings to the degree that SAP would like.  

Do extensions or custom business processes align with SAP BTP’s vision?

The impact on SAP’s aspirations for capturing the lion’s share of innovations, particularly at the leading edge of the cloud – customer, partner, and employee experiences –is potentially significant. If a developer builds a compelling app on AWS, Azure, or GCP, particularly one that extends functionality that is not part of the fit-to-standard models of S/4HANA or the other SAP cloud properties, that extension will run on that hyperscaler’s cloud, not the SAP Cloud. If it’s built using that hyperscalers’ IoT or AI/ML tools, chances are every enhancement moving forward will continue to do so. 

So while the workload of an individual extension may not be that great, to SAP that app is a Trojan Horse, threatening to lead the customer to more and more SAP workloads running on its competitors’ clouds. Start with one little extension, let the concept spread from one LOB to another, and the next thing you know those LOB decision-makers are defaulting to the hyperscalers’ toolset, and along the way the perception of SAP’s strategic value heads south. 

Remember, extensions are for the most part high-value apps that help differentiate a company in an individual market that SAP (and all SaaS vendors) is trying to shift to a fit-to-standard approach for most strategic business processes. But when it comes to strategic business processes, fit-to-standard also means “non-differentiating,” and therein lies the real problem. By definition, if you’re going to “disrupt” a market, you’re going to deviate from the standard best practices. So those extensions you build with an Azure, AWS, or GCP toolset, particularly the net new ones running in an S/4HANA or other SAP cloud environment, are considered the leading edge of innovation at the company that uses them. Enough thinking like that and pretty soon SAP starts looking like a commodity player, and suddenly the vendor finds itself cut out of a lucrative SAP Cloud deal in favor of a hyperscaler, which, coopetition be damned, is definitely something SAP would like to avoid at all cost. 

To BTP or not BTP? apps, platform, and tools

So here we are: SAP's BTP is being used as a staging ground for all the tools and services a company might be tempted to use from a hyperscaler as a way of preventing a hyperscaler from capturing the innovative edge extensions that could make SAP seem less strategic to its customers. BTP is definitely a good staging ground for these apps, and the other services, like integration and orchestration, that customers will need in order to build the end-to-end processes that will help it differentiate from their competitors. 

Final thoughts on SAP BTP

But it is a pretty fine line to walk between capturing as much as possible of a customer’s cloud migration business – apps, platform, and tools –without alienating the hyperscalers so much that it throttles SAP’s need to move a huge quantity of deals through its hyperscaler partners. RISE was one such attempt to both control hyperscalers, by effectively allowing the customer to contract with SAP for a hyperscaler’s services, while incenting as many customers as possible to get moving with their cloud migrations, the majority of which will end up running on a hyperscaler’s platform. BTP plays a similar role: here’s how to do the things you want and need to do while staying as much in the SAP camp as possible. It’s a good strategy insofar as it offers customers a choice, albeit one that can be confusing at times. But’s that’s what we have acronyms for, right? FWIW. 

Download Josh Greenbaum’s latest special report “Custom Business Processes and SAP’s RISE: Strategies for Migration and Co-Existence"