Services as Products
In 2011 Gartner published a Paper, The Shift From Projects to Products Will Drive Major Application Organization Changes, that predicted “a major shift in how enterprises … approach … application portfolio management and application strategy … [to become] product-centric”. Under this new approach, “Instead of planning projects to make changes to their applications, … Product road maps [will] chart the course of new capabilities to be added and their priority”. Now, some ten years later, what we still see at SAP is an annual, ‘project-centric’ release cycle for its core product, S/4HANA (e.g. 1709, 1809, 1909, etc).
Given exploding demand for all-things-Cloud at SAP today, this project-centric release cycle will likewise become less visible than is currently the case with On-Premise versions of S/4HANA. At SAP, “Total revenue in 2020 was €27.34 billion, including €8 billion from its cloud business”. Cloud revenue “is expected to reach more than €22 billion by 2025”, meaning that more than half of SAP revenues will be Cloud-hosted within four years. Given this, we certainly shouldn’t anticipate any change to the current ‘Project-centric’ approach to the delivery of SAP’s “core product”. Or should I say core ‘Project’?
Whilst many obviously do refer to S/4HANA, Ariba, Concur, etc. as ‘Products’, there is little doubt – in the context of product-centric “application portfolio management” – that they should more accurately be seen as ‘Projects’: monolithic applications. Although both terms will no doubt continue to be used, what Gartner actually predicted in 2011 was that, “Instead of planning projects to make changes to their applications”, product road maps will become the new ‘application strategy’ planning tool: “a lot like a [Agile] back log of stories but at a higher level and providing a future vision of where the product is going”. But, more importantly, Gartner declared that each Product Road Map’s “resulting digital service is a product that you sell to a customer and requires disciplined product management”.
Many will no doubt continue to argue that S/4HANA, for example, is a bona fide “digital service … a product that you sell to a customer”, but can anyone imagine what the corresponding S/4HANA ‘Product Road Map’ might actually look like? SAP’s ERP was already divided into (more-manageable) ‘Modules’ as far back as the 1970’s, and still is today: any notion of S/4HANA as a unitary ‘Product’ is unthinkable (as well as such a notion being inconsistent with SAP’s licensing model). What’s more, a key phase of the discussed transition to product-centric delivery, is the regrouping of teams by ‘Product’ – each team having autonomy to manage their own Product Road Map. Is it even possible to imagine a singular, functioning ‘S/4HANA Product Team’, with a single Road Map? Absolutely not: S/4HANA is therefore not a ‘Product’.
As you probably noticed, whilst upgrades to monolithic applications are typically project-based, the outcome of any Product Road Map should be a “digital service”; not a monolithic application (for which reason “the new application architectures needed to build a digital service blur the lines of what an application is”). This obviously leaves open the question of precisely what type of ‘Service’ can be sold to a customer? Despite what the remaining hordes of microservices advocates will tell you, a microservice can never be sold to anyone. A microservice, as the name implies, is not even a ‘Service’; it is no more than a constituent part of a functioning Service. Without the other microservices upon which it depends, it is worthless.
At this point, most people are likely to argue that API-based, SOA-type services should instead be revered as the ideal ‘Product’. Whilst this is obviously possible for standalone, SOAP-based services (where the service-vendor is typically also the host of the necessary data), such a delivery model for S/4HANA alone, is entirely unthinkable. SOA services are ‘API-rigid’; they work only if the caller uses the currently-supported API-version. If a client makes a service call using any other API (SOAP) version, the call will typically fail. Now multiply this by the number of individual ‘Modules’ that constitute SAP’s ERP; and I am yet to meet a single consultant that can even name all of the Modules. The reality is that not even the ERP’s ‘Modules’ can be delivered independently of one another; they must be in complete version-alignment across the entire ERP for communication between them to be successful – should the SOA paradigm be used. Now consider the fact that each ERP Module contains hundreds of individual ‘services’ – that would each need their own API-versioning – and it becomes clear why SAP is currently trapped in project-centric delivery; and this before we even consider the effort required to integrate the ERP with SAP’s other application offerings.
Now for the good news: this still leaves us with ‘Macroservices’ – something I proposed in an earlier Blog, From SOA to Macroservices (https://blogs.sap.com/2020/06/01/from-soa-to-macroservices/). Macroservices – unlike SOAP-based services – are ‘API-flexible’ (as I explain in the same Blog). They are triggered by JSON-based event payloads and therefore, unlike SOA, they are also fully decoupled; fully asynchronous. For an explanation of how such Macroservices are triggered, see the EDA ‘Requested’ Event-Pattern (https://camhunt.medium.com/requested-event-pattern-cf354deff906)
Should SAP wish to transition to a modern, Customer eXperience focused, Product-centric organization, the choice is simple; there is only one choice. Should SAP ever make the transition to more Agile delivery, unlike the situation today – where I have likewise never met a single (non-German-speaking) consultant capable of telling me what S.A.P. actually stands for – SAP might instead come to stand for a revolution in application portfolio management: Services as Products.