From my point of view one of the most exciting and promising component of SAP bit and pieces, was SAP netweaver gateway. Born to make it easy to build OData services, was potentially introducing a new, revolutionary, and disruptive approach at developing SAP based enterprise solutions: open RESTful interface to any external non-SAP platform, client, or system. Making much easier to build your enterprise solution on an heterogeneous mixture of SAP/non-SAP software components.
Now, it’s not that I consider SAP NW Gateway such a revolutionary product, or a technical achievement (in fact I do not), what I found exciting was the potential shift from a walled garden to an open approach.
Was that a definitive change of course in SAP history?
SAP is still struggling to offer a reasonable Web platform.
That’s somehow astonishing, it’s now year 2015, internet have been around for a while. Internet users amounted to 50% of world population in year 2000, Amazon was born in 1996, Salesforce in 1999 (more on salesforce later) and had 1M paying subscribers in 2007, and (to make just one example) SAP has tried for years to sell its customers an e-commerce solution which was laughable (SAP ISA then SAP Web Channel) before to finally give up and apply some common sense buying Hybris.
Mobile have been even more tragic.
After years of struggling with a windows based mobile platform (SAP Mobile Solution) they realized how much the world had changed and bought Sybase to finally have something to offer (Sybase Unwired Platform, better known as SUP). Comparing SUP to the most familiar mobile app development framework was disheartening in terms of time to develop, but who cares, SAP customers have plenty of money and patient. The shopping spree continued with Syclo acquisition, which at the time was praised by many as a better alternative to SUP.
I am very supportive of the attempt to buy something which works, in both cases, Web and Mobile. But does it mean SAP understood the fundamental different nature of web applications when compared the old enterprise apps SAP have been selling for decades?
Browse SAP websites and try to figure out what its user interface looks like, you will have a hard time, no screenshot whatsoever, a lot of beautiful picture of smiling business people using laptops, smartphones and tablets, but not even a glimpse of what SAP applications UI looks like.
Trying to get an idea of what SAP UI/UX looks like maybe frustrating, but in a way is corroborating to see at least SAP is aware of the problem, in that context SAPUI5 is finally giving them something show off.
And we must admit they tried, launching attempt after attempt, to head in a different direction.
SAPUI5 is just the most recent one, will it be the last one? And is it really a sign of a change in SAP approach to UI?
SAP is working hard on trying to revamp its image, from the giant mammoth of enterprise software to a more agile and sexy player in the IT innovation field.
Looking at SAP history can be instructive. When Hasso Plattner and his peers left IBM to form SAP AG in 1972 they probably where the closest thing to Jobs and Wozniak in a garage that Germany in 1972 could produce.
Their client/server enterprise application, with real time database access, compared to the established mainframe enterprise software of the time (using punch cards to store data) was a bigger and more daring revolution than Apple iPhone.
History tell us Davids sooner or later become Goliaths, but can they turn back into Davids again?
Having witnessed few customers turning from SAP CRM to Salesforce, I can list few reasons why the latter is more appealing to today IT stakeholders, and why Salesforce, not SAP, disrupted the market Siebel systems created becoming the market leader.
The cloud vs on premise debate is misleading, enterprises are as much worried of clouds as happy to get rid of metal.
The truth is business needs in terms of CRM are diverse, are frequently changing, and UX expectations are much more uncompromising.
SAP CRM ability to address these needs have been disillusional for years.
There’s seems to be a curse in SAP which just make it impossible for the german software giant to conceive a software application which is svelte, quick to adapt to new needs, and sexy to use.
If we believe this is not the side effect of their tactic to protect their walled garden, then we cannot avoid to spot the light of SAPUI5 trying to change things. But, is it?
When I first got knowledge of SAPUI5 in 2012 it looked unbelievable.
I thought SAP had finally understood that even with its size (and enterprise market control), was impossible to fight web standards and was finally embracing them.
It allows developers to build SAP integrated dynamic application on top of HTML5 web standard.
They even introduced an open-source-licensed version of SAPUI5 and share it on github. As of today commits are very frequent but the same can not be told about wide spread adoption with only a little more of 150 forks and less than 500 stars, ridiculous when compared to frameworks as Bootstrap or AngularJS with tens of thousands of followers.
The problem is this library is another little baby mammoth growing. They choose to base it on jQuery and its functional DOM manipulation approach just when the Web was abandoning it. And just looking at the library is clear they spent a lot of time, of a lot of developers, in building it.
Some years ago they must have looked around wondering what is web development, and then chosen to re-do it SAP way, putting 500 developers in a building to write millions of line of code. Microsoft did the same mistake in the past few times before to realize that: if you can’t beat them, join them.
Without going too technical and just to make one example, web development today is going in another direction, two-way data binding introduced a paradigm shift in how DOM abstraction is done in modern frameworks, making code much more concise and simpler. jQuery “imperative” DOM abstraction have been replaced by a “declarative” approach. If you are a developer and you want to get scared you can look at how data binding is done in SAPUI5, or the nightmare two-way data binding is in SAPUI5.
Another good example of why it’s the approach being wrong is SAP mentioning templating as one of the strength of the library, a Business developing a web application in 2015 doesn’t want “templating”, doesn’t want to be able to change the color of buttons. It needs total control of the user interface.
No matter how good their “templating” is, because it is. They even developed a powerful theme designer which translate into LESS.
It’s evident they put a lot of care and love in building SAPUI5. And it would have been a great innovation, if released one decade ago.
From a business point of view SAPUI5 requires skills that are scarce on the market, hence more pricey, time to develop it’s slower than using the most popular modern frameworks (like Knockoutjs, Angularjs, React.js, and for the CSS part things like Bootstrap, Foundation, etc…) and I don’t see any guarantees this is the road to the future.
So if SAPUI5 development is as expensive as previous iteration of SAP UI, plus it’s as complex, and it’s not going into the direction where modern svelte web development is going, why should business adopt it?
One reasons why for sure some will, is SAP ability to push it. Credibility and trust can sell anything, and SAP as a lot of deserved credibility and trust from the market. But as someone said, “You can fool some of the people all of the time, and all of the people some of the time, but you can not fool all of the people all of the time.”
A second possibility, is SAP building a broad and deep set of apps based on SAPUI5 to justify its adoption. Which is in my opinion what is trying to do with SAP Fiori; not just showcasing what is possible, but offering apps to SAP customers, ready for production out of the box and ready to be personalized with SAPUI5 development.
Another bold move could be to just replace SAP ECC interface overnight with a SAPUI5 based interface, which may sound a titanic enterprise but in my opinion is not, then it could still make sense, you have the same development cost and time-to-go live of the old UI but at least you moved a step forward.
Maybe. It all depends on your definition of enterprise-ready. If Google, Twitter, and Facebook, developed AngularJS, Bootstrap and React.js respectively, to serve billions of pages a day, to make code reusable and to be able to adapt quickly to new needs… Well, I am inclined to believe these frameworks could suite the business need of SAP customers as well.
Are they natively integrated with SAP? No, but they are easy to integrate with anything, and closing the loop with this post opening paragraph, SAP Netweaver Gateway and odata open the doors to use whatever you want to develop your next UI/UX.
I can feel the frustration down there in Walldorf, and I feel sympathy for them.
I can feel the struggle to change skin they are going through, and I totally side with them. If they will ever succeed, the world will be a better place for their customers and for all of us working on SAP consulting.
Good luck SAP.