Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Herndon. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 25 years of experience in SAP business process analysis and SAP systems integration. ITP is a Silver Partner with SAP, as well as an Appian, Pegasystems, and UIPath Low-code and RPA Value Added Service Partner. You can reach him at [email protected].
For decades, being an SAP developer usually meant becoming deeply skilled in the technologies that live inside the SAP ecosystem. ABAP was the center of gravity. JavaScript and SAPUI5 became increasingly important as the user experience moved toward web applications. More recently, SAP Business Technology Platform, cloud services, APIs, automation, and artificial intelligence have expanded the technical landscape again.
That expansion creates an important question for SAP professionals: what skills matter when the work is no longer confined to the ERP core?
Python deserves to be near the top of the list.
That does not mean Python is replacing ABAP. ABAP remains essential for many processes and extensions close to SAP business logic. Python serves a different purpose, particularly for data transformation, integration, testing, automation, migration, analytics, AI, and lightweight services.
For organizations modernizing to SAP S/4HANA, that distinction matters. The future SAP developer is part of a broader engineering environment in which SAP interacts with cloud platforms, external applications, data services, automation tools, AI models, and DevSecOps pipelines. Python provides a practical bridge into that world.
Why Python Fits the Direction of SAP 
One of the biggest changes in SAP architecture is the emphasis on keeping the ERP core cleaner and moving appropriate custom capabilities into well-governed extensions. SAP describes side-by-side extensibility on SAP Business Technology Platform as a way to build capabilities that are decoupled from the core, while on-stack extensibility remains available for requirements that need to execute inside the ERP environment.
That architectural shift changes the developer mindset. The question is no longer simply, “How do I customize SAP to do this?” Increasingly, the question becomes, “Where should this capability run, how should it integrate with SAP, and what technology is best suited to the job?” Python becomes useful because it is exceptionally strong outside the transactional core.
Consider a typical S/4HANA program. The ERP system may remain the authoritative transactional platform, but the modernization effort can also require millions of records to be profiled and reconciled, interfaces to be validated, spreadsheets and legacy extracts to be converted, test results to be analyzed, logs to be monitored, data to be prepared for AI, and external services to be orchestrated.
Python gives SAP teams an efficient way to handle those tasks without forcing every technical problem into the ERP application layer.
The first major use case is data. SAP environments contain enormous amounts of structured business information, but modernization efforts rarely involve SAP data alone. Teams may need to combine ERP data with flat files, legacy databases, data warehouses, external APIs, or cloud services.
Python has an extensive ecosystem for reading, cleaning, transforming, comparing, and analyzing data. For an SAP transformation team, this can be valuable during data migration, reconciliation, financial validation, interface testing, master-data analysis, or reporting. SAP PRESS similarly identifies data engineering, automation, integration, AI, and cloud development as areas where Python is becoming increasingly relevant to SAP professionals.
Imagine a migration team moving from ECC to S/4HANA. Instead of manually comparing large extracts before and after migration, a Python utility can identify mismatched records, calculate totals, flag duplicates, test transformation rules, and create exception reports for analysts to review.
The objective is not to replace SAP migration tools. It is to automate the analytical work around them. The same principle applies to testing. Python can call APIs, verify responses, compare expected and actual values, check file transfers, inspect interface output, and automate repetitive technical validations. Manual comparisons can become repeatable tests executed every time a build changes, which is particularly useful in regulated ERP programs where evidence and traceability matter.
Python and the Clean-Core Mindset
The clean-core conversation is another reason SAP developers should understand Python.
Clean core does not mean “no customization.” It means being more deliberate about where extensions are built and how tightly they are coupled to the ERP platform. SAP’s guidance distinguishes between on-stack and side-by-side extensions. Side-by-side extensions can run independently on SAP BTP and communicate with SAP S/4HANA through remote APIs, while on-stack approaches remain appropriate when functionality needs to execute within the ERP environment. This creates a natural architectural boundary.
When business logic must execute within SAP and participate directly in SAP transactional behavior, ABAP Cloud or another supported on-stack approach may be appropriate. But when the requirement involves external processing, automation, data science, AI, integration support, or a standalone service, a side-by-side architecture may make more sense. Python can be highly effective on that side of the boundary.
For example, an organization might create a Python service that receives data through an approved API, performs a specialized calculation or AI-assisted classification, and returns the result to an SAP-connected application while SAP remains the system of record. Python also has direct relevance to SAP HANA. SAP provides a Python extension module for SAP HANA based on the Python Database API specification, allowing Python applications to interact with HANA data when the architecture and security model support that pattern.
The bigger point is architectural, not linguistic. SAP developers should no longer assume that every requirement involving SAP must be implemented inside SAP. Sometimes the best SAP customization is the customization you do not put in the core.
AI Changes the Equation
Artificial intelligence makes Python even more relevant.
Much of today’s AI ecosystem has developed around Python. Machine-learning libraries, data-science frameworks, natural-language processing tools, model APIs, notebooks, and AI development examples frequently assume Python proficiency. For an SAP professional, this opens practical possibilities. A finance organization could classify transaction exceptions before human review. A supply-chain team could analyze historical data for anomalies. A support organization could summarize recurring incident patterns. A developer could combine SAP business context with an enterprise-approved language model.
The important architectural principle is that AI should not simply be bolted onto a production ERP environment. Enterprise teams still need security, governance, data controls, testing, access management, monitoring, and human review. Python does not remove those obligations. It simply gives developers one of the most mature toolsets available for building and experimenting with AI-enabled capabilities.
AI is also changing the developer’s own workflow. AI coding assistants can help explain code, propose unit tests, generate documentation, suggest refactoring, and accelerate routine programming, potentially shortening the learning curve for an experienced ABAP developer beginning to work in Python.
But AI-generated code should be treated as a draft, not an authority.
Developers still need to understand what the code does, validate dependencies, test outputs, check security implications, and ensure generated code complies with enterprise development standards. The SAP PRESS article that inspired this discussion makes the same important point: AI-assisted code still requires human validation before production use.
The Modern SAP Development Workbench
Learning Python is easier when it is paired with modern engineering practices. A sensible starting environment includes Python, Visual Studio Code, Git, and an enterprise-approved AI coding assistant. What matters most is the engineering discipline the environment encourages.
- Visual Studio Code provides a common workspace for writing, debugging, documenting, and reviewing code.
- Git introduces version control so developers can track changes, work in branches, review modifications, and return to previous versions when necessary.
Python virtual environments help isolate dependencies between projects. Dependency files make builds more repeatable. Environment variables and managed secrets help keep passwords, tokens, and API keys out of source code.
These practices are routine in modern software engineering, but they are especially important as SAP development becomes more integrated with cloud and DevSecOps processes.
An SAP developer learning Python should therefore avoid thinking in terms of standalone scripts stored on a laptop. The better model is to treat even a small automation utility like a software product. Put it in source control. Document what it does. Separate configuration from code. Create a repeatable environment. Add logging. Handle errors. Write tests. Review dependencies. Protect credentials. Use pull requests or peer review for production-bound changes.
Those habits matter more than memorizing Python syntax.
Teams do not need an ambitious AI initiative to begin. Good first projects are small, repetitive problems where success can be measured.
- Build an SAP data reconciliation utility. Compare two approved data extracts and produce a report identifying mismatched values, missing records, duplicates, and control totals.
- Create an API validation script. Call a non-production SAP or integration endpoint, verify response codes and required fields, and record the results as test evidence.
- Automate a recurring operational report. Combine approved SAP output with other enterprise data, apply established business rules, and create a standardized result for review.
- Develop a log-analysis utility. Scan interface or batch-processing logs for known failure patterns and produce an exception summary that directs support personnel toward the highest-priority issues.
- Prototype an AI-assisted business service. Using non-sensitive or synthetic data, demonstrate how an external AI capability could support an SAP business process while leaving the transactional core unchanged.
Each project teaches Python while solving a recognizable business or engineering problem. More importantly, each forces developers to learn the surrounding disciplines of APIs, source control, testing, security, and maintainability.
Summary
There is a risk in every modernization program of turning new technology into the objective. Python should not be adopted simply because it is popular. AI should not be introduced simply because executives are asking about AI. Side-by-side applications should not be created simply because clean core is the current architectural trending message.
The goal is not more technology, the goal is a better enterprise system.
That means fewer brittle customization, faster testing, better integration, more reliable data, repeatable automation, stronger engineering practices, and an architecture that can evolve without making every SAP upgrade a major remediation effort. Python can help achieve those outcomes because it expands what SAP teams can do without forcing all innovation into the ERP core. For longtime SAP developers, that is the real opportunity. Learning Python is not about leaving SAP expertise behind. It is about making that expertise more useful in an environment where ERP is increasingly connected to everything else.
ABAP knowledge tells you how SAP works. Python gives you another way to work with the world around SAP.
The developers and architects who can do both will be better prepared for the next generation of SAP modernization, where clean core, cloud integration, automation, data engineering, and AI are no longer separate conversations. They are becoming parts of the same enterprise architecture.
