Skip to Content

Can we embrace the Long Haired developer?

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.

You must be Logged on to comment or reply to a post.
    • Thanks Graham.  Interestingly, whilst we know you have grey hair (!), you are someone who I would consider a long haired developer.  Simply because you know how to think outside the box.  Your workflow solution that you presented at TechEd is an example of that. 
      Being a long haired developer in this context is a state of mind, not a physical trait.  A willingness to learn and use new technologies for example. In fact many of the development focussed SAP Mentors are of that mould.  Look at their skillsets ... they all tend to have a foot in other technologies such as Flex, Google Apps etc.

      Thanks again

  • From my point of view the most pragmatic solution for all parties would be to separate the business logic (completely in ABAP in SAP) and mobile app (Android, iOS, HTML5 etc.) as much as possible and have different specialized developers for each part. So you can still make use of your grey haired staff and can also hire some new long haired guys for the mobile thing.

    For this scenario something like Gateway 2.0 would be a perfect tool but you could also use other approaches as discussed here in many different blogs.

    But again I have to state that for our customers Web Dynpro Java did not happen. They simply continued to use the old-fashioned ways to use SAP. Therefore I cannot imagine that now they are all eager to buy and license a Gateway System and a SUP system.

    I would be happy if SAP would deliver something like FPM that would be able to generate web apps that work nice on all mobile devices without the need of extra software. It does not always have to be a 100% solution. For sure Apple users are demanding shiny apps that work perfectly on their devices but sometimes 80% may be enough to fulfil business needs.

    Finally I think that again there is a huge discrepancy between SAPs vision and the vision of the SAP developer community. Hopefully this discrepancy will get smaller in the near future.

    • Grey haired not being able to develop in more than one language?  Really?

      Long haired not good enough to learn the ABAP side.  Really?

      It would make your projects harder to staff.  You may be waiting for one or the other resource.  Someone that could do it all would be highly in demand.  You wouldn't have to wait for the developer, or hire a lot of new people, or pay a lot of consultants or...

      I would hope any developer could learn different languages and different ways of thinking.

      My $1,


      • Speaking for me I love to learn new languages and tools ( as probably most of the active SDN community does also) but in order to do things efficiently you cannot be the jack-of-all-trades.

        And I know many consultants that do not like to learn new things every day although they should have to...

        But these questions depend on your specific business and the size of your company etc.

        • Ah...  but that's the debate, isn't it?   Is it a jack-of-all-trades to know how to develop in more than one language or format?  Or is it simply good development skills?

          • I do believe there is a point that Mark does have.  While I believe many developers can create a great user experience, there is an art to making a beautiful application which is more a creative artistic flair (not to mention there are many that can't create a great UI experience).
            While consistency means a lot of us can create pretty good apps (with things like jQueryMobile) which are fine 80% of the time, I still believe the visual design of a mobile app is something I would bring in specialised skill for, especially if developing for non-Enterprise users (customers or vendors).  i.e. Throw into the mix the experience of catering for multiple devices and form factors, the subtle differences between hex colours, curves and (what I've experienced) very lateral thinking design that challenges your thinking.
            For example, I tend to recommend to those building customer facing mobile web applications, to get a visual design company who can deliver HTML/CSS that is tested on multiple devices; then give it to the developer, SUP, etc.
            Of course, the developer can probably run with changes from there; but that initial design is definitely a skill just as good as an excellent SAP programmer that comes from years of experience.
            That said, I'm happy to give it a go and know I'll do a pretty good job but is that good enough with today's expectations for Mobile Apps?
          • Matt,
            I agree 100% with your comments.  In particular, there comes a point where we all need to recognise that developers don't necessarily make good usability experts.  I also recommend engagement of UX experts where appropriate.  We did that just recently on a project and the outcome was simply outstanding, compared with the out of box solution. 
          • I agree a good point.  But - there is always a but, By definition isn't a good programmer creative?

            There are so many different sites on the internet, and our business people use them.  Couldn't they say I want an App to look like XYZ with this information and then we can run with it?

            I don't know.  I agree - I look back at the screens I developed for MII, they are basic.  But at the time basic was what we needed.  

            Apps does that extend to web design?  I know Web Dynpro by it's very nature doesn't really support HTML / CSS design.   BSP, of course it does.

            Interesting discussion.  I really like the responses to this blog.  It does make me think.  We are probably a year or so out from developing
            apps here.  Although I do plan on playing with them.

            Also I agree with Stephen, in theory we could bring in an app designer.   But our department doesn't have an unlimited budget.  That is why a jack-of-all-trades is valuable here.

            Round and round I think about this one....  80/20 usually a good number to give the business.

          • For me, the ongoing discussion was really helpful and I have found my individual approach to mobile apps now (thanks to all of you):

            In order to get going, I will definitely start in small steps: Build a web service via SICF, then build a native Android app that consumes it. This will be enough to realize some small apps for the first customers who will ask for mobile solutions. If other platforms (Apple, Blackberry, MS) are asked for, then I will try to do native development there, too. But for Android the hurdles are the lowest...

            Then the customers have the choice of buying a large platform like SUP which will offer many more features or (if it is possible) getting only a Gateway server or continue to use the approach mentioned above with SICF.

            For sure I will develop the first tiny apps all by myself but as soon as the volume of ordered apps will be large enough I will try to get specialists to do the work on either sides (be it me or a colleague or an external does not really matter here).

            @Michelle: Now you will be able to find my email address...

            Regards,  Mark

          • Hi Mark,
            I like your approach.  One piece of advice based on my own experiences.  Whatever you do, make sure you separate the data feed from the client consumption layer.  This is a best practice architecture and sets you up to swap your client layer or use alternative clients (eg. swap from native app consuming the feed, to a HTML5 app).  Sounds like you are going to do that anyway.
            One thing to avoid is the older 'page-based' approaches where your constantly serve the layout with data embedded as a web page (eg. JSP, BSP).  This is because you have no flexibility with this architecture, and the payload is constantly 'bloated' since you are constantly serving the layout alongside the data.  I blogged on this approach in one of my earlier blogs but I now see it is outdated.  I do still use BSP for mobile web apps, but only in the context of serving the initial HTML payload, which then uses javascript to consume the RESTful services.  If you are using HTML5 concepts (cache manifest), that initial HTML payload can be cached onto the device and never need to be reloaded again (similar to a native app).  I might blog about this when I get the time.
            Good luck!
    • I couldn't find your e-mail!!!!  Sorry.  I had to reference this comment in a blog I wrote.  This comment really made me think.  After I finished being one sided, I love this comment.  It's what SCN is all about. And anything that makes me think is a good thing.  I don't want to get so one sided that I can't see some valid points.

      Keep up the great comments - this one drove another blog!


    • Hi Mark,
      Your pragmatic solution to separate the business logic and the client layer with specialized developers for each resonates for me.  In fact, that was probably SAP's own thinking in their own slide depicting grey haired developers on the Gateway service creation side, and long haired developers on the Gateway consumption side.   That said, just like a proportion of SAP developers were able to reskill for NetWeaver, likewise a proportion will be able to transform into long haired developers.
      Thanks for adding to the discussion.
  • SAP combined with mobile apps is a powerful tool.  Is it one that will be "needed"?  Can we create the demand for customized mobile apps?  Probably, but we have limited resources, limited projects, and frankly our development team is not involved in helping with the project list.

    I wonder if that is true for anyone else?


    This grey haired developer is working outside of my job / workplace to improve my skills.  They will be needed sometime.  Of course the feeling here is not to learn it until it is needed.  Catch 22 anyone?  Chicken or the egg?

  • Thoughtful blog and comments everyone.
    Lets face it, this is more an attitudinal thing, that a colour of hair or chronological thing.

    I am sure we have all seen folks of all skill and career types who just get into a lenghty comfort zone who don't embrace change, or picking up new skills and knowledge.

    This applies equally across Business folks, Functional, Technical, all areas, not only to Developers.

    Cheers, Phil G.

  • Hello John,
    Mobility everywhere.
    HANA everywhere.
    Now me being a developer my take on all these:
    Customers are not embracing these changes as fast as they are released.
    I am still working on BSP and not Web Dynpro.These would be ramped-up to Web Dynpros in future though.
    I am still working on Smartforms and not Adobe forms.There are still legacy systems which are gruadually getting decommisioned.I understand that this can be due to multiple project management issues.
    I see gamification/streamwork scaling new heights but yet to be added in list of customers seriously.HANA has managed to be in the list,though.
    This comment might seem irrelevant for this blog but then learning new language is not a very big deal. We have been doing that - C,C++,Java,Eclipse,ABAP and now more.
    Skill + opportunity matters.


    • I LOVE your comments too.  I read them, and they make an impression on me. 

      I am coding in Web Dynpro.  Why?  It's what we learned, we totally skipped BSP.  Now I'm revisiting BSP because I want to write some Apps. 

      I am using Smartforms.  BUT we just had a consulting company develop in Adobe forms.  So I'm changing to Adobe forms so that I can support the development.  (And they are great by the way!  Much easier to use.)  I also support SAPScript.  That is not going away.  Sadly, very sadly, maintenance mode really does not allow for rewrites.

      I love your comment - learning a new language is not a big deal!  We are developers and do it constantly to keep up with our changing world.

      Tortoise - yes we seem to move at the pace of a tortoise at times.  And sometimes we require our consultants to move as slow as we do.

      Interesting comment, and some more things for me to think about!


    • Hi Kumud,
      Thanks for your comments.  And the topic of 'opportunity' is a valid one.  It seems in the comments that my blog was interpreted as too focussed on the topic of learning new languages.  As Phil Gleadhill in his comment rightly mentions, it really is about attitude.  If you have the right attitude, then building great solutions with whatever languages, toolsets and technologies will come easier to you. 
  • Wow the comments about ERP implementation teams being super complex and not agile enough is no longer true.  You must think every customer running SAP has 200 people supporting which is is far from the truth.  A lot of implementations have very small teams that have to move quick and must deliver solutions in small timeframes.

    Honestly a lot of arguments you bring up on why ERP developers can't do the work was the same tired story spouted by the, portal, exchange, etc groups of developers.  In the end its the soft-skills mentality of your developers that are the key and not always the ability to code in a particular language.

    Oh BTW, I have also seen a mobile application designed by one of those gray haired developers  that without offline capability is more user-friendly, quicker to implement and more agile than cool kids applications built on a super ultracomplicated platform.  Perhaps that's why we don't want those gray-haired developers working with mobility because they might apply the KISS principle and deflate the hype.

    Take care,


    • Hi Stephen,
      Thanks for adding to the discussion! 
      I apologize if you interpreted the blog as having an overly negative tone on large partner ERP implementations.  I would agree I have seen smaller teams operating on smaller scope projects.  I have yet to personally see a large partner in my region running true Agile implementations on SAP projects (there might be, I just have not seen one).  Is that the case where you work? 
      I completely agree it is the attitude of your developers that are they key.  I think the words in my blog were overly focussed in hindsight on the ability to code in certain languages.  My bad.  That said, with the right attitude, developers will be able to think outside the box.  This also means knowing when to call in the UX designers for instance for specialist assistance.
      If you have seen a grey haired developer build a great mobile application then I would say that is fantastic.  Perhaps then they are not a grey haired developer after all?  In my blog, I didn't mean to connect the definition of a grey haired developer to one's age or physical attributes, although you could be forgiven for taking the literal interpretation so I apologise for that.  You might see in my earlier comments that I attributed Graham Robinson as being an example of a long haired developer, even though he does have the grey hair.
      Interested in your reference to the 'super ultracomplicated platform'.  It is a separate topic, but it tells me you are not enthralled by the SUP approach to mobility?
      Thanks again for your contribution.
      • SUP approach - mobility...

        Now isn't that another great blog with some interesting comments.  You should write it!

        SAP SUP - new, bleeding edge...  It will be interesting to see how it grows.

      • What I mean by Agile should have translated to "nimble".  In other words implementing SAP irregardless of your project methodology religion(waterfall, agile, etc) and do it with small amount of resources in a reasonable amount of time.

        I agree that at the end of the day it's the person doing work that matters and their attitude instead of focusing on where they came from in terms of tools set.  I just feel that some of these arguments were the same being preached to the ERP crowd by the "dot-com" web crowd. 

        The SUP approach which is technically ultra-nice faces some pratical issues when trying to add it to an existing landscape.  The biggest problem is that it adds more moving parts to a landscape instead of reducing the number of servers/logical components needed to do XYZ.  The web folks also had this problem with their solutions(look at early versions of Internet Sales) and isn't really a problem if you enjoy spending more and more money on hardware.

        I always think there needs to be some type of "lab"(beyond sample data demos) available for those of cheapskates(myself) that want to show value via prototype to build a bigger solution, but can't acquire the hardware needed.

        Take care,


        • Hi Stephen,
          I agree with your concern about the complexities that SUP brings.  In fact I created a demo when co-presenting with Sascha Wenninger at TechEd Las Vegas on REST, on how you can surface CRM opportunities and activities easily using a combination of BSP and RESTful services.  Everything delivered straight out of the ICM (no new servers required) with some ABAP combined with jQueryMobile.  The work only took about a week to build this.  If you want to see it, it is triggered as an embedded youtube clip at the end of this presentation (sorry, no audio, as this clip was originally created as a fallback if we couldn't perform the live demo and I was to talk to the audience with the clip).  I think this follows more of a KISS approach.