If you had a new vegan or vegetarian product and wanted to get an “influencer” to blog about it would you pick Colonel Sanders or Ronald McDonald?
In this case I have been an ABAP programmer since 1999 and even before then I was interested in programming. I wrote my first code when I was 14 (1980). I have done this for so long that naturally I am going to be a bit biased and say that programming is a Good Thing.
However unless you have been hiding under a large rock lately you will have noticed that there has been a large push from SAP recently in regard to “Low Code/No Code” solutions.
I have been fairly vocal on this subject in my various books and blogs, for example:
https://blogs.sap.com/2022/03/31/the-no-cod-future-is-here-with-sap-mccloud-appy-meal/
The spiel I usually come out with is that this concept is not new in the least – even back in the days when programmers used punch cards to program the “news” was that very shortly you would just be able to tell a program what it should do in some sort of declarative manner and the program would be created without one line of code. This message has been repeated on and off since about 1950 i.e. for over seventy years now. So the obvious question would be – is this like Nuclear Fusion? Always ten years in the future.
The Ghost of No-Code Past
Sticking with SAP - over the years there have been a series of ways to speed up development by providing tools whereby “Citizen Smith Developers” (before the term was even invented) could shoulder the burden of code writing that was normally done by ABAP developers. In no particular order such initiatives included:-
Let us look at the last two in some detail
Excel
It will come as no great shock that an incredibly large number of end users download data from SAP (and whatever other systems you may be using plus the internet) into spreadsheets and do a whole bunch of calculations. Sometimes the aim is to make pretty graphs and pie charts, sometimes the aim is to calculate data which then gets fed back into the SAP system.
This is why SAP has always enabled a standard way of downloading ALV reports to Excel. From about ten years ago there was also ABAP2XLSX (every heard of that? If not, then invent a way of uploading/downloading from ABAP to Excel and then write a blog about it on the SAP Community website every month forever).
Some of the data in the spreadsheet is just a straight download from SAP but of course you also have calculated columns – this can range from simply adding two columns together progressing to doing a VLOOKUP between worksheets and often ending up with mega-complicated macros in Visual Basic.
Back in 1989 on my very first day in the accounts department when I was still a student doing a summer job I discovered you could do macros. Excel did not exist then - the spreadsheet was Lotus 123.
Did that make me a Citizen Smith Developer? Are people who do VLOOKUPS Citizen Smith Developers? Do people who add two columns together qualify?
What am I going to be working on next month? That would be this whacking great spreadsheet developed by people in the business over a period of years. It has dozens of worksheets most of which are populated with SAP data, and the end result is fed back into SAP. My job of course is to build the same thing inside SAP. At my company we do that sort of thing all the time, often having an “Excel In Place” front end so the users do not get a heart attack.
How complicated can these spreadsheets get? The most complicated one I have ever seen was used to design concrete and I translated that into ABAP code to power the variant configuration module. How long did it take to translate that spreadsheet into SAP? Four years.
Robotic Process Automation
I have to confess that where I work we do not use the RPA company that SAP bought and rebranded. We use a competitor product namely UIPATH.
Going down a rabbit hole for a second when one of the first use cases was being developer it was all about going into a web site, getting some information, and putting that information into SAP. The only problem was that the website popped up that “Are you a robot?” question. So the question was asked – can the robot automatically tick the box saying it is not a robot? I really, really hope the answer is “no”.
In any event since RPA was a “Citizen Smith Developer” type of thing a call for volunteers was made throughout all the head office staff. Someone in accounts payable put their hand up. A few months later I was talking to that RPA champion, and he showed me some things he had built.
It looked like a big VISIO flowchart to me, a bit like business workflow, where you configure the various boxes to do assorted things by clicking checkboxes and filling in fields. And guess what? If a box cannot do every single thing you want you can add code to it or call a Z function module.
After a very short time I realised that this “random end user” was actually sharp as a whip and I said to him that when (not if) he wanted to transition to getting a job as an actual ABAP programmer I would give him any advice/help that I could.
The conclusion I draw from all this is that anyone who has the desire to be a “Citizen Smith Developer” in fact has the desire to be an actual “Pro-Code” developer.
The Ghost of No-Code Yet to Come
The current SAP push for no-code is “SAP AppGyver”. Here is a blog which explains the concept:
https://blogs.sap.com/2021/11/18/the-no-code-future-is-here-at-sap-appgyver/
I always thought the most interesting quote in that blog was “solutions being worked on by teams of 20, can now be placed in the hands of one person“. If that is true then logically you can sack 95% of the programmers and everything will be fine.Some managers will believe this statement as it is what they want to hear and are most likley heading for an unpleasent surprise once the development team is gone.
The Ghost of No-Code Present
Now, despite all the negative things I have been saying about no-code solutions, one fine day I was contacted by somebody who wanted to demonstrate one such solution to me, so I could blog about it. So this is what I am doing.
The gentleman in question is called Avi Mishan and his company in Israel (Home | DPROS (d-pro.biz)) has pretty much cornered the no code market. When he contacted me he had no idea that I had actually lived in Tel Aviv for two years many years back and so was most surprised when my replies included short bursts of Hebrew (one of my silly pastimes in 1998/1999 was trying to translate the Spice Girls song lyrics into Hebrew e.g. Stop Right Now, To-Dah-Ra-Bah)
So here I am, Colonel Sanders, trying to be as unbiased as possible whilst talking about organic vegan soya beans taking the place of Fried Chicken.
Here are two slides from his (DPROS) presentation which state the aim of Low/No-Code. This aim has not changed since the 1950’s but let us spell it out.
This process is what I have always been used to and I never questioned it as it always seemed to work well to me. If I had to be brutally honest though often the end user requirement does get distorted before it gets to the developer.
In any event the purpose of “Low/No-Code” is to change the process as follows.
That sounds wonderful does it not? You end up with a new end user requirement live in production, potentially on the same day they ask for it. Possibly an hour after they ask for it.
At this point you probably expect me to start screaming and shouting and generally jumping up and down like a Baboon and grunting incoherently in an attempt to totally discredit the whole concept. Admittedly that would normally be the way I would proceed but as have said I am trying to be as unbiased as I can here and so will just describe what I saw in the product demonstration.
This Episode has been Sponsored by the Letter “Z”
I have no idea if where I work is typical, but if you were to ask one of our end users what is the split between their usage of “Z” reports inside the SAP GUI and their usage of standard SAP reports they would probably say “Oh, are there standard SAP reports?”
So – why are all the reports custom? It is generally because (a) standard SAP has to cater for all countries and business lines so the standard reports have to be very generic by nature and (b) though you can influence some standard reports to a limited extent via the IMG and user exits the scope of what you can do is never enough for the end users and (c) when we started most standard SAP reports still used WRITE statements as opposed to the ALV.
Thus we wrote loads of bespoke ALV reports. But what if at the time we could have indeed made all the needed changes to the standard reports without writing one line of code?
Veneer Disease
Now is the time to revisit the “Open/Closed Principle” which is how you can change the behaviour of an existing application without changing the code at all. That sounds impossible at first glance until you think to yourself “What does a user exit do then?” and it all starts to make sense.
The idea is to put a “veneer” on the surface of standard SAP. You still have all the standard tables and BAPIs and unreleased function modules you love to use in the background, but on their journey to and from the user they are intercepted by another layer which alters what the end user sees and increases that user’s ability to interact with the system.
As far back as 1998 you had GUIXT whereby you could drag fields all around the screen on a standard SAP transaction, rename them, change drop down lists into radio buttons, add fancy graphics and so on. The underlying SAP system was not changed at all. As an experiment we made a standard transaction look like the legacy transaction on the mainframe – right down to the green and black colour scheme – so of course the end users loved it.
Nowadays you have Screen Personas doing the exact same thing, albeit with a web front end, and if you think about if the UI5 concept is all about totally decoupling the front-end user interface from the back-end system.
Of course with those three approaches – GUIXT, Screen Personas and UI5 – there is lots of code involved, even if some or even all of it is generated automatically.
Use Case / Suitcase / Suits You Sir!
In this case I can see three areas where you might want to do some sort of “no-code” development in regard to reports.
I would also note if all an ABAP programmer ever did was create and change ALV reports then they would probably get bored very quickly and start wishing “the business” did in fact have some sort of self-service tool to make these changes, so the programmer could work on something more interesting.
Out of Work Navvy Going to a Demo
The no-code product that was demonstrated to me was called “Insight SAP” which is an SAP add-on (written in ABAP)
https://insight-sap.com/
Interestingly on the web site the very first words about the product are „Instant Spreadsheet Functionality Within SAP“. A bit like ABAP2XLSX (if you have ever heard of that) I suppose but without the code. The logic being if you could do Excel like things to the data within an SAP report you would not need to download the report to Excel and then do Excel like things on the data.
Anyway with this toll what you can do to the SAP report is as follows:-
Basically a lot of things you can do by adding/changing code in an ALV report and some you cannot (such as the graphics) but without actually writing any ABAP code. So from the Citizen Smith Developer point of view there is not one line of code, but I presume there is a lot of code dynamically generated in the background based on what I would call the report configuration.
As per the pictures above the end goal of this sort of thing is to reduce the development time for weeks to hours and knock the ABAP developer out of the equation.
Why-Z Man Say, Only Fools Rush In
As a last point my favourite quote from the slides was “If the company wanted lots of manual coding, why did they buy an ERP system in the first place?”. I would say that in the year 1996 SAP was promising that a vanilla SAP system can give you everything you want, no need for your own code. Fast forward to 2022 and SAP is saying that S/4HANA can give you everything you want, you do not need all that Z code you wrote over the last twenty odd years, because all that missing functionality is now in the standard system, bound to be.
In effect I am hearing the exact same message from SAP that I heard 25 years ago i.e. stay vanilla, keep the core clean, you don’t need any custom code. That message did not work so well the first time and now SAP are doing the exact same thing again and expecting different results.
Disclaimer
I would just like to state I have no financial interest in the above product whatsoever, or indeed in any “no-code” product. If anything I have a financial interest in companies not using no-code products as that supposedly safeguards my job and the jobs of all ABAP developers. In reality the latter is nonsense – no-code products have been around for decades, and all the “pro-code” developers are still employed.
Just this morning I saw on Twitter an article about how very soon no-one will have to do any manual testing anymore, testing will all be done by advanced AI programs. Yes. Of course it will. And even if that were true it most likely would not cause a headcount reduction. Starting with the very first SAP implementation I worked on in 1997 and right up until the current date the business case always includes a headcount reduction and yet after go-live you usually end up employing more people.
The rule seems to be – the more you automate things the more people you need. This paradox probably has a name, but I don’t know what it is. In one of our sites in Australia we “replaced” some of our laboratory staff with a giant robot, but when I went to see the robot in action I noticed no-one had actually been laid off, if anything there was an extra position that was created – someone had to watch the robot all day and when any of its arms got stuck they had to hit them with the “robot stick”.
My Take
These products clearly work. In the demo I just wrote about and what I saw with the UIPATH RPA product you can clearly build/change something “without one line of code” very quickly indeed. Also, there is clearly a market for this sort of thing.
The billion million dollar question is – will the “new generation” of “no-code” products revolutionise development in the way that all the previous generations promised to do? To recap – the inventor of “SAP AppGyver” promises a 95% reduction in the number of developers you need. The “SAP Insight” claim a more modest 15% reduction in work hours based on statistics from actual clients.
Either way I am not going to be losing any sleep. Companies will no doubt buy these products and no doubt get a benefit from them.
But ABAP is rather like COBOL and Cockroaches and Excel and the SAP GUI. No matter how many atom bombs you drop on any of those they crawl out from underneath the mushroom cloud and keep on going.
Cheersy Cheers
Paul
CS vs RMD
In this case I have been an ABAP programmer since 1999 and even before then I was interested in programming. I wrote my first code when I was 14 (1980). I have done this for so long that naturally I am going to be a bit biased and say that programming is a Good Thing.
However unless you have been hiding under a large rock lately you will have noticed that there has been a large push from SAP recently in regard to “Low Code/No Code” solutions.
I have been fairly vocal on this subject in my various books and blogs, for example:
https://blogs.sap.com/2022/03/31/the-no-cod-future-is-here-with-sap-mccloud-appy-meal/
The spiel I usually come out with is that this concept is not new in the least – even back in the days when programmers used punch cards to program the “news” was that very shortly you would just be able to tell a program what it should do in some sort of declarative manner and the program would be created without one line of code. This message has been repeated on and off since about 1950 i.e. for over seventy years now. So the obvious question would be – is this like Nuclear Fusion? Always ten years in the future.
The Ghost of No-Code Past
Sticking with SAP - over the years there have been a series of ways to speed up development by providing tools whereby “Citizen Smith Developers” (before the term was even invented) could shoulder the burden of code writing that was normally done by ABAP developers. In no particular order such initiatives included:-
- SAP Query
- HR pseudo-code
- Variant Configuration pseudo-code
- Validation/Substitution logic in FI/CO
- BRF+
- ABAP for Key Users
- Robotic Process Automation
- Excel
Let us look at the last two in some detail
Excel
It will come as no great shock that an incredibly large number of end users download data from SAP (and whatever other systems you may be using plus the internet) into spreadsheets and do a whole bunch of calculations. Sometimes the aim is to make pretty graphs and pie charts, sometimes the aim is to calculate data which then gets fed back into the SAP system.
This is why SAP has always enabled a standard way of downloading ALV reports to Excel. From about ten years ago there was also ABAP2XLSX (every heard of that? If not, then invent a way of uploading/downloading from ABAP to Excel and then write a blog about it on the SAP Community website every month forever).
Some of the data in the spreadsheet is just a straight download from SAP but of course you also have calculated columns – this can range from simply adding two columns together progressing to doing a VLOOKUP between worksheets and often ending up with mega-complicated macros in Visual Basic.
Back in 1989 on my very first day in the accounts department when I was still a student doing a summer job I discovered you could do macros. Excel did not exist then - the spreadsheet was Lotus 123.
Did that make me a Citizen Smith Developer? Are people who do VLOOKUPS Citizen Smith Developers? Do people who add two columns together qualify?
What am I going to be working on next month? That would be this whacking great spreadsheet developed by people in the business over a period of years. It has dozens of worksheets most of which are populated with SAP data, and the end result is fed back into SAP. My job of course is to build the same thing inside SAP. At my company we do that sort of thing all the time, often having an “Excel In Place” front end so the users do not get a heart attack.
How complicated can these spreadsheets get? The most complicated one I have ever seen was used to design concrete and I translated that into ABAP code to power the variant configuration module. How long did it take to translate that spreadsheet into SAP? Four years.
Robotic Process Automation
I have to confess that where I work we do not use the RPA company that SAP bought and rebranded. We use a competitor product namely UIPATH.
Going down a rabbit hole for a second when one of the first use cases was being developer it was all about going into a web site, getting some information, and putting that information into SAP. The only problem was that the website popped up that “Are you a robot?” question. So the question was asked – can the robot automatically tick the box saying it is not a robot? I really, really hope the answer is “no”.
In any event since RPA was a “Citizen Smith Developer” type of thing a call for volunteers was made throughout all the head office staff. Someone in accounts payable put their hand up. A few months later I was talking to that RPA champion, and he showed me some things he had built.
It looked like a big VISIO flowchart to me, a bit like business workflow, where you configure the various boxes to do assorted things by clicking checkboxes and filling in fields. And guess what? If a box cannot do every single thing you want you can add code to it or call a Z function module.
After a very short time I realised that this “random end user” was actually sharp as a whip and I said to him that when (not if) he wanted to transition to getting a job as an actual ABAP programmer I would give him any advice/help that I could.
The conclusion I draw from all this is that anyone who has the desire to be a “Citizen Smith Developer” in fact has the desire to be an actual “Pro-Code” developer.
The Ghost of No-Code Yet to Come
The current SAP push for no-code is “SAP AppGyver”. Here is a blog which explains the concept:
https://blogs.sap.com/2021/11/18/the-no-code-future-is-here-at-sap-appgyver/
I always thought the most interesting quote in that blog was “solutions being worked on by teams of 20, can now be placed in the hands of one person“. If that is true then logically you can sack 95% of the programmers and everything will be fine.Some managers will believe this statement as it is what they want to hear and are most likley heading for an unpleasent surprise once the development team is gone.
The Ghost of No-Code Present
Now, despite all the negative things I have been saying about no-code solutions, one fine day I was contacted by somebody who wanted to demonstrate one such solution to me, so I could blog about it. So this is what I am doing.
The gentleman in question is called Avi Mishan and his company in Israel (Home | DPROS (d-pro.biz)) has pretty much cornered the no code market. When he contacted me he had no idea that I had actually lived in Tel Aviv for two years many years back and so was most surprised when my replies included short bursts of Hebrew (one of my silly pastimes in 1998/1999 was trying to translate the Spice Girls song lyrics into Hebrew e.g. Stop Right Now, To-Dah-Ra-Bah)
So here I am, Colonel Sanders, trying to be as unbiased as possible whilst talking about organic vegan soya beans taking the place of Fried Chicken.
Here are two slides from his (DPROS) presentation which state the aim of Low/No-Code. This aim has not changed since the 1950’s but let us spell it out.
Existing Development Process
This process is what I have always been used to and I never questioned it as it always seemed to work well to me. If I had to be brutally honest though often the end user requirement does get distorted before it gets to the developer.
In any event the purpose of “Low/No-Code” is to change the process as follows.
Utopian Development Process
That sounds wonderful does it not? You end up with a new end user requirement live in production, potentially on the same day they ask for it. Possibly an hour after they ask for it.
At this point you probably expect me to start screaming and shouting and generally jumping up and down like a Baboon and grunting incoherently in an attempt to totally discredit the whole concept. Admittedly that would normally be the way I would proceed but as have said I am trying to be as unbiased as I can here and so will just describe what I saw in the product demonstration.
This Episode has been Sponsored by the Letter “Z”
I have no idea if where I work is typical, but if you were to ask one of our end users what is the split between their usage of “Z” reports inside the SAP GUI and their usage of standard SAP reports they would probably say “Oh, are there standard SAP reports?”
So – why are all the reports custom? It is generally because (a) standard SAP has to cater for all countries and business lines so the standard reports have to be very generic by nature and (b) though you can influence some standard reports to a limited extent via the IMG and user exits the scope of what you can do is never enough for the end users and (c) when we started most standard SAP reports still used WRITE statements as opposed to the ALV.
Thus we wrote loads of bespoke ALV reports. But what if at the time we could have indeed made all the needed changes to the standard reports without writing one line of code?
Veneer Disease
Now is the time to revisit the “Open/Closed Principle” which is how you can change the behaviour of an existing application without changing the code at all. That sounds impossible at first glance until you think to yourself “What does a user exit do then?” and it all starts to make sense.
The idea is to put a “veneer” on the surface of standard SAP. You still have all the standard tables and BAPIs and unreleased function modules you love to use in the background, but on their journey to and from the user they are intercepted by another layer which alters what the end user sees and increases that user’s ability to interact with the system.
As far back as 1998 you had GUIXT whereby you could drag fields all around the screen on a standard SAP transaction, rename them, change drop down lists into radio buttons, add fancy graphics and so on. The underlying SAP system was not changed at all. As an experiment we made a standard transaction look like the legacy transaction on the mainframe – right down to the green and black colour scheme – so of course the end users loved it.
Nowadays you have Screen Personas doing the exact same thing, albeit with a web front end, and if you think about if the UI5 concept is all about totally decoupling the front-end user interface from the back-end system.
Of course with those three approaches – GUIXT, Screen Personas and UI5 – there is lots of code involved, even if some or even all of it is generated automatically.
Use Case / Suitcase / Suits You Sir!
In this case I can see three areas where you might want to do some sort of “no-code” development in regard to reports.
- Enhancing a standard SAP report
- Enhancing an existing “Z” report
- Creating a new report from scratch
I would also note if all an ABAP programmer ever did was create and change ALV reports then they would probably get bored very quickly and start wishing “the business” did in fact have some sort of self-service tool to make these changes, so the programmer could work on something more interesting.
Out of Work Navvy Going to a Demo
The no-code product that was demonstrated to me was called “Insight SAP” which is an SAP add-on (written in ABAP)
https://insight-sap.com/
Interestingly on the web site the very first words about the product are „Instant Spreadsheet Functionality Within SAP“. A bit like ABAP2XLSX (if you have ever heard of that) I suppose but without the code. The logic being if you could do Excel like things to the data within an SAP report you would not need to download the report to Excel and then do Excel like things on the data.
Anyway with this toll what you can do to the SAP report is as follows:-
- Add a new column which gets its value from the database
- Add a new calculated column
- Do conditional formatting (i.e. change cell colour based on certain criteria)
- Have columns where the user can enter/change data (which is more than CL_SALV_TABLE can, I don’t know if I have ever mentioned this anywhere)
- Add in pie charts and bar charts and such based on the data in the report, like you can do with Excel and indeed ABAP2XLSX
- Display the report and associated data in the from of a Fiori App, so you can see it on your smartphone
- Send Alerts
- Add new functions on the toolbar
Basically a lot of things you can do by adding/changing code in an ALV report and some you cannot (such as the graphics) but without actually writing any ABAP code. So from the Citizen Smith Developer point of view there is not one line of code, but I presume there is a lot of code dynamically generated in the background based on what I would call the report configuration.
As per the pictures above the end goal of this sort of thing is to reduce the development time for weeks to hours and knock the ABAP developer out of the equation.
Why-Z Man Say, Only Fools Rush In
As a last point my favourite quote from the slides was “If the company wanted lots of manual coding, why did they buy an ERP system in the first place?”. I would say that in the year 1996 SAP was promising that a vanilla SAP system can give you everything you want, no need for your own code. Fast forward to 2022 and SAP is saying that S/4HANA can give you everything you want, you do not need all that Z code you wrote over the last twenty odd years, because all that missing functionality is now in the standard system, bound to be.
In effect I am hearing the exact same message from SAP that I heard 25 years ago i.e. stay vanilla, keep the core clean, you don’t need any custom code. That message did not work so well the first time and now SAP are doing the exact same thing again and expecting different results.
Disclaimer
I would just like to state I have no financial interest in the above product whatsoever, or indeed in any “no-code” product. If anything I have a financial interest in companies not using no-code products as that supposedly safeguards my job and the jobs of all ABAP developers. In reality the latter is nonsense – no-code products have been around for decades, and all the “pro-code” developers are still employed.
Just this morning I saw on Twitter an article about how very soon no-one will have to do any manual testing anymore, testing will all be done by advanced AI programs. Yes. Of course it will. And even if that were true it most likely would not cause a headcount reduction. Starting with the very first SAP implementation I worked on in 1997 and right up until the current date the business case always includes a headcount reduction and yet after go-live you usually end up employing more people.
The rule seems to be – the more you automate things the more people you need. This paradox probably has a name, but I don’t know what it is. In one of our sites in Australia we “replaced” some of our laboratory staff with a giant robot, but when I went to see the robot in action I noticed no-one had actually been laid off, if anything there was an extra position that was created – someone had to watch the robot all day and when any of its arms got stuck they had to hit them with the “robot stick”.
My Take
Citizen Smith Developer
These products clearly work. In the demo I just wrote about and what I saw with the UIPATH RPA product you can clearly build/change something “without one line of code” very quickly indeed. Also, there is clearly a market for this sort of thing.
The billion million dollar question is – will the “new generation” of “no-code” products revolutionise development in the way that all the previous generations promised to do? To recap – the inventor of “SAP AppGyver” promises a 95% reduction in the number of developers you need. The “SAP Insight” claim a more modest 15% reduction in work hours based on statistics from actual clients.
Either way I am not going to be losing any sleep. Companies will no doubt buy these products and no doubt get a benefit from them.
But ABAP is rather like COBOL and Cockroaches and Excel and the SAP GUI. No matter how many atom bombs you drop on any of those they crawl out from underneath the mushroom cloud and keep on going.
Cheersy Cheers
Paul
- SAP Managed Tags:
17 Comments
