What SAPUI5 and Fiori tells us about the future of UI development skills

[former_member182638]

At the recent SAPPHIRE event in Orlando, SAP unveiled a collection of impressive looking web apps named 'Fiori', built on SAP's new HTML5 framework (affectionally referred to as SAPUI5).  SAPUI5 (which is based on HTML/CSS/Javascript and built on libraries such as jQuery) has been in the making for over a year now.  But the release last week by SAP of Fiori apps has demonstrated that SAP is dead serious about SAPUI5 as a UI development toolkit going forward.

dj.adams foresaw the shift to SAPUI5 over a year ago in this post.  Then, bjoern.goerke mentioned it quite plainly in this recent blog post, when he says

SAPUI5, our HTML5 controls library, that SAP is using as the standard User Interface Control library in all their future applications that need a “consumer grade” User Experience

In fact, in SAP's own User Interface Technologies Roadmap 2013, SAPUI5 is considered a viable UI technology in any scenarios irrespective of levels of usage or reach (although clearly Fiori apps currently target the higher usage or reach scenarios).  If we assume then that once customers get a taste of Fiori apps, they will crave more over time, and expectations of "consumer grade" user experience will become more pervasive, what does that mean for the expectations of developer skills?

SAP gives us a hint with a table in the Appendix of the User Interfaces Roadmap 2013, where a comparison of Classic Dynpro, Web Dynpro ABAP, and SAPUI5 technologies is made.  Here is what we see ...

UI Technology	Skills Required (per SAP UI Roadmap)
Dynpro	ABAP & Dynpro
Web Dynpro ABAP	ABAP OO, Web Dynpro ABAP, Floorplan Manager
SAPUI5	Javascript, HTML5, CSS3, Gateway, OData

If you look closely, this is a big shift in skill expectations for SAP developers, not unlike a decade ago when SAP sought to shift the user interface layer onto the Java stack.  With SAPUI5, web developers are expected to craft the client-side web application with HTML5/CSS/Javascript, whilst ABAP developers focus on the business logic in the ABAP system, exposed as APIs using NetWeaver Gateway and consumed by the web application.  To illustrate further, SAP's guide to extending or enhancing Fiori apps which are based on SAPUI5 provides the following table ...

With this shift to SAPUI5 over time, I foresee some challenges in the SAP ecosystem ...

Can SAP rely on the ABAP development community to upskill to SAPUI5?

My opinion here, is that not enough numbers will make the shift.  That's based on my observations in the field.  Many developers are still not comfortable with the shift to Web Dynpro ABAP .... indeed, this was evidenced at a TechEd I attended 18 months ago when the first booked-out hands-on session was 'Introduction to Web Dynpro ABAP'.  So if many ABAP developers have struggled to make the leap to Web Dynpro ABAP (and associated concepts such as FPM and ABAP OO), I'm not hopeful that a large proportion will be able to upskill with Javascript, HTML5 etc.  That said, ABAP developers will still be needed to craft the underlying business logic under Gateway services.  This does raise the spectre of multi-developer scenarios to achieve anything with SAPUI5 - A front-end developer for the web app, and a back-end developer for the business logic.  This is something which customers needed to contend with in the Web Dynpro Java days when business logic was still embodied in ABAP, so you needed a Web Dynpro Java developer to craft the front-end user interface, and an ABAP developer to refine the business logic in ABAP function modules.  It will be interesting to see if customers are willing to embrace that multi-developer scenario again.  That said, this split between front-end developers and back-end developers is not unusual in some worlds.  And of course, those few who have the skills for both tiers will be highly in demand.

Can SAP engage a new community of web developers to embrace SAPUI5, outside the traditional SAP ecosystem?

