When a request lands, the team picks one of two roads: solve it with a definition, or open a development. The choice usually gets made on who is free that week rather than on technical grounds.
Both roads carry a cost. Opening a development ties every later change to source code; three months on, somebody reads that code to work out why the report was written the way it was. Solving it with a definition stops at its limit: when the requirement runs deeper than a definition can express, you change direction mid-project.
What the work solved by definitions has in common
On reading, joining, filtering, output layout and distribution, a definition is usually enough. An iDataView report definition covers the source, the fields, the joins, the conditions, the selection screen and the output layout; the generated ABAP code moves into SAP with a transport request. Transfer projects are built from field mappings, a load method and package settings. Service, email and file outputs stay at the same level.
What those share is this: the result stays readable as a definition. A change does not send you back to source code, and whoever opens the definition can see what was done and why. The gain is not a speed claim; it is the working life of whoever inherits that definition six months from now.
Four places where code is still required
- Complex business rules. Chains of conditional calculation, exception handling and process logic can run deeper than a definition can express. The product leaves room for custom ABAP code blocks, class and module references and custom conversions — but what goes inside that block stays your responsibility.
- Performance tuning. How generated code behaves at a given volume comes down to index and access path decisions. That work sits with developers and BASIS; the fact that code can be generated does not prove how it performs.
- SAP business validation. Writing a row into a table does not make the record valid in business terms. A transfer flow writes to the target table in packages; where standard validations must run, the BAPI/RFC path and developer review are required.
- Recovery after a failure. If one package fails, rows written before it can remain in SAP. There is no end-to-end rollback across packages, so somebody has to design the rerun and reconciliation scenario.
Which box does the request fall into?
Three questions are usually enough to sort one. Is the result a read, or does it create records in SAP? Can the rule be expressed in a single definition, or are exceptions being managed? And how many times larger than today’s test data is the expected volume?
The third gets skipped the most. A definition that runs cleanly on test data can behave differently at production volume, and discussing that difference at the start of a project beats discovering it in the middle.
The conclusion is plain: a low-code approach does not remove the need for ABAP developers or BASIS. What it changes is the division of labour — repetitive definition work moves into product flows, and developer time is left for the parts that genuinely need code. Take five requests from your backlog and sort them with those three questions; seeing which box turns out fuller than you expected is a good way to open the capacity conversation.