Okay - Now what? A developer pondering on how to b...

MattHarding · ‎03-08-2018

Intro

Okay, to make an awkward combined sports metaphor, the SAP Developer Skills proverbial puck that Gretzky tells us to skate to where it’s going to be, seems to have split into several pucks in recent years and all of them are bouncing along a different mini-golf hole where there are multiple “holes” that may lead to better positions for your final putt; so I thought I’d take a moment to really sit down and consider: “How do I, as a developer, ensure I remain relevant, and hopefully, in-demand from an SAP perspective in 5-10 years?”.

I mean, 3 years ago now it was pretty evident what was required as S4/HANA came along bringing UX and HANA into focus. So combined with UX Design, Design Thinking and Agile approaches, this meant Gateway, SAP Personas, Fiori/UI5 development and HANA were clearly what the next curve was all about.

Middleware integration was and continues to be still an important skill but it fees like enough of us learnt the basics, and with SOA no longer a buzz word; changes in this space (not to mention, people releasing better interfaces), made this just something you could re-learn as required when it came up.

So back to 3 years ago when S4/HANA came along; from a technical perspective only, the following was introduced to SAP developers:

A Single Page Application framework (plus obviously lots more) built and leveraged with JavaScript, and

The concept of a stateless/RESTful like solution via HANA and Gateway

Obviously lots more came along like XS Advanced development, Lumira, mobility and other techniques and tools; but the above focuses on your typical ERP developer impact.

This meant most ERP Developers were all thrown in the deep end of what many non-SAP developers had been doing for quite some time.

I would say many of us just stayed afloat, many sunk and swum back to their ABAP Stack Island, and a very small number built bridges between SAP and the non-SAP development practices and embraced the real software engineering world outside of SAP on this journey and you can see these people presenting at Conferences making you feel like like you’ve just been playing in the development space all these years.

Maybe because of this significant hurdle for SAP Developers combined with the “newness” of the tools, and learnings of Fiori; enhancing S4/HANA became an ever evolving solution since it was evident we needed consistency, stability (which JavaScript doesn’t lead itself to do), and simple (not only for end-users, but for developers too). I would say many developments and UX designs done on an on-premise S4/HANA solution 3 years ago would be thrown away and started again today if money and time were not an option.

If we look at S4/HANA on premise today, the danger I feel is that with any extension of the solution, you are either developing legacy code or you are developing Beta code; but let’s ponder the future first…

You’re a new SAP customer in 10 years time - What do you expect your new ERP landscape to look like?

Full disclosure - I cannot talk from experience implementing S4/HANA but from what I can tell talking to others, watching videos, TechEd presentations and reading about S4/HANA.

I would not want to be a CxO implementing SAP in 10 years’ time saying “Let’s install S4/HANA on premise edition and customise the heck out of it”. Even without the customising, it’s nearly a cringe worthy thing to say today without knowing why you need to be on premise (of course, today there are plenty of reasons why you would still do this and even in the future you may still need S4/HANA Cloud on premise too but not the “on prem” version).

So with that, you’ll probably have S4/HANA Cloud (automatically updated with features every 2 weeks by then) and also be looking at plenty of additional Software as a Service solutions, some may not even be from SAP! They will all integrate fairly seamlessly via your Integration PaaS since all integration platforms have become fairly standardised in a way that prebuilt “mapping, process logic & connectivity/authentication” is available from vendors so you’re not dealing with obscure integration requirements.

So with the premise that only your Operational Technology systems (hidden within OT networks) or Secret Squirrel glorified spreadsheet systems, are the only systems on premise; we then have to realise that how people build additional solutions for S4/HANA will be done on a Cloud Platform (which we will assume is the SAP Cloud Platform).

On a side note, I’d like to think with the move to SaaS suites like Office365 and Azure Active Directory, that in the future we can remove Corporate Networks for Users altogether and go with simply endpoint security and your offices simply connect to high quality Internet connections - but I digress.

A lot of work is being done by SAP to make extensions easier through CDS, Business Definition Languages (over BOPF?), Fiori Elements, etc. Even tools like the Mobile Development Kit are being built to give you as near as drag and drop style development tools that are easy to pick up to deploy mobile online and offline content to iOS and in the future, Android and potentially Windows one day.

In other words, the focus is attempting to make n% of all development, more of a configuration WYSIWYG style change that is compatible with the SaaS continual upgrade cycles. Marketing would probably say n is around 90, but I suspect a stretch target would be 70 IMO.

So this is where the Beta vs Legacy coding comes back into the conversation as all of the above is continually and rapidly changing. e.g. Using BOPF draft framework today for an enhancement is still a bit Beta in my mind and could be considered legacy once Business Definition Language (BDL) is released, but if you jump on BDL, then you’re building Beta software too until the dust settles a bit on changes there. Of course, what BDL ends up being is still guess work outside of SAP.

That said, the fact these technologies are being simplified and it feels like SAP have a fairly clear vision they are following for all of this; means writing Beta software today is probably fine and the leap to being full S4/HANA Cloud should be not nearly as painful as for those ERP customers today that will need to radically rethink how their “enhancements” will be brought across into the new world (it is an implementation of S4/HANA and not just an upgrade after all).

So what about the (100 - n)% of development remaining? For this, I ask this question...

Is Leonardo the Future of SAP Integrated Custom Solutions?

“Leonardo” is like the term “Internet of Things” to me. It’s a marketing term for the most part that surfaces to the people with the purse strings of a company what people have done, potentially in a more bespoke and expensive manner with less standardised tools and techniques, for many years now. e.g. Look at any utility for the last 20 years and IoT is what Operational Technology is mostly about (FYI - I love early IoT stories like building light sensors over a panel light in a station in order to tell you remotely whether an alarm is triggered).

