Brightwork Advisory Note: A Change in SAP Development Strategy

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

SAP is now making significant changes in its 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.

Video Introduction: Brightwork Advisory Note: A Change in SAP Development Strategy

Text Introduction (Skip if You Watched the Video)

SAP’s board has recently come to terms with two important realizations. First, customers are moving to the cloud with or without SAP. Second, the biggest force holding SAP back in the cloud race is SAP’s own development organization. SAP’s many cloud acquisitions have left the company with a patchwork of competing organizations that have led to a diffuse strategy on the cloud. Every year that passes, SAP falls further back in the cloud. A decision was made by SAP to try to address this problematic organizational design. You will learn about this change and can determine for yourself if you think there is a reasonable likelihood for success.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

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 several IoT, AI, big data, and RPA. Fedem, Altiscale, and Plat. One in 2016, Recast.ai, 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.OOn the other hand, an acquisition 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”

and…

“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

The board recently approved key personnel changes at the top echelon of the development organization including the CTO, product development leadership, and teams.
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]
SCP/CF will expand its PaaS offering with more investments placed on open source.
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.
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.

Go to top

Conclusion

Microsoft, AWS, and Google’s success as their focus on developers drove technology companies. 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.