SAP Development Language and What Businesses Need to Know

• SAP sits at the centre of how a significant number of large and mid sized businesses manage their core operations. Finance. Procurement. Supply chain. Human resources. The breadth of what SAP covers and the depth to which it embeds itself into business processes means that decisions about SAP development are rarely straightforward.
• Understanding SAP development language options is not just a technical question. It is a business question about how the organisation extends, customises and integrates its SAP environment in ways that serve operational needs without creating technical debt that compounds over time.

What SAP Development Actually Involves

• SAP development covers a range of activities that are worth distinguishing from each other before evaluating options or partners.
• Custom development within SAP. Building functionality that does not exist in the standard SAP system. Reports that reflect how the business specifically needs to see its data. Workflows that automate processes in ways the standard system does not support. User exits and enhancements that modify standard SAP behaviour without changing the underlying code.
• Integration development. Connecting SAP to other systems the business uses. A CRM that needs to exchange customer data with SAP. A manufacturing execution system that needs to pass production data to SAP. An e-commerce platform that needs to interact with SAP inventory and order management. These integrations are where much of the real SAP development work in most organisations sits.
• Migration and upgrade work. Moving data and custom development from one SAP version to another. S/4HANA migrations in particular have generated significant development work as organisations move from legacy ECC environments to the current SAP platform.
• Reporting and analytics. Extracting data from SAP in ways that support business decision making. Whether through SAP’s own analytics tools or through external BI platforms that consume SAP data.

The Primary Development Languages

• SAP development language options have evolved significantly as SAP has developed. Understanding what each language is used for and where it fits helps clarify what is involved in different types of SAP development work.
• ABAP is the foundation. Advanced Business Application Programming has been the primary SAP development language since the early days of the platform. The vast majority of SAP’s own application code is written in ABAP. Most custom development in SAP ECC environments is ABAP. Most organisations with a significant SAP history have ABAP code running in their systems that they may or may not fully understand.
• ABAP has evolved significantly. Object oriented ABAP. ABAP for HANA that leverages the in memory database capabilities of the SAP HANA platform. ABAP RESTful Application Programming Model that provides a framework for building modern SAP applications following current development best practices. The language that was characterised as legacy by those promoting newer alternatives has continued to develop in ways that make it relevant for current SAP development work.
• JavaScript and TypeScript through SAP UI5. The user interface layer of modern SAP applications increasingly uses SAP UI5 which is built on standard web technologies. Development in this layer uses JavaScript and increasingly TypeScript. For organisations building custom SAP Fiori applications the front end development work uses web development skills rather than ABAP.
• Java and other languages through SAP Business Technology Platform. SAP BTP provides a cloud platform on which applications and integrations can be built using a range of programming languages. Java. JavaScript. Python in some contexts. The BTP environment extends what can be built in and around SAP beyond what is possible within the ABAP environment alone.
• SQL for HANA development. Direct development on the SAP HANA database using SQL script and other HANA specific capabilities. Relevant for performance critical development that benefits from pushing logic down to the database layer.

The S/4HANA Context

• The migration from SAP ECC to S/4HANA is the most significant SAP development context for many organisations right now and for the foreseeable future. Understanding how SAP development language choices are affected by S/4HANA migration matters for organisations at any stage of that journey.
• S/4HANA deprecates significant amounts of custom ABAP code that was developed for ECC environments. Custom code that accesses database tables directly in ways that are not compatible with the HANA data model. Code that uses function modules that have been replaced or removed in S/4HANA. Enhancements that relied on ECC specific behaviour that has changed.
• Custom code assessment before S/4HANA migration is essential. Understanding what custom development exists. Whether it is still being used. Whether it is compatible with S/4HANA or needs to be remediated. What the remediation involves and how complex it is. Skipping this assessment produces migration projects that discover their custom code problems at the worst possible point.
• The ABAP RESTful Application Programming Model represents SAP’s current recommended approach for building new custom functionality in S/4HANA environments. Custom development that is built following this model is better positioned for the evolving SAP landscape than development that uses older ABAP programming patterns that SAP is moving away from.

Integration Development in the Current SAP Landscape

