The SAP developer transformation

The original SAP developer

In the first years of SAP and adoption the product creation process was different. Software was developed by SAP together with the customers. The functional experts from customers had direct contact with the developers at SAP. The SAP employees were maybe even sitting directly at the customer and developing the software there. After shipping the software, it was adjusted by functional experts from the customer. The same that influenced already the creation process. As many times people from SAP were still working closely with the customer, perhaps still on site, these customer adjustments influenced directly the SAP standard. Why was this deep knowledge exchange and cooperation possible? The functional experts from the customer were the people with a very good business understanding and that had the skills to translate this into code. The original SAP developer from the customer side was a business person with a good IT understanding. Not necessarily a “hard core” coder nor IT specialist. This was in the 70’s – 90’s, in the beginning there wasn’t even a degree for IT with business. The need for fast implementation and high value results nevertheless was already reality. No wonder that ABAP is one of the most important pillars of SAP’s success. ABAP is a 4GL programming language. And that’s for a reason: it enables business people to create programs fast by letting them focus on the outcome. If a report was needed and SAP did not offer this in the standard, it was easy for the business person to create a custom report, displaying data from several tables. Entering or changing data was also an easy task, as long as the person learned the basics of the SAP system (and IT). This is also one of the main reasons why SAP was such a success.

The original SAP developer was not a computer scientist. It was a business person with a specific problem and they had no problem to solve it by themselves in SAP. No add-on product needed, no 3^rd party software or consulting company involved (ok, freelancers). It was the employee that had to deal with a problem and solved it. This was possible not only because SAP allowed their customers to create custom applications. The world was a different one. And yes, the world was simpler. Until the 2000s an SAP system was an integrated system. It was not unusual to have (almost) all processes and data in SAP, maybe even in one SAP system. Not only the system landscape was easier. DEV, QA; PRD? People worked directly in production, meaning their changes were available immediately. There were fewer legal requirements. The world was less international. 24/7 and zero downtime were not a requirement.

The new SAP developer

Today the world is different. What made an SAP developers 30 years a hero for the organization will get you fired today. Accessing data from several systems is not only complicated because the communication nowadays is across several heterogeneous systems, protocols and data formats. Just getting it legally correct is a challenge. Transporting software is a complex tasks and developing evolved drastically. Today you need (ok, SAP world, you should have) a repository, code checks, unit tests, integration tests, package apps, distribution, and many more tasks. You might find people saying that they do not understand why today it takes so much longer to develop and rollout solutions. That junior consultants are not trusted as they were in the 90s. The reason is simple: the world did not stop spinning, and so did the ERP and business world. A small error that once only affected a team of maybe 10 people and a handful of customers, today might take down business in a whole region.

Transition

With this the profile of an SAP developer changed. I’ll take inspiration from one of the more known SAP graphics of the last decade to illustrate this.

The classical SAP developer role changed to a person with a very strong computer science background. The new SAP developer is still not a nerd. SAP developer then and now are not going to build a media center solution, a new audio compression format, or a streaming solution for videos. They are fully aware that an SAP system is used by their employer to solve business problems. That’s the reason the ERP system was installed. And their role is to ensure that the process supports the business. But they are not the business people. They are not the ones that define the process. They work together with the business side, implement the process, learn the process, and can get a good understanding if they stay long enough in the same area.

The transition was that the classical SAP dev was replaced by the new SAP dev. The task of doing was shifted down. The task of influencing, defining the process and what to do, was taken away from the SAP dev. This means that valuable business knowledge is lost. The business persons that knows the process end to end nowadays is rarely writing code. They define specifications, monitor processes, optimize them. The actual SAP developer is “reduced” to the doing role. Defining the process, directly identify small gains that bring great benefit is rarely happening.

The business knowledge, that once was brought down to code, is now gained through code and partially goes back to business.

Less contribution is possible for the new SAP developers. It takes time, if not years to gain the business knowledge through projects and code. Knowledge that the business side already has, logically. This is indicated by the thickness of the arrows in my graphic. This transition in roles is a problem. This makes it harder for customers to get benefit and business vantages out of using SAP software. A missing report that can help a team to solve faster a problem adds tremendous value. If they now need to first find budget, time, an implementation partner, a project, and a sponsor to get the report implemented, likely that the report will never be realized.

Modern complexity

SAP is aware of this. They never gave up on the business person that has the skills to develop solutions. For SAP this is the key user. An employee that works closely with the real end users (or is one of those) while at the same time defines what kind of features a solution must offer. Or that even tries to offer such a solution by developing it. For Analytics, there are many self service features available. Many presentations highlighted the possibility that end users can create the reports they need. For the SAP Portal, there was Visual Composer. A tool to easily create apps by using existing services. SAP Fiori lets the user adopt the UI. S/4HANA comes with key user extensibility. Latest take on this is AppGyver. It seems that for SAP the world is still the same as 25+ years ago.

Depending on the scenario this might work. Most time it won’t work as in SAP’s dreams. Landscapes are complex. What was once one integrated system is now split up into several cloud services like Ariba, SuccessFactors, Concour. The one ERP system is split into a FI system, CRM, SRM, Logistics. Add BI and other office services like SharePoint. And then repeated for several regions or countries. As stated above, add legal, corporate rules, governance, compliance, etc. It is complicated.

This is a serious problem for companies. The transition from the new SAP developer back to the classic SAP developer is necessary. More SAP developers must start as business people. Therefore, more business people must be back to coding. One approach can be to get both better aligned by moving them closer together. Low code can help. For this to work, companies as well as SAP must understand that some very hard work must be done before hand. Learning is a building block, as well as seamless integration. Looking at the market and the offering, my impression is that the solution providers still think that the situation is as 20+ years ago. A solution made for a profile from decades ago, offered for the users and their problems today, this won’t work as expected.