After 15 years in consulting, focusing on mainly ABAP development and architecture, I recently changed my job and joined a software vendor and SAP partner which builds a platform focusing on rapid application development with a low-code approach. In discussions about my new job which I had in the last months, I realized, that many developers see the whole low-/no-code buzz rather critical. I can absolutely understand their criticism. I had the same opinion before I had a closer look.
I call myself a rather critical mind, especially if it comes to buzzwords, hypes and trends in our industry. So, people who know me, might have been surprised by that move.
Also, if you follow me on Twitter you might have seen rather critical Tweets about low-code and no-code. I also did an episode on Coffee Corner Radio with hobruche and matt.steiner about this topic. It was not super critical, but I tried to express my doubts. You can be sure, I'm still critical.
I already saw some attempts of getting something similar flying: approximately 15 -20 years ago there was a hype around Model Dirven Development (MDD), Guided Procedures and other rapid application development tools and platforms. I tried some of the tools back then and to be honest, Itried to stay away as far as possible for long time, afterwards.
The model driven approach was often based on complex UML models, which became because of their complexity almost unreadable for humans. If you ever tried to stick to the UML definition and syntax, you might have also experienced, that drawing and defining models can be as complicated as writing code. With this approach, it is not possible to give this tooling to "citizen developers" and let them define the models on their own. Neither a developer became faster in developing an application. But lets come to the even bigger problem with that approach: As a next step, code was generated based on that models. It was nearly impossible to maintain or change that code. If you changed the code, you could not change the model again, because your code changes would just have been overwritten by the code generator again.
SAP offered also similar tools called Composite Application Framework, Guided Procedures and Visual Composer. In a nutshell: The idea behind these tools was to enable users to compose applications by modelling a process and combining reusable services without writing code. The modelling language was not UML, but something developed by SAP, closer to BPM than to UML. The modelling was better suited to business users than UML but there was another big issue: the real world was often more complex than the modelling language. Meaning, there were limits in modelling and most complex business processes reached them and this was the dead-end for these applications. There was no way to change the generated code. At the dead-end the only way out was to develop it without these tools.
Just because of that first attempts with MDD we should not doom the model approach. I hope, no developer would deny that having some sort of diagram of an application, system or even landscape helps a lot. I would also not doom UML. But UML got too overengineered. For the modeler it was not clear when to use which diagram and artefact. Furthermore, it was possible to model each and every detail. This makes sense if you want to generate code based on the model. But the actual idea behind a model is to abstract things. This means to focus on the relevant things for your model and leave out the not relevant things. If you do so, the models help you to get the big picture of something. Maybe there is a need for a different model which focuses on other aspects. This other model contains maybe information which are not in the first model.
As developers bridging the gap between technology and a functional domain is always part of our job. I call it proofed, that software fits better to the needs of its users, if the software was developed in a fusion team. This means all stakeholders, from development-, security-, infrastructure- to domain and business-experts work in a dedicated team.
If we talk about Rapid Application Development, we also need to talk about frameworks. It took way too long that the principle of one was established in the ABAP world. The principle of one means, there is one dedicated tool for one specific task. If we look ten years back, there was not "the" framework for ABAP development shipped by SAP. There were several frameworks in different products built with the NetWeaver ABAP Application Server. Then BOPF appeared which matured and became somehow part of the RESTful ABAP Programming Model (RAP) now.
Why do I think it took too long? Because frameworks make developer’s life much easier. Good frameworks relieve developers of repetitive tasks. Furthermore, they streamline development by forcing developers to follow the design patterns the framework uses. This also means less freedom for the individual developers. But it's much easier to understand the code and therefore makes development and maintenance easier and faster. If a manager reads this, yes, this translates to lower TCO 😉
Just one side mark about BOPF here: why did I really like to work with BOPF? It had all the advantages I just described. Furthermore, it started with modelling and brings the layer of abstraction I was mentioning earlier with its advantages. It also relieved one from repetitive tasks and boilerplate coding but with almost no code generation but a clever use of design patterns like dependency injection.
In the marketing buzz about Low-Code and No-Code we often hear that the business side will use those platforms to develop applications on their own and that there will be so called citizen developers who will do that. If a professional developer hears something like that, he starts to laugh in the best case. I personally think, it's rather frightening. Not because I'm afraid of losing my job, rather because of topics like data privacy, security, access control and the fact that there might be the day these apps need to be taken over by the IT department for maintenance or additional features. There is potential for Low-Code platforms to become the next shadow IT applications which become business critical over the years. As it happened with Lotus Notes databases, Excel VBA Macros and Access databases in the past. In order to avoid shadow IT, IT departments should embrace the emerging Low-Code platforms. Not because of all the skilled citizen developers who will be able to develop apps which fulfill all their requirements in no time. I'm still waiting for all those very IT skilled business users ;-). But because a good Low-Code platform can speed up development by relieving them from boring and maybe even annoying tasks and potentially reducing the backlog. Of course, IT departments should be part of the decision process when it comes to choosing a platform.
There are certain aspects from an IT perspective to have an eye on: single sign on capabilities, API based integration, pro-code capabilities to prevent the dead-end situation described before, the used technologies should comply with the company's IT strategy, support of stagging (implying no development on production!) and a roles and authorization concept which fulfills the needs and more. After the decision for a platform, the IT departments should make it “their” platform and something they just run for their business.
There was a great and entertaining and critical talk by James Govenor (monkchips) about Low-Code Neptune's Impact Festival. You find it on YouTube.
I was working more than ten years as a developer in the SAP ecosystem. I think developers should embrace the low-code trend (maybe not the big buzz around it). I personally think, a good Low-Code Platform can be seen as the next level of abstraction and can relieve developers from the huge backlogs they have to deal with. Not necessarily with moving development tasks completely away, but with speeding up the whole process. Furthermore No-Code and Low-Code features can help to improve the teamwork which is needed to deliver applications which fulfill the needs of the users and support the processes best. The platforms should support a seamless transition from no-code to low-code to pro-code and by doing so support the work in Fusion Teams.
Developers tend to see themselves as craftsmen or even artists who can do everything the way they do it. That's for sure a good attitude for learning new stuff. It's for sure a plus to know the technology and principles under the hood of a platform. But I don't see the benefit in doing the time-consuming basic stuff on my own if there are tools which can do that for me.
The individual way of working without platforms and frameworks is very expansive. Nobody at a car manufacturer would question the unified process flow they defined for their production, just because he or she would be able to assemble a car on its own. Give it a try and experience the low-code world!
I call myself a rather critical mind, especially if it comes to buzzwords, hypes and trends in our industry. So, people who know me, might have been surprised by that move.
Also, if you follow me on Twitter you might have seen rather critical Tweets about low-code and no-code. I also did an episode on Coffee Corner Radio with hobruche and matt.steiner about this topic. It was not super critical, but I tried to express my doubts. You can be sure, I'm still critical.
I already saw some attempts of getting something similar flying: approximately 15 -20 years ago there was a hype around Model Dirven Development (MDD), Guided Procedures and other rapid application development tools and platforms. I tried some of the tools back then and to be honest, Itried to stay away as far as possible for long time, afterwards.
Rapid Application Development with MDD and other tools
The model driven approach was often based on complex UML models, which became because of their complexity almost unreadable for humans. If you ever tried to stick to the UML definition and syntax, you might have also experienced, that drawing and defining models can be as complicated as writing code. With this approach, it is not possible to give this tooling to "citizen developers" and let them define the models on their own. Neither a developer became faster in developing an application. But lets come to the even bigger problem with that approach: As a next step, code was generated based on that models. It was nearly impossible to maintain or change that code. If you changed the code, you could not change the model again, because your code changes would just have been overwritten by the code generator again.
SAP offered also similar tools called Composite Application Framework, Guided Procedures and Visual Composer. In a nutshell: The idea behind these tools was to enable users to compose applications by modelling a process and combining reusable services without writing code. The modelling language was not UML, but something developed by SAP, closer to BPM than to UML. The modelling was better suited to business users than UML but there was another big issue: the real world was often more complex than the modelling language. Meaning, there were limits in modelling and most complex business processes reached them and this was the dead-end for these applications. There was no way to change the generated code. At the dead-end the only way out was to develop it without these tools.
But why is modelling still a good idea?
Just because of that first attempts with MDD we should not doom the model approach. I hope, no developer would deny that having some sort of diagram of an application, system or even landscape helps a lot. I would also not doom UML. But UML got too overengineered. For the modeler it was not clear when to use which diagram and artefact. Furthermore, it was possible to model each and every detail. This makes sense if you want to generate code based on the model. But the actual idea behind a model is to abstract things. This means to focus on the relevant things for your model and leave out the not relevant things. If you do so, the models help you to get the big picture of something. Maybe there is a need for a different model which focuses on other aspects. This other model contains maybe information which are not in the first model.
As developers bridging the gap between technology and a functional domain is always part of our job. I call it proofed, that software fits better to the needs of its users, if the software was developed in a fusion team. This means all stakeholders, from development-, security-, infrastructure- to domain and business-experts work in a dedicated team.
Finally, frameworks appeared in the ABAP world and they are there to stay
If we talk about Rapid Application Development, we also need to talk about frameworks. It took way too long that the principle of one was established in the ABAP world. The principle of one means, there is one dedicated tool for one specific task. If we look ten years back, there was not "the" framework for ABAP development shipped by SAP. There were several frameworks in different products built with the NetWeaver ABAP Application Server. Then BOPF appeared which matured and became somehow part of the RESTful ABAP Programming Model (RAP) now.
Why do I think it took too long? Because frameworks make developer’s life much easier. Good frameworks relieve developers of repetitive tasks. Furthermore, they streamline development by forcing developers to follow the design patterns the framework uses. This also means less freedom for the individual developers. But it's much easier to understand the code and therefore makes development and maintenance easier and faster. If a manager reads this, yes, this translates to lower TCO 😉
Just one side mark about BOPF here: why did I really like to work with BOPF? It had all the advantages I just described. Furthermore, it started with modelling and brings the layer of abstraction I was mentioning earlier with its advantages. It also relieved one from repetitive tasks and boilerplate coding but with almost no code generation but a clever use of design patterns like dependency injection.
Short look to the business side and shadow IT
In the marketing buzz about Low-Code and No-Code we often hear that the business side will use those platforms to develop applications on their own and that there will be so called citizen developers who will do that. If a professional developer hears something like that, he starts to laugh in the best case. I personally think, it's rather frightening. Not because I'm afraid of losing my job, rather because of topics like data privacy, security, access control and the fact that there might be the day these apps need to be taken over by the IT department for maintenance or additional features. There is potential for Low-Code platforms to become the next shadow IT applications which become business critical over the years. As it happened with Lotus Notes databases, Excel VBA Macros and Access databases in the past. In order to avoid shadow IT, IT departments should embrace the emerging Low-Code platforms. Not because of all the skilled citizen developers who will be able to develop apps which fulfill all their requirements in no time. I'm still waiting for all those very IT skilled business users ;-). But because a good Low-Code platform can speed up development by relieving them from boring and maybe even annoying tasks and potentially reducing the backlog. Of course, IT departments should be part of the decision process when it comes to choosing a platform.
There are certain aspects from an IT perspective to have an eye on: single sign on capabilities, API based integration, pro-code capabilities to prevent the dead-end situation described before, the used technologies should comply with the company's IT strategy, support of stagging (implying no development on production!) and a roles and authorization concept which fulfills the needs and more. After the decision for a platform, the IT departments should make it “their” platform and something they just run for their business.
There was a great and entertaining and critical talk by James Govenor (monkchips) about Low-Code Neptune's Impact Festival. You find it on YouTube.
Reduce the backlog and start to develop faster
I was working more than ten years as a developer in the SAP ecosystem. I think developers should embrace the low-code trend (maybe not the big buzz around it). I personally think, a good Low-Code Platform can be seen as the next level of abstraction and can relieve developers from the huge backlogs they have to deal with. Not necessarily with moving development tasks completely away, but with speeding up the whole process. Furthermore No-Code and Low-Code features can help to improve the teamwork which is needed to deliver applications which fulfill the needs of the users and support the processes best. The platforms should support a seamless transition from no-code to low-code to pro-code and by doing so support the work in Fusion Teams.
Developers tend to see themselves as craftsmen or even artists who can do everything the way they do it. That's for sure a good attitude for learning new stuff. It's for sure a plus to know the technology and principles under the hood of a platform. But I don't see the benefit in doing the time-consuming basic stuff on my own if there are tools which can do that for me.
The individual way of working without platforms and frameworks is very expansive. Nobody at a car manufacturer would question the unified process flow they defined for their production, just because he or she would be able to assemble a car on its own. Give it a try and experience the low-code world!
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
