Last week I had the privilege to attend and then to present at SAPSA Impuls alongside my customer colleague 9ef2f01b41e84f219aa1e666d8f86042 on the topic of Clean ABAP.
SAPSA (For those that may be unfamiliar) is the Swedish SAP user group (so similar to DSAG or ASUG).
SAPSA is often interesting and engaging, it’s a great opportunity to catch up with the latest innovations from SAP, to re-engage with old-collegues from across Scandinavia, to meet new ones, to talk with the real SAP experts, and to raise your knowledge levels a little, and for me this year it became a substitute for being at Teched in person, now that it has left European shores (please SAP bring teched back to Europe!).
SAPSA started off with a bang with a keynote "Racing with the red queen" that highlighted the rapid pace of change in the world that we are living in, that we all need to be a rabbit (or was that a hare?) to keep up with the changes in our rapidly evolving SAP tech world. SAPs’ latest innovations now include generative AI in CAP and soon to come to the ABAP BTP platform as well. Customers must be agile, and keep their cores clean is being heard repeated year after year.
I attended 2 really interesting presentations from m-skrzyniarz (from Int4), the first a fascinating dive into where we (in the SAP world) really stand with generative AI today (from his own investigations and perspectives). Mateusz has blogged quite a lot on this topic, something for me to catch up on. My own topic of focus for this SAPSA was around the relationship of technical debt to clean code, I found it fascinating that Mateusz also considered the implications of using generative AI to the potential future technical debt situation this can take us. A key question it raises: are we going from a world of technical debt in ABAP created by humans, to a future world of increased technical debt created by generative AI? Will this new world be that much better as a result? Will our code be cleaner or more messed up than ever?
My own thoughts here, perhaps the real breakthrough is to ensure the machine learning also trains on the principles of clean code, I was reading that MIT trained a machine learning algorithm to behave as different behaviours of a scrum team, so some as code reviewers, some as designers and some as testers, perhaps with this approach even generated code could be clean, but not yet. Mateusz focussed on the challenges for the generative AI to understand the differences between standard and custom code, this will surely require training across a myriad of customer systems, and perhaps this will become a barrier for the generative AI within the ABAP space (as customers systems are often in private cloud or on premiss), who knows? It was a really interesting topic and it certainly got me thinking.
The second presentation also from Mateusz on the possible impediments to our S/4 upgrade journeys, I also found myself to be in full agreement with. There is no point to upgrade to S/4 if all we do is continue to code like its 1999 (a topic I have blogged on previously), before we get there, we must focus on training our developers to upgrade their skillsets, to include CDS, RAP, ABAP Unit and the latest and greatest from SAP. If we do not make the effort to make our code bases cleaner and more modern, we will hinder our ability to deliver with any kind of agility. Then understanding our technical solution well before we embark on our S/4 upgrade journeys is also critically important to success.
All of which leads me onto the topic that I was there to present alongside my friend and colleague Mattias Johansson. In our presentation we presented the journey to Clean ABAP, why clean ABAP is more than just a style guide. How we should learn from the industry giants of Robert C Martin and Ward Cunningham by standing on their shoulders, to solve our technical debt problems in our ABAP code. Our technical debts have accumulated over many years of custom code delivery, by applying the principles of clean code that are now adapted to SAP ABAP by klaus.haeuptle, florian.hoffmann and co in their book on Clean ABAP (2021 SAPPress). Thanks to this publication and the online Git guide we now have a clear guide on what practices to apply, how to begin applying them, by starting conversations on the important topics in conversations within our development teams. In my own team we are deciding on our own Clean ABAP cheat-sheets to become our new programming guidelines for our own organisations. The challenge of adapting legacy code can be approached by applying the boy scout rule whenever we make changes, and encourage all developers to follow this priniciple, so that our ABAP code base becomes incrementally cleaner with every new change we make. Then apply Clean Islands to new development, to ensure we build new changes in the right way from the start. The work of introducing these principles with our teams is critical as Mattias clearly pointed out. Additionally we now have a whole armoury of tools to help us get there, in terms of Code Pal, ABAP Cleaner, ABAP Lint and more.
The challenge as I see it today, is that SAP tech is often far advanced of customer reality, and our only hope of keeping up, is to clean our code bases and be ready for the future challenges that come. So our message is: now is the time for us all to start cleaning our code bases, wherever we are in our SAP tech journeys. We are all ABAP Cleaners – so lets get cleaning!
The second day of SAPSA brought with it a late reminder (better late than never) that we must all be ready to upgrade to S/4, that there will be no further extension of the deadlines from SAP, and the reasoning behind this became clear, legal issues, vendor addon complications, the cost and complexity to SAP of keeping alive these really old versions of SAP. They all point to one thing, we must all get ready now for S/4, no exceptions!
I also managed to engage some of the really learned SAP experts at SAPSA and had some fun with the slightly unexpected conversations. In particular a crazy chat surrounding the possibility of making ABAP a prepackaged delivery similar to JAVA. I would argue if you can precompile ABAP as opposed to have it generated on transport import, this would really make ABAP significantly more flexible, and so more agile friendly. In the past this has not been possible (I suspect due to hardware dependencies), but for a BTP Rise platform, where the hardware implementation is under SAPs control, we can remove the issue of needing to make ABAP compatible with all possible hardware, pre-compilation/generation becomes a possibility. I was then referred to look into ABAP Git, and sure that is a part of the puzzle, but not the whole picture. This was fun and interesting, and I would recommend all to engage with SAP at these events to discuss curious possibilities (even if they appear somewhat crazy on the surface). This is also why we need teched in person, not just online.
I would like to say a big thank you to the organisers of SAPSA (Pontus and co) and to all of my fellow speakers who helped to make it a truly memorable event. I look forward keenly to our next get together, and encourage everyone to engage with their local SAP user groups.
And finally a little advert for our (Avega) swedish based technical architects forum.
https://avega.se/event/sap-technical-architect-forum-a-knowledge-sharing-event-hosted-by-avega/
If anyone working in the Scandics is interested, my company Avega is in the process of starting up an SAP Technical architects forum, for any senior SAP developers, or SAP tech architects to join who maybe interested (its free to join). This forums purpose will be to host quarterly knowledge sharing sessions so that we can all learn from our shared best practices, and from our shared mistakes too, and so improve our technical understanding through our shared knowledge, and be ready for all the future challenges that will come our way.
And finally a little disclaimer, neither myself nor Mattias have any kind of working relationship with SAP Press or the authors of Clean ABAP, apart from being customers of SAP Press, and enjoying "Clean ABAP".
SAPSA (For those that may be unfamiliar) is the Swedish SAP user group (so similar to DSAG or ASUG).
SAPSA is often interesting and engaging, it’s a great opportunity to catch up with the latest innovations from SAP, to re-engage with old-collegues from across Scandinavia, to meet new ones, to talk with the real SAP experts, and to raise your knowledge levels a little, and for me this year it became a substitute for being at Teched in person, now that it has left European shores (please SAP bring teched back to Europe!).
SAPSA started off with a bang with a keynote "Racing with the red queen" that highlighted the rapid pace of change in the world that we are living in, that we all need to be a rabbit (or was that a hare?) to keep up with the changes in our rapidly evolving SAP tech world. SAPs’ latest innovations now include generative AI in CAP and soon to come to the ABAP BTP platform as well. Customers must be agile, and keep their cores clean is being heard repeated year after year.
Technical debt 2.0
I attended 2 really interesting presentations from m-skrzyniarz (from Int4), the first a fascinating dive into where we (in the SAP world) really stand with generative AI today (from his own investigations and perspectives). Mateusz has blogged quite a lot on this topic, something for me to catch up on. My own topic of focus for this SAPSA was around the relationship of technical debt to clean code, I found it fascinating that Mateusz also considered the implications of using generative AI to the potential future technical debt situation this can take us. A key question it raises: are we going from a world of technical debt in ABAP created by humans, to a future world of increased technical debt created by generative AI? Will this new world be that much better as a result? Will our code be cleaner or more messed up than ever?
My own thoughts here, perhaps the real breakthrough is to ensure the machine learning also trains on the principles of clean code, I was reading that MIT trained a machine learning algorithm to behave as different behaviours of a scrum team, so some as code reviewers, some as designers and some as testers, perhaps with this approach even generated code could be clean, but not yet. Mateusz focussed on the challenges for the generative AI to understand the differences between standard and custom code, this will surely require training across a myriad of customer systems, and perhaps this will become a barrier for the generative AI within the ABAP space (as customers systems are often in private cloud or on premiss), who knows? It was a really interesting topic and it certainly got me thinking.
The second presentation also from Mateusz on the possible impediments to our S/4 upgrade journeys, I also found myself to be in full agreement with. There is no point to upgrade to S/4 if all we do is continue to code like its 1999 (a topic I have blogged on previously), before we get there, we must focus on training our developers to upgrade their skillsets, to include CDS, RAP, ABAP Unit and the latest and greatest from SAP. If we do not make the effort to make our code bases cleaner and more modern, we will hinder our ability to deliver with any kind of agility. Then understanding our technical solution well before we embark on our S/4 upgrade journeys is also critically important to success.
Standing on the shoulders of giants The giant being Ward cunningham and Uncle Bob, then thats me in the middle presenting.
All of which leads me onto the topic that I was there to present alongside my friend and colleague Mattias Johansson. In our presentation we presented the journey to Clean ABAP, why clean ABAP is more than just a style guide. How we should learn from the industry giants of Robert C Martin and Ward Cunningham by standing on their shoulders, to solve our technical debt problems in our ABAP code. Our technical debts have accumulated over many years of custom code delivery, by applying the principles of clean code that are now adapted to SAP ABAP by klaus.haeuptle, florian.hoffmann and co in their book on Clean ABAP (2021 SAPPress). Thanks to this publication and the online Git guide we now have a clear guide on what practices to apply, how to begin applying them, by starting conversations on the important topics in conversations within our development teams. In my own team we are deciding on our own Clean ABAP cheat-sheets to become our new programming guidelines for our own organisations. The challenge of adapting legacy code can be approached by applying the boy scout rule whenever we make changes, and encourage all developers to follow this priniciple, so that our ABAP code base becomes incrementally cleaner with every new change we make. Then apply Clean Islands to new development, to ensure we build new changes in the right way from the start. The work of introducing these principles with our teams is critical as Mattias clearly pointed out. Additionally we now have a whole armoury of tools to help us get there, in terms of Code Pal, ABAP Cleaner, ABAP Lint and more.
The challenge as I see it today, is that SAP tech is often far advanced of customer reality, and our only hope of keeping up, is to clean our code bases and be ready for the future challenges that come. So our message is: now is the time for us all to start cleaning our code bases, wherever we are in our SAP tech journeys. We are all ABAP Cleaners – so lets get cleaning!
The second day of SAPSA brought with it a late reminder (better late than never) that we must all be ready to upgrade to S/4, that there will be no further extension of the deadlines from SAP, and the reasoning behind this became clear, legal issues, vendor addon complications, the cost and complexity to SAP of keeping alive these really old versions of SAP. They all point to one thing, we must all get ready now for S/4, no exceptions!
I also managed to engage some of the really learned SAP experts at SAPSA and had some fun with the slightly unexpected conversations. In particular a crazy chat surrounding the possibility of making ABAP a prepackaged delivery similar to JAVA. I would argue if you can precompile ABAP as opposed to have it generated on transport import, this would really make ABAP significantly more flexible, and so more agile friendly. In the past this has not been possible (I suspect due to hardware dependencies), but for a BTP Rise platform, where the hardware implementation is under SAPs control, we can remove the issue of needing to make ABAP compatible with all possible hardware, pre-compilation/generation becomes a possibility. I was then referred to look into ABAP Git, and sure that is a part of the puzzle, but not the whole picture. This was fun and interesting, and I would recommend all to engage with SAP at these events to discuss curious possibilities (even if they appear somewhat crazy on the surface). This is also why we need teched in person, not just online.
I would like to say a big thank you to the organisers of SAPSA (Pontus and co) and to all of my fellow speakers who helped to make it a truly memorable event. I look forward keenly to our next get together, and encourage everyone to engage with their local SAP user groups.
And finally a little advert for our (Avega) swedish based technical architects forum.
https://avega.se/event/sap-technical-architect-forum-a-knowledge-sharing-event-hosted-by-avega/
If anyone working in the Scandics is interested, my company Avega is in the process of starting up an SAP Technical architects forum, for any senior SAP developers, or SAP tech architects to join who maybe interested (its free to join). This forums purpose will be to host quarterly knowledge sharing sessions so that we can all learn from our shared best practices, and from our shared mistakes too, and so improve our technical understanding through our shared knowledge, and be ready for all the future challenges that will come our way.
And finally a little disclaimer, neither myself nor Mattias have any kind of working relationship with SAP Press or the authors of Clean ABAP, apart from being customers of SAP Press, and enjoying "Clean ABAP".
- SAP Managed Tags:
7 Comments
