Cloud-based integration pricing, NetWeaver Cloud Portal SLA and other tidbits in the latest version of NetWeaver Cloud Supplemental Terms and Conditions

The latest version of the SAPNetWeaver Cloud Supplemental Terms and Conditions agreement contains some interesting changes including pricing details about OnDemand integration platforms and an additional description of the NetWeaver Cloud Portal.

Let’s take a closer look at some of these changes.

Integration with On Premise Platforms

One of the most important features of the SAP NetWeaver Cloud is its ability to facilitate hybrid (OnPremise / OnDemand) scenarios. Thus, a long section in the agreement regarding such interaction received my particular attention.

(a) Customer may connect Customer Applications to SAP on-premise enterprise systems and non-SAP enterprise systems using the connectivity service provided by the Platform. A connection is defined as the association of a Customer Application deployed on the Platform to any unique on premise enterprise business application or on premise data source. SAP Named Users must be purchased under an Order Form for each individual accessing a Customer Application and utilizing a connection to an SAP on-premise enterprise system unless such individual is licensed under an on-premise license for the type of access to the SAP on-premise enterprise system requested through the Customer Applications running on the Service.

First of all, let’s define exactly what functionality this section refers to.  “[T]he connectivity service provided by the Platform” in my opinion refers to the “NetWeaver Cloud Connectivity service”  and is one of the central features provided by the platform.   What can you do with this service?

• Consume REST Web services in your SAP NetWeaver Cloud applications
• Establish secure connections between your SAP NetWeaver Cloud account and your on-premise systems, using SAP Cloud Connector
• Configure HTTP destinations used by your on-demand applications [SOURCE]

The use case that is of the most interest to me is integration with OnPremise systems. What is important to remember is that you can access SAP OnPremise systems and OnPremise systems from other vendors.

What happens if you access non-SAP back-ends?

(b) For mixed environments (SAP on-premise enterprise systems and non-SAP on-premise enterprise systems), Customer must purchase connections to non-SAP backends (connections to SAP systems are not charged) under the Order Form.

It looks like you will be charged for each non-SAP connection. Since I don’t have access to the Order Form, I have no idea what the prices for such connections might be. However, customers considering such scenarios – I have no idea if the Cloud Connector could still be used – should be aware that additional costs are involved. This decision is unfortunate since it forces enterprise developers wanting to connect the platform to non-SAP systems to consider alternative platforms where such pricing isn’t present. I’ve always assumed that one goal was to attract such developers to the platform yet such financial disincentives are detrimental to such efforts and hamper the creation of a broader developer ecosystem.  

I assume that this also applies to custom-developed OnPremise applications as well.

This section also contains a strange paragraph on “mediated middleware solutions”.  Since I didn’t find a definition of “mediated middleware solutions”, my assumption is that the reference is to integration platforms (for example, NetWeaver PI OnPremise/OnDemand, Boomi, Informatica)

(c) For access to on-premise enterprise systems through mediated middleware solutions:

(a) If SAP mediated solution, Customer does not pay for connections irrespective of SAP or non-SAP on-premise enterprise systems connected to this mediated solution.

(b) If non-SAP mediated solution, Customer must purchase a connection under the Order Form only for the connection to each non-SAP mediated solution.

I’ve tried graphically to depict my interpretation of the impact of this paragraph.

Note: In my diagram, I’ve used Oracle Fusion applications as an example of an OnPremise system from another vendor.  Other applications from other vendors could have been used as well.

I have no idea how SAP is going control the connection characteristics. For complicated applications that pull data from multiple sources, I fear that this will be an administrative nightmare.

One motivation of this decision is to promote SAP mediated middleware solutions at the expense of competitors.

SAP has always emphasized that their hybrid environment is open to third party integration platforms. 

[SOURCE]

The current implementation for the replication for SAP’s Cloud Payroll uses Boomi which demonstrates that this integration is technically possible yet it appears that there will be a financial impact for such usage in the future.

Inclusion of SAP NetWeaver Cloud Portal

The latest version of the document now mentions the newly release NetWeaver Cloud Portal.

An optional component of the Service is the NetWeaver Cloud Portal (“Portal”) hosted on the Platform, which requires payment of a separate fee. Customer must license a Named User for each individual accessing the Portal. The term of the subscription to the Portal must equal the term of the subscription to the Platform.

This paragraph is rather intriguing for a variety of reasons:

1. There are a variety of SAP solutions which are based on the NetWeaver cloud – some of which have their own Terms and Conditions (for example, the Precision Retailing Solution. What makes the Cloud Portal different from these other solutions?  It is also described as a “component” rather than a solution  – perhaps because it is NetWeaver-branded.
2. The fact that the Portal necessitates “a license a Named User for each individual accessing the Portal” also restricts supported use cases to ones associated with business users.  I have no idea how this might work with portals that are more associated with consumers where the user fluctuation might be high – leading to higher license fees.

SLAs

The latest version of the agreement also describes the SLAs for the Platform and the CloudPortal

With respect to the Platform (includes compute, structured storage, unstructured storage, bandwidth, connectivity connector in the Cloud), SAP warrants at least ninety-nine point nine percent (99.9%) System Availability over any calendar month.

…..

With respect to the Portal (if Customer has purchased the Portal subscription), SAP warrants at least ninety-nine point two percent (99.2%) System Availability over any calendar month.

What is interesting is that there appears to be a base SLA without a distinction between the various NetWeaver Cloud editions (Lite, Professional, Premium, and Premium Plus). Thus, one option that SAP has yet exploit is to make customers pay for better SLAs.

The fact that the SLAs are disclosed at all is important inasmuch as some competitors such as salesforce.com offers no SLA, only committing to “commercially reasonable efforts”.

End-Users vs. Named users

The pricing models for the NetWeaver Cloud still aren’t publicly known but some pricing model based on the number of end-users is possible. Thus, I’m paying particular attention to how end-users are defined in this document

The older version of the agreement contained this description:

Only Named Users are permitted to access the administrative areas of the Platform. End Users are limited to screen-access of the Customer’s Applications via the Internet.

The new version has this description:

(e) End Users must be licensed as Named Users.

I’m troubled by this change, because I’m not sure how this work in consumer-focused use cases.

Conclusion

At this blog demonstrates, such legal agreements reveal important details about SAP’s Cloud strategy.  I’ll be paying particular attention to such agreements as the number of Cloud-based solutions multiply and the number of hybrid environments increase.