The importance of being boring in the SAP cloud as a success driver
- Summary:
- Call the SAP Cloud Platform boring? Not quite. In his latest SAP cloud investigation, Dick Hirsch explains why cloud at scale should be boring, with micropaths to monetization.
Such demos provide entertaining examples of innovative – and indeed important - scenarios. With an ever increasing number of SAP Leonardo and other SAP Cloud platform (SCP) services to pursue such endeavors, SCP developers are able to create exciting applications to exploit such functionality.
Yet, a recent James Governor (RedMonk) blog about Red Hat demonstrates the hard realities of enterprise software.
Enterprises trust Red Hat precisely because it makes open source boring. Exciting and cool, on the other hand, often means getting paged in the middle of the night. Enterprise people generally don’t like that kind of thing.
The day-to-day life of most conference attendees are probably largely filled with mundane matters. Part of this trend is based on a transition to DevOps in many organizations, which forces developers to take over additional responsibility besides coding. IT, however, is much more than just pure development – there are operations, support, testing, etc, without which an application won’t be successful. A developer could create the sexiest Blockchain app ever created but if it can’t be maintained by support staff or if it is unable to be monitored then it won’t have a very long life in most organizations.
This awareness is best described with one question: What happens to code after the first deployment?
Post deployment in the SAP cloud platform?
Unfortunately, I get the feeling that the official press releases and media attention regarding SCP often focus on the developer but ignore the broader IT landscape.
What about the support staff or the operations teams? It isn’t that SAP isn’t aware of such aspects of the development cycle - there were sessions at the TechEd (for example, S4H202: Lifecycle Management of Applications Built on SAP Cloud Platform, S4H102: Hybrid Lifecycle Management in SAP Cloud Platform), that demonstrated such cognizance. This experience is more than just theoretical – two sessions at the TechEd (CPL226: Deliver Smooth Operations on SAP Cloud Platform and CPL219: SAP Community: Real-World Microservice Architectures on SAP Cloud Platform) provided actual operational SCP experience from SAP IT and the SAP Community, respectively.
From the wide spectrum of the software lifecycle, however, the focus is placed primarily on the “develop and build” aspect - it is often depicted as being cooler (for example, the announcement regarding Mendix and its Rapid Application Development platform). Other aspects are usually paid less attention. During the keynote in Las Vegas, the demo regarding Google Cloud Platform showed a quick screen with microservices being monitored within that environment but it was used to demonstrate the microservices were running in that environment rather than discussing any operational aspects.
For example, there was an interesting announcement from Dynatrace during TechEd that describes how this tool can monitor Cloud Foundry applications in SCP – my assumption is that most people probably missed it in all the other noise at the event. Dynatrace had two sessions at TechEd (DX303: Dynatrace AI-Powered Applications Monitoring for SAP Cloud Platform and NET52834: AI-Powered, Full-Stack Monitoring of Your Workloads on SAP Cloud Platform)
There are a few interesting aspects of the video:
- It shows the detailed steps that a customer must perform to move from a purchase of a Cloud Foundry-based service in the SAP App Center to deployment within SCP. For those partners interested in providing such services on SCP, it shows the whole associated user journey which looks relatively straightforward.
- At the moment, most of the monitoring functionality in SCP revolves around SolutionManager (For example, SolMan can already monitor Hana Cloud Integration). The next planned E2E monitoring innovation for SolMan is End-to-End Trace Analysis for selected SAP Cloud Platform scenarios (Neo environment). Future direction is to provide similar functionality for Cloud Foundry (CF). For those customers without Solution Manager, Dynatrace is able to monitor such applications today. Also since Dynatrace can be used to monitor a variety of other cloud applications (yes, I know that SAP handles most of the lower-level (ie, IaaS) monitoring itself), IT staff from customers / partners don’t have to learn a new tool. SCP has its own Monitoring Service which provides the ability to “monitor the state and metric details of a Java application and its processes” but it looks like it is NEO-based rather than CF-based.
The mighty dollar - paths to cloud monetization?
As I searched for other non-development topics regarding SCP, I realized that one critical topic was missing: money.
SAP customers or partners do not provide software for the pure joy of creation but rather for baser motivations such as increasing profits or supporting other parts of the organization to achieve such goals. This also applies to SAP. As Dan Lahl, SAP product marketing vice president, stated in a recent interview with Enterprise Cloud News:
Our strategy is to go multi-cloud and add value on the PaaS layer [w]here we will make our money is where we have always made money, which is the business process layer.
Despite its importance, monetization of such efforts is one of those aspects of IT that is usually not sexy enough to make the keynote but without which such efforts would be impossible.
Note: Commercial applications as well as for applications created for internal customers have associated costs in their creation as well as associated with the daily use. These costs must be covered either via individual users, divisions or whole companies.
In the past, monolith applications were relatively easy to monetize based on a user- or processor-based license fee. The shift to SaaS applications, lead to the emergence of other more complicated monetization models usually based on a subscription model. This pattern, however, breaks down as architectures start moving towards API-based architectures with a dependence on microservices – perhaps based on different metrics originating from different companies running in different IaaS cloud providers:
Monetization of such architectures is non-trivial – yet, it is critical to assure that the digital transformation efforts on which services are often based are successful. A recent McKinsey report provides further details on API monetization:
Determining what and how to charge, for example, requires quantifying how much the underlying data or service is worth (often based on how proprietary it is and its role in generating value), the revenue streams the APIs open up, and how much developers and users might be willing to pay to access them. Those answers, combined with the company’s overarching strategy, will inform which monetization arrangements to pursue with different partners.
Despite the almost ubiquitous focus on microservices regarding SCP, there is almost no information regarding the monetization of such microservices. Of the 515 listed applications in the SCP-related App Center, most of those applications (even many of the newer SuccessFactors extensions) are still charging based on a monthly per user rate. Yes, I know that these applications are in the AppCenter which has its focus on applications rather on APIs – still, there are 25 hits when you select the “APIs & Micro-services” filter with similar pricing structures.
“The AppCenter is the wrong location for APIs – you need to look at the SAP API Business Hub” some might suggest. Yet, this site largely provides information on APIs for other SAP cloud products (Concur, etc) that are financed via other means (usually SaaS subscriptions) rather than charging for the APIs themselves.
Monetization in SCP’s API management service is also based on an API-usage metric (per request/access model) which is a crude measure and is a little heavy-handed. Microservices can provide more granular and domain-specific metrics based on the service provided. Such richer metrics have been present in SAP’s cloud applications for a while (here is a blog from 2012 with details) albeit at an applicational rather than an API level. As evidenced by the billing of the SCP-based Data Quality (DQM) microservices, SAP is already starting to move in this direction for the some of the microservices that it provides.
More accurate/flexible monetization schemes are critical for most SCP developers but might be especially relevant for those partners working on the platform. Those partners using the new Embedded PaaS financial model in which partners pay SAP 25% of the subscription revenues as remuneration for the SAP Cloud Platform services available.
With this offering, such partners can also go to market fully independently as self-sustained cloud service providers and service any customer - net-new to SAP, or SAP customers who have not yet signed up for SAP Cloud Platform. The pricing for this embedded PaaS-service provided by SAP on a revenue share-basis aligns perfectly with the revenue inflows of the partner. It is easy for the partner to plan for and supports perfectly a land-and-expand approach for scaling the business per customer and overall. [SAP Application Development Partner Center FAQ]
Although this description appears to be more focused on SCP-based applications, those partners creating specific microservices would probably also fall under its rubric. The ability to track usage and revenue creation at a much granular level will critical to be exploit the associated revenue-sharing model.
Based on this need to monetize such microservices, what is SAP doing to support the ecosystem in this area?
Abacus – Hybris Revenue Cloud
SAP and the SCP team have been working on monetization issues in this architecture (CF rather than Neo) via two components: CF Abacus and the Hybris Revenue Cloud.
CF Abacus is a Cloud Foundry Incubator Project on which various CF-active companies such as IBM, SAP and others have been working.
Abacus is usage metering and aggregation service for Cloud Foundry. It is implemented as a set of REST micro-services that collect usage data, apply metering formulas, and aggregate usage at several levels within a Cloud Foundry organization. [Google Doc].
This requirement is non-trivial.
Specifically, being able to provide a metering engine that can deal with millions of users, applications, and service instances. Second, being able to do it in soft-real time. This is important since, metering information is more useful the closer in time it is to when it is consumed. Finally, that information will grow significantly so there is a need to manage the growth of the data while still allowing queries over time. To make matters a bit more complicated, the information being metered needs to be flexible. [cloudfoundry.org]
This service is currently not generally available in SCP but development on it has been ongoing for the last two years.
CF Abacus by itself, however, is not enough to meet the monetization-related requirements of modern architectures since it doesn’t provide any billing or invoicing to customers.
Note: Regarding billing, we are discussing those entities using the CF environment rather than those individuals operating the underlying CF platform (CF Providers). For those entities, they can bill via usage events.
To meet this billing-related requirement, SAP has combined Abacus with the Hybris Revenue Cloud which is a billing engine and includes CPQ, Order Management and Subscription Billing capabilities. What is important in this combination is that the generic usage metrics supplied by Abacus are placed in a richer business process context in which the customer and broader business relationships are taken into account. The Hybris Revenue Cloud is also already being used for scenarios with S4 Hana Cloud and in combination with complementary CF-based microservices could be a very powerful architecture:
It looks like this architecture is already being used in SAP since the description of a related session at next week’s Cloud Foundry Summit contains the following sentence: The demo will use the knowledge and experience we have gathered at SAP in monetizing some of our cloud solutions using Cloud Foundry.
Note: SCP API Management service also has a billing aspect but it is isolated and doesn’t reflect the broader nuances of a mature billing environment.
Note: Other cloud-based billing engines exist (such Oracle Monetization Cloud) but I haven’t seen any other Abacus integrations beyond that with SAP’s billing engine. This week’s announcement that CF will also be supported on Oracle’s IaaS would mean that an Abacus integration with Oracle Monetization Cloud should probably be examined in greater detail regarding its viability.
My take
I’ve focused on monetization as it is associated with those providing microservices on SCP. A recent job description for developer for the new SAP Cloud Platform Commercialization Services demonstrates that monetization can be seen in a much broader perspective which includes how consumers deal with / purchase microservices and other digital assets.
Cloud computing brings its own new business standards, challenges and qualities. Self-service enabled processes (a.k.a “low touch” operations), low entry barriers and short time to production are only few of these. Similarly, the Digital Transformation process, which SAP customers are going through, requires simpler and more flexible buying and consumption models for our customers. SAP Cloud Platform must adhere to these new “ground rules” to gain a competitive edge in the Enterprise Cloud domain.
To address those challenges, we aim to create a single, common digital SAP customer experience for finding, trying, buying and consuming all Apps/API/service offerings/content/platform from (all) SAP & partners via high- and low-touch channels.
Thus, getting monetization right is critical for SAP and its customers. Let’s hope that SAP's long-running struggle to get a single store for its cloud-offers isn’t a precedent for creating a platform to purchase microservices.
In terms of a long-term strategy, SAP’s growing support of Kubernetes suggests that we may see a shift towards a different model in which developers have even greater independence and responsibility. A recent blog from Mike Vizard provides details.
In the meantime, developers appear to be finding Kubernetes to be the more accessible of the two platforms. PaaS environments are typically stood up by IT operations teams with lots of expertise. Kubernetes provides a lighter-weight form of abstraction that many developers can provision on their own. At the current pace of adoption, it might not be too long before the instances of Kubernetes cluster simply overwhelm traditional PaaS environments. In fact, for that reason Red Hat has already fused its PaaS with Kubernetes.
New technologies such as Kubernetes reveal that IT is constantly evolving. Yet, SAP must also look at its own history - it was successful over the years not only for its unique process experience but also based on the maturity of the platform itself. This stability was based on creation of a set of tools and processes/best practices that helped assure that staff members weren’t getting paged in the middle of the night.
At the recent keynote in Las Vegas, the upcoming beta of ABAP in the SCP received probably the most applause from the crowd. What is perhaps more critical for SCP, however, is that ABAP alone isn’t the only part of the Business Suite that should be brought into the new environment. It is also an understanding of the criticality of those Basis activities that assure that those mission-critical systems remain running.
The tools that they use to do their job in SCP will probably change (although CTS+ is also available in SCP) but the realization of the necessary activities to have a successful IT environment is vital. Best practices from SAP Community or from internal SAP IT on SCP that include not only technology but processes as well demonstrate how modern DevOps on SCP can be performed. Such assistance must be provided to those customers and partners as they transition towards SaaS or PaaS environments – away from OnPremise environments.
The innovation of the SAP Leonardo offerings on SCP must be complemented by boring functionalities (such as monetization, monitoring, etc) without which such innovative activities are running on a very unstable foundation.