Main content

SAP Customer Experience CTO explains why YaaS was retired in favour of Cloud Platform Extension Factory

Derek du Preez Profile picture for user ddpreez October 10, 2018
Summary:
Moritz Zimmermann admits that SAP got it wrong initially, mistaking YaaS For a start-up development platform, when in fact, it’s enterprises that want to make use of microservices in the cloud.

Yaas
It was somewhat surprising that earlier this year SAP made the unexpected announcement that it would be retiring its cloud development YaaS, which had a strong focus on microservices. A surprise because not too long ago, the SAP executive team were pitching it against Salesforce’s Force.com platform and said it would be a strong pull for entrepreneurs and developers.

Dick Hirsch has done a deep dive into YaaS, explaining its innovative use of microservices, and his surprise at its unexpected demise back in May - so I won’t go into too much detail on that front.

However, when I sat down with Moritz Zimmermann, SAP’s Customer Experience CTO, at its Customer Experience Live event in Barcelona this week, I thought it a good opportunity to get an understanding of the company’s thinking behind the move and what it meant going forward.

Zimmermann explained that SAP misunderstood the technology use case for YaaS - enterprise, rather than start-up - and us such, required a new go-to-market approach that fitted with the SAP Cloud Platform. He said:

We were, and still are, one of the early proponents of a microservices architecture in the enterprise space. We have a significant proportion of our portfolio ready built on microservices over the last three years, maybe 20-30% of our applications. Part of C/4 HANA is natively built on that architecture already.

With YaaS there were two dimensions to look at. Architecture is one. That has really proven to be correct. And then we applied a go to market commercial thinking to it. And there we learned a lot. We took on that feedback.

What we did was that we had the hypothesis that this was so disruptive that large companies would not be interested in it for a long time, but rather it had to grow in a more start-up, more open way. We were proven wrong. Because technically speaking, if you have five people sitting in a room building a website, they don’t benefit that much from a microservices architecture. If you have 5,000 developers, hell yeah, your productivity will go through the roof if you can parallelise their work through a microservices architecture.

Zimmermann added that, at the same time, enterprises are at risk of being disrupted by smaller, challenger companies, and as such they are under pressure to be more agile and adopt services at speed. This is why YaaS needed a rethink and Zimmermann admits that SAP got it “wrong”. He said:

So we came back and said, ‘wait a minute, if this is an enterprise play, we need to tie this to our go to market, we need to tie this to our positioning, we need to tie this to SAP’s Cloud Platform.

Nobody would understand if we came back and said ‘here’s another innovation platform’, there’d be a lot of questions. So we retreated, took one step back, and took two steps forward. Also, at the same time, on the technology front, we built YaaS on Cloud Foundry, which back then was all the rage. Now, not so much anymore. There’s a new shiny object that’s appeared, Kubernetes. So we jumped on that and said we would build it on that.

The second thing was, we said this had to work with the SAP go to market, so it has to be usage based and so on, but also enterprise ready. It has to also work with Cloud Platform. So we went to our colleagues in Cloud Platform and said we need to change some things, we need to evolve this.

An extension of YaaS

As a result, the YaaS team began working with the SAP Cloud Platform team and built the Cloud Platform Extension Factory, which it describes as an ‘open extension framework’ that essentially integrates SAP and non-SAP apps to the cloud platform, using event-driven extensions.

Zimmermann said that SAP has ‘evolved its thinking’ and wants the Extension Factor to be an event-based, common extent Simon platform. One that creates a common extension environment across a heterogeneous stack. He explained:

It brings a number of innovations to Cloud Platform and C/4 HANA. One, this idea of a loosely coupled, event based integration. So all of these C/4 HANA applications and also S4 and others, they can simply connect into Extension Factory through events. Much more decoupled. That means you can also extend a main monolithic application, maybe even an on prem application, with microservices, in a gradual way.

So you can now do deployments every second, rather than every forty minutes, every hour, every year. You can get much more agility that way. We have now introduced serverless functions in there, so you can now listen to an event with a serverless function.

We now have a common environment, finally, with C/4 HANA to do extensions. Before that it was a bit like going to the zoo - some are tall, some are small, some have stripes, all different technology stacks. That’s not a good proposition from a TCO perspective.

A drive to become more open

We’ve already outlined this week SAP, Adobe and Microsoft’s Open Data Initiative, which aims to create a common data model between the companies, so that customers can more easily and more effectively use their data across siloed systems. Interestingly, Zimmermann is keen to push the argument that the Open Data Initiative, as well as the Platform Extension Factory, as an indication of SAP becoming more open. He said;

What’s also important is this idea that we are pushing heavily through, and we have a lot of support now, is this idea of openness. We acknowledge that SAP has a long history with inventing its own programming language, app, server, database, which isn’t exactly open.

But we fundamentally believe that the world has moved on from a big monolithic, unwieldy application that comes from one vendor only, that needs very dedicated support to run it - to a world where you have hundreds of microserves. You’re just going to mix and match, wire them together.

Openness is truly critical for that. So you can take a backend services from AWS, a service from Salesforce or Adobe, and just connect it in and extend it and build it. And then of course we open sourced the whole thing.

Loading
A grey colored placeholder image