SAP Highlander
Background
This blog post started off as a comment reply to the very brilliant blog posted by John Moy – 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. 😉
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… 😉
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 🙂 ) ?
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 😉 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.
Sounds right up my street geographically 🙂
You forgot to copyright it 🙂
As you say, SAP taking an open standard and "improving" it has been a frustrating thing that they continue to do. Yet they also go and do great things like create Gateway, with an odata stream, offering JSON or whatever other odata format you wish to use. Want to use Drupal as a frontend to SAP, no problem, SharePoint, yup, can do that too now.
Thankfully they have also relaxed the Gateway licensing agreements (note you may have to have an argument with your account manager on this) which means that if you have the backend license for a user to access the data you're accessing via gateway, then that is included in that.
However, I feel that they are still confusing things, particularly with the launch of Fiori. HTML5 / SAPUI5 as a mobile frontend - yes great, but they seem to of only released them as SAPUI5 apps and not turned them into mobile apps. More importantly, they have further confused the water with where you use SUP / SMP, suggesting that you never need them, but in reality, as soon as you want to get clever and use offline scenarios, that is when you do need SMP.
Gateway is one of the really positive moves by SAP in recent times in my opinion. As you mention Paul, it is a massive enabler for a better user experience. Relaxing the licensing arrangements is probably the final thing needed to ensure it becomes the de-facto standard too, and again is a big positive step by SAP.
The really important thing for me is the naming of the product - for once SAP have delivered something that does just what it says on the tin. "Gateway" is almost as vague and specific at the same time as "Cloud" is 😉
With respect to Fiori, whenever SAP launch something like this I can't help thinking it is just bait, a shot of the art of the possible to get customers and SI's interested and excited. That is no bad thing, until licensing then gets in the way.
The offline challenges with mobility are something for a further blog I think (but don't hold your breath, it's taken me how many years to do this one?!)
Hi Gareth,
Really great to see you jump into the SCN blogosphere. It's always refreshing to hear new voices, thoughts and opinions.
I must say ... I found this to be one of the most entertaining and hilarious blogs I've read in a while. Keep blogging. And as I always tell people ... the first blog is always the hardest.
Oh, and thanks for the mention.
Cheers
John
Thanks for the positive feedback John - the first one really was the hardest. I'm glad you found it to be a bit light-hearted as it was definitely meant that way!
Hi Gareth,
Great blog post, especially had to laugh at:
In all fairness though, I think we're moving in the right direction. SAPUI5 (being JS) already is more open than WDJ ever has been, and the opening up of all of SAP's business functionality via OData (be it not only via Gateway) is also a big step forward.
Add to that the different development tools converging to Eclipse+ (I know, we're not there yet), and I think the situation is not really that bad at the moment, and I'm positive it'll get better in a year or two.
Can you wait that long? 🙂
Cheers, Fred
I second favoring that quote 🙂
It's a really good blog, very true, recognizable and entertaining.
In my opinion though, that highlander framework (there can be only one) is already there. You business logic goes into BAPI's. simple as that.
If you want to build the application with SAPUI5, fine. Activate REST services on your bapi via gateway an build your frontend.
If you want a webdynpro application, fine. Call the BAPI from your assistance class, put the data in a context and build your webdynpro application.
On mobile? cool, create an MBO on your bapi and build your mobile app.
But you want it all in one IDE? hmm, okay, use eclipse... Although I don't mind switching between SE80, Eclipse and Visual studio. It's not as if I expect microsoft to get rid of .Net in favour of ABAP either.
Don't get me wrong though. I actually agree with what you say. I'm just playing the devil's advocate for a second to give a different perspective on things.
Cheers, and keep up the blogging!
Big plus 1 on don't expect a single ide. <sigh> #androidstudio
I think at a high level you're right Tom, Highlander is more or less there. I guess lots of my pain is down in the detail, the day to day stuff that frustrates and causes headaches for me as a busy developer trying to get customer solutions built and working.
In actual fact, I wasn't too far away from my Highlander nirvana on a recent customer project delivering CE BPM solutions - we had CE, PI and ABAP services all curated via Service Registry, with the only work outside of NWDS being ABAP. If we'd had ABAP in Eclipse we would have been there!
However if we had needed to use Gateway, or deliver some mobile solutions this model would quickly have fallen down.
Maybe it is the last 10% of the environment that is missing but as we all know, this will no doubt be the hardest to deliver.
Well, I do have some good news for you.
As from NetWeaver 7.4 Webdynpro for ABAP will be integrated into Eclipse as well, and as I understand it, SAP's strategy is to move all developments into eclipse and no longer extend SE80.
In my interpretation, Gateway would also fall under this scenario.
HANA is already in eclipse
SAPUI5, ditto
So the shift has begun a long time ago, but now it's picking up momentum.
Couple more years? Who knows?
Totally agree we are on the right track Fred. My comment about Gateway really was tongue in cheek. I can't help thinking Gateway is the real game-changer in SAP tech of late, although maybe not for all of the very clever technical reasons HANA has been. It really feels like a step-change in SAP's attitude to opening up their systems and making it easier than ever before for developers (both SAP and non-SAP) to get building solutions.
I'm hoping it is the foundation for more consistency and stability in the longer term but we'll see how that pans out...
Funny think is the simpler solutions (and the ones with the better licensing) are the ones which survive. SOAP adapter, with all its limitation, and done a lot for SAP openness, and I'm glad to be able to migrate to Gateway now that they have come to their senses with named users.
Until SAP stops changing the roadmap at every second, I'm not investing one more second in SUP/SMP.
I enjoyed this, despite understanding only 7% of the details but 87% of the sentiment. Keep poking and prodding; this is good perspective that may help to direct improvement; thanks for sharing.
M.
I enjoyed writing it Mark, despite only understanding 7% of the details too 😉
Thanks for the feedback. 🙂
Hi Gareth,
nice work on the first blog! Sounds like you really cranked this one out quickly as John's original hadn't been up for even half a day yet!
Although I can sympathise, I don't think we'll ever see radical simplification in the stack. I don't think anyone will disagree with the basic pattern of front end/API/backend in the Highlander Stack. But there are simply too many use cases with too many constraints/priorities to make *one* solution feasible or even a good idea.
Yes, Gateway might be fine for most UI use cases where you want to drive a HTML client from the backend. It'll even work for most mobile clients without (gasp) SMP. But then there are those use cases which are simply outside the product. Say you want to serve up PDFs? Or images? Or Excel files generated via ABAP2XSLX? And that's assuming a REST paradigm makes sense. Because sometimes it doesn't and you're better off with messaging, or SOAP, or FTP. But never shared databases. Unless it's HANA of course 😛
I'm told that once upon a time there were strange creatures like AppleTalk, token ring, and networking over coax cables. Eventually Ethernet won and now is the main standard. But it's a long way down the OSI stack and a lot of other very useful things have been layered on top of it over the years.
We're not there yet I think. We're still at the top of the stack - where it's getting wider - still discovering new use cases, and approaches. That consolidation hasn't happened yet, nor do I know what future use cases could come over the top of where we are today and force this consolidation.
And even in the lower reaches of the stack there isn't one player. Besides Ethernet there's Fiber Channel and a raft of wireless protocols. Besides TCP there's UDP. And so on.
So yes, SAP should try to deprecate some stuff and not offer 24 bloody UI frameworks. Maybe 5. That ought to be enough for anybody 😉
If you got all the way here, sorry this turned into a bit of a rant. My excuse: it's past midnight. But thank you very much for the blog!
Sascha
Stop doing such awesome comments and go to bed, you're making the rest of us look lame 😉
😛
I think you've hit the nail on the head Sascha -
"So yes, SAP should try to deprecate some stuff and not offer 24 bloody UI frameworks. Maybe 5. That ought to be enough for anybody ;-)"
We can dream...
Great first blog! 🙂
Think your vision is pretty close to SAPs. So don't give up hope. Bit do learn as much ECMAscript as you can. 😉
Fantastic first blog. I can almost sense the frustration as you were typing and I do share your pain. I know my children's children will be working on SAP Highlander one day and I will refer them to this blog.
Talk about making an entrance - that's the way to write a first blog:-)
One thing always strikes me about the effect you describe. I see lots of developers/consultants who aren't particularly bothered by it. I assume they work on enough projects that it is worth investing time to learn a new technology because they'll get use from it even if it only lasts a short time. Plus learning new stuff is fun - that I can certainly agree with!
As a customer, though, I need a bit more of a guaranteed lifetime for a technology before I get enough use from it to justify investing in the infrastructure to support it and the time to learn it. Having stuff change every few years means just as I'm getting around to using something, it becomes obsolete and the next shiny new thing appears.
I do understand stuff is just changing very quickly and SAP need to keep up, but I'd love there to be a way to not have to learn a new technology every 5 minutes.
Thanks for the comments Steve. It's especially interesting for me to get a "customer's perspective" on this topic and the implications and hence I've not responded straight away whilst I mull over my thoughts...
I could (and probably should!) write a whole series of blogs on customer expectations of SAP consultants versus the constantly changing technical requirements. Maybe that could be my follow up to this blog...
As you say, learning new technology is indeed fun but it is very challenging, in tight economic times, to get the balance between on the job learning, self-development and official training with the ultimate commercial payoff from engaging with a customer who wants the technology implemented. Especially when the technology is redundant before you are fully conversant with it!
It is even worse if that technology is then replaced/changed every 6 months as the customer then just gets frustrated, loses confidence and potentially ends up sticking with the tech they already have. I think your final point about technology changing every 5 minutes is a foundation point of my cries for SAP Highlander...
I'm beginning to ramble and feel another blog posting coming on instead. Watch this space (but don't hold your breath as I take ages to get round to this sort of thing!)
Gareth.
STELLAR first blog post, Gareth. Can't wait to read more from you. Kudos for a fantastic post, and not only do you write well, you also seem to have a huge bandwidth of SAP experience to write about. Keep sharing. 🙂
Thanks very much for the positive feedback Thorsten - hopefully future blog posts will be of a similar standard but I can't promise anything 😉
I can feel your pain! 🙂