So my, non-approved, extended definition of Leonardo is (without overthinking it):

Taking a customer opportunity or problem statement through Design Thinking techniques to quickly identify, prototype and prove/endorse a solution that doesn’t fit into standard SAP which can then be built out over a longer period of time, leveraging S4/HANA Cloud interface friendly approaches that leverage any capability/product within the SAP Cloud Platform such as Machine Learning, Natural Language, Predictive Analytics; Cloud Analytics, iOS SDK, etc; but doesn’t preclude it from leveraging other non-SAP tools on top of that if required (e.g. Office365, etc).

In other words, Leonardo sounds like the future S4/HANA Cloud Custom Solution Development approach of the future to me.

So if, like me, Custom Solution Development in SAP is your thing, and you want to be part of this future, how do you go about knowing what to learn? For example, we can also build Cloud applications using Server-Side ABAP, JAVA, Server Side JavaScript, HANA’s non-ABAP versions of CDS and Calculation Views exposed as OData, various services providing Machine Learning capability, Natural Language capability, Blockchain (which I still haven’t come across any problem today that I can see that being useful), etc.

I mean the problem here is there are so many options to go with here that I really hope we don’t end up with solutions that require several architects and developers to bring this all together in a supportable way.

On the subject of Server Side ABAP in the cloud, this may be a great way to bring across your old legacy/proprietary solutions into the Cloud. Similarly, as it’s still hard to get non-ABAP developers who know SAP to build solutions, it may be the best option for many customers who don’t want to grow their development team.

But hang on a second. In 10 years time; maybe SAP will build a multi-language (JAVA, C#, Swift, Scratch 😉 ) version of the “ABAP” tooling for enhancing S4/HANA Cloud? Hmm - Now new customers have a choice to get developers who don’t know ABAP at all. Scary thought and what about my ABAP skills???

Today we have a strong community of SAP ABAP’ers, which may make SAP rethink their forward position here; but in 10 years time, if due to lack of exposure to the rest of the software industry, we’re still writing ABAP without automated unit testing with mock data (as one example of devops); then SAP will probably be doomed with the rate of change now in the software industry, so I don’t see that as the future (though it could be easily debated that SAP themselves will develop this way so maybe this is simply an issue for customers).

But how this progresses is definitely the crystal ball part. My predictions (focusing on ERP) to help work out where we heading are:

S4/HANA on premise will become common at customers by 2020 (e.g. You don’t want to be that customer still running R3 by 2021)

By 2020, SAP will get their S4/HANA Cloud programming model stable enough for mere mortals to confidently build relatively complex long lasting n% solutions that don’t become legacy

In addition, it will also be when customers start to realise that new custom solutions need to be built in a SaaS friendly way and then PaaS will become the next battleground by vendors; especially if interfacing becomes less of a proprietary aspect by 2020.

2020 is also the year the server side “language” wars will begin for real.

2021 - People will start to feel comfortable talking to their computers in the office with Natural Language taking off and noise cancellation headphones will feature strongly when people are next to that loud guy.

S4/HANA Cloud by 2022 will then be the go-to upgrade/migration due to people realising that upgrades are costing them a fortune compared to company X who keeps coming to conferences and telling me how easy it is to be on the S4/HANA Cloud.

As part of this, SAP will need to continue to be strong, to keep ahead of other SaaS offerings as there is a real danger of these “migrations” becoming software selections.

And hopefully, by 2028:
- SAPUI5 3.42 will be the last stable release as everyone will be happy to upgrade fortnightly to innovation releases hence just pointing at sapui5opensource.com. The original SAPUI5 team will also tour the world and be treated like rock stars wherever they go since Google adopted their framework to build all future Google web apps.
- Design thinking techniques will be standard practice where developers and real end users come together with designers to solve their unique problems right the first time (preferably much sooner).

So with the myriad of some serious, and some less serious thoughts above, all I can think is I need to do the following as a start point for the next year at least:

Keep taking all open.sap.com courses on Cloud and UX content - filtering out the marketing courses which occasionally try to hide themselves in there!

Similarly, look beyond SAP for good courses (plan is to start this one next - https://developers.google.com/machine-learning/crash-course/)

Learn how to train a machine learning model and use it to solve a real problem.

Get a data scientist to explain to me how I know when to use a predicative library and go back to my University maths days to even understand the various equations.

Play with Google’s Natural Language Processing interface (surely this one will win out in the end as an SAP CP Service with a Google partnership at some point, as it rocks)

Monitor what’s happening with Integration PaaS and slap companies who keep doing weird non-standard interface designs, especially ones with strange Window’s dependencies or similar.

Try introduce a whole devops approach to the build of a solution at a very nice customer who lets me do this (e.g. Still a challenge when dealing with SAP data and no idea if ABAP mock testing fits into an S4/HANA Cloud solution for real repeatable testing in the future)

Keep an eye on Cloud Analytics understanding how this capability can be embedded into future solutions

Keep following the unofficial twitter account which tweets all posts from blogs.sap.com and experience.sap.com https://twitter.com/sapCommBlogs to see what the community posts

Keep attending meet-ups and conferences to hear from SAP and customers about the S4 and Cloud journey

That’s my brain dump for now; but interested in where you see this whole Cloud thing going, especially if you have worked on both S4/HANA on premise and in the cloud. It’s definitely a big hurdle for an SAP customer to go S4/HANA cloud but I’m sure we’ll all end up there one day and that world is going to be so different to what we know today; so let’s all attempt to prepare ourselves as a community.