I would certainly like to see this, although I think much more could be done.  I am fearful that SAP in it's desire to craft a proprietary HTML5 framework in SAPUI5 may choke opportunities for it to see mass adoption.  I look back to Web Dynpro Java, another proprietary framework, and how I think that most pure Java developers that you meet on the street have not heard of it - that's not mass adoption.  Licensing of SAPUI5 usage is also problematic.  My understanding (currently) is that whilst SAPUI5 is free to trial, productive use requires a SAP development license (eg. NetWeaver development license or SAP HANA Cloud).  That's enough to turn most non-SAP web developers away - these web developers tend to use free open source or low cost frameworks.  Also the licensing implies usage is pretty much restricted to SAP platform scenarios (somewhat like Web Dynpro Java).  Most web developers walking into a SAP usage scenario will instead prefer to use more commonly known libraries or frameworks - ones that they have hands-on experience and expertise with, and are freely available and/or open sourced, such as Twitter Bootstrap. Personally I think SAP could do more to make SAPUI5 more visible, perhaps making it open-source, and also increasing promotion of it outside the traditional SAP TechEd conferences - I've attended some developer and web developer conferences in Australia recently and lamented that there was no presence or sponsorship by SAP at those events.  Right now, there is a fierce battle underway in the web ecosystem around what web frameworks or libraries web developers choose to adopt (eg. all the various Javascript MV* frameworks) - in my mind those with sufficient adoption will be more likely to succeed or have greater longevity.  And for many web developers, SAPUI5 isn't on their radar.

SAP's software engineering teams have crafted a nice framework for SAP's user interface future.  But I'm wondering if we are heading for a skills sinkhole around SAPUI5, where inadequate numbers of traditional SAP developers move into this space, and non-SAP developers remain unengaged due to lack of visibility and licensing concerns.  I'm hoping I'm wrong.

[joao_sousa2]

Expression binding is awesome.

[kyo_choi2]

It depends on SAP's direction.  If SAP starts to release SAP UI5 apps for ECC then there's no way around it.  For example, SAP CRM decided to use WEBUI and if you don't have knowledge or experience then you have no job in UI for CRM.  It's better to get in early then late.  You need to be proactive in training in IT.  SAP provides so much free application tools and access why not jump on it?   

[phil_soady]

So A few Years Later, what is the common consensus.

SAPUI5 versus WEB IDE versus Non SAP Java.

What about Mobile offline.

Use the SAP Gateway or Just Rest Services.

Odata or Just Json.

Launch pad or Not.

Anybody got their crystal ball shined or an opinion ?

Surely after a few years we know more about what SAP is doing and what bits we should avoid.

[markteichmann]

Currently I am implementing UI5 apps build with WebIDE using the Launchpad as entry point. This works pretty well. In the backend we use custom Gateway services. This is a setup for current needs.

In the future Gateway services will be replaced by annotated CDS views on HANA DB.

If you will use many custom apps then you should have a look at Neptune software as this is the fastest way to implement Fiori apps.

So at the moment I would use the sugegsted stuff and avoid non-standard solutions like Non SAP Java, non Gateway REST services etc.

Regarding Mobile offline: This is done easiest with Neptune, but you can also use WebIDE and SAP HCP mobile services.

[GrahamRobbo]

Hey Phil,

you should have been at this week's SAP Architect & Developer Summit in Sydney. Much discussion around this. Look for conversations on twitter over the past few days. :wink:

Cheers

Graham Robbo

[phil_soady]

Ok Will do Robbo. Thanks for the tip.

BTW  im in Heidelberg these days

[phil_soady]

thanks for the tip Mark

[frank_stdle]

Hi Mark,

I've been using the SAP REST classes for building an API for a lightweight web application. My application is just an Angular app that runs of a node web server, but it pulls all it's data from SAP via the REST API. I have to say I like the simplicity and versatility of the SAP REST API framework and I would be tempted to use this also for more complex applications (instead of Gateway). Could you elaborate on why you would avoid non-Gateway REST services?

[markteichmann]

Hi Frank,

I am sure that custom REST services built on the REST API are more lightweight than the Gateway services. And if you build many similar applications this could be a good choice, too.

But I think you are in danger of reinventing the wheel when developing without using the SAP standard tools. Also the support for these solutions may be more difficult for other developers that may know Gateway but are not used to your homegrown solution. But this strongly depends on your use case and your role in your job.

Maybe as a conclusion we can state that in a standard SAP infrastructure it is easiest to use standard heavyweight SAP tooling. But if you are looking for a lean, cost efficient solution and also have skills outside of SAP technology like Angular or similar than it could be a better choice to go this route.

There are strong dependencies between your infrastructure (skills of developers and support staff, technical infrastructure in place) and the best technology to use. As part of a larger consulting company for me it is better to stay near the standards because my colleagues also have to understand and support what I am building.

[frank_stdle]

