SAP Highlander

[Former Member]

Background

This blog post started off as a comment reply to the very brilliant blog posted by john.moy3 - What SAPUI5 and Fiori tells us about the future of UI development skills - but as usual with my comments it quickly became long, rambling (a little boring?) and marginally ranty so I thought I’d give in and finally complete my first blog posting on SCN…  (As an aside, I’ve been threatening to blog on SCN for years & years and just never got round to it – customer work and life in general always get in the way.  I think I've made up for it here, in quantity if not quality!)

Following John’s posting, there was a short twitter conversation around the subject but I couldn’t do justice to my thoughts with only 140 characters at a time!

As mentioned on twitter, I completely agree with all of John’s comments and have been having many similar conversations recently with my colleagues and my manager.  I'm keen to encourage some of our ABAP experts to expand their skillset into Gateway at a minimum, as this in my opinion (and many more learned SAP people) is going to be a big part of the technology stack moving forward.  As it is an extension to the ABAP stack, I don't believe this is a massive leap either, which is a bonus.

More interesting is the change in UI tech (again!)  The big challenge for me is that SAP don't seem able to stick to a long term solution in this area (much the same as the rest of the IT industry) but do insist on inventing their own mechanisms, standards & frameworks for UI development time after time.

My UI History.

I started ~14 years ago as an ABAP developer and since then I've:

• As a noob, got outwitted by PAI and PBO modules, pf-status’ and related entities, and been thankful that I could move into more web based UI design, and stick to only building business logic in ABAP!
• Hated working with ITS which made no sense, was horrible to design & build with and delivered poor results.
• Got frustrated with the Portal API and its limitations, and how there was no real development environment with nice wizards and stuff 
• Grown to really like Web Dynpro Java, the development environment and most importantly, the power it gives me when combined with CAF, BPM & BRM, and more recently PI all wrapped up as PO.
• Grown to be really frustrated that Web Dynpro Java still delivers dull old grey & blue screens.
• Lost hours to frustration & anger working with Java Struts whilst implementing CRM Internet Sales 4.0 and the old Java based IPC.
• Enjoyed wrapping CE CAF delivered services in jQuery and SUP Hybrid web containers, and the quality UI experience this can deliver.
• Instantly got frustrated that Agentry appears to be displacing SUP and my skillset is out of date before I’ve even got my head around it.
• Got frustrated that every time I complete a Sybase mobile training course, SAP shift the goal posts and change the tech and roadmap (who knows how customers must feel?)
• Wondered why SAP had to invent HTMLB - what was wrong with HTML?!
• Wondered why SAP had to invent BSP - what was wrong with JSP, ASP, etc.?!
• Wondered why SAP had to invent SAPUI5 - what is wrong with pure HTML5?!

I'm sure if I was more awake (our 7 week old son isn't helping on that front!) I'd be able to remember other great UI odysseys of my SAP career...  I don’t even like talking about Visual Composer as it triggers night terrors.

The Point?

The key point is I've had to constantly learn and change my skillset, bouncing from ABAP, to HTML, to Java, to JavaScript, etc. which is great as I am motivated by and enjoy learning new technologies.  However, all of this makes it almost impossible to put longer term UI roadmaps in place with customers.  I'm currently losing the will to live with the constant changes to the SAP Mobile Platform.

I won’t even talk about the time and effort needed to keep up to date with all of the constantly changing SAP technologies – I’d love to know how some prolific bloggers in the SAP sphere manage to get any “real” work done to earn their livings. :wink:

The constantly shifting technology requirements are bad enough but it is SAP’s constant commitment to seemingly re-invent every wheel they can find and somehow get an SAP badge on it that is becoming my biggest bug-bear.

Boxy but Safe

At TechEd a couple of years ago, my colleagues and I were pleasantly surprised by the NW 7.3 news that SAP would be opening up to more industry standard UI technologies, such as HTML5, jQuery, JSP, JSF, etc.  We saw this as a big step forward enabling customers to deploy qualified UI specialists to work alongside SAP business logic specialists to deliver truly feature rich solutions that were finally no longer grey and blue.  It really could all become about the user-experience.

I’ve always likened SAP’s traditional grey and blue UI theme to Dudley Moore’s character in the film Crazy People, commenting on a certain Swedish car maker’s approach to design - Crazy People

It was disappointing to hear ABAP Web Dynpro would become the de facto UI technology and Java Web Dynpro would no longer be developed but we all agreed opening the platform up to “industry standard” UI technology more than made up for it.  And of course, we knew this situation wouldn’t last forever… :wink:

Highlander

This (eventually) leads me on to my main point, and it strays away slightly from John’s original thoughts about SAP Developer skillsets changing although is highly related in my eyes…  I’d love to see some rationalisation of technologies from SAP.  The development workflow, architectural decisions and day to day tasks moving away from the current spiders nest of technologies, layers, stacks and standards.

Why can’t we have a single, integrated service/resource/integration layer (this started off as a SOA layer but I was reminded not everyone is happy with that approach - SOA #fail :smile: ) ?

A development environment that “does it all” and supports a one true integration layer (currently Gateway but I’ve taken an hour or so to write this blog so it may have changed) to enable all UI channels.  I’m going to give this nirvana development environment the codename “Highlander” for hopefully obvious reasons - Highlander

As an SAP development architect with ranging skills and responsibilities, it pains me that I can’t use one environment for development of ALL solutions.  I can use NWDS for many tasks now, which is a big stepforward but I won’t be happy until I can do EVERYTHING – ABAP, Web Dynpro, BPM, PI, Gateway, Mobile, Responsive UI, HANA, etc. – in a consistent, feature-rich environment.  It doesn’t have to be NWDS, I still love SE80 for instance.  Or start again from scratch, I kind of don’t care.

Why do I have to consciously think about the varying layers needed to expose a piece of business logic via mobile, or via the Portal, or via a traditional Dynpro?  Why should I need to worry in a different way if I want my data to be available off-line in a mobile application?

Why can’t I simply focus on pure business logic functions* and then chuck whatever UI channel I want on top, all from within the same environment with common, standardised development workflows, wizards and tools?  Completely decoupling the logic from the UI and not suffering imposed constraints from one to the other.

*I wanted to write SOA services here but dj.adams might lynch me :wink:   Joking aside, as a business logic developer, why should I need to sweat over whether my function will be available via SOAP, RFC, REST, oData or whatever other combination of integration protocol(s)?  I really shouldn’t need to worry about that detail.  And as a UI developer, why should I care how much pain my colleague has had to make his logical units of work cope with concurrent users?!

I really shouldn’t need to think “this function is going to be consumed by a mobile application so needs to be built using method A” or “this is a function for a SAPUI5 application so needs to be built using method B” etc…

The Highlander Stack

I’m conscious this is a particularly dull blog, with too much text and not enough images, so here’s my vision of the SAP Highlander Development environment.  It’s pretty simple:

I’m not asking for too much am I?  (And yes I know I've over-simplified lots, made sweeping statements and assumptions and generally ridden rough-shod over lots of stuff but my important question still stands - why is it all so complicated?!)

Elephant in the Room

I’ve deliberately not mentioned much at all about SAP licensing strategy in this post – many people with a much better understanding of the process have done this to death already.  What I will say is that SAP seem hell-bent on producing clever technology solutions, then licensing those solutions out of the grasp of many typical SAP customers.