Sap
Content
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 Dynpro Web Dynpro ABAP SAPUI5 ABAP & Dynpro
Skills Required (per SAP UI Roadmap)
ABAP OO, Web Dynpro ABAP, Floorplan Manager 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 developerand 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.
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 Dynpro Web Dynpro ABAP SAPUI5 ABAP & Dynpro
Skills Required (per SAP UI Roadmap)
ABAP OO, Web Dynpro ABAP, Floorplan Manager 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 developerand 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.
