Is HANA the end of ABAP Objects?
Long time has passed since I wrote my last ABAP Objects blog. I have been working as a development lead during the past years, focusing mainly on leadership and concepts such as design thinking and lean. I am in the middle of a major SAP implementation and therefore a question that is puzzling me a lot is: “How will HANA impact our object-oriented ABAP design?” As a devoted ABAP Objects believer, I still often get into basic discussions with developers on why to use ABAP Objects. Some clever developers argue that “HANA is the end of ABAP Objects”. In this blog I will briefly describe some of my thoughts on this delicate subject. I am not an HANA expert, my knowledge merely covers some basics about HANA that can be found here on SCN. However, I probably represent the majority of SAP customers and therefore my thoughts might be inspiring for others to comment this blog post or write a better blog themselves.
Let’s start with the top five reasons why I prefer object-oriented (OO) programming for ABAP:
- Reuse. Objects are self-contained and therefore reusable.
- Complexity. OO is ideal for breaking complexity into smaller and more manageable units with different responsibilities. ABAP developers often spend vast amounts of time to find out how BAPIs work and what impact various parameters (in those huge signatures) have on the functionality. Wrapping BAPI calls into methods with reduced signatures often makes it less complex for other programmers to use the BAPIs.
- Consistent business rules. Reusable code makes it is possible to write business rules centrally. Changes to the business rules will impact all code using them and thereby keeping them consistent.
- Division of labor. The division of labor comes with both reuse and structure of OOP. Senior developers can work with a central library and less experienced developers can focus on peripheral implementations.
- Maintainability. In my opinion OOP is more structured and therefore easier and faster to grasp. Once the logic is understood, changes can be implemented centrally which reduces the development time significantly.
If HANA is the end of ABAP Objects, then it would imply that the above mentioned benefits will erode with HANA?
- Reuse. I currently cannot see any reason why HANA will prevent us from creating reusable code. Even if the calculations are no longer done in the application layer, it is probably still smart to wrap HANA calculation calls in methods and bundling HANA calculations for an object in a class.
- Complexity. Sometimes I hear the argument that HANA is so fast that it is better to place all code in the UI layer. Wait a minute! Technically there is nothing preventing a developer from writing select statements or BAPI calls directly in the UI layer today, but to achieve the above mentioned benefits we do not. I cannot understand why this should change with HANA.
- Consistent business rules/Division of labor/Maintainability. Same as above assuming that 1 and 2 are fulfilled.
My best guess is that ABAP Objects is here to stay, but there will probably be HANA specific design patterns. Does that mean that code written in ABAP classes will stay the same? Surely not. As described in various blogs here on SCN, code pushdowns will have a significant impact on existing code, for example calculations on internal tables.
To sum it up, is HANA a good excuse to not learn ABAP Objects? No, HANA is not the end of ABAP Objects! OO is a paradigm that is not directly related to HANA. However, HANA will most likely change the code within existing objects and the data that is passed between the objects.
I would love to see more ABAP Objects on HANA blogs. Why not start by showing us how SAP is implementing the ALV framework?