What SAPUI5 and Fiori tells us about the future of UI development skills
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.
Hi John,
Not being a front end developer myself, I think you've got a very important message here. I'm wondering which group will fill the sinkhole: ABAP front end developers moving towards HTML5, or external web developers.
From what I see around me I wouldn't bet on the ABAP developers. Couple of reasons: people don't want to get out of their comfort zone, don't want to invest (considerably) in new techniques and programming models, be it because of financial reasons or time issues (priorities?), and last but not least there is (for the moment) a lack of adoption which means there's no way to learn on the job.
So yeah, it's vitally important to attract web developers from outside. I hope SAP is listening...
Cheers, Fred
HI Fred
I agree with your point
IMHO its just because of uncertain fear of Uncertainty of adaptation, and the most important part is the confusion which is everywhere. Also with frequent release of various UIs is creating a danger, as being a developer its tough to decide which side to choose and if you move for certain skill development say for eg. UI5 (HTML5) whats the guarantee of adaptation?...and that particular product is going to sustain and SAP will not kill it with time.
I hope SAP will clear the confusion soon.
Regards
Kumar 🙂
Hi Kumar,
In relation to the common excuse ABAPers give that 'this technology from SAP might not prevail' or 'my release level is not high enough to use this' ...
One piece of advice I would like to give to ABAP developers with an interest in user interface or mobile development, and willing and able to spend time to upskill into HTML5 .... Even if you take the position that perhaps SAPUI5 may be the flavour of the month and might not be adopted or successful longer term, you SHOULD take the time to learn the underlying aspects and open standards-based components such as ...
- HTML5/CSS3/Javascript
- jQuery etc.
Why? Because these things WILL prevail irrespective of where SAP goes with SAPUI5. You will be able to do some cool things coupling those technologies with BSP, Gateway etc. And if you ever want to reframe your career outside of ABAP, those skills will come in handy and give you added job security.
Here's a start... There's a free introductory book about HTML5 here. (I purchased the O'Reilly version some years ago, but it is also published for free online).
Regards
John
Hi John,
Thanks for putting up a great blog on UI. I would also like to thank for good advice. I totally agree with your point i.e. career outside ABAP.
Being an ABAP and BW developer I am already into learning process of SQL Script, Javascript and JQuery (taking 1 at a time) In a way I can say I have started getting my hands dirty with all upcoming developments.
Thanks again for passing on the link for HTML 5 book. I will definitely go through it.
Regards
Kumar 🙂
Good work Kumar, great to hear.
I 100% agree with John's point here. Never mind what product a vendor (SAP or otherwise) is currently pushing, learning the fundamental technologies underlying many products/frameworks can never be a waste of time or effort. And even if <insert product name here> falls into a sinkhole, you will have learnt some valuable things being exposed to a different way of thinking and approaching problems. In the long run, this is the stuff desirable employees/consultants are made of!
Sascha
Thanks Sascha for boosting me up 🙂 I totally agree with you as I am experiencing the edge when it comes to HANA as of now. with time I will be learning more as I have already decided to move on and learn. 🙂
Regards
Kumar
Excellent. And at the end of it you might be able to join Paul Tomlinson 's team. 😉
Hi John
Someday I might join one of the best team 🙂 or can take the path of freelancing.
Regards
Kumar
Hi John,
When you draw the comparison between WebDynpro Java I couldn't help but think of the quote about insanity being doing the same thing over and over again and expecting a different result! I hope you are wrong too but some how I feel you could be right on the money.
Thanks
Simon
Hi Simon,
Yes, and it just occurs to me that the original code name for SAPUI5 was in fact 'Phoenix'. Is this the idea of a proprietary framework like Web Dynpro Java rising from the ashes?
Cheers
John
Hi John,
no, the name "Phoenix" had a different origin (even though it is still somewhat related to Web Dynpro):
The HTML rendering part of Web Dynpro has the codename "Lightspeed". Now there is the next generation of HTML UI, so what is the next thing beyond light speed? Warp speed! And the first space ship to reach that kind of speed was the one called "Phoenix" in "Star Trek: First Contact". 🙂
And by the way: the aim of SAPUI5 is definitely to be NOT the next proprietary framework, but to be as open and standards-based as possible, even though some blogs and tweets don't acknowledge this.
The list of Open Source libraries which have been included (and can be directly used by applications) is long, extending far beyond jQuery, data.js and LESS. And HTML/JS/CSS is and will always be directly accessible - in sharp contrast to what was the case with Web Dynpro. UI5 rather does the things not provided (or provided well or in a way that fits together) by others.
So from a technical perspective you are right that even once SAPUI5 will vanish many of the skills are not lost because they are about HTML/JS/jQuery etc.
And technically I would argue that UI5 is no more proprietary than jQuery, Bootstrap, or all the other JS libraries.
At the same time I absolutely share your concerns: the current SAPUI5 license makes it completely inattractive to outside web developers (and in the sense of "not-free" UI5 is indeed proprietary).
My own experience also confirms that many ABAP developers are not keen on learning all that new Web/JS/HTML stuff.
On top of that the web presence of SAPUI5 could be improved a huge lot. Hidden in SCN, barely any content, updated infrequently,...
Believe me, these issues are seen very clearly and hopefully the situation can be improved.
Thanks for sharing your thoughts and pushing us
Andreas
Hi Andreas,
Really appreciate you bringing your perspectives on the matter. And I'm really now liking the origins of the original name "Phoenix" ... I'm a big Star Trek fan and First Contact is one of my favourites - I definitely now understand the analogy.
I agree with your more granular assessment of SAPUI5 versus Web Dynpro, that there is more underlying 'openness' to SAPUI5, and that the real problem is licensing and visibility.
Its as if the SAP engineering teams put their heart and soul into producing a nice HTML5 library, only to have it snatched by the marketing & legal suits who live in the land of big dollar enterprise deals and have NO understanding of the world of long-haired web developers. So we end up having the library tied to expensive developer licenses (where I have been, you can almost purchase a car for the cost of a single NetWeaver Developer license), and also tied to usage on SAP platforms only.
I would love to see SAP put SAPUI5 onto a completely separate site, if not on Github (which is where Twitter Bootstrap is). Kendo UI has a nice accessible site http://www.kendoui.com/ and could be used as an example. Intel XDK also has a nice one http://html5dev-software.intel.com/ And then of course there is Sencha (with which SAP has partnered) http://www.sencha.com/ .
http://html5dev-software.intel.com/Instead people trying to get to the SAPUI link from Bjorn Goerke's blog post get taken to this https://sapui5.netweaver.ondemand.com/sdk/#content/Overview.html which will present to them a login screen (unless they happen to have a SAPPassport certificate in their browser - which they won't) - a perfect way to turn away the very web developers which SAP needs.
Then I would like to see SAP license the framework for use on any platform, make it affordable (or ideally free), and then actively promote it to non-SAP developers through non-SAP channels. Focussing too heavily on events such as SAP TechEd is basically trying to preach to the ABAP developer crowd which many of us agree is the wrong strategy (not saying it shouldn't also be promoted there, just not to place too much reliance or hope on it to drive the necessary traction).
Anyway, that's what I would love to see - and of course I know these types of things are probably outside your control. Nonetheless, if it happened it would be a clear demonstration that this isn't your grandpa's SAP. And really it wouldn't be that difficult for SAP to do (when compared with, for instance, making Business Suite run on HANA). Other big companies such as Intel (referenced above) have managed to do it (albeit by acquiring the technology from Appmobi)
Thanks again for all your thoughts.
Cheers
John
Hi Andreas,
I agree with your comments.
I think its important to note that a lot of SAP products have started their life with a foundation based on Open Source Libraries and Open Standards, for example I remember when the Java Dev Stack was predominantly Tomcat with Maven and Ant.
Point being the intent probably wasn't to move these products towards being proprietary frameworks, but rather towards providing the Enterprise grade and scalability that the stakeholders thought was necessary at the time. And whilst SAPUI5 is currently a library collective of open source functions, it wouldn't take much for frameworks like AppDesigner or HANA UIServices or ThemeDesigner to start moving SAPUI5 down the proprietary path.
In short the developers you and I collective are the key users and stakeholders of SAPUI5 and SAP needs to formally recognize this, maybe it calls for something like OData the Open Standard Gateway is built on has, it is currently steered by an OASIS Technical Committee.
Cheers
John P
Great post John and you echo a lot of my feelings about SAPUI5.
IMHO, you'll see a small percentage of ABAP developers bridging the gap and skilling up on SAPUI5. Looking at the small number of people I've encountered who've actually mastered WebDynpro ABAP and even ABAP Objects (which dates from the late 90s - heck, SE24 was in 4.0B although it didn't work properly!), I don't hold out much hope.
Along similar lines, what incentive is there for web developers to either learn SAPUI5 (the proprietary nature galls with people who are used to open source licenses) or even cross-skill into ABAP?
My feeling? We'll see silos - (some) web developers will learn SAPUI5, probably because they have to, being seconded to an SAP project, and ABAP developers will develop the backend services to be consumed by said web apps.
Hi Michael,
I like your analogy about 'silos'. To me that is similar to what happened with developers in the Web Dynpro Java world. I just don't feel SAPUI5 will be as successful as it otherwise would if the storyline plays out the same way as Web Dynpro Java.
Regards
John
I can think of at least one reason which might attract non-enterprise web developers to the SAP/#EnSW space, and on my keyboard it's found about the [4] key 🙂
On a less flippant note, I wonder if silos are the (not really new) reality of software development and we just have to accept that no customer can expect to build an app or complex extension of SAP using just a couple of ABAPers. The world is only ever getting more complex, and there is simply a limit of how much stuff even rock star developers can internalise and wrestle with for long enough to be really great at. So while maybe in the 90's it was possible to hire someone who was able to master the entire stack from UI client to backend ABAP, such a thing is just no longer feasible. The same thing has happened to every other knowledge-based profession (any astro-anthropologists here?), so why not also in enterprise IT.
Money aside though, I do agree there is little/no incentive for someone earning a living using, for example any of the more popular frameworks here, to make the jump to UI5.
HI Micheal.
I agree with you, Lots of Old ABAP guys still prefer Procedural ABAP against OO ABAP. They dont want to come out from there comfort Zone. To be very frank with you ABAP is far more easier than these languages. And ABAPer knows that, In SAP world lots of ABAPer dont know ABAP Objects and Webdynpro ABAP. But a new breed of ABAPer with small amount of experince can bridge this gap between ABAP and SAPUI5 Because these new ABAPers has enthusiam to learn new things and new technologies by SAP, As an ABAPer i started learning JSP and digging out more about AJAX so that it could help me for my SAPUI5 learning ,,
Hope this attitude of new ABAPers leads to good solution.
Thanks,
Faraz
As someone who has had a team of developers using gateway for around 18 months, I thought I'd pitch my thoughts in.
First of all - I've so far resisted the front end UI being developed in SAPUI5, simply because I was put off it with the original version, which looked like HTMLB / WDJ - i.e. not great. Therefore the team have been using HTML5 instead, which produces really nice UIs.
Having said that, having seen the improvements, I'm now re-visiting SAPUI5 again.
On the developers front, I agree that SAPUI5 has some issues. The team I have has an ABAPer to develop the BAPIs and Gateway services and also a HTML5 developer. They are two distinct people. However it works quite well when you're running in an agile way.
As to how many people transition from ABAP to SAPUI5, I'm not too sure. There is plenty of old fashioned ABAP work out there and creation of gateway services is an ABAP role too.
As you have said, this is where there could be a limit / shortage of SAPUI5 developers, where as there will be plenty of HTML5 developers. So the question is, if you have a shortage of SAPUI5 developers, but plenty of HTML5 developers, why would you bother with SAPUI5?
Hi Paul,
Firstly, I must say I'm impressed how you have positioned your team. I don't see that enough from the large System Integrators.
Secondly, yes I had the same thoughts when I saw the early prototypes of SAPUI5 - if I remember correctly I thought I saw the standard icons ported from SAPGUI, and thinking to myself ... you've got to be kidding me. Based on what we now see with Fiori apps, its come a long way.
Finally, to your last point ...
... That's pretty much the synopsis of my blog. But SAP has time to change things here. Other corporates have seen fit to deliver free HTML5 frameworks or libraries into the community. The example I quoted in my blog was Bootstrap, delivered by Twitter. Another example is the HTML5 development environment and framework delivered by Intel, provided 'free of licensing fees and other costs' - and incidentally I have installed this and played with the demos ... it really sets a benchmark for what I'd like to see from the SAP AppDesigner, when that finally gets released.
Thanks for your thoughts.
Regards
John
Funnily enough, we started the team with just ABAPer's, trying to cross train them, but it didn't really work, as they often don't have the point of view of a UI designer (hence a lot of SAP's lack of UI design in existing products!).
So the frontend developer (the 20 somethings which Mark Somper referred to) do the UI design / development and the ABAPers do what they are best at.
"So the question is, if you have a shortage of SAPUI5 developers, but plenty of HTML5 developers, why would you bother with SAPUI5?"
Precisely. People have been building Java Front Ends to SAP for ages with JCO. The tool of the month club will sling code with J<insert your name> because it is free and cool.
As an ABAP veteran, I have seen: Haht Site, BSP, WDJ, CE, PageBuilder... and on and on. Anything outside of SE80 (and its built in version control) has, and never will, take off.
If SAP spent half the time they do generating the "next" UI, and just focused on making their own ABAP tools better (including WDA) -- just think of where they might be now.
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.
I will just stick with what works (ABAP). Its just a simple business proposition (time and money).
Hopefully someone smart at SAP will realize this one day, and invest in the horse that got them to the race.
Haht Site - that's the name I was trying to remember for my last blog. Thanks. I seem to remember it as a single word - Hahtsite.
HAHTsite -I think, but not really an SAP tech more a partnership
http://reference.mapinfo.com/common/docs/mapxtreme-haht40-2.0-dev-pdf-none-eng/HAHTsiteProgrammingGuide.pdf
Oops meant to include this link.
http://www.thefreelibrary.com/SAP+to+extend+R%2F3+Internet+strategy+with+Haht+Software%3B+SAP+to...-a018624398
Think this had already gone out of favour with ITS templates taking its place when I started playing with ESS and MSS.
Yep it was HAHT....they were originally doing the "first" ESS for SAP (as well as doing something similar to a web connector like "Web Methods" did). But that partnership soured and SAP got behind ITS as their way to web enablement. I had a good friend (really good ABAP-per/catch-all that left IBM for Haht) that worked at Haht, and it was funny listening to some of his stories.
TMI,...I still have my Haht boxers they gave out at TechEd (don't worry...unworn) haha
I have. Actually I do both now, but I don't have a problem using GitHub for development, and using STMS from production transport.
I have worked with all of them, BSP, WDJ, WDA and SAPUI5. The big difference is that SAPUI5 is open, so you can leverage community driven development tools.
I just made my first OpenUI5 library, I never tried to develop web layouts for WDA.
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...
Great contribution John.
I am reminded of this tweet from James Governor which was posted over 2 and a half years ago.
learning Javascript used to mean you weren't a "serious software developer". today, not learning Javascript means the same thing.
Cheers
Graham Robbo
Hi Graham,
I like that quote! And we shouldn't forget about jQuery ... it really is great and does all things.
Cheers
John
Like the others who have commented up to this point, I would also very much hope that you’re wrong. I think however that time will prove you right.
In many mid-sized and larger IT departments the split is already there - ie. they contain at least two distinct groups:
When customers want to expose selected Netweaver functionality into their Intranets and into the Internet, will the WEB group reject their current toolset and embrace SAPUI5 as the new way forward? For the reasons you have mentioned and several others, I fear not.
What is going to work however is that those members of the SAP group who can do ABAP-OO will use Gateway to provide the WEB group with a suitable interface to the Netweaver system. Most WEB groups are going to prefer a JSON format though and as you and other have long pointed out you don’t even have to use Gateway for the more basic stuff - a simple “ABAP Servlet” consisting of a SELECT and several CONCATENATE statements will do!
Hi Mark,
Thanks for adding your thoughts.
One thing that just occurred to me when you say the following ...
That's another argument for ABAP developers to embrace ABAP OO. I know some still question why it's needed. Well, here's another reason for them.
Cheers
John
Very interesting blog post as well as comments. I share some of the doubts that not many classic ABAPers will make the leap to SAPUI5.
However my personal observation is that especially those teams who have younger colleagues on-board that only started in the SAP world within the last 5-10 years will be more likely to have WebDynpro ABAP and SAPUI5 skills available. (Which doesn't mean that other colleagues with more experience won't take up SAPUI5 skills as well.)
On the other hand I'm wondering whether it will be possible in the future to support your SAP installation and/or customers properly if you don't have any knowledge about these technologies. Mobile is not a niche thing anymore, ABAP OO is everywhere in applications or new functionalities that have been shipped with an EhP and the same will be the case for UI5 in the near future. Take HR Renewals as an example ...
Hey John,
I love how a conversation over lunch last Friday has become a blog (although i'm guessing you had the idea before then!)
As we discussed: having two separate teams in the WDJ world did not work. What was needed was a skill set that covered both.
I love that I work with people that can cover both 😀 , but think customers are going to be very wary of adopting this because supporting it will be a nightmare due to skills shortages. Some places I have worked have had troubles supporting WDA, WDJ just wasn't supported and they learnt from that. (I hope)
But perhaps here in Australia where most customers are not huge multinationals the support issue is perhaps bigger than elsewhere in the world.
I suggest customers hire some web developers, and train them up in ABAP, as it's not that hard really - the hardest bit is learning that there are so many different ways of doing things, but hopefully the web devs wouldn't have the hard time picking up OO ABAP that current ABAPers do and might bring things like TDD into the ballpark too...
That or they could hire me or you at very very expensive rates that are very worthwhile btw. 😉
Great blog and really appreciate you raising this with the community. Too often we forget about these skills and the issues around providing them.
Anyway - flight just called. must post now!
Cheers,
Chris
Hi Chris,
Yes I've had this on my mind for quite a while ... although the release of Fiori really brought it to a head, when I tweeted this ...
Its also born from my frustration in recent times that developers with deep WDA/FPM skills are still difficult to find. Not much has changed since my old blog Can we reinvent the grey haired ABAPer? other than that WDA seems to be a mandatory entry on every developer's resume, irrespective of their level of experience in that area.
I should also point out for others reading this that your rates are much more expensive than mine, but then again I see you as a superior developer so you're worth every cent.
😀
And yes, as you know I really worry about the skills issues. I believe that it's great to focus on new technologies, but that perhaps it is the people issues which will determine the ultimate adoption, success or failure of new technology offerings from SAP.
Cheers
John
Given the rates I charge, John you are selling yourself short. 😉
Seriously though this deserves debate. As per Friday and Sascha's comment can we expect anyone to hold this whole skill set?
I think yes. But I may have a strong bias here.As this clearly advantages teams that put both ABAP and "new" tech as important for internal training.
I don't think capability in these areas (nb not claiming expertise) is beyond most, in the same way java and abap skills were needed for wdj. It will just stretch most and will flummox those si's that don't invest in their people.
But I still see the biggest issue being how does a customer support this.
Cheers,
Chris
PS if there are typos please forgive. Taxi back from airport a bit bumpy.
Sorry, what?!? "Train them up in ABAP, how hard can that be?"
Quite difficult I'd say based on the fact that quite a lot of people have worked very hard for many years to not just learn the syntax of ABAP (which, will all those keywords and global scopes is a lot more to swallow than, say, Python), but to learn which of the umpteen ways of doing something in SAP is the least-bad way.
Let's face it, how many developers are there who can build a highly performant, you-beauty HTML5, OO-CSS, IE6-compatible, responsive web app on an MV* framework, design the RESTful API to the backend and then implement it in ABAP using BOR/BOL/BOPF/all the right function modules, etc. etc?
The stack is simply too complex for a single homogenous "SAP team" to deal with. But the solution isn't "learn more" but to avoid creating homogenous teams in the first place. After all, great teams are built from T-shaped people who overlap quite a lot...
Difference between expertise and competency. Frameworks like UI5 mean less of need for you-beaut understanding. Yes solutions won't be as awesome as they could be, but modifying a Fiori "app" to do a slightly different behavior or look, shouldn't take from first principle HTML5 skills.
Past experience of difficulties with multi-functional teams with wdj makes me very afraid.
And an ie6 compatible web page shouldn't be even a consideration. No-one should have to deal with that crap, not even ie8 ta v much. Although I fear the latter may be enterprise truth currently.
Being a developer, I have no problem with SAP using different technologies every now and then. I use whatever should be used and I am happy to learn what is needed.
But our customers do not want to use new technologies too often and therefore are mostly sticking with SAP GUI until now.
From my point of view the developer is much more flexible than the customer and his infrastructure.
I am finding that customers certainly do like the look and feel of a UI on top of Gateway (e.g. HTML5 / SAPUI5) and are starting to want it. The main reason for this is the huge improvement in UI, which makes it much more like a phone / tablet app, which users (including senior managers) are starting to demand.
Excellent blog post; most informative. I've been wondering for a while now where SAPUI5 and Gateway technology fit within the SAP ecosystem. With Fiori, that vision is starting to become clearer. It also seems clear to me that Web Dynpro technology no longer carries the banner of "standard UI technology" for SAP. As Fiori apps come to prominence, it will be interesting to see what will happen to WDA/FPM technology...
Regarding the draw of developers outside the SAP landscape, I have an interesting anecdote. About a year ago, I attended a free-to-the-public demo of Gateway technology at SAP Labs. There, I was surprised to see that most of the participants were not SAP developers. Instead, the majority of the participants were Ruby on Rails developers, Python developers, and so on. Talking to a few of the folks there, it seems that their companies were attracted to Gateway because they wanted to make it easy for existing web development groups to tap into SAP functionality. With the advent of mobile apps, etc., maybe that split between application developers and UI developers makes more sense than it did in the past. Definitely something to watch for.
Hi James,
Thanks for adding your thoughts. The comment about the SAP Labs demo attracting non SAP developers is of real interest to me. It means in some circles SAP is to engage these developers. That's heartening news. I'd really like to see SAP do this more often, and also in other regions such as my own.
Cheers
John
Nice blog John - appreciate your thoughts...
...and Sascha as an ABAP-er of old coming into HTML5+CSS+JavaScript+JSON+JQuery+OData+Gateway++++ - no en masse they really aren't any easier to learn than ABAP. Even if, like myself, you have a few of these reasonably under your belt already getting your head around a) how to fit them together and b) how *best* to fit them together is no small feat. Worse... they will insist on using ( and { side by side and for those of us working late night shifts or whose eyesight is degrading... give me MOVE-CORRESPONDING any time. 😉
BTW Just for benefit of all... in case you hadn't yet noticed there's a new SAP UX Explorer site https://uxexplorer.hana.ondemand.com/ that is aimed at assisting customers and others to assess user interface options. There is quite a lot of choice, but I think the adopt / adapt / extend message is fairly clear in the material and will give a feel for which technologies are suitable depending on your corporate change culture and use case scenarios. Interesting to see all the options up there!
Thanks Jocelyn for mentioning https://uxexplorer.hana.ondemand.com, hadn't heard yet of it. Quickly had a look and it seems to provide a lot of information and will be helpful for quite some internal discussions I think ... 🙂
Has anyone been able to access this friggin page? - I am always just re-directed back to the logon screen
Frank, I think you need to be a customer or partner to access the site. Previously I was trying to logon with my SCN user and had the same issue. However using my S-User I could successfully access the site. Cheers.
Hi Frank,
I have to say "Thank You" and at the same time "Sorry".
Thanks to your comment, we realized a bug that we have had in our login coding that affected SCN users, only. Since the majority of users have used their S-User from SMP, we didn't realize the issue earlier.
Sorry, for the inconvenience caused.You should be able to connect to http://uxexplorer.hana.ondemand.com now.
If you still experience any problems with the login, please don't hesitate and get directly in touch with me.
All the best,
JJ
Hi Juergen,
thanks for fixing this and letting me know, I am now able to access the page. But I might ask, what is the point of hiding this tool behind a logon screen at all? Lots of people don't have have either S users or SCN users, but are still interested in learning more about SAP technology and strategy, why would you want to make it difficult for them?
Best regards
Frank
Hi Frank,
Good to know, that you get into our tool now.
Your question regarding login is a good one. One main reason is a legal requirement and the fact that we are on beta. Saying that, it might be possible that this will change over time and we will open it up for all.
Just for my own curiosity: What would be reasons to not create a SCN user? While looking for the bug you have found, I have created a SCN user by my own for testing. It was a task of some minutes with no difficulties. I also couldn't find anything that would make one "afraid" of creating an user account at SCN.
Best regards,
JJ
Sorry, just had to chime in.
Jürgen: this is IMO the wrong question to ask. As you say yourself, it does take a couple of minutes to go through the process, and that can easily be too much for people. Even the very fact that you need to go through this (and upfront you don't know how much effort it is, how much data you'll be asked this time) can put people off.
To be honest, as a consumer I'm also encountering this regularly, and information that should be publicly available (as it contains no secret code or whatever), and despite that isn't, makes me turn away from it often enough, sometimes as a matter of principle.
You should try to get the outside customer view (ok, maybe it's easier for Frank and me), and from that perspective it's perfectly reasonable to ask for this information to be available without having to login, or worse to have to create an account.
And about the legal aspects: it's about time SAP tried to renew itself here, and not use it as an excuse every time. Nothing that you can do much about, I know 🙂 . And the legal department won't read this. But it had to be said nonetheless.
I know, I''ve been going off topic. But IMO it's important stuff, especially applying the consumer mindset.
Cheers, Fred
Nothing I can really add here other than +1.
Juergen, I am glad you asked.
Fred already sums it up pretty well, but I can't help adding my perspective. Imagine a situation where I meet salesperson on the street who wants to tell me about a great product. When I agree to listen she tells me that first I need to answer 19 questions (from the sign up form) and also sign an agreement (the TOU). At this point I would walk on, rather annoyed - this is not way to treat a potential customer. The situation is perhaps not directly comparable to my case of wanting to access the UX website, but I believe SAP needs to adopt a more open and friendly mindset if it wants to engage future customers and developers. I too am a bit tired of the old "legal" excuse. With technology such as UI5 SAP is venturing into an area full of competitors (open source, startups etc.) who fully understand the importance of making life as easy as possible for the customer/developer, so the contrast to the old SAP ways becomes even more apparent.
I want to thank you Juergen for engaging in this discussion, I of course fully understand that you are not to blame in this particular instance, but don't let that keep you from trying to make things better 🙂
Regards,
Frank
Hi Juergen,
The question of sign up screens reminds me of this interesting post I read last year.
http://philosophically.com/why-were-pivoting-from-mobile-first-to-web-first
Forget for now the topic of the post. What I am reminded of is this excerpt ...
I am unsure how valid this number is, but to lose 25% of your audience for what is primarily an informational website seems a high price to pay. Just my 2 cents.
Regards
John
Hey guys,
So, we already seem to have one shared opinion. I'm the wrong to blame here... 🙂
Honestly, I got your points. I will take this topic with me an see how we can optimize our too to this endl. Of course I cannot promise anything, yet. But at least, you can be sure that I'm taking your feedback serious.
Just one little remark to Fred's statement:
"You should try to get the outside customer view"
This is why I'm asking... 🙂 I was consultant for many years so getting the customer view is what I'm trying to do by heart... 😉
Thanks guys for the good discussion and feedback.
All the best,
JJ
Hi Juergen,
Thank you for collaborating and listening. Of course I understand you can't make promises about changes, but it is your willingness to hear our views and take them onboard that is appreciated, and that proves you are part of the 'new' SAP (design thinking, empathy etc.).
Kudos to you.
John
I'm not sure if this is productive yet, but there are plans to make SCN use your twitter/facebook handle if you want. That should reduce even the enourmous task of creating an SCN user in order to freely use SAPUI5 (or HANA Cloud Platform / Portal).
Y
Unfortunately right now you can only use Twitter/Facebook login if you already have an SCN/SAPID account, IIRC. So it doesn't decrease the overhead of creating an account at all. Hopefully that will change in the future!
I hope I'm not spamming but hopefully it's beneficial to someone.
From point of view of enterprises:
On average, support and maintenance is at least 50% if not more for a software and with an ERP there's going to be a degree of
risk aversion compared to consumer space.
From developer's side, the key thing which comes to mind is learning how to learn things:
- Going through the initial period, where we may not be very productive in the beginning. It's not a very comfortable feeling.
- After a while ( and making mistakes , not choosing the best design pattern in hindsight ) we start gaining insights about how to better use a particular technology.
- Try to refine skills by learning best practices / recommended design patterns etc.
However, beyond the particular technology what we gain are different design patterns which sometimes makes learning the next thing easier. In my experience, it took a lot of mental effort to transition to use OO ABAP ( and in the beginning very pedantic about it.. trying not to use any form routines, work areas or even field-symbols unless absolutely necessary instead of object references ), using it for everything including persistence and even transient objects between two different contexts in the call stack.
Learning iOS was more difficult as Objective-C is less forgiving and at a lower level ( even sorting requires you to make an effort).
However, at some point we start seeing advantages: ABAP persistence objects make learning Java hibernate easier as we have the mental model ready and having done iOS, learning android becomes easier especially if one is familiar with Java from before.
Even in SAP world, I've seen advantages of trying to use the best practices e.g. utilizing enterprise services along with ABAP OO cut down integration effort for a recent project and it was much painless than previous experiences.
Talking about solutions: I won't put all the blame on developers. If a problem exists at a macro level, perhaps a different solution is needed. I can see some good news in organisations like pluralsight and even SAP has gone into MOOC platform which should make learning easier .IMHO, apart from pushing technology ,SAP can help its cause by having a video learning series as it has a far less cognitive load.
Reading product documentation sometimes requires you to be somewhat familiar with a technology.
I'm one of those people whom Graham might have referred to in past - mental block against doing JS but seems like JS is going everywhere and avoiding it via GWT etc. is not going to really help 🙂 .
Great post,
History shows that SAP developers have a lot of resistance towards new UI development tools. Non-SAP developers (java, web etc.) have proven to be ineffective in projects with a huge overhead in development cost. If you don’t even know how to debug ABAP and don’t know anything about SAP functionality, it may be challenging to be productive.
However, we must give SAP some credit. UX is the biggest pain point for any SAP customer. Over twenty years of added functionality to the static SAP GUI screens has had a negative impact on usability. It is therefore very positive to finally be able to address this pain point.
In addition, I would like to mention that SAP has opened up their platform for third-party development tools like Sencha, Appcelerator and Neptune. Neptune is a HTML5 designer based on ABAP and by far the best development tool in SAP I have seen where one can create GUIs for smartphones, tablets etc. It is my opinion that any ABAP developer, even without much js, HTML5 and CSS experience, can create innovative GUIs using Neptune.
Really nice post, abap developers are always interested in understanding what to learn next.
Someone said that sap abap is easy, I think it is easier for an abbaper to move to html5 and css, rather then a html5 css developer to move to abap.
To be onest I am really attracted to sapui5, it would be fun to design a fancy user interface, and develop a proces completely end to end, but will the client think I am adding value? would the client prefer someone with only html5 to work on sapui5 and let me concentrate on the hardest part in sap?
When people say move to sapui5 well first I need to understand what is more valuable and what will add value to my skills, I have being doing webdynpro and abap OO, it is time to learn something new like gateway, mobile development, Hana cloud, workflow brf plus ...etc. etc.
.
Objective Javascript is the hardest part to learn ui5. They used MVC just to create view.
Great blog and comments, really echoes my view on UI5, it's a great, well designed and developed library, but unless SAP decide to open source, or at least relax the license it will remain a niche skill.
Having worked as a SAP portal consultant for a number of years, it is clear that clients expectations and willingness to invest in the UI has changed over the last few years, and with SAP developing great looking applications like Fiori it's only going to raise the bar higher.
With the advent of Gateway and UI5 it's exciting that we finally have some flexibility that goes beyond theming.
Regarding skill sets, with flexibility comes some of the complexity that Web dynpro does a good job of hiding. I know UI5 is supposed to still abstract a lot of the complexity, but developing still requires good knowledge of closures, browser quirks, css specificity, vendor prefixes etc, and in particular when things don't work the ability to debug the JavaScript libraries.
I've only come across a few people that have the knowledge and experience to transcend the different technologies, and Gateway provides the perfect abstraction to separate the front end and backend development to ensure you have the specialist skills required to develop slick, supportable applications.
However this the goes back to the question how do you attract web developers with this knowledge to UI5... is really going to interest the open source or jQuery community etc to extend/develop plugins if it can only be used in conjunction with NetWeaver, especially when there are other great libraries out there such as Sencha, kendoui that others have mentioned.
I think SAP have a great opportunity with UI5 and will watch with interest how this progresses.
Another excellent blog from John Moy. A license for SAPUI5??? There are some excellent examples of opensource HTML 5 UI libraries out there and looks heaps better. Puzzles me why they would take an opensource library like JQuery and create a licensed product, kind of defeats the purpose of opensource. I'm on the other side of the coin, a Java/web developer learning ABAP:-)
Excellent Blog, John! Just my two cents about ABAP guys and HTML5 in SAP:
Inside our company we had a lot of discussions about how to get the ABAP guys involved into the development of HTML based UIs. I'm a ABAP developer for 14 years now and also familiar with WebDynpro ABAP, HTML, JavaScript and so on, so it wasn't rocketscience for me. In the end we solved the issues by starting with a SAP certified 3rd party tool: http://neptune-software.com/ It's easy to get ABAP guys on the track with it and encourage them to dig deeper into HTML5 if they start with an familiar looking environment. I'm training ABAP guys of our customers for some months now and all of them were able to create their first basic UI for mobility using jQuery Mobile after about two hours.
@Rajendren: You really have a point there. I'm already using Mansonry and Isotope for jQuery to create responsive layouts. Both are free and rocksolid. Check the demos at http://isotope.metafizzy.co/ or http://masonry.desandro.com/
Hi Experts,
I am working as a WebDynpro ABAP Developer.I am interested to learn mobile UI technologies in SAP.I Have download ECLIPSE and Installed in my system.But i am not aware of JAVA and HTML.As a developer i can not understanding JAVA.Yesterday I have read the articles of Ralf-Juergen Triebel( http://scn.sap.com/people/ralf-juergen.triebel/content).I have understood very well because of it is similar to webdynpro abap UI. .Could you suggest which UI is better for ABAP er's.How is the market for Neptune UI5 .How it is Help full to ABAPers.
Thanks&Regards,
Srinivas Namamula
Hi Srinivasa,
SAPUI5 is something I would look at, it is becoming the go to front end technology for both mobile and desktop for SAP. There is no need for JAVA knowledge but SAPUI5 is based on mostly javascript, jquery mobile, css and html but javascript is the most important part of it. Neptune also uses SAPUI5 these days. The other very important piece for someone with your background is going to be the netweaver Gateway and that will be the easier part since it is ABAP based and a key part in any mobile project for connecting to the SAP backend. There are a lot of videos and documents on all of these so it is relative easy to get started.
Just to let you know that FIORI can now be installed with HR Renewal. You will need to import ACP (Attribute Change Package) for the SRA0nn add-ons (SRA002,3,4,6,7,8,9,10,12,16,18 and 21) that SAP published yesterday. ACPs will allow these add-ons to be installed with EA-HR 607 (HR Renewal). Previously these add-ons could only be installed with EA-HR 600, 601, 602, 604, 605 and 606.
Thanks SAP for fixing this.
Looking for some thing on FIORI, I landed here. Its very useful discussion.
Thank you
Srinivas 🙂
I am a web developer who spent some years working on Netweaver Portal and decided try other things when I noticed SAP didn't improve the product the way I expected, regarding web-standards, javascript libraries and the use of ajax. This happened when 7.3 came out. Now I was requested to "take a look" at Fiori and UI5 to see if it fits our company needs, and while trying to find some info about it I came across this blog post!
First, my vision is from a Web Developer with an open source background.
Clearly I was not impressed. Why do I need another UI framework when I can use Twitter's Bootstrap and AngularJS/Backbone? These are open source projects embraced by a community of millions of people, what SAPUI5 and Fiori brings to the table that I can't do with them? I simply don't see the point in adopting it, I really want to know!
I checked the new declarative support and frankly, it's a considerable learning curve for an experienced designer used to web standards. The generated HTML doesn't help flexibility, as I'm stuck to SAP css classes and themes, I have to know what the generated code will look like to do my own CSS!
And seriously, I installed the UI5 plugin for eclipse, took a look at the source code and noticed it is shipping with an outdated jQuery 1.7.1 released in 2011! Also checked the no-jquery version and saw that it also relies on part of jQuery 1.7.1. This way I cant swap jQuery for the lighter ZeptoJS if my target are mobile devices.
For me it is looking like another failed attempt to improve user experience (like WebDynpros, Visual Composer, HTMLB and so on). It looks to me that SAP should stick to the back-end and providing easy access to ERP data, and leave User Experience for the ones who knows about it.
Sorry for the rant, but it's how I feel by seeing what looks like to be another failed attempt, and seeing how SAP is charging the customers for solving a problem created by having spent years and years with the eyes closed to the outside world.
Hi Fabio
Rants are often welcome and this one is no exception. It is not unknown for me to have a rant now and then 🙂
But I would challenge you on the "another failed attempt". In the enterprise customer adoption and lifecycle context, the takeup of Fiori apps is still completely in its infancy. Heck, there are only, currently, 25 ESS/MSS style apps to choose from, in Wave 1 (plenty more on their way). And the adoption of SAPUI5 is also going to take some time.
As a consultant/contractor for many years, I've seen companies "stuck" on an old release of SAPGUI, still building UIs in classic dynpro, still using procedural ABAP, etc. How might one expect that conservative approach (or an approach based on other reasons) to rapidly take up SAPUI5, which is a completely different paradigm for them? It's not only a new approach to UI building and delivery, it's also a new approach to UI design, and a completely opposite development context (and all the software logistics and lifecycle management that goes with it). So I would suggest that it's far too early to stated that this is "another failed attempt". In my humble opinion, SAP are doing exactly what they should be doing (ok, there are more things they could do, e.g. open-source SAPUI5, but that's a different story).
I suppose it might be fair to challenge SAP with SAPUI5 if, at the same time, one has challenged all the producers of the frameworks listed here: http://todomvc.com/ when they brought yet another framework out. Did people challenge Angular?
Of course, debates like this are always going to come up in the software industry, and while they might be fun and long lasting ("vi forever!" :-)) ultimately there are many reasons, obvious and non-obvious, why new tech is introduced.
I personally think that SAPUI5 (and Fiori) has come at the right time, and do think that the SAPUI5 team as a whole has put an incredible amount of effort in to produce a pretty damn polished product, in an enterprise context, in a very short space of time.
dj
Hi DJ,
I agree that SAPUI5 is a pretty good product and it brings together a lot of great components into a cohesive whole. (Yes it does do some seemingly pointless things and do a lot of unnecessary work if you follow the debugger, but most MV* frameworks do the same thing.)
However, why build another framework that UI developers are going to have to learn when there were already plenty out there? Yes it does bring together a bunch of very cool "enterprisey" stuff like accessibility and OData, but could that not have been done by enhancing one of the existing frameworks?
If SAP chose to instead enhance an existing framework, they could immediately bring into the SAP design world a bunch of experienced Web UI developers. Rather than either those already skilled developers will have to learn a new framework, or more likely the existing SAP developers will skill up exclusively in SAPUI5. The benefits of learning from and embracing a whole new ecosystem of developers could be gained.
I hope that the Developer Advisory Board have something to say about this space, it will certainly be interesting to see how it progresses.
Cheers,
Chris
Hi Chris
This is a fair challenge. But I can only half-imagine the difficulties that would be encountered trying to steer the adopted framework in the directions and the developments that would be required to sit comfortably and squarely in between at least two three hugely important moving parts:
- the Fiori apps, with their teams of app developers and the extension concepts required to allow us, the wily SAP hackers, to modify, adapt and extend those apps without breaking things and without causing yet more people to complain that the concept is totally broken because there are no proper software logistic mechanisms in place
- the ABAP stack's UI services, where things like the launchpad, persistence services and the wider goal of an eventual unified shell can and do influence some of the development decisions happening in this space
Could SAP have delivered something as good as SAPUI5 with the different constraints introduced by adopting a 3rd party framework? Of course, there are positive and negative benefits, but it's not unthinkable to imagine that what would have happened is a framework fork. Then we'd have more people complaining.
It's a difficult situation but what the teams have done is JFDI, which in my book is more often than not a good thing.
cheers
dj
Hi Dj.
I think we're facing a revolution in the so called enterprise software world. As people get used to technology in they everyday activities they start pushing for having the same experience while working. The gap between enterprise and casual usage has narrowed (RIM/Blackberry can tell us about it). In my company this is a growing issue, as the user evaluation of SAP based products and services is way below the average of non-SAP products. We know that behind the user interface, SAP offers a proven, rock solid back-end that has no rival in the enterprise business, but in the end of the day what the end user sees and uses is the interface, and probably what he takes most into account in evaluating a product as a whole. Sometimes it's unconfortable to tell to a client that he has to wait for the next version or the product to mature to have a feature that is considered basic otherwise.
Regards
Hi Fabio,
I'd like to address some of your concerns. Maybe this helps to clarify things and to make your perception a bit more positive:
Regards
Andreas
Hi Andreas,
That is great news to hear that there will be HTML templating in the next version. Although I would be interested to know what you mean by 'real' HTML templating. On a side project I'm currently using Underscore.js (which comes with Backbone.js) and I'm loving it (feels a bit like BSP fragments but on the client side).
Regards
John
Hi John,
you are right: "real" is not very precise. What I mean is that the new kind of templating is quite different from the "declarative support" (and the HTMLViews) in UI5 where you can already write some sort of HTML to define the UI:
Let me just give you an examplethat will fill some plain HTML with UI5 model data (there is also an actual UI5 control mixed in):
<section id="myTemplate" data-type="text/x-handlebars-template">
<h3 id="title">{{text path="/title"}}:</h3>
<ul>
{{#each path="/persons"}}
<li><span class="lastName">{{text path="lastName"}}</span>, {{text path="firstName"}}
</li>
{{/each}}
</ul>
</section>
Of course not using the controls but writing the HTML by hand means you don't get some of the goodies like right-to-left support, theming without thinking about it, accessibility and all this stuff (well, at least you get the data binding and models). But from those comments along the line "well, UI5 gives you lots of enterprise features but you cannot just write HTML" it looks like some prefer low-level HTML coding over feature-rich controls. So this is for them. I still have to find a framework that provides this all at the same time...
Regards
Andreas
Me like 😀
Awesome. So that is very much like Underscore.js, which I currently use. That will be a great addition to SAPUI5.
Thanks for taking the time to clarify.
Regards
John
Hi Andreas
thanks for the answers, some of the information you posted is not exactly easy to find! I'll address these questions with my co-workers when time comes.
The reason I said that it looked like another failed attempt was really not about building something from scratch, in fact without this approach probably we wouldn't evolve much in that area 🙂 What had me worried is that I don't think SAP will be able to keep up with the open source frameworks. They have a big community of developers/users, getting a load of feedback everytime. And who knows, today we're talking about Bootstrap and Angular, what we'll be talking about in one or two years time? Bootstrap 3 was just released and it evolved to the point it's disruptive! Will SAP have the capacity to keep up with they way things are changing? This is my concern, we have seen it before with other attempts, in my company we still have problems with browser support and SAP's generated HTML code, which backed us from doing browser updates!
In the end, it is a matter of sheer numbers, SAP has a team working on UI5 (which is a good sign, shows the company at least is aware of the problem and is making some kind of effort in that area) and right now a limited community of users, open source projects have a host of people involved. It will take longer for the SAP team to adapt to new tendencies, as you said jQuery was the big thing when UI5 development started. It still is the big thing today, but we have other options on the table that may fit specific scenarios, mainly mobile scenarios. I'm afraid of a snowball effect here.
I don't think forking would be a good option for SAP either: you have your own fork of bootstrap, then a year from now something fancier has come up, will you be stuck with bootstrap? Things are changing faster and flexibility is very important these days. What I think would be excellent is to provide a killer way of exposing ERP data, letting web developers choose whatever they want to provide the user interface!
Edit: Oh, I was talking about charging for Fiori, sorry for not making it clear!
Thanks.
Hi Fabio,
thanks for sharing these thoughts.
Indeed documentation is a known weak point. Even if there is a lot of documentation (even sometimes too much to find stuff easily) there is a lot not documented well enough or easy enough to find. It's not a simple thing to provide loads of features and keep the documentation slim and precise while covering everything...
I'm not sure the sheer development capacity is the main challenge: when you look more closely, Open Source projects do indeed have loads of users (which helps spreading the knowledge a lot), but real contributors that do actual work in the very core of the framework? Then the numbers are much lower. Plugins like custom jQuery UI controls may be an area where many contribute, but this kind of things do not evolve a framework.
Actually I don't think one and the same Open Source framework keeps being itself and evolving at great speed at the same time. New frameworks come with new trends, old ones get less important even though they had their time of fame. Dojo and jQuery UI were sort of cool, but did they evolve over the years and stay the hottest toolset in town, just because they are Open Source, with seemingly unlimited contributors power?
Or there are breaking changes, as you mention, which is more or less like creating another framework. When it comes to enterprise applications a UI library development team cannot say: "last year we built a great DOM manipulation lib, this year we are building a cool MVC framework and next year we will create something new with Web Components." There has to be something a bit more stable and lasting, but at the same time flexible and as modern as possible. It's difficult, obviously, and does not lead to perfect results. Being able to disruptively change things every year would make things for framework developers much simpler, but try to sell this to the application developers who have to re-build their apps...
> I don't think forking would be a good option for SAP either:
> you have your own fork of bootstrap, then a year from now
> something fancier has come up, will you be stuck with bootstrap?
True, but what should be done instead? Use it as-is? Still all the applications built using it would then be stuck with bootstrap a year from now and have to be re-built. Not even mentioning all the features it is lacking which are required for the current batch of apps. So a lot of development would have to be invested in it or on top and as you say: there will be something hot in a year which will make bootstrap (and UI5) look old and the same discussion would start again.
This is written from an inside perspective, though, considering the need of a stable toolkit for many applications which should live some years.
When it comes to SAP customers or partners who what to provide a UI for ERP data with the hottest tech of the day, not so much caring about what is in two years, then there are other choices than UI5. I think SAP is sort of trying to provide this killer way of exposing ERP data by offering Gateway/OData. You don't need UI5 to consume this. Use the (Open Source) data.js library (which is also part of UI5) and your UI technology of choice. This is part of the UI strategy of SAP as far as I understand, in order to decouple the backend more from the UI layer.
So you are free to choose something different than UI5 for the UI, but once you have a deeper look you might find that UI5 makes it very easy to consume OData and it does a lot of things for you which other libraries don't do. The choice is yours, but of course UI5 is trying to be your lib of choice. 😉
By the way: when I wrote about Open Source, the limited number of actual contributors etc. I did not want to imply anything bad about Open Source. I love Open Source, I see its advantages and contributed to projects myself. And UI5 uses and includes lots of Open Source libs. It's just that sometimes people consider a framework to be superior by nature just because it is Open Source. And that's too much glorification for my taste.
Actually I'd love UI5 to be Open Source, but there are many legal and organizational considerations, so it's not an easy and quick task to get the OS license stamp on it.
Regards
Andreas
Hi Andreas,
Yeah, I understand your point about Open Sourcing. I guess I see that as a potential means to and end, being developer engagement, rather than an end itself.
I've been talking to SAP about developer engagement with web developers locally in my region. I've suggested it would be great at events for web developers if SAP stood up and talked about SAPUI5. But we came to the conclusion that with the current licensing regime for productive use (my understanding is you need a SAP NetWeaver developer license or SAP HANA Cloud) most generic web developers wouldn't be interested. So if not freeing up the license, or Open Sourcing, how to get this in front of developers, if we assume (as in my blog) not enough classic ABAPers (who typically are the holders of developer licenses) will be able to take this on? As per my blog, I don't want to see a repeat of the Web Dynpro Java story from a developer engagement perspective.
It would be interesting to see what the new SAP Developer Advisory Board would think of this.
Regards
John
Hi Fabio
Good thoughts. But I'm not sure, as a customer, or a developer in the SAP ecosphere, that I'd *want* SAP to "keep up with the open source frameworks". While I want the benefits of modern development platforms and techniques, what I want just as much if not more is a stable platform, a stable target runtime and something I and my customers can rely upon over the next few years. As you say, today Bootstrap and Angular, what comes next year, with all that will change? I don't know, and I don't want to wait (and my customers can't afford to wait) to find out. What's more, there's another huge group of developers with the same requirements. Yes, the SAP-internal folk who are building out the apps.
With SAPUI5 (and Gateway/OData/ICF) I have the toolset and the platform to build out user-focused apps. And if I fancy using Angular or Boostrap or something else that is disruptive and just around the corner, there's nothing stopping me technically from using that too. If you swung an ethernet cable round the room here, I'm sure you'd hit a few people who had already done that, with, say, JQTouch, Sencha Touch or JQuery Mobile for example.
In my opinion we shouldn't try to make SAPUI5 be all things to all people across all of future development paradigms. Then it would be running the risk of failing on all counts. Yes, let's look to SAPUI5 to bring us the design- and run-time platform that we need to build great apps for the users, on multiple devices. And there's nothing stopping the SAPUI5 team from making great improvements (look at the templating features that Andreas mentioned elsewhere in this thread for example). But stability, compatibility, reliability and integration capabilities are critical too.
cheers
dj
Hi Fabio,
Thanks for contributing your thoughts. There are aspects of what you say which ring true for me. However, like DJ and Andreas mention, it is much to early to judge SAPUI5. From my discussions with SAP personnel, there appears to be a significant engineering effort underway focussed on Fiori (and consequently UI5) by SAP. I think we will hear more during TechEd season which is close. Even Andreas' comment about SAP adding HTML templating demonstrates that SAP is trying to evolve this framework as quickly as possible.
That said, I stand by the comments in my blog, whereby I feel the greatest risks to SAPUI5 are :
I would add one third concern ... the library appears to be on the heavy side. I have discussed this with product management and believe it will be optimised in future releases.
Cheers
John
I agree, it is more a people's issue than anything. It would be awesome to see it available on GitHub with feedback and people contributing, criticizing, submitting ideas, I think it would evolve a lot faster, and responding quickly to change is the key today.
First of all, I think SAPUI5 is great. I have worked with JQM and Sencha in an SAP context for more than 30 productive customer implementations in the last two years (Using Phonegap/Cordova for Hybrid solutions). Your concern about the Library being on the heavy side is valid tho - Build for Blackberry fails because of the sheer number of js files (Even if you delete all the debug stuff) So I hope they will make a slimmer version for mobile like they have done for desktop.
They thing I was most skeptical about 1.5 years ago when the first beta was released has turned out to be the thing I like the most in the framework - The high level Controllers/Elements. Our projects used to have a major focus on UX and CSS (In cost and time). For Enterprise Apps the Fiori Look&Feel get's fantastic feedback from most customers (Who are used to SAP GUI and WebDynpro). This means we can deliver great looking apps with less effort to the customer.
Another aspect to consider is the SAP Store. If partners deliver Apps to the SAP Store it is important that the UI is consistent so customers can chose solutions from different vendors.
Njål
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.
I was lucky enough to see a tweet highlighting the conversation still taking place on this great piece. Subscribing now to the blog entry. I think one of the biggest issues is actually highlighted by the fact that I was just lucky to become aware of the SAPUI5 upcoming updates included in these comments. It takes a rather brave soul to dig into the latest and greatest UI technologies from SAP after being burned by the previous attempts at the same. Better documentation and communication between the brave souls (count me in please) and the product development team, with more of everything (demos, tutorials, in depth technical documents) can go a long way towards improving the life of those of us that are taking the risk of preaching the latest gospel from SAP on the UI side.
Side question/note. Since I am going to Teched Las Vegas, CD168 seems to be the SAPUI5 session that is of most benefit for those interested in UI5 (one of the first hands on sessions that got fully booked). Are there some others recommended?
I can fully recommend the CD168 course, very hands on, and lots of excercises! See you there!
Hi Experts,
I am working as a WebDynpro ABAP Developer.I am interested to learn mobile UI technologies in SAP.I Have download ECLIPSE and Installed in my system.But i am not aware of JAVA and HTML.As a developer i can not understanding JAVA.Yesterday I have read the articles of Ralf-Juergen Triebel( http://scn.sap.com/people/ralf-juergen.triebel/content).I have understood very well because of it is similar to webdynpro abap UI. .Could you suggest which UI is better for ABAP er's.How is the market for Neptune UI5 .
Thanks&Regards,
Srinivas Namamula
Hi Srinivas,
I work for Neptune so I am biased here. Anyhow it is free to download a trial version from our webpage and install it on any non-productive Netweaver system. So my suggestion is to try it out and if you don't like it don't use it 🙂
https://twitter.com/monkchips/status/25217409319 😎
That means you now can be considered a serious developer Graham 😉
I remember in the late 90's when I was a J2EE developer and got pretty angry when ppl thought js and java was the same thing. With HTML5 things have drastically changed 🙂
"Things have changed drastically" < so waiting for John Moy to chime in with an anecdote right now.
Unfortunately I think whilst many (the engaged few that are reading and commenting on this blog post) are aware, there still exist many many that are not. Although such fossil hunting is thankfully becoming harder.
Like Chris and John I still come across plenty who think java & javascript are the same thing. Amazing stuff really. 😡
I just had that conversation last week with the "technical lead" of a customer. Here is my favourite reply to the question on the difference between Java and Javascript:
http://stackoverflow.com/questions/245062/whats-the-difference-between-javascript-and-java
Thanks for sharing that Frank,
Best thing I've seen today! Very funny.
Regards
John
By the way, I am asking myself for a long time now which one is performing better, SAP or SAPScript?
Good blog.
I was once a Webdynpro Java developer. I do feel that SAPUI5 is not that easily acceptable by ABAP developers. But with the changing market trends, most ABAP don't prefer to shift to some new development tool which no one can predict when it will vanish again in future. But, still its worth updating once skills with the upcoming new technologies such as SAPUI5.
Regards
Uday
Got to add my 2 cents.
Since my company ( state government) is always a few versions behind and too cheap to but the new fancy stuff, we make do. Read John Moy's J Query mobile blogs and got permission to build a 'Mobile' gateway for some HCM stuff using BSPs.
Works fine and looks good. We only have about 30K users, so not a big worry on demand.
Building the BSP pages using ABAP is pretty easy. Easier than SAPGUI dynpros, and much easier then Web Dynpros.
Now we FINALLY have the gateway and I can start learning using SAPUI5, but jQuery still looks better to me...
Hi Steve,
developers will continue to debate which framework is better for the foreseeable future - and (in the unlikely event you are not aware of it) SAPUI5 is built on top of jQuery so it is not necessarily a either/or decision.
For me the real value proposition for SAPUI5 is when you combine it with oData services such as those provided by Netweaver Gateway. The controls are very oData aware and, as John Paterson says, the data binding "just works".
Cheers
Graham Robbo
This times 10. That's the big advantage of OpenUI5 versus something like AngularJS which is the top HTML5 framework.
And as far as I can see, OpenUI5 has many rich controls, while with AngularJS you need to rely on Bootstrap to make those fancy sites.
For enterprise software, OpenUI5 beats the other frameworks I checked out. It's very data driven, now we just need two way binding for oData models. It sucks having to use a JSON model to have two way (I know, beta, but I don't use it).
PS: Yes, Bootstrap beats Fiori as far as eye candy, but this is enterprise software.
Keep in mind UI5 is a library...which means you can actually use it WITH those other frameworks. So yes, UI5 within Angular? Sure!
Sure you can but do you want to mix a DOM-based framework with a OO framework like OpenUI5?
Right now I haven't felt the need, although I do want to try out Angular a bit more so I can compare it fairly to OpenUI5.
Lot's more coming from UI5 team - here is one place you can see what might be coming soon. http://openui5.tumblr.com/post/113243652527/new-openui5-preview-release-1-28
Expression binding is awesome.
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?
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.
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.
thanks for the tip Mark
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?
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.
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:
I guess this is what Phil is asking above, and I'm sure wondering the same 🙂
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).
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.
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? 😉
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.
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.
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. 😉
Cheers
Graham Robbo
Ok Will do Robbo. Thanks for the tip.
BTW im in Heidelberg these days
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......
Nice question to be answered,
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 🙂 , 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
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.
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
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.
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.
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
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.
"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.
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:
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.
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.
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