• Integration is where much of the most practically important SAP development work happens for most organisations. The SAP system rarely operates in isolation. It exchanges data with other business systems. Those integrations need to be built, maintained and evolved as the systems on both sides change.
• SAP Integration Suite on BTP is SAP’s current strategic integration platform. It provides pre-built connectors for many common integration scenarios alongside the tools to build custom integrations. Organisations building new integrations in the current SAP landscape should evaluate Integration Suite before building custom point to point integrations that create maintenance overhead.
• The older SAP PI/PO middleware that many organisations have used for integration is still running in many environments. Development knowledge for these platforms remains relevant for organisations that have not yet migrated to the current integration approach. Understanding which integration approach an organisation is using and where it is heading shapes what development skills and tools are needed.
• API based integration using standard REST and SOAP APIs is increasingly the approach for connecting SAP to external systems. Many SAP Fiori applications expose OData APIs. BTP applications can expose custom APIs. External systems that connect to SAP through well defined APIs are less tightly coupled than those using older integration approaches and therefore easier to maintain as SAP evolves.

Finding the Right SAP Development Partner

• SAP development language knowledge is a necessary but not sufficient qualification for an SAP development partner. The technical ability to write ABAP or build UI5 applications needs to be accompanied by the SAP functional knowledge to understand what the development needs to achieve in business terms and the SAP architecture knowledge to build in ways that are supportable and aligned with where SAP is heading.
• SAP development done well requires understanding how the standard SAP system works before deciding what custom development is actually needed. Many custom development requests can be addressed through configuration of standard functionality or through standard SAP enhancements rather than bespoke custom code. A development partner that defaults to custom code without exploring these alternatives creates an unnecessary maintenance burden.
• SAP development done poorly creates technical debt that compounds over time. Custom code that bypasses standard SAP mechanisms. Integrations that are tightly coupled to specific system versions. Development that works today but creates problems when SAP releases updates. These are the problems that emerge from development that prioritises immediate delivery over long term supportability.

What Organisations Should Expect From SAP Development Work

• Regardless of which SAP development language is involved, good SAP development work shares consistent characteristics.
• Clear understanding of the business requirement before any development begins. SAP development that starts from technical design without adequately understanding what business problem is being solved produces technically correct code that does not quite address the actual need.
• Development that follows SAP’s recommended patterns and practices rather than finding creative workarounds that happen to work today. SAP upgrade compatibility and long term supportability depend on custom development that respects the constraints and extension points that SAP provides rather than bypassing them.
• Proper testing across the scenarios the development will encounter in production. SAP systems are complex and interdependent. Development that has not been tested against the full range of relevant scenarios produces surprises in production that are expensive and disruptive to resolve.
• Documentation that allows someone other than the original developer to understand what was built and why. SAP development that exists only in the system and in the mind of the developer who built it creates dependency that becomes a serious operational risk when that developer moves on.

Getting SAP Development Right

• The organisations that manage their SAP development well are not necessarily the ones with the largest SAP teams or the most complex customisations. They are the ones that develop only what is genuinely needed, build it in ways that are maintainable, and manage their custom development landscape as a portfolio that needs to be understood and kept current rather than accumulated without oversight.
• SAP development language choices and the development practices that surround them determine whether custom SAP work creates lasting value or accumulates technical debt. Getting those choices right requires both technical knowledge and business understanding that the best SAP development partners bring together rather than treating them as separate concerns.
• EZYPRO works with organisations navigating SAP development challenges. Bringing the technical depth to build in SAP environments properly and the business engagement to make sure that what gets built actually serves the operational needs it was created for.

Questions Worth Asking

How do we assess whether existing ABAP custom code is compatible with S/4HANA before starting migration? 

• SAP provides tools including the Custom Code Migration Worklist that assess custom code compatibility. A proper custom code assessment before migration planning begins gives realistic input into migration scope and complexity rather than discovering incompatibilities during the migration itself.

How do we decide between building custom development and configuring standard SAP functionality? 

• Ask specifically whether the requirement can be met through configuration or standard SAP enhancement before committing to custom development. Development partners with strong SAP functional knowledge are better positioned to answer this question honestly than those whose primary skill is technical development.

How do we manage custom SAP development as a portfolio rather than as individual pieces of code? 

• Maintain a custom development inventory that records what exists, what it does, who uses it and when it was last reviewed. Review custom development regularly against whether it is still needed and whether it is still compatible with the current SAP environment. Custom development that nobody uses still creates upgrade and maintenance overhead until it is removed.