SAP standard development is very different from traditional customer projects as you are contributing to products that may be used by thousands of customers worldwide. That changes everything: quality expectations, development processes, testing requirements, release management, and even the way you name your objects.
In this article, we will share practical lessons from SAP standard development projects and explain the tools, processes, and best practices every ABAP developer should know before joining such a team.
In customer projects, developers often focus on delivering functionality within a specific timeline and budget.
In SAP standard development, the priorities expand to:
As a result, SAP developers must think beyond "Does it work?" and ask:
"Will it still work correctly in future releases, maintenance packs, hotfixes, and customer systems?"
Before writing a single line of code, it's important to understand where your changes will travel.
SAP Standard Projects Environment usually consists of Development (Infinity) and Delivery Landscapes (for each major release), where both include:
All systems within the SAP environment are controlled by the central system called Development Landscape Management (DLM).
This separation ensures development activities do not interfere with testing and maintenance work.
Most SAP standard projects follow three major milestones:
The deadline for implementing new features.
At this stage:
Only bug fixes are allowed.
Developers work closely with QA teams to resolve issues found during testing. After CC dev systems are locked, any further changes must be justified to regain access, which may be granted only by Quality Managers (usually from the SAP side).
The final opportunity to apply critical fixes before release.
After ECC:
This release discipline helps ensure product stability at scale.
One of the quickest ways to identify an experienced SAP standard developer is by looking at object names.
SAP heavily relies on consistency.
Typical conventions include:
These conventions improve readability and make large codebases easier to maintain.
For CDS Views and RAP development, naming becomes even more regulated.
SAP uses the Global Technical Name Catalog (GTNC) to ensure consistency across products and teams.
A CDS view name usually consists of:
Example:
Where:
When creating a new CDS view, developers typically submit a naming request in GTNC. The tool validates the proposed name against SAP naming rules, including prefixes, suffixes, approved abbreviations, and length restrictions. After validation, the name must be approved by the responsible SAP experts before it can be used in development.
Global field names follow a separate process and are often even more important than CDS view names.
Before introducing a new field, developers are expected to search GTNC for an existing approved field name. Reusing established names improves consistency across SAP products and helps ensure semantic alignment between CDS views, data elements, APIs, and UI artifacts.
For example:
Boolean indicators should typically start with Is or Has
Date fields should contain Date
Time fields should contain Time
Description fields usually end with Text or Name
If no suitable field exists, a new global field name can be requested through GTNC. The request is reviewed against naming standards and business semantics before approval. As with CDS views, developers should prefer clear business terminology over abbreviations whenever possible and stay within the 30-character limit.
A practical rule of thumb: create new CDS view names when necessary, but create new global field names only when reuse is not possible. In SAP standard development, consistency is usually more valuable than originality.
SAP standard development is built on three quality pillars.
In many customer projects, unit testing is optional.
In SAP standard development, it is not.
Typical expectations:
Example:
Unit tests provide confidence that future enhancements won't break existing functionality.
ATC is the primary quality gate.
Before delivery:
No Priority 1 findings
No Priority 2 findings
ATC checks typically cover:
Developers should review findings regularly instead of waiting until release week.
Pragmas should not be your first choice.
A better approach is:
This aligns with SAP's clean-code philosophy.
Performance matters because SAP products run in thousands of customer environments.
One common anti-pattern:
This generates multiple database calls.
A better solution:
Using SAT, developers can identify:
The goal isn't perfect performance, but we should still eliminate major bottlenecks before customers experience them.
Transport management becomes significantly more sophisticated in SAP product development.
The process revolves around:
Represent a business topic or backlog item.
Contain transport requests related to that topic.
Best practice:
Public Cloud introduces stricter governance.
The hierarchy becomes:
Key principle:
Deliver complete features, not isolated technical changes.
Once an increment is integrated, changing its scope becomes difficult, so planning is critical.
A challenge in SAP standard development is maintaining multiple release streams simultaneously.
Sometimes systems are not connected through transport routes.
That's where UDO (Upport/Downport Overview Tool) comes in.
UDO helps:
Without UDO, developers often resort to manual copying—a risky and error-prone approach.
Many developers think development ends after go-live.
In SAP standard development, that's when maintenance begins.
Maintenance is delivered through:
Contain:
Contain:
For urgent customer issues, SAP uses Notes.
A note typically includes:
Developers create correction instructions containing the exact code delta customers need to apply.
Public Cloud follows a different model.
Key concepts include:
Released approximately every two weeks.
Reserved for critical production issues.
Emergency patches require additional approvals and should remain exceptional events—not part of normal development practice.
One of the most valuable lessons from SAP standard development is understanding that large-scale software is a team sport.
Developers regularly interact with:
When issues arise outside your ownership area:
The application component structure exists for a reason: ownership and accountability.
Before releasing your next feature, ask yourself:
SAP standard development requires a different mindset than implementation projects. The focus shifts from simply delivering functionality to building maintainable, high-quality software that can survive multiple releases, maintenance cycles, and customer landscapes.
Developers who master tools like ATC, SAT, GTNC, UDO, and SAP's release management processes become far more effective contributors in any enterprise-scale ABAP project.
Finally, the best SAP developers write code that remains reliable long after the release date.