Citizen Developer Dilemma

In a previous post I wrote about the original SAP developer: a business person that was able to not only adjust SAP standard, but also to enhance it via coding. Implemented business logic in code. Over the time the role changed, due to increasing complexity. Today, the original SAP developer is seperated into a functional and technical person. While the technical person still translates business logic into code, the formerly direct influence of the business logic is not given automatically. Here the functional consultant acts as an intermediate between process and code.

Citizen developer

SAP never stopped to deliver tools for the original SAP developer. The problem is only that these tools were not meant for the new SAP developer – aka coder – but for the functional consultant. The features offered yet were for the coder. The functional consultants however have problems using these tools. They are rarely able to realize their ideas in code. This is because the tools delivered by SAP are from developers intended for developers and are too hard to use for a functional consultant (e.g. Visual Composer was such a tool). SAP never stopped trying, and since a few months is using a new name for the original SAP developer: citizen developer.

Citizen Developer is the latest buzzword in ERP. Specially SAP adopted the term and is using it extensively in their marketing. My impression is that the term comes from Gartner, and they sold the idea to SAP. And SAP is more than happy to have the next big thing to push at their conferences, after IoT, Leonardo, Cloud. The train does not stop, analysts, partners, customers want to be entertained. For the next year(s) it is citizen developer. That’s business.

Independent of the term used, the world is nowadays more complex than 30 years ago. SAP installations are more complex, and this is given by the simple fact that the reality for companies is more complex. Worldwide distribution, contractors, business networks reaching countries all around the world, local laws, international laws, new ways of producing and shipping goods. For the SAP developer the challenges increased too. Do more stuff, more efficiently, faster. With this come shorter innovation cycles. For these challenges, people need tools to help them. It doesn’t matter what you think about Excel, but there is reason it is widely used: it allows to be “simply” enhanced using code. You do not need to be top developer to enhance Excel with some macros that make it a killer tool for people working in a department.

Challenges

One person with some Excel coding skills can add tremendous value to a whole team and help them to run a process better. Looking to SAP, it is way more difficult to enhance it and add some “simple” features. SAP transport management controlled by Solution Manager is the death to any innovation. This is where citizen developers enters the SAP universe. Enabling functional consultants to be highly productive be enabling them to adjust SAP without having to know too much about SAP coding. Consultant already adopted low code tools from Microsoft as they allow them to work the familiar tools from Microsoft, while working on SAP data. Unfortunately, nothing is as easy as shown in marketing slides.

For the citizen developer to be able to deliver on the promise of low code, several obstacles have to be removed first.

• Access: Single Sign-on, profiles, access to the services and data, across systems.
• Services: Consume data, a service that provides access to the data must be available.
• Integration: Between systems and data to be able to use the data. This implies a data model that allows to understand the data across systems and services.
• Availability: Not only available when needed, but accessible too. In the expected language and scenario, like offline.
• (and more …)

The obstacles are the citizen developer dilemma. It is easy to give the citizen developer the tools to develop low code apps. But the tools must also solve the above obstacles. These are super complex problems, and honestly, I do not see how the low code solutions that are marketed currently are solving all of these in a way that make them citizen developer ready. They try to solve some partially, or try to hide the missing support by putting other features in front.

Missing services

One of the main problems to make the citizen developer vision a reality are services. If your business problem is solved by combining two existing services, why wasn’t this already done? Why wait for low code to get someone to connect the dots? Because at least one service is missing and needs to be created. If a citizen developer wants to create a low code app that is using signals to trigger an action and notify a user, most probably the action and notification are already possible. What about receiving the signals like access to a site or email? If there is no way to read these signals, the low code app will never be realized. Which is bad, as the idea is there, the impact on the daily work, even the concept of what is needed and how to create the app or solution. Yet, important pieces are missing, turning the app into a dream and not a real asset. This is just an example, but I hope it shows that sooner or later a critical part in the app will be missing and must be created. Above example also shows why Microsoft is so popular: they offer a wide range of services and ways to connect them.

The question is now: how to create these missing critical services? It depends on the type of the service. Creating a complex business entity is out of scope for low code. Most of the time a “real” developer will be needed: create a service, API, publish, governance. And for the “easier”, lighter services? Does SAP already offer some features here?

SAP tools

For a motivated functional consultant CDS Views that expose some tables is doable. For the skilled ones, a simple RAP / CAP service. For low code apps, it should be sufficient to read some data from tables, or from existing reports (my friends from Cadaxo offer a tool that transforms reports into an OData service). Consuming exposed APIs, creating maybe even automatically some UI (via Fiori Elements) is already doable. A UI builder tool that makes it super easy to create apps, screens and FE annotations is missing, but MDK shows that this is possible. Workflows allow for intuitive connection of services, controlling the flow. Integration, security, app distribution, all of this is available in some sort from SAP.

Today SAP offers most you need to enable the citizen developer to perform. The problem is: it is still way too complex. It is a wide range of tools, from on premise to cloud that needs to be integrated. And still, you get several tools to solve one task: RAP, CAP, BAPI/report/ALV to OData, MDK/FE/AppGyver for UI, many workflow alternatives, etc. One tool to guide the citizen developer is missing. And then we do not even touch high risk areas like SSO or integration, data models, etc. As stated earlier, these tools get complex very fast. This is because they are developed by developers, for developers. Yet, SAP must solve it, it is their platform. A tool that is made for the citizen developer, that helps them through the process end-to-end: connecting systems, creating (simple) services, controlling the flow and deliver the result to the end user.

The citizen developer dilemma

Low code apps are created by functional consultant for the functional department and end user. Apps that connect the dots: services, information, and a control flow. We are talking here about apps that should only take a few hours to create. They add value and allow the people to work differently with the available data, exploring new ways of working. This frees up a tremendous number of resources. Simpler, yet powerful apps can be created. Apps that were never realized because of time, budget, spare resources can be brought to life. The “real” developers can focus on complex scenarios.

The citizen developer dilemma is that it is expected from them to deliver such apps. At the same time, they cannot create them because barriers that prevent them of doing this. Missing services, complex landscapes, Single Sign-on accross systems, a single tool to cut through all the complexitiy. They have to resort to the core developers again. They are stuck right in the middle of the expectation, reality and tools that just don’t fit the expectation.