Can we embrace the Long Haired developer?

[former_member182638]

A short history for developers

The current times remind me of the early years of NetWeaver, when SAP developers were faced with the new challenges of Web Dynpro Java, Enterprise Portal, and XI.  Those technologies were introduced by SAP in response to the dramatic shift in global technologies a decade ago towards web-based screens and interactions.  History tells us that only a proportion of ABAP developers successfully made the transition from ‘classic SAP ABAP development’ to ‘SAP NetWeaver development’.  To help with this shift SAP sought also to tap into the legions of Java developers who in global weight far outnumbered their ABAP brethren.  It turned out that only limited numbers of those Java developers embraced the SAP ecosystem, discarding their well loved open frameworks in favour of SAP’s proprietary approach to UI development in Web Dynpro.  Partly this may have been influenced by the requirement for SAP’s Java platform, a pre-requisite for coding Web Dynpro Java. 

Turn the clock to today, and consider the following statement by a Gartner analyst at a recent Gartner conference ... 

The demands of mobility represent a new challenge, promising to be as significant as the shift to web user interfaces a decade ago.  Once again the gauntlet has been thrown before the SAP developer community.  And at the same time SAP is seeking to attract the help of a new class of developer, the so-called ‘long haired developer’.  The technologies in play for mobility this time around are (primarily) Sybase Unwired Platform (SUP) and NetWeaver Gateway.  Can the existing SAP developer community re-skill for the new age of mobility, and will the non-SAP mobile development community turn their back on open frameworks in favour of SAP’s proprietary SUP SDK and NetWeaver Gateway with OData?  Whilst it is early days, we have had a patchy start.  Developers are generally struggling to get their hands on any kind of free trial edition of Sybase Unwired Platform.  The situation with NetWeaver Gateway is better, with a 90 day free trial released.  In general however there are still questions about the licensing models and platform complexities.  Those issues are discussed in some excellent blogs by Graham Robinson and Richard Hirsch.  Here I focus on the skills challenges for developers.

Reinventing the grey haired developer

Let’s cast our minds back to Web Dynpro.  We now know that to drive the adoption of Web Dynpro the SAP engineering team undertook the herculean task of porting Web Dynpro from the Java stack to the ABAP stack.  All this time, the focus on Web Dynpro has insulated the SAP developer from needing to build their skills in open web client rendering technologies, such as HTML/CSS/Javascript, jQuery and other frameworks.

Now with new mobility architectures, the SAP developer (and in particular the ABAP developer) is faced with needing to understand and embrace precisely those technologies that SAP has sought to shield us from over the past decade.  And I would suggest this will be a significant challenge to many SAP development teams.  It will require a different way of thinking.  It will require developers to look outside the SAP realm, to tear down the fortress-SAP mindset, to embrace the ideas and learnings from non-SAP communities.  It will require a willingness to ‘think outside the box’, to become comfortable coding in a variety of languages.  This might include for instance, web development (HTML5/CCS3/Javascript, jQuery, jQuery Mobile and other frameworks etc), native mobile development (iOS, Android etc.), and a greater understanding of common approaches in development generally (design patterns, test driven design, usability, Agile practices etc.).

Think the Sybase Unwired Platform (SUP) will save you?  Not quite.  You will need to consider coding potentially in Java for SUP.  For anything using the SUP Hybrid Web Container you will still need to have skills in HTML/CSS/Javascript and potentially some idea about jQuery Mobile.  If you are using SUP to generate a native app, you may still need to roll up your sleeves and code in the native app language (eg. Objective-C for iOS) if you want to achieve something the SUP framework can’t generate.  And of course you will need to understand the applicable SUP SDK, and NetWeaver Gateway which depending upon the use-case may require some ABAP.

The demand for such a seismic skills shift presents a challenge for SAP and the existing SAP development community.  In some ways, it is not simply a skills shift, it also demands cultural shift (to discard the fortress-SAP way of things).  And it is a shift that needs to occur quickly now, much more so than in the early days of NetWeaver when the shift to Java was introduced.  The competitive challenges of SaaS providers, and the rapid growth in demand by customers for mobile offerings is driving this need, and fast.  SAP of course has stated it is hoping to contribute 20% of apps and the partner ecosystem to pitch in and contribute the remaining 80%. 

