Personal Insights
Nellie the ABAP Elephant
To Bombay
A Change Control Circus came
They brought an ABAP elephant
And Nellie was her name
One dark night
She slipped her legacy chain, and off she ran
To H. Island; bugs were never seen again
Nellie#1
Table of Contents
1 – The World in General
2 – The ABAP World
3 – My World
Part One: The World in General: There’s an ABAP Elephant in the Room
As you may have noticed this year there has some sort of virus going around. Put another way probably the greatest global disaster since the second world war, and in 98% of countries it is getting worse every day.
What is notable about the human race however is the way it responds to disasters. You have no doubt heard the saying “necessity is the mother of invention” and in times of crisis often the pace of technological innovation goes up through the roof.
Two examples I can think of are the fact that by the end of the year one in seven cars in the EU will be electric in some form, and the almost weekly launches of radical new spacecraft. I cannot predict when and if electric cars will ever become the mainstream but if they do it won’t be because of drivers caring about the environment (nice as that would be) but rather because the technologically has advanced to the stage where such a car is (a) cheaper than a traditional car, (b) can go further than a traditional car before having to refuel and (c) takes less time to refuel than filling up a traditional car. To state the obvious you would not normally replace something you own with a product that was in any way worse than what you already had. However if the proposed replacement was better in every single way then you would be crazy not to replace your current (whatever it is) when it runs out with the better cheaper one.
With electric cars we have not got to that stage yet – many say that to get to that stage might be impossible, especially the rapid charging bit, this is a very emotive subject, but if it does happen (to state the obvious again) it will be because of rapid advances in technology.
In the same way, in information technology world the fact that the actual world is getting turned upside down by the plague has forced companies to bring forward IT projects they were sort of thinking about possibly doing in five years’ time to having to implement them right here and now in record time.
The analogy would be – at government level rather than company level – the disaster that was the second world war turning two things from dreams to reality – computers (Bletchley Park in the UK) and space travel (Werner Von Braun in Germany).
Because that sort of innovation is now happening across the board when (if) this crisis ends a lot of companies will have found themselves having moved forward five to ten years IT wise in only a one to two-year period. In other words the surviving companies will bounce back stronger than before.
Where I work (in the building materials industry) IT technology has always advanced very quickly but if I think about what has happened/will happen this year it is amazing, even by our standards.
What has been replaced/upgraded/introduced: –
Replacement of BW moving to BW4HANA
Replacement of the Expenses System (not with Concur!)
Replacement of the Optical Character Recognition system
Replacement of Office => Office 365
Replacement of video conferences to that took 70 minutes to get working in order to have a one-hour meeting with TEAMS Meetings. I now know what all the bedrooms of my co-workers look like. If I had said that even a few years ago you would have drawn a very different conclusion.
Introduction of Robotic Process Automation (not the SAP one!)
That is all I can think of off the top of my head. I am sure there is a lot more, possibly dozens of other things. The point is we are going gangbusters fast forward into the future and no doubt so are hundreds of companies all around the globe.
That is fantastic is it not? So what is the ABAP elephant in the room? I cannot help but notice that whilst all this high-tech bright future stuff is going on a bucket load of the core Z programs that are used by SAP customers all around the world – to run the most vital parts of their business – are still the same way to this day that they were written in the year 2000, all procedural DYNPRO monsters with all the business logic mixed with UI logic. They are written in what is known as “legacy code” and every day more legacy code is being written/added to all these SAP systems.
This brings us to part two – why would this vital code be classed as “Legacy Code” and why is it a problem?
oooooooooooooooooo…
oooooooooooooooooo…
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the Jungle
Off she rode with a Trumpety Trump
Donald Trump
Nellie#2
Night by night, she did all her tests by hand
When Nellie was leading the big parade she looked
So proud and grand
No more Citrix for Nellie to PERFORM
They taught her how to do workflow and she took
The crowd by storm
Part Two: The ABAP World: There is an ABAP Elephant Under my Bed
“Here it comes – prepare for the worst! The Ugliest Code in the Universe!” – Elephant! (1989)
According to IT guru Michael Feathers the definition of “Legacy Code” is code without automated tests. In SAP world the framework for running automated tests is ABAP Unit. How much of your ABAP code has automated unit tests you can run at the press of a button after making every change? If the answer is “none at all” then you would be far from alone.
Why does this matter? Why waste your time writing automated unit tests to change your current “legacy” code into so called “real” code?
The answer is all to do with the pace of change. The speed of change was accelerating every year anyway – the current crisis just put the foot on the accelerator pedal. I saw a presentation the other day that noted that over the years the ideology of IT departments had moved from “never change a working system” to “make as many changes as you can as often as you can”. The idea being that you need to do the latter in order to stay competitive.
Let us say something changes in the market – it does not matter what. The CEO informs IT and says “The XYZ has changed, it is vital you change the following six areas of the SAP system in order for us to be able to respond to this XYZ change otherwise we will lose market share. Please make this a priority and have the changes working in production ASAP”.
What the CEO expects based on experience is that those changes will go to production in the next release – maybe in two months’ time, possibly a lot longer. What the CEO wants is for those changes to go to production tomorrow, or preferably by lunchtime today, in any event faster than the competition can make those changes. So ten seconds time would be good.
So – why I can’t just make a change to my program that takes me an hour and then press a button and send it to production straight away? Well first off my change might not work, and secondly my current change might break something else. It would be irresponsible to send something to production that may not work and/or may cause serious damage elsewhere, so the traditional solution has been a very large number of people spending a very large amount of time doing manual testing.
The problem is that changing area A of a program often breaks area B or area C all the way down to area Z and you just do not know what is going to break. Moreover systems have become so complicated it is just unfeasible to manually test every possible eventuality. As someone I asked about testing once put it “Your average car has hundreds of components in its engine. When we build a new “car” all that seems to be tested is the radio”.
Automated unit tests – as in ABAP unit – can never replace manual testing but they can certainly remove a lot of the “grunt work” and find low level bugs before the code leaves the development system. As Robert Martin puts it “QA should find nothing!”.
Amazon makes much of the fact that they put a change into production on average several times a second. Based on your experience of SAP systems you would therefore expect that their live system would be broken 100% of the time – but as you know it is not. If you went to buy something on Amazon and the platform malfunctioned you would be very surprised indeed – and yet if your SAP end users found a serious bug in production suddenly started happening after the quarterly release they would be really annoyed but not surprised in the least.
The question then becomes how can they (Amazon) be so sure their constant stream of changes will not break their live system? A ten-minute outage would probably cost them a million dollars. Automated unit tests are not the only reason they can make such a vast number of changes, but they do play a vital role.
With SAP maybe we do not have such lofty goals – instead of several changes a second to production maybe we can hope to move from three releases a year to six? Is one release a week a ridiculous thing to aim for?
As the very first step on that road it would be great if you had an automated test for every aspect (low level programming unit) of your vital ABAP programs, so you know if any of them break after a change to a seemingly unrelated area. Now comes the major stumbling block – 99.9% of your legacy code is written in such a way that it is totally untestable, because business logic is mixed with UI logic and database logic and all sorts of things.
To make the code testable you would have to change it, and that (changing code that currently works 100% correctly) is a horrible, horrible risk, and risks are what we are trying to avoid.
So it would seem that the only way you can reduce the risk of program changes breaking your system in the future is by making lots of “un-needed” changes (to make the code testable) now which may break the system.
That is a very difficult business case to make i.e. I would like to make some changes that will have no immediate benefit and will possibly break the live system, in order to prevent some unspecified future problems which may or may not occur. If you put it like that, your chances are not high of getting approval.
This seems like a “you can’t get there from here” problem. The risks involved in reducing risks are just far too high. So how do you square that circle? That brings us to part three.
oooooooooooooooooo…
oooooooooooooooooo…
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
Nellie#3
Code Cleaning Device
Part Three: My World: How can you tell if an ABAP Elephant has been in your fridge?
“Giant Footprints in the Butter!”
Just prior to the last burst of singing we were considering how to move from “Legacy Code” to a situation where all the code has automated tests – all without blowing up the entire universe in the process.
As it transpires this is exactly the sort of thing I have been working on in my day job for the last year or two. Right at the start of this blog you may have noticed in the introductory song that Nellie had ran away to “H. Island”. What is that you might ask? Why would an ABAP Elephant want to go to such a place?
“H. Island” stands for “Happiness Island”. The idea came from the Open SAP Course on Test Driven Development and revolves around adding all new code to old Z programs (or extracting any routine you need to change) into a new class which is developed via TDD and thus has 100% of its code subject to automated unit tests. You add in calls to the new happy code from your existing sad legacy code just like you were adding a new function module call, thus not having the risk of a major re-write of your existing code.
The idea is that as time goes by the Island gets bigger and the Mainland (huge legacy code program) gets smaller but the end user does not notice anything except that the time between asking for something new and getting something new decreases.
Was this some sort of esoteric academic new theory? Possibly yes. Have I been doing it in real life? Yes I have. Does it work? Yes it does. Therefore it has been proven (by me and hopefully by lots of other people) that it is possible to make your vital Z programs better with every change as opposed to worse. What I mean by the latter is traditionally with every change you make to the program not only might that new change break something but even after it works the fact that the program is now more complex has increased the risk of every subsequent change breaking it i.e. it gets more fragile with time. This can be turned upon its head.
Naturally that is easier said than done – what you would ideally like is some sort of detailed step by step guide on how precisely to go about this exercise, rather than having to work it out yourself by trial and error
I have been blogging about this sort of thing on SCN (I still call it SCN, I do not hold with the SAP concept of renaming every single thing every single week) for many years. As a starting point you really need to program using OO. If you don’t know what that stands for then, oh dear. The OO version of ABAP was introduced in 2000 but even now many ABAP programmers cannot see the need/purpose.
I tried to approach the subject with an open mind and only after a vast amount of experiments -which I documented via SCN blogs – did I conclude that OO is the way to go. I concluded it is a good thing in and of itself (not just become someone said so but from real life experience).
For example
https://blogs.sap.com/2012/10/27/crossing-the-great-divide-procedural-vs-oo-abap-programming/
If OO is the starting point there is a next level. If it is true (and sadly it is) that even after 20 years hardly anyone writes in an OO manner in ABAP then of that small percentage only a small fraction of that small fraction use automated unit tests. Thus I have blogged about that as well.
For example
https://blogs.sap.com/2018/04/21/sap-open-course-unit-testing-week-6-working-with-existing-code/
Both sets of blogs are – in effect – all about getting Nellie the ABAP Elephant away from the Legacy Circus and onto Happiness Island.
Whilst we are on the subject of SCN blogs, you won’t have seen very many blogs from me on SCN this year, but just as work has gotten loony busy this year, so has the amount of SAP things I have been doing in my spare time have exploded just as exponentially as the worky SAP things have.
- In February 2020 I published an e-learning course all about Test Driven Development on a platform called “Michael Management”.
- I was due to give three presentations in the “Mastering SAP Technologies” event in South Africa in March 2020.The in-person event was cancelled at the last minute due to virus concerns, but the conference ended up happening virtually – so I gave two speeches just last week.
- In April 2020 there was the fantastic virtual event “SAP Online Track” which ran for 24 hours and was sort of like an SAP “Live Aid” event in that it raised money for a charity “Girls Who Code”. I was very happy to be able to do a presentation during that event.
- In May 2020 I had a so called “E-Bite” published by SAP Press which was all about how to migrate custom code to S/4HANA – https://www.youtube.com/watch?v=ebbTDNuJf8A&feature=youtu.be
- Ever since June 2020 I have been writing a book all about increasingly the quality of ABAP code, incorporating some parts/concepts from the SCN blogs I have written over the years, but mainly using a bucket load of actual examples I have encountered in real life over the years. This is the opposite of “ABAP to the Future” in that it is focused on code written in the past. This has been really brutal, it has been like having to write two or three blogs a week, every week.
- In September 2020 I did a live Q&A about all things ABAP for the Michael Management company – https://www.youtube.com/watch?v=EyvEKww2kXk
- This month – October 2020 – on the 21st of October 2020 – I have another SAP Press E-Bite coming out; this time called “Refactoring Legacy Code” – link at the end of the blog -which is based on what I have been doing in real life recently in this regard i.e. what I just talked about in the third section of this blog. The book is a step by step guide how to change a monstrous legacy ABAP program into a modern OO program with automated tests in a safe manner using the “Island of Happiness” approach.
So, as you will have just gathered, this whole blog is in fact just a plug for my new book! Ha Ha Ha! A-Ha Ha Ha! HA HA HA HA HA!
Nellie#4
Once upon a time that would not have been allowed to publish such a shameless plug on the SCN site… but now the moderators tell me I can plug whatever I want. That makes me want to sing – SING – SING!
oooooooooooooooooo…
oooooooooooooooooo…
BANG! BANG! BANG! BANG!
Nellie the elephant packed her trunk and
Said goodbye to the circus
Off she rode with a Trumpety Trump
Donald Trump
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Donald Trump
The head of the herd was fed up – Leg, Legacy
So they meet one night in Microsoft Silverlight
On the road to TDD
Nellie the elephant packed her trunk
And tumbled off to the jungle
Off she rode with a Trumpety Trump
Trump! TRUMP! TRUMP!
1956 Version
https://www.youtube.com/watch?v=28Rh9zRdXxA
1984 Version
https://www.youtube.com/watch?v=9m7tPikH0UA
Plug
Coupon code – RLAC10
The coupon code provides customers with a 10% discount when they purchase the E-Bite from the SAP PRESS site.
Cheersy Cheers
Paul
Nice ?
SAP has tried to introduce too many things all at once.
Developers are not able to grasp everything at once hence in order to save time and effort they are sticking to what they already know. In a practical project, there is very limited timeline to complete the development. Hence many developers hesitate to adapt new methods of development.
Introducing so many new things without proper documentation and tutorial would make it even impossible to adapt the new technology in the upcoming years also.
Hello!
I know it can be almost impossible to "swallow" loads of new concepts if they keep coming at you every thirty seconds like a tennis ball machine.
In this blog I am talking about two concepts - object-oriented programming (which is still new to a lot of people) and test driven development/abap unit (which is still new to a lot of people). Are you referring to either of those or making a more general comment?
To be fair to SAP they do have free open courses which are very detailed indeed on new concepts. For example in 2018 there was a really good one on TDD and right now there is one running about the "ABAP Restful Programming Application Model".
https://open.sap.com/courses/cp13
Cheersy Cheers
Paul
I totally agree that there is a lot to try to learn. (above and beyond oo and test) I've been trying to take it one small piece at a time.
And that's the way to do it! (To be punchy).
Step by step. Make sure every program you change is better after the change than before. One thing I've started doing is every time I see something like this:
I at least change it to:
or even
But OO and TDD are well served with documentation and tutorials, so really, there's no excuse if someone chooses to improve. I learned Java just so I could ABAP-OO properly. (Back in 2005, there weren't any larn-yerself-ABAP-OO books (that I could get to grips with) - so I learned OO techniques through Head First Java from the O'Reilly Press, in which I do not own any shares).
I think SAP’s strategy in terms of the BO move and then the BW on any DB (7.5) to BW4HANA and other moves has caused lot of tech debt at the customers end and it even provides a panacea to that by selling cloud solutions where the release to the software is probably daily as Paul sir suggested.
Fun blog. Liked the style.
Traditionally ERPs are monolithic. It would be interesting to see how this goes from here, given that everything nowadays is cloud native, with micro services, CI/CD etc..
Netflix has a system in place to randomly bring down some of it's production servers just to be sure that their code is resilient enough to ensure seemless customer experience even some parts of the code goes missing.
It's interesting to note that some new age ERPs are starting with a clean slate. For example Tekion offers a Cloud native and mico service based ERP solution to automotive industry.
Enjoyable piece of writing...And true to the bone also.
How do you think the present situation and the ABAPers mindset has influenced (in a bad way ) the going forward of the FIORI ecosystem?
A lot of die-hard ABAP programmers would (and do) say that traditional DYNPRO programs and ALV lists give everyone what they want, why bother with anything else?
I have seen first hand how a chief engineer at one plant in our company reacted when they saw an SAP plant maintenance GUI screen (for the very first time) and then thirty seconds later a FIORI app (for the very first time) that did the same thing with about 2% of the fields. I think you can guess which one got the big thumbs up and which one made them physically sick.
More importantly what holds a lot of ABAP people back with UI5 is that the prospect of having to learn JavaScript scares them. Why? At one point they did not know ABAP and they managed to learn that. Some people advocate learning one new programming language a year just to stop your brain from atrophying!
Very good article. I’m always craving for your next post.
About people resistance with new languages such as UI5, the vast majority of ABAP consultants that I know have more than 6/7 years of experience in ABAP. From the career point of view it’s hard to learn a new technology like UI5/Fiori, one moment you are a Senior ABAP Consultant and in the next moment you are a SAP UI5/Fiori “trainee” with a strong SAP ABAP Background.
I started developing Fiori Apps this year, and it’s not easy to make the switch. It takes time do adapt to new tools, especially when you are used to the good old SAP Tcodes.
SAP also doesn’t make things any better to motivate the ones that want to do the switch. I started with webide and now I will have to use the new Business Application Studio.
I would just like to stress once again the key point about UI5 and the resistance to learn JavaScript.
At one point I had been programming in ABAP for ten years and it looked like our company was going to switch from SAP to Oracle. It didn't happen but even if it had I would have stayed - I have no idea wat language the Oracle ERP system uses for custom programs and I didn't care. Whatever it was I would have learned it in no time at all. It might have been one I knew already.
Is it hard to learn a new programming language? It shouldn't be. For me personally I found the learning curve for JavaScript a lot easier than the learning curve for Wey Dynpro. Because JavaScript is a generic programming language and Web Dynpro was a proprietary SAP specific thing.
And even if for some reason you had a total mental block about knowing more than one programing language (which I am sure no-one has) then SAP has tools to auto generate all the code for you. But it is so much better to be able to look at that code and know what it does.
Cheersy Cheers
Paul
Good points..I know of what working in 24x7 production environment means and how fast SAP can loose the respect of production people and fall in the category "i ll deal with it when i have time"....
As far as the FIORI ecosystem , you have good points with javascript. I would also add the fact that moving tot he new OO era needs software engineering skills that many ABAPers may not know or even forgot after many years of NOT practicing them..
I myself had and have hard time following legacy ABAP paradigm. Also i am having hard time following the Hybrid-OO approach that SAP pushes...Its the only way forward with so much legacy code, i know, but still may be nightmare with pure OO people....
Anyway i think that there are exciting times ahead...
As someone with the design sense of a deranged bower bird, listening to early Pink Floyd while taking er... smarties, I have a different approach. I don’t do UI.
With ABAP for SAPGui, that was a bit difficult, since I had to do ALVs and even DYNPRO from time to time. But with Fiori and SAPUI5, it’s even architectured into the framework that a design professional can do what they’re good at, and I can do what I’m good at.
(I have learned JavaScript and can build UI5 apps – I just don’t really like doing front ends).
Funnily enough, I had a request just this week to clone a very complex and sensitive report just to add a couple of columns and some additional algorithms for a small part of the business. Sounded trivial to me, but our functional team are petrified about changing this because of potential big impacts on the global business. Naturally, I said no to the cloning, but I thought again about an idea I had in the past to introduce custom enhancement spots in sensitive custom reports, with filter support for the appropriate organisational values. This would localise the regression impact to the business unit asking for the change, and as this blog reminds me, I could introduce unit test classes for the badi classes... couldn't I?
Anyway, as much as I am unthrilled about the idea of testing generally, I found this an interesting blog.
Cheers
Ged
I am very much in favour of user exits in your own Z code. I do this all the time, to cater for country specific logic. And do those exits have unit tests? Yes they do!
Well as usual - I loved the blog. Nellie is my best friend. There are so many different "new things" . Of course more than just OO and and testing are new.
Story:
About 20 years ago I walked of of an OO class. I was with two other colleagues. We came back and decided OO was a very bad way of programming as it was a LOT slower - runtime. So we recommended not using it.
Today - and earlier:
OO became a part of normal programming for me. And I began to think about that first class. Thinking about it in my mind. When I first started programming ABAP, I wrote some horrible programs. Why because I wasn't thinking about anything but what we learned in class. With that thought horribly written OO is of course slower. Why? I walked out of class and programmed OO in a very bad way.
So everyone out there should think about how they are writing/using the OO. Is it correct? There is now a ton of information out there. Learn how to write it correctly and not just the abstract way in course. It's still great to go to a class. There you learn basic concepts. BASIC CONCEPTS keep that in mind when you go back to the office and think about using it.
Resistance? Why?
I liked what Md Shadab wrote. It is true and there are very valid points. Throwing a lot of things at us at once. And here, I don't just think about OO.
There is the learning curve vs. deadlines.
Eclipse is used to develop CDS. Another "newer" type of development. So now you need to lean Eclipse to use CDS.
There is a FIORI app.
OK there is a lot more. Maybe I need to write a blog about that....
And there is the skill set of the people you work with to take under consideration. If you go on vacation, you really want someone else to be able to change the code you wrote.
I think Nellie is here to stay for awhile.:)
Michelle
Nowadays, under the heady influence of TDD, I code to interfaces. I don't use inheritence much. I use injection where I can. My OO style is far different from ten years ago.
Sadly, a young man is taking over from me at one client where my contract is ending after several years. He was trying to tell me how wonderful static classes are, and how using them "you don't need to instantiate". It's odd, since he learned programming using C++ at university, so you would have thought that he'd have some OO horse sense.
*sigh*
The Tall Guy reference. Very nice.
Well done for spotting that! I wondered if anyone would get it, but it was obscure I doubted it.
It's what we say about our moggy. "Take a deep breath, prepare for the worst, the stupidest cat in the universe". (She runs into walls, legs, chair legs...).
Wow, it was a long article but I read it completely and I enjoyed.
Excellent work.