SAP has recently made a subtle but potentially significant change to its tagline, shifting from branding itself as the enterprise digital platform to the business technology platform. Irfan Kahn, the former Sybase CTO who recently made the jump to heading global sales and marketing, insisted that the change was more about terminology rather than path. But to us, it was more of a shift from vague promises of digital transformation to a more tangible emphasis on the nuts and bolts that will get you there.
And part of that message means rationalizing the platform portfolio in the cloud to make the benefits of transformation more doable and tangible.
The headlines, as reported by Andrew Brust and Larry Dignan from SAP TechEd’s Barcelona event last week, included the general availability of the SAP HANA Cloud and the SAP Data Warehouse Cloud sometime in Q4, with the DW cloud embedding capabilities from the SAP Analytics Cloud.
Beneath those headlines was a very significant development, of SAP re-architecting HANA for its new managed cloud database service to become what it terms “cloud-native.” By that, they are speaking of a separation of storage from compute and embrace of Kubernetes, the combination of which will enable elasticity and quick start, stop, and resizing of cloud services. And combined with phasing in of pay-as-you-go licensing, which will simplify pricing and offer more economical options for running HANA and its sister services in the cloud, the result could lower barriers to adoption.
In another post, we’ll devote a further airing on what’s meant by “cloud-native” data platform as the term is being applied so broadly these days that the definition is in the eye of the beholder. For now, we’ll refer to it as denoting a data platform that exploits the elasticity (use and pay only for the compute that you use) and horizontal scale of the cloud.
By that definition, SAP HANA is just the latest database to exploit a cloud-native architecture. For instance, other platforms such as Amazon Aurora, Microsoft Azure Cosmos DB, and Google Cloud Spanner also exploit the scale of the cloud. In some cases, they deliver new approaches to ACID transaction processing, while in others, they enable distributed database management. And the list goes on. Oracle Exadata in the cloud also exploits an abstracted storage/compute architecture to support elasticity.
And as Andrew wrote about Cloudera the other week, even Hadoop is finally doing a similar separation that marks a 180-degree turn from Hadoop’s original design premise of bringing compute to the data. There’s more deployment in the cloud, and the faster gigabit backplanes of the cloud have rendered Hadoop’s original design obsolete. Times have changed.
Back to our main train of thought, we think that as the data pillar of SAP’s next-generation enterprise application portfolio, including S/4HANA and C/4HANA, rearchitecting HANA for the cloud presents some unique possibilities. It could change the very architecture, and the way we run and pay for enterprise applications. And by the way, for the record, SAP’s not alone here. Oracle faces a similar possibility because its Fusion SaaS applications only run on Exadata.
Of course, there’s a good question as to why we should even entertain the notion. Isn’t cloud transformation going to be disruptive enough without looking at a major sea change in the set-up of your ERP or other back office systems? Hold that thought.
Until now, elasticity has been associated with Internet applications that see significant traffic spikes. By separating storage from compute, customers only pay for the compute that they use, and when traffic varies, they can adjust compute up or down, or even turn if off in dead periods. It avoids having to engage in the practice of procuring “just in case” capacity that was common with on-premise systems that lacked access to the virtual infinite scale and elastic capabilities of cloud computing.
By contrast, traditional enterprise applications were viewed as monoliths. That made sense when ERP systems were walled gardens, processing data from within the four walls of the enterprise, with processing volumes that were relatively predictable. And, if you simply lift and shift your enterprise application to run as Infrastructure-as-a-service (IaaS) in the cloud, nothing changes except how you pay for it.
But today, enterprises dealing with B2B and B2C alike are likely to have to embrace multi-channel transactions and interactions. And there’s no question about the impact of real-time business, driven largely by consumers on their mobile devices, that in turn is impacting B2B. Furthermore, given the sociopolitical climate of today, disruptions in supply chains are likely to become more commonplace as the tug of war between globalization and nationalization introduce unpredictable obstacles to global inventory flows and rational decision-making on where to source and manufacture.
In other words, dealing with the uncertainties of global supply chains is going to require enterprises to compete on a more agile basis, with their front and back office systems having to keep pace. As enterprises face generational change brought on, not just by the morphing competitive environment, but also by their vendors (SAP has publicly announced a sunset of development on the legacy ECC ERP system by 2025), the new systems that they adopt must support the new realities on the ground.
Given such upheaval, back office enterprise systems are likely to start taking on some of the volatility associated with pure digital business applications or processes. More to the point, given the vast functional spread of an ERP system, different modules or processes are going to have their own rhythms that are only going to become more diverse. End of period reporting, for instance, has always had a much different peaks and valleys of activity compared to planning, invoice processing, procurement, manufacturing operations, and supply chain movements. Those peaks and valleys are likely to get even more pronounced as enterprises further digitize their operations, such as wrapping real time IoT data into maintenance, repair, and operation (MRO) processes.
So arguably, shouldn’t enterprises have the option on Black Friday or Cyber Monday to ramp up more resource specifically for inventory processing and supply chain operation, and then do the same with forward planning after the peak holiday season passes?
It stands to reason that, if the underlying data platform is reengineered to support elasticity, why shouldn’t the application tier? It provides the opportunity for SAP (and others) to rethink their SaaS enterprise application portfolios to provide the ability to ramp up and down compute for specific business processes, or modules.
But adding elasticity at the application tier would require SaaS providers to take containerization from the package to the module level, which will introduce new complexity. SAP is currently taking some baby steps here. Today, customers can accelerate the deployment of a specific workload in the cloud such as group reporting or central procurement without having to implement a complete ERP-system.
Now, let’s throw in more complications. SAP plans to offer the core of its portfolio – S/4 and C/4 – on-premises, hybrid, and in the cloud, as managed or unmanaged service; that adds another challenge for keeping the application experience consistent across all environments. And for enterprises facing the prospect of generational change in their applications, adding yet another level of architectural change could add insult to injury. Then, let’s not forget this one. When we’ve talked about elasticity, customarily it has been about a single application, function, or program running, as opposed to something more complex like an enterprise application where there may be complex interdependencies between different modules, such as inventory planning, supply chain optimization, and manufacturing. Were SAP to make different pieces of S/4 elastic, it would be breaking new ground.
So, nope, there are no easy answers here.
Nonetheless, as noted above, enterprises will have to embrace agility and their core business systems should support that agility. SAP’s product roadmap will be driving customers to make some major path choices in the next few years. And while those customers may not make changes to low-value, static processes (keeping them on maintenance), they are likely to look to SAP (or other solution providers) for modernizing key pressure points in their operations.
As SAP is taking a step to make the cloud, from a cost standpoint, more accessible through pay-as-you-go pricing, it stands to reason that they should take that thinking to their core enterprise SaaS offerings. With SAP HANA Cloud, they are taking the first step to making that thinkable.