Those of us who have been in the SAP game for a few years will remember the days when object-oriented ABAP was considered exotic. Ten, fifteen years ago, most ABAP developers had been brought up exclusively with procedural programming in ABAP (and often COBOL), and there were only a few younger developers in the SAP world who had grown up with Java and other object-oriented programming languages and to whom the concept of object-orientation in programming was natural.
Managers and team leads are typically about least five years more experienced than the average of their team members, and so among managers, the percentage of those with previous exposure to object-oriented programming was even smaller than in the general developer population.
The result? When faced with the question: “Should we adopt object-oriented development,” in most teams about 70% of the team members were against it, and most managers followed the majority and decided against object-oriented development.
Fast-forward to fifteen years later, and ABAP OO is absolute mainstream. One of the main drivers for this is that development in customer projects doesn’t take place on an island.
As a result, slowly but steadily ABAP Objects has taken over most of SAP development. Granted, there are still niches and comfort zones for strictly procedural developers even in the S/4 HANA world, but these become smaller and smaller as method calls and object instantiations become more and more inevitable when interacting with the SAP standard codebase. ABAP Objects is now completely mainstream.
Just as soon as development teams are beginning to feel comfortable with ABAP Objects, around the corner comes the next paradigm programming paradigm: CDS views. (Don’t get me wrong, they’re not replacing ABAP Objects, but they’re a new technology at the very core of SAP’s business applications just like ABAP, object-oriented or not.)
In SAP’s recent development, especially in the S/4 HANA space, CDS views are hugely important. CDS views with annotations are the core technology for building anything new along the lines of:
Paradoxically, CDS views are even crucial for building compatibility of refactored applications with old programs through compatibility views, which replace some transparent tables that used to hold redundant data.
I often coach development teams who want to learn the new technologies. Those teams where the decision process towards adopting new technologies has already taken place and management has approved the expenses for hiring an outside coach are very enthusiastic and open-minded in adopting new technologies.
Of course, many teams haven’t reached this point yet: They aren’t yet aware of how much SAP’s programming paradigm has changed with S/4 HANA, and expect that they’re going to get along just fine with the skills and knowledge that served them well working with ECC 6.0. Team managers don’t yet realize they need to build new skills in their teams, because everything looks similar to the way it used to.
Customizers and developers are pretty comfortable when they look into what they think are transparent tables via transaction SE16 (even though they do get irritated when they insert a record via ABAP and it doesn’t show up in SE16 or their subsequent OpenSQL SELECT attempt, because both get redirected to a CDS compatibility view instead of accessing the database table into which the record was inserted). Many teams are in denial.
When confronted with and challenged by a lot of new stuff technologically, it may be tempting to close one’s eyes and deny the relevance or urgency of dealing with the technology.
When there is a new technology but you’d prefer not to deal with it, these are some easy ways to deflect it (and justify your denial):
Where will such an attitude get them? Where did it get the laggard teams from ten, fifteen years ago?
The earlier and especially the most whole-heartedly (i.e. quickly) someone adopts a new paradigm, the sooner they leave the stage behind during which they create very messy code. The more hesitantly and slowly someone adopts a new paradigm, and the longer they drag it out, the longer the stage during which they create messy code, and the more liabilities they create during that stage.
Following from that, my recommendation is to embrace significant new paradigms head-on and with plenty of energy. Give yourself the time to learn, ideally in a playful way. Use a sandbox system, build prototypes, extend your knowledge, and don’t be afraid to create a big mess, because it’s a learning process.
But which new developments are “significant”? Clearly, few people are in the luxurious position of being able to learn every new thing. Most of us have to make choices and invest in some skills, while we leave others for later or indeed never.
In the SAP world, when choosing which skills to build and into which knowledge to invest, it’s always wise to look at what SAP is using for its own application development.
Currently, this is clearly the combination of CDS views with annotations, BOPF, and OData. These are the key technologies to understanding what’s even going on in S/4 HANA, and without which developers will simply be unable to figure out what the standard does, how to extend it, and how to troubleshoot it. Don’t let your team be that team.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
37 | |
10 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
2 | |
2 |