Brightwork Advisory Note: A Change in SAP Development Strategy

Executive Summary

  • SAP is now making significant changes in product development strategy.
  • In this advisory note, we cover the reasons for this strategy shift and what it means for the future of SAP developers and customers.


SAP’s board has recently come to terms with two important realizations. First, customers are moving to cloud with or without SAP. Second, that the biggest force holding SAP back in the cloud race is SAP’s own development organization. Clearly, a decision was made to put SAP on the right track.

The Cloud Journey

SAP’s cloud journey started in 2011 with the acquisition of SuccessFactors. This cloud acquisition strategy continued for a decade. SAP acquired Ariba in 2012, Hybris in 2013, Fieldglass and Concur in 2014, Callidus in 2018, and Qualtrics in 2019. At the same time, SAP made a number of acquisitions in IoT, AI, big data, and RPA. Fedem, Altiscale, and Plat. One in 2016, and Contextor in 2018.

Over the past decade, every SAP cloud application was acquired NOT developed internally.

SAP favored cloud acquisitions over in-house development for a number of reasons. First, developing enterprise cloud apps takes years. An acquisition, on the other hand, delivers an instant new product, instant new revenue stream, and instant new customers.

In a press interview a few days following the Callidus acquisition, SAP’s CEO Bill McDermott said:

“It would have taken too long to build it”


“We did that to get another cloud revenue stream in the mix” [1]

The Cloud Acquisition Side-Effect

SAP’s cloud acquisition strategy had an unfortunate side-effect. It robbed SAP’s own product organization from the opportunity to evolve beyond the monolithic, ABAP, NetWeaver application server and embrace modern cloud methodologies, architectures, and tooling.

With SAP’s cloud apps being exclusively acquired not developed internally, the development organization was effectively kept in the dark ages for too long. Developers had no compelling reason to upgrade their skill sets and remained focused on doing things the old way.

Moreover, The acquired cloud properties continued to operate as independent entities with their own siloed development organizations and none of the “cloud DNA” was infused into SAP’s own development organization.

The Pull of the Monolith

The monolithic development mindset at SAP made it practically impossible to build services. Cloud services (IaaS, PaaS and SaaS) are distributed, multi-tenant, loosely-coupled, API-driven, independently and horizontally scaled. Monoliths are massive, centralized, single-tenant, tightly-integrated, vertically-scaled systems. SAP HANA and Leonardo are examples of how this monolithic development mindset handicapped SAP’s cloud transition.

HANA  was born as a specialized OLAP appliance. Later, the product included an OLTP database, an application development platform, and an application server supporting the world’s most sophisticated ERP application suite.

Can you imagine the complexity of making the smallest development decisions for a product with this many design goals? More importantly, this monolithic approach is completely incompatible with how cloud services are consumed. How do you charge a customer who wants to use Search and Streaming services only? How do you scale the mobile service only?

SAP Leonardo also started life as an IOT platform then grew to include analytics, machine learning, big data, data intelligence, and blockchain! The same monolithic development mindset that wants to build large, complex, tightly-coupled, single-tenant systems instead of smaller, specialized, lightweight, API-driven distributed services.

By comparison, consider how AWS AI products are designed and offered. Specialized, single-purpose, fully managed services each covering a specific AI use case.

Mission Impossible

As an ABAP developer, how do you make the transition to the cloud? Here’s a slide from SAP TechEd 2018. SAP expects ABAP developers to learn: UX, SAP HANA, State of the art development, and Cloud. A piece of cake, especially when all cloud apps were acquired!

The New SAP Cloud, IoT, and ML Strategy: Less Proprietary, More Technology-Agnostic

  1. The board recently approved key personnel changes at the top echelon of the development organization including the CTO, product development leadership, and teams.
  2. The NEW SCP IaaS and PaaS strategy will be significantly less SAP proprietary and more technology agnostic. SCP/Neo and Leonardo IoT will move to Azure by the end of the year. [2]
  3. SCP/CF will expand its PaaS offering with more investments placed on open source.
  4. SAP HANA will expand into smaller, more specialized product groups. Expect a fully-managed AWS RDS for HANA by mid-2020 similar to AWS RDS for PostgreSQL, Oracle, and SQL Server. The service will support automated provisioning, scaling, backup, and recovery.
  5. Going forward, product development will be increasingly collaborative with technology partners (AWS, Azure, and GCP). The goal is to integrate SAP products into third-party platforms as discrete, specialized, and metered services allowing administration and consumption via native admin consoles, standard API calls, and a broader portfolio of IaaS/PaaS services.


The success of Microsoft, AWS, and Google as technology companies was driven by their focus on developers. Their go-to-market has been B2D2B. Once developers adopt a new product, they do the internal selling on behalf of vendors. It’s a bottom-up, social proof strategy.

SAP’s traditional approach has been top-down targeting senior executives and budget owners. This approach has limited success in technology-driven categories like IaaS and PaaS where the value is more evident to developers, architects, and product owners.

Outside of SaaS, which is purely acquired, SAP’s internal developer culture needed an immediate and radical transformation. The first pragmatic phase of this transformation is now underway.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP Custom Code Content


AWS and Google Cloud Book

How to Leverage AWS and Google Cloud for SAP and Oracle Environments

Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.