Will the partners deliver?

Whilst it is early days, I have yet to be convinced that the partner community is well placed to take on these challenges.  The larger partners in particular have spent years commoditizing their SAP developer resources.  A great proportion of these resources have been organised to approach SAP related work in a cookie cutter fashion.  Implement an enhancement point here, write a conversion program there etc.  The business models for these organisations rely upon large complex SAP implementations using armies of consultants and developers with a mix of onshore and offshore resources.  This is a far cry from the small agile teams of technological ninjas required for mobility.  The smaller boutique SAP partners may be better placed, as these often differentiate themselves by bringing an innovation (high value) focus rather than commoditization (low cost) play when dealing with SAP customers.  But are these boutique players sufficient in number, and will customers favour them over the larger partners with whom they might historically have preferred to engage? Dennis Howlett has suggested the merits of engaging the broader development community, including independent developers, through an app store approach and this would certainly change the dynamics around developer resources focussing on mobile app development.

Can developers focus on user delight?

Sometimes I wonder in the debates about mobility whether the focus on usability and user delight are missed.  It is the defining reason for Apple’s success.  It also happens to be an area where historically SAP solutions have not always rated highly.  Conversely this presents one of the greatest opportunities for SAP and the ecosystem to add value to the SAP core system … by providing consumer-grade mobile apps to interact with SAP data and processes in such a manner that users (as best as possible) enjoy the user experience.

(Image courtesy of Geek and Poke under creative commons license.  Thanks also to Sascha Wenninger aka @sufw for pointing it out)

That said, in the few instances where I have seen SAP-related mobile apps constructed by the large partners I have yet to be thrilled.  An example was an iOS app that I examined, which failed many of the basic user interaction tests prescribed in Apple’s own Human Interface Guidelines.  For instance, when the device had no network connection, it failed to alert the user that this was the case (instead the app simply failed to respond to any button actions because of the lost network connection).  The app also crashed on occasion.  Behaviours like this would mean an instant rejection if submitted to review by Apple.  As a side note - I would advise any developer looking to build enterprise apps for iOS to first read Apple’s Human Interface Guidelines.  Even if your app will not need to be reviewed by Apple, reading these guidelines will give you a real appreciation for the level of focus Apple gives to the user interface (and a key reason for the success of that company, and the creation of competing platforms such as Android).  As a more subtle example, Apple’s guidelines specify the following relating to an iOS table view …

"If a row selection results in a navigation to a new screen, the selected row highlights briefly as the new screen slides into place.  When the user navigates back to the previous screen, the originally selected row again highlights briefly to remind the user of their earlier selection (it does not remain highlighted)."

This example gives you an appreciation for the level of detail that enterprise mobile developers should give to the user experience  (and if you are wondering, the partner-built mobile app example I saw demonstrated didn’t exhibit this behaviour).

On the other hand, there are some apps appearing that look to have a great user experience, such as this Team Performance Assistant app created by SAP.

Can we embrace the long-haired developer?

I once attended a seminar hosted by Apple’s enterprise group.  The topic was ‘iPad for the Enterprise’.  One of the statements that resonated with me was when the speaker told the audience that ‘the best enterprise apps we have seen have been built by games developers’.  Personally I believe SAP mobile development teams would benefit from including mobile developers and UX designers with experience in the consumer mobility worlds.

Am I willing to write off the grey haired SAP developer?  Of course not.  I’m one of them.  But it will require a mammoth effort for us developers to transition to the new world of mobility.  SAP itself coined the terms ‘grey haired developer’ and ‘long haired developer’ (in a slide I saw over a year ago).  There will always be a place for the grey haired developer.  But on a global scale SAP clearly sees the need to also embrace the long-haired developer for mobile development and UI innovations.  That will be where the future is.  It’s time to grow our hair.