Skip to Content
Product Information
Author's profile photo Paul Hardy

Colonel Sanders on Being a No-Code Vegan

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:

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


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:

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 ( 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)

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.


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


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andrea Borgia
      Andrea Borgia

      Hahaha, that's the beauty of your titles: I KNEW it was you already from the notification, before reading the name 😀

      Yup, simplification comes along from time to time but in general it seems the tradeoff is between power and convenience: if you want to be able to do everything, you'll typically have to do everything, most of the time.


      Author's profile photo Matthew Billingham
      Matthew Billingham


      A few random thoughts.

      Back in the early nineties we had a no-code solution that generated COBOL. Much fuss and noise. "No more developers". Yet two years later, there they were.

      The thing is, as soon as you add a loop or a conditional - you're back to programming. And a non-programmer (or a bad programmer - which is essentially the same thing) will screw things up. Or at least create an unmaintainable monster.

      Back in the mid 90s, I was going through some processes with a FICO consultant. She explained that she ran one (Z) report, downloaded the results, then ran another (Z) report and copy pasted the data in the results, into the selection screen. I was able to explain that as both are Z reports, I could simply add the functionality to call the second one directly from the first. "Oh, can you do that?".

      Ooo. SAP Data Services... began life as Actaworks then got bought out by BO (a business that didn't stink, apparently) and then by SAP. Generated Z programs in production. I had a lot of fun (=$$$$) dealing with these for a client, as they were so slow. I also pointed out that the RFC Function Modules that generated the code were somewhat insecure and could be used to inject any code into the production server, which concerned the security team so much that they enforced the Dev->Test->Production process for any generated reports.

      There were other security issues as well (like the DS code was in the Z space instead of a /namespace/ space). I and someone who used to be reasonably well known on this site, managed to highlight these to some senior bods at SAP and get addressed. I'm pretty sure that we were on the DS team as the first against the wall when the revolution comes.

      And then, back in 2016, while in Barcelona for TechEd, I did a workshop on developing Fiori Apps. The trainers stated "With Fiori Apps, you see, there's no need to develop anything in ABAP!". I took issue with this and explained I'd just come from a workshop entitled "Developing Fiori Apps with ABAP". 

      Plus ça change... 😀

      Author's profile photo Pierre COL
      Pierre COL

      Hi Matthew,

      I discovered computer programming in 1978, when I was 15 yo, and it was Z80 assembler.

      I graduated as an engineer in computing science in 1986 after having learned programming in BASIC, Pascal, Fortran, COBOL, Lisp, Prolog and finally C.

      The only programming language I coded programs with during the beginning of my career, 1986-1992, was C.

      So I know a bit about what is programming and what is a programming language. And now I'm working at SAP to promote low-code/no-code, because it is the sense of IT industry!


      Author's profile photo Matthew Billingham
      Matthew Billingham

      I started programming a little later. ZX80, when I was 11. A year later got a ZX81 and soon after that was programming in Z80A. Loved it. I guess you always remember your first love... 😉

      I can't remember how many programming languages I've been paid to program in since then (and others I've just learned for fun), but it's double digits. Nowadays, it's just ABAP and Java. There are basically three programming languages: procedural, object oriented, functional.

      Or maybe four with Clojure, Lisp etc.

      I'm sure programming will become lovely with visual design. But it has been tried since those first "the pretty diagram compiles to COBOL" days, and never really caught on. I'm cynical because I've seen this stuff again and again - and because management will always buy on the premise that "it'll reduce IT costs", which it never does*. I'm always open to new ideas though. Perhaps this time you really have designed a better mousetrap.

      Interestingly, I'm currently developing a plug-in for ADT. The e4 framework does a lot of the coding for you, via forms and configuration - leaving you just to do the interesting bits. I guess that's moving towards low-code. But it certainly isn't for Citizen Smith!

      One thing I have learned over the years in the IT industry is that, essentially, not much changes. In the science of computer programming however, well that's quite different.

      (Btw, in the notifications it shows the first sentence you originally wrote. Your secret is safe with me.)


      * The best way to reduce IT costs it to employ really really good people and keep them. Sorry, I'm already taken. 😁

      Author's profile photo Esmee Xavier
      Esmee Xavier

      the inventor of “SAP AppGyver” promises a 95% reduction in the number of developers you need

      Hi Paul. Coming from the AppGyver team, need to correct you here since this is definitely not what Marko promises, and none of us are aiming to put developers out of work. It's quite the opposite - that developers will have tools available that let them build and focus on more exciting things beyond syntax. There's always a need for programming and pro-developers, which is why AppGyver's approach to no-code is through visual programming.


      Author's profile photo Matthew Billingham
      Matthew Billingham

      I totally agree. As soon as you have conditions and loops -> you need a programmer!

      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      Ok in that case what does "“solutions being worked on by teams of 20, can now be placed in the hands of one person“" mean? That is a direct quote from his blog.

      Probably i am mis-interpreting that quote in some way, but at first glance it seems to indicate that a solution which previously took 20 people to develop can now be done by one person.

      Cheersy Cheers


      Author's profile photo Esmee Xavier
      Esmee Xavier

      I don't want to speak for Marko Lehtimäki, but I think when we're talking about these tasks it's not necessarily the large complex projects - these will of course still require the involvement of pro developers. For smaller processes though, the "business user" who faces a certain problem every day can certainly create an app or automation to solve that, under the governance of IT. I'd also add that since the beginning of SAP AppGyver, we never wanted to take the "programming" out of no-code - but with no-code, teach everyone to become a (visual) programmer. The journey with non-tech users is that they often start off with simple apps, and then gradually dive deeper into the tool to more complex tasks.

      Just out of curiosity, have you tried out AppGyver yet? It would be interesting to hear your perspective there once you've had some experiences with the tool.

      Author's profile photo Pierre COL
      Pierre COL

      Hi Paul,

      FYI, and with all my respect, saying "the RPA company that SAP bought and rebranded" does not reflect the truth at all, and is misleading the reader on what SAP Intelligent RPA really was.

      I am from Contextor, "the company SAP bought" end of 2018, and I can tell you that SAP Intelligent RPA is (or was, as it is now deprecated) not at all a rebranding of what our product was in 2018: Contextor features and building blocks have been integrated into a brand new product SAP started developing months before acquiring Contextor, and this new product, SAP Intelligent RPA, has been launched at SAPPHIRE NOW 2019.

      In a few words: what Contextor brought was a full set of connectors to automate on top of non-SAP stuff like Microsoft Excel, web browers, legacy systems such as IBM mainframes and AS/400 through terminal emulators, Oracle etc. We also brought a Desktop Studio for bots design, and this studio has been completely recreated to offer a Cloud Studio, launched in version 2.0 at SAP TechEd 2020.

      And you might have seen that we recently launched SAP Process Automation, a broader tool made out of SAP Intelligent RPA (RPA, of course) SAP Workflow Management (BPM tool) with also embedded AI capabilities such as AI Business Services to better extract data out of documents, and of course with a low-code/no-code experience for Citizen Developers, as this product is part of SAP's LCNC portfolio.

      Do not be afraid, Paul: attend our LCNC sessions at SAP Sapphire 2022 and give SAP Process Automation a try, you might be positively surprised 😉

      Author's profile photo Pierre COL
      Pierre COL

      Juergen Mueller, CTO of SAP, just shared his opinion on low-code/no-code: "Every Company Is A Technology Company".

      On March 18, he explained that "Low-Code/No-Code Development and Citizen Automation are the Future of Enterprise Resilience".

      Author's profile photo Manfred Klein
      Manfred Klein

      Back in 1997 our Software Engineering Professor made the prophecy that software gets standardized by the minute and software developing will become obsolete. Fast forward 25 years: nothing changed. Did you ever adapt variant configuration to the commerce cloud? Thank god if you get spared...

      Author's profile photo Jorge Gutiérrez
      Jorge Gutiérrez

      I think my job as a developer is less in danger than that of managers promoting the miracles of no-code tools.

      I experimented with iRPA Cloud Desktop for a proof of concept and i felt tortured. Since the moment you drag and drop a loop or a condition block and understand what you are doing, you become more of a developer than of a "citizen". Also, the time comes, not too late, when to achieve a certain requirement it is not enough to combine a set of blocks and you end up needing to write some code. To integrate that code with the non-code part is not the easiest task even if you are a skilled code developer.

      Does anyone believe that a diagram with more than 20 blocks is more intelligible than the equivalent in code? Renaming elements, moving pieces of code from one place to another, in other words refactoring, is a constant in development. Does anyone deny me that this task in a diagram-like tool is not an absolute nightmare?


      Author's profile photo Matthew Billingham
      Matthew Billingham


      I'm intrigued how concepts such as clean coding, SOLID etc. translate into these tools. Profoundly badly I'd imagine.

      Author's profile photo Jorge Gutiérrez
      Jorge Gutiérrez

      The citizen developer must be assumed to be a person without principles.

      Author's profile photo Eitan Shahak
      Eitan Shahak

      As a programmer and a Creator of InsightSAP, I can tell you that by implementing the system I am now able to focus my efforts on the more complicated and interesting tasks. It doesn't eliminate the need for my programming skills but it does free resources and allows us to provide better support to our business end-users.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Give it a few years and some of those reports that the citizens have created will need to be rewritten in a more appropriate platform - probably ABAP.

      And it will be painful and expensive.

      The problem with these citizens' tools is that are simultaneously too powerful and too limited. They're powerful enough that non-developers can screw up royally, and limited enough that they can't do everything (easily) the citizens want to write.

      Maybe this time it'll be a better mousetrap and actually fulfil the desires - but forgive me if I'm highly skeptical. I've been in this business for over 30 years... there's not that many new ideas.

      Even HANA was touted as a new thing. "In memory database!". I first encountered that such a beast back in 1994 (when the 2GB of memory required was really rather expensive!) . 😁

      Author's profile photo Paul Hardy
      Paul Hardy
      Blog Post Author

      Also bear in mind that creating something is 5% of the software lifecycle.

      Bug Fixes + Enhancements are 95% of the software Lifecyle.

      I am sure all these no-code solutions have automated unit tests when you make changes. I am  also sure 99.9% of ABAP code does not have such tests but mine does, ha ha ha, ah ha ha ha.

      As Matthew says maybe this time - after 50 years - the problem has finally been cracked. If so great.



      The above shows how to do he UI5 equivalent of the screen painter - in AppGver. I am not so sure there is an equivalent in the general  Eclipse / VS Code / BTP way of building screens.

      Cheersy Cheers