Thanks Mark, that makes sense. For now I am only creating some tools for developers, and I am allowing myself some room for experimentation with more "fun" technologies. I recognize the need for sticking to standards when working with bigger projects and when working in a larger environment consisting of SAP professionals.

Having said that, this quickly leads back to the discussion on who should be developing modern SAP applications these days. Should the old school ABAPers learn new technologies, or should they just stick to serve up data to modern web developers? A web developer would probably feel more at home with a custom REST API than a Gateway OData API. More broadly, if I were to build a new web application for SAP, I would question the following:

1. Should the app run on the SAP server or a dedicated web server (.Net, Node, others)?
2. Should I use UI5 or an other more widely used modern web framework (Angular, React, Ember, a 100 others)?
3. Should I use Gateway or build my own REST API?

I guess this is what Phil is asking above, and I'm sure wondering the same :smile:

[joao_sousa2]

OData is REST, so if you go the lightweight route and keep adding functionality to your REST API you will eventually end up "recreating" OData. Well, not quite, since your "ZOData" won't be compatible with other people's "ZOData".

When I develop using SAPUI5 I like using OData, since a lot of the work has already been done. When I'm using Angular, for simple applications OData ends up being a pain. Using Data.js is not the same as using the SAPUI5 OData Model.

If you're going to use SAPUI5 I don't think there is a reason to avoid OData. Otherwise, it depends on the complexity of your data service and if you expect it do be used by a wide range of people (who don't want to learn another API).

A web developer would probably feel more at home with a custom REST API than a Gateway OData API.

OData isn't specific to SAP, a modern web developer should know OData (or at least what it is) even if they have never worked with SAP.

[yoppie_ariesthio]

Objective Javascript is the hardest part to learn ui5. They used MVC just to create view.

[#14]

One would have to object to the comment "OData is REST" - as OData, 1) isn't RESTful, with things like batching of request, and 2) OData is far more complex. Best description I've heard is that it is ODBC for the Web.

I would suggest that building a fully functional OData service/API is far more complex than you might think. Enabling filtering, paging, expanded sorts etc is very complex. Consuming it is easy (even if a little heavy on the bandwidth), but producing OData is a huge pain. If you are building an OData service to support a specific application, it will be much faster to build a simple REST API. If you are building a generic API - OData is a very good option, just expect it to take a long time to build!

As to web developers understanding OData - it should be noted that especially with the prevalence of SAP specific annotations and the breaking of the OData v2 standard by including non-standard annotation areas in the metadata - when working with SAP APIs we are often not dealing with OData but SAP-OData... don't expect your generic web developers to understand it.

Besides - if you're looking for awesome consumer web experiences, perhaps REST isn't the way to go anymore - should you instead be looking at WebSockets to provide your data? :wink:

[joao_sousa2]

I would suggest that building a fully functional OData service/API is far more complex than you might think.

I believe the point I made was that it was in fact dificult to "standardize" all the OData functionality from scratch. I didn't comment on what it took to make a Gateway service that provides every functionality, but that's what the configuration is for, to tell what is available and what isn't. Most times you don't need a "fully functional" OData service, I never needed one.

Besides - if you're looking for awesome consumer web experiences, perhaps REST isn't the way to go anymore - should you instead be looking at WebSockets to provide your data? :wink:

I've played around with ABAP Push Channels and made a PoC together with Node.js and Angular, but for most use cases it's hardly a bonus. Same thing for Angular+Meteor.

And I find that it confuses users to have data change in real time unless you are dealing with natural real-time scenario like chat or dashboards.

[michael-john_turner]

The ONLY web front end I invested my time in has been WDA.  The really simple reality is, no ABAPer who has used SE80 with integrated version / release control will ever switch to antiquated check-out / check-in code management.

If you've ever used any other version control tool seriously you'd realise just how poor version/release control in SE80 is. Change tracking is good and rigorously enforced but you can't do anything that is taken for granted elsewhere, like feature and bug fix branches, patch sets, etc.

That's one of the great benefits to me of UI5 - I can use my own toolset rather than being restricted to using what SAP thinks is best. Yes, there should be project standards for version control (a war that Git has long since won, for now at least), issue tracking, deployment, etc but I should be free to use my own editor, editor plugins, etc - none of those are easily possible in the ABAP world. This is a Good Thing, but I think it's taking old school ABAP developers some time to adjust...

[kyo_choi2]

I believe it will replace the ABAP Webdynpro, BSP, WebUI and ABAP Dialog programs all together.  Fiori and UI5 Apps are so power now it even does ALV, Select-Option functions along with once written runs everywhere.  UI technology changes so fast and why not for the SAP?  I wouldn't be surprised if next version of ECC or CRM front end is all Fiori apps.  ABAPers will be limited to working on OData, BAPI backend, CDS Views for HANA....

once written runs everywhere......

[Sijin_Chandran]

Nice question to be answered,

What SAPUI5 and Fiori tells us about the future of UI development skills

Coz right now I am just a new entrant ( having only Core ABAP experience of 5 years ) in the UI5 framework, and am this much curious that's my curiosity  always lands me to blogs like this :smile: , which I like reading.

My answer to this question,

If you check the SAP's main webpage,

http://go.sap.com/india/developer.html

Under the Developer you can see the following screen,

This itself answers , they have taken UI ( or SAP UX ) as a separate entity of what they offer or rather say what they want to offer to their customers.

SAP UI5 ( Fiori ) will be the one UI Development Framework for all kinda SAP Business Suites what I feel.

And ABAP being only required for coding inside Odata Gateways service's DPC and MPC classes, i.e. for implementing Business logic.

Thanks,

Sijin

[Former Member]

That's so true. I understand the problem with the outdated libraries. They need to produce bullet-proof software and the speed of this development is high. Big companies moves slowly. Angular 2, Golang and the rest of the brilliant JS libraries are here to stay and SAP has zero chances to compete with Open Source. Zero.

I like SAPUI5, I like SAP HANA a lot, but I am realistic about this approach. I rather concentrate my efforts to become a Full Stack Web Developer rather than engage again in the same super human effort that I had to do to learn Webdynpro ABAP.

[former_member209088]

So, this old ABAPer developed a UI5 app with WebIDE, Master/Detail Template, and custom ODATA.

I gotta say, ODATA is one hot mess of a solution (very database centric, when we know SAP uses APIs (BAPIs, FMs, etc).  Not to mention use $Batch (no deep update).

I will be looking at NEPTUNE, which seems to have done things the way I would have done it.   Leave the coding in ABAP, but use the OpenUI5 libs.

P.S.  I have yet to meet a "Full-Stack" UI5/ABAP resource -- and I have had 3 SAP consulting resources on-site so far.

[ChrisSolomon]

NEPTUNE makes good stuff! ....and they offer options too (ie. with or without Gateway and such).

By "full stack", you mean "end to end"...UI5-Gateway Service(s)-ABAP/FMs? There should be several...though VERY busy. haha

[former_member209088]

By Full Stack, I definitely mean End-to-End, and not someone who is partially competent in Front/Back end SAP.  I mean EXPERT (including Techno/Functional knowledge) at both.  If they exist, they are a very rare bird.

I know everything there is to know within SAP Technical.  I know enough to get by with HTML/JS/CSS, but by no means an expert...quite a novice actually.

I could learn the UI5 framework .... not horribly different than WDA once you get used to it, but the shortcomings of ODATA blow me away.  The concept is very database table centric, or even view centric if you consider entity/entitysets and the way templates work.

Not ready for prime time IMO.

S4 developers must be pulling their hair out, and they haven't even gone through an upgrade yet.... maybe that explains V1, V2, V3 of apps.

[former_member209088]

Would hate to be the guy upgrading FIORI apps, or even applying OSS notes.  Note to those redefining views...you are fouling up any upgrade opportunity.  Better hope you are using Hooks exclusively.  Just saying.

And if you don't know what SPDD, SPAU, and SPAU_ENH are, you should not be modifying anything.

[ChrisSolomon]

You will find a "few" that are technical end-to-end....but throwing in "functional" in there is a stretch in most cases as that is fairly domain specific business knowledge. I have been doing "this" since 1996 or so and consider myself "functional" in areas just enough to be dangerous. haha

OData is "interesting" for sure...but by no means "SAP specific"....as it is born from Microsoft land. You have the "other" big one that is Jersey (an implementation/framework of JAX-RS) out of the Java/Oracle world. So this is nothing new in the web dev world....ie. waiting for something to standardize and shake out while in the meantime, competing models are at war. haha

S4 and HANA developers? Yeh....not even sure how those guys keep up right now. I keep an eye on it...but each time I go through some tutorials, a new version comes out that makes the old completely useless. haha

[Former Member]

The changes taking place right now are so extensive that I expect only a small portion of current developers (ABAPers) to make the transition needed to stay in the business.  What we have so far is only the start that is not even that simple.  Fiori as it has been is forms, tables, some graphics but when looking at the roadmap you see natural language processing, notifications, odatav4, AI, IOT etc etc.  This will take years of course but in some 5-10 years I expect that the most sought after SAP developers are probably not even working with SAP at the moment.  Only few consultancies and consultants are making the investment to learn what is the foundation for SAP UI/UX going forward.  Key areas to learn now are Javascript, browsers/DOM, Design thinking, web security and the UI5 framework. 

This is from a recent Job description from SAP that gives a look at what is coming:

"This next-generation SAP Fiori UX design will be the new face for enterprise software and deliver a series of innovative new features such as improved contextual interaction, action-oriented personal notifications, real-time collaboration in a transactional model, and improved productivity tools with a personal assistant experience supporting interaction in natural language"

I hope that the current SAP developers that want to continue working with SAP in X years will get onboard now because they will otherwise be facing a rather huge hill to climb in a few years time when we have moved from the Fiori 1.0 bicycle to the Fiori 2.0 racer. 

[Former Member]

"I expect only a small portion of current developers (ABAPers) to make the transition needed to stay in the business."

Well but that's the point some colleagues are trying to make. SAP as a whole is already way behind the outside world of technology and innovation. And the Gray Hair developers are even worse because we have a community that refuse to learn new things and prefer to stay in their comfort zones of SAP GUI. We have been working with proprietary tools and technologies for years and this is the era of Open Source. We knew Webdynpro ABAP would fail because it couldn't run on IPhone. Guess what, although JQuery is the most used JavaScript framework, is already obsolete in comparison to their peers.  Don't expect adoption from the "outsiders" of any proprietary Fiori framework. And don't expect a massive adoption from ABAP developers either. Not because the product is not good enough (Which I think it is ), but because ABAPers refuse to learn.

I have been working with abapers for years myself: you can safely say not many knows Object Oriented ABAP. That's the foundation of WDA. Now the web is one step further. If they couldn't catch up two years ago, now is too late.

[soldner]

We have just started with Fiori for HCM apps.  We have a developer who is .NET and she handles the Fiori side of it, and me who does the ABAP.  All I can say is if you have no ABAP customization, you might be able to use FIORI apps our of the box.  But, we have customized both, so lots of work is involved in getting the both to work better.

We've done one 'Z' Fiori and that works pretty good. 

[AdrianDBorja]

A number of my colleagues and myself were able to successfully deploy an internal project based on custom UI5 app with medium complexity CSS based on a custom oData with custom ABAP logic which we are proud of, so for pure ABAP developers to do the shift, it is actually possible. But here’s what we discovered:

1. Especially for those who did not have Web development background in college or does not have the passion or time to learn and only does ABAP for the money and nothing else, it is extremely difficult to encourage those people to learn the UI5 side(JavaScript, HTML, XML and CSS).
2. Compare the UI5 development paradigm to one of its nearest siblings such as Android(Java) development, or the farther cousins such as the traditional web developments and try to search the typical problems in Search Engines and you’ll easily notice the stark difference in terms of community support. While low adoption means no Community at the moment, not even the official SAP website provides enough useful or consolidated end-to-end code samples integrating everything from backend to frontend.
3. Learning UI5 provides a dilemma. Since SAP developer resources isn't too Developer-friendly, developers are forced to decide: a) polish their existing core-ABAP skills which they can already use in the immediate term b) learn non-SAP Web Development frameworks which can be learned in a short span of time due to availability of resources c) try their luck in learning UI5 which they cannot really make use of outside SAP despite the steep learning curve and time investment required and might not even be useful in the near-term

Points for SAP though, openSAP.com is a really useful resource if one wants to learn new technologies rolled-out by SAP. It is very time consuming though.

[former_member286504]

Hi

How about encouraging someone who wants to switch career to start with UI5, HTML5 alone without touching ABAP. Will it work in real time?

 

Thanks

cap