Last month, there was on the HANA Cloud Platform (HCP) Trial environment. The problem was a few days later. Communication with the developer community on such issues is usually performed via a mailing list and the SCN forums.
As I reflected on this situation, I started to consider a broader approach to such issues that would include other SAP Cloud solutions.
Introduction
There is an ever-increasing importance placed on the transformation of SAP to a cloud company and this evolution takes place in various forms. Usually, much of this focus is on the relevance of the solution’s features for end-users. Yet there are other important aspects - associated with mundane but critical aspects such as SLAs, uptime, etc. - which are important for success in the marketplace. Despite their importance, the ability to find such information is often unfortunately very difficult. As the dependence on such cloud-based applications increases, however, a certain level of transparency is mandatory.
This transparency is also often lacking regarding SAP’s cloud offerings. Try and find details about the various SLAs for such solutions and you will be hard-pressed to find anything. There are some general descriptions of maintenance windows in legal documents (for example, in the Supplemental agreement for SAP Cloud for Financials or SAP Cloud Appliance Library - Maintenance Schedule) but only rarely will you find any information about SLAs, etc.
I started researching how other cloud vendors meet this requirement and discovered that many use Trust Sites.
Background on Trust Sites
What is a Trust Site?
A Trust Site is a public-facing website on which you post your SLA (current and historical uptime performance, or whatever metrics your customers need to know to trust you), Security Policy, and Privacy Policy. This is a pretty simple concept, but if you think about it, you are actually taking it to another level by making this information public. [SOURCE]
Salesforce has a Trust Site and the motivations behind this site are enlightening:
I don’t really know, but what I heard is that Salesforce.com was spending way too much time negotiating their SLA (how to measure it, how to determine and how to apply the credits, yada yada). This was unnecessarily extending the sales process, so they did some deeper thinking about the issue.
They realized what customers really just want to be assured that:
- The vendor knows when a site has performance issues
- The vendor is working to resolve the issue
- They will be notified when the performance issue is resolved
All of this can be addressed through a Trust Site (instead of the SaaS or PaaS agreement) dedicated to explaining why customers should trust you with their important data. If that is the way your customers are looking at it, you better start thinking about it that way, too. [SOURCE]
Some Examples of Trust Sites
|
|
|
|
|
|
Despite the fact that many cloud offerings have a Trust Site, there are some notable exceptions – such as Workday or SuccessFactors.
Does SAP need a Truth Site?
A similar Truth Site for SAP wouldbe useful for these reasons:
- Such a page would demonstrate SAP’s operational prowess to potential customers. With a quick glance, it is possible to see if a solution has fundamental operational problems. SAP has already created a site focusing on its cloud data center – a Truth Site would complement such marketing efforts.
- If customers can immediately check the status of an offering, the number of support calls would be reduced. This change would also result support-related savings potential.
- Developers could immediately see if environments that they are using are having issues
- Partners who are using such solutions could more quickly deal with problems.
- The increasing complexity of hybrid environments means that finding the reason behind problems / faults is often more difficult; a Truth Site would make such trouble-shooting more efficient.
A Truth Site doesn’t solve all problems
In a comment on an older blog that I had written about a HANA Cloud downtime notice, harald.mueller pointed out the limitations of such sites.
I'm very much aware of the single pages of truth offered by other vendors. Knowing all the internals and details of our platform we are very much aware of the impact we have with our planned actions causing downtimes for each individual customer. We work on making his information and data very transparent and tailored to each individual customer. While one single - aggregated - page does create a certain outside perception it is not helpful for individual customer specific issues with the service.
You need a cloud support concept that scales and which also is able to provide customer-specific assistance.
A single Truth Site or separate sites for each cloud solution?
SAP’s cloud strategy promotes networks of applications that bridge the OnPremise and Cloud worlds. A Trust Site that includes multiple offerings would be useful to deal with such complexity. For example, a partner dealing with end-user complaints concerning Cloud-based HR-Extensions could quickly see if there were problems with SuccessFactors, the HANA Cloud Portal, HANA Cloud Integration, etc.
Yet, each solution also has its own unique Metrics (as seen in the Boomi Trust Site) that should be available.
In my opinion, one Trust Site with a global view on all solutions combined with detail tabs for each individual solution would be the ideal means to provide the broader ecosystem with useful information.
I just checked and trust.sap.com appears to be available – the perfect choice for SAP’s new Trust Site.
- SAP Managed Tags:
2 Comments
