Written by: Bhavin Topiwala, Director R&D – Integration @ Nakisa
- Many Enterprises Use SAP ECC or S/4HANA. But What Are They, Exactly?
- What Is SAP ERP Central Component (SAP ECC)?
- What Is SAP S/4HANA?
- What Are Key Differences Between SAP S/4HANA and SAP ECC?
- Data Modelling Methods – Multiple Data Tables vs Single Data Tables
- Accounting Methodology
Many Enterprises Use SAP ECC or S/4HANA. But What Are They, Exactly?
Everybody in enterprise world has heard of and uses some version of SAP products. SAP ECC and SAP S/4HANA are especially popular. However, very few people truly understand the difference between them. Consequently, their understanding of how to best choose solutions that work well or integrate with either or both is also impacted. In this two-part series, we’ll help you demystify the ways in which ECC differs from S/4HANA and highlight what modern third-party (finance) solutions need to do in order to integrate with, and bring value to, these two market-leading ERPs.
What Is SAP ERP Central Component (SAP ECC)?
SAP ERP Central Component (SAP ECC) is an on-premise ERP system that was introduced in 2005. It has one of the largest enterprise user bases today, owing to its longevity and the fact that it was expressly designed to work with third-party databases so that clients could create a powerful ERP uniquely tailored to their needs.
Many organizations heavily customized their ECC systems to serve their own use cases and to integrate with other mission-critical systems. Nearly 20 years later, companies are hesitant to migrate to newer systems, fearing upgrade costs and, especially, loss of stability. It’s worth noting that SAP ECC’s end of life is 2027, after which clients will have to pay extra fees to receive maintenance and support with no further upgrades.
What Is SAP S/4HANA?
SAP S/4HANA is a modular ERP solution introduced in 2015. Whereas ECC is a traditional client-server (disk-based) system with redundancies, S/4HANA utilizes HANA, SAP's proprietary in-memory database. The key impact of this design decision is that S/4HANA users have a constantly updated single source of truth for all their business data. Many benefits abound, but the key is that users can perform real-time analyses of their business to drive dynamic decisions and strategies.
SAP S/4HANA is offered on-premise and via cloud deployment. While migrating from ECC to S/4HANA is challenging, the dual offering provides clients with a well-supported path for enterprises to transition to the newer ERP. Between ECC’s end of life and this migration capability, many organizations do plan to (slowly) migrate to SAP S/4HANA in the next years.
What Are Key Differences Between SAP S/4HANA and SAP ECC?
Despite their shared lineage, SAP ECC and S/4HANA have vastly different architecture. As mentioned above, SAP ECC uses client-server architecture. More specifically, it has a 3-tier architecture consisting of:
- The presentation layer (i.e., its user interface),
- The application layer, where the user’s work is done, and
- The database layer, which is where all the client’s data is stored. This last layer consists of traditional, third-party databases like Oracle.
The basic workflow in this architecture is that actions/requests are input by users at the presentation layer, which are passed to the application layer which in turn retrieves data from the database layer. The application layer does the work requested by the user using the retrieved data and passes the results back up to the presentation layer.
While common for its era, this architecture necessarily introduces delays to work, not least because this is all disk-based. Responses to user commands are always limited by disk read-write speeds, in addition to any other delays inherent to information transfer across layers.
SAP S/4HANA utilizes SAP's in-memory database technology called HANA (hence the name). At its introduction, the HANA platform was a real industry innovation and game-changer. Essentially, the difference in architecture directly drove differences in data modelling; S/4HANA’S underlying platform allowed for models that streamlined and consolidated data and processes, enabling faster data processing and real-time analytics. How? It comes down to the fact that SAP ECC employs multiple data tables by design, whereas SAP S/4HANA employs a singular data table.
Data Modelling Methods – Multiple Data Tables vs Single Data Tables
To be clear, SAP ECC separates its data according to functional modules (e.g., Financial Accounting, Production Planning, etc.), and each module has its own relational database table. Additionally, transaction data lives in their own specific tables that are in turn related to particular business processes. Finally, clients can customize their own tables according to their needs. Effectively, data is segregated (while obviously accessible) as a function of business processes out of the box, and clients can create even more distinct configurations of data and processes. Each partitioning of data introduces more processing time and requirements, all of which stack.
By contrast, SAP S/4HANA has a single in-memory approach. More practically, S/4HANA has a single data table (its Universal Journal) that holds all data in one place regardless of function. This is a streamlined approach that dramatically reduces data processing time, which further permits real-time analytics to be done. Additionally, the system permits role-based, personalized user experiences.
In SAP parlance, general ledger functionality can be separated into “classic” and “new” general ledger (GL) support. This is another way of referencing single ledgers (Classic GL) versus parallel ledgers (New GL).
In the SAP ECC system, the default ledger functionality is Classic GL. Out of the box, only the leading ledger is available. In similar fashion, SAP ECC supports classic asset accounting out of the box. That is, it doesn’t require every depreciation area to be assigned to a ledger group.
In SAP ECC, implementing ledgers for different accounting standards had to be individually created and managed, along with any attendant reports. This parallel accounting in this scenario requires adopting the accounts approach, which involves more complex workarounds. Effectively, implementing the New GL functionality (along with new asset accounting) is an option for ECC, but it requires significant configuration and training efforts.
By contrast, in the SAP S/4HANA system, the New GL is the default setting and supports parallel ledgers and new asset accounting out of the box (in fact, new asset accounting is the only option supported by S/4HANA). This enables the creation of non-leading ledgers for parallel accounting purposes, such as IFRS and GAAP. The parallel ledger functionality is particularly advantageous for global organizations operating in diverse currencies, as it facilitates the generation of multiple sets of financial statements.
One of the key differences between ECC and S/4HANA lies in reporting – S/4HANA’s real-time capabilities extend to reporting, providing clients by default with the ability to analyze and visualize data from multiple dimensions in real time. Multi-dimensional reports can be further sliced and diced in pivot tables, charts, or some combination of the two, and personalized configurations/versions of reports can be saved. By contrast, real-time reports in ECC require specialized knowledge and effort to create.
One of the key reporting features in S/4HANA that bears highlighting is segment reporting. A segment is a new account assignment object (Profit Center and Segment) that can be used to produce segment reports to provide an additional dimension for users. It helps in running analyses for objects at a level lower than the company code. This functionality aligns with the requirements of IFRS/IAS Segment Reporting. Earlier versions of SAP ECC simply do not permit this type of reporting. By contrast, SAP S/4HANA generates segment reports by default. This feature allows users to analyze data at a more granular level, providing valuable insights and meeting the requirements of segment reporting under IFRS/IAS.
Summary Table of ECC vs S/4HANA Differences
This was a lot of information to throw at you. Here’s a quick summary table of the differences between SAP ECC and S/4HANA we’ve covered above:
|SAP ECC||SAP S/4HANA|
|Architecture||Disk-based, 3-tier client-server architecture||Proprietary in-memory, columnar, relational DBMS architecture|
|Data Modelling||Separate transactional and analytical modelling systems||Single source of truth for all transactions and analytics|
|Reporting||Separate reporting and data extraction systems; segment reporting only via workarounds||Embedded analytics, real-time reporting, segment reporting|
|Digital Transformation Functionality||n/a||Machine learning, IoT integration, advanced real-time analytics|
|Roadmap Support||EOL 2027||SAP's current development focus|
|Accounting Functionality||Single ledger by default (Classic GL) |
Classic Asset Accounting, New Asset Accounting via workarounds
Parallel ledgers by default (New GL) New Asset Accounting only
|Maturity||Launched 2005||Launched 2015|
How Should Modern Financial Solutions Integrate with SAP ECC and SAP S/4HANA?
The Importance of ACID Compliance
Even before we talk about any one specific integration technique, it’s important to note that properly integrated systems should allow transactions to take place while respecting Atomicity, Consistency, Isolation, and Durability, i.e., ACID compliance:
- Atomicity: This refers to each transaction being treated as one indivisible unit of work. The transaction must work, leading to related changes or fails, and nothing happens to the system, data, or data table. It’s all or nothing, essentially.
- Consistency: This refers to transactions that only ever change databases according to established rules, ensuring data integrity is maintained no matter what user requests are made.
- Isolation: This refers to simultaneous transactions being executed without interfering with one another.
- Durability: This is a guarantee that when transactions are completed, its changes are permanent.
Financial and mission-critical systems should follow ACID compliance for efficiency, effectiveness, and continuity. How does this look on a practical level? It should mean that we aim to have such systems integrate with each other at the highest possible levels. It’s important that we all have a common understanding of what integration references (and particularly important for you to have your prospective vendor spell out in writing the type(s) of integration their solutions offer).
How We’re Using the Word “Integration”
There’s a wide range of technical possibilities for integration that vary by underlying technology and function, so let’s clarify what we mean in this blog. We are not talking about functional integrations (e.g., having two systems share the same payroll system). While those are important and related to the topic at hand, we’re discussing the ways in which systems integrate with one another to pool and share core master data. Broadly, we’re talking about:
- Application Programming Interface (API)-based integrations: This allows different software systems to both communicate and interact with one another, enabling seamless exchange of data and functions. There is a broad swath of API subtypes (that we won’t cover here unless it applies to SAP functionality): REST APIs, RESTful APIs, SOAP APIs, GraphQL APIs, and more, such as SAP’s BAPIs (see below for more on REST APIs and BAPIs).
- Flat file integrations: This type of integration allows data exchange via text files of particular formats. Popular file types include CSV, XML, and JSON, although certainly, other formats can be used. Flat file integrations have the advantage of being very simple to implement, but this ease comes at the price of lacking real-time data synchronization. On the whole, flat file integrations are an especially poor fit for enterprise usage.
- One-way integrations: Here, data flows in only one direction. Practically, this means that modifications that are effected in one system are sent to the integrated system. However, the changes made in the other system aren’t sent back. This can create some serious data inconsistency over time, requiring considerable effort to track.
- Point-to-point integrations: This refers to a direct connection between two systems intended to serve a single data exchange purpose. Sometimes the connection is supported by an API, but often it’s a bespoke connector created by users. This type of integration is quick to develop but generally can’t be reused for other applications in the same organization, and quickly adds to complexity as a company grows (leading to something called “spaghetti architecture”).
- Bidirectional integrations: This is where data that is read and written in one third-party app is also changed in the integrated app (I.e., the ERP in this case) via intelligent, reusable applications of APIs. Out of all the options we’ve listed, it’s the best way to ensure smooth interactions between huge connected systems. Now that we’ve planted our flag on our preferred integration technique, let’s take a quick look at how to do it.
Using SAP’S APIs to Get Bidirectional Integrations
Third-party applications should use, at a minimum, secure open Representational State Transfer Application Programming Interfaces (REST APIs) that have undergone validation by SAP when developing integrations. These are software connectors that ensure the security of data transfers by employing a two-way encrypted channel for all communications between SAP servers and the application’s cloud, using TLS over TCP. Additionally, this method of data transfer allows IT professionals to configure and utilize existing SAP infrastructure and security frameworks, further enhancing data security and integration capabilities. It has to be noted that you would use REST APIs to integrate more general functions in SAP, regardless of version.
For more business-critical data (such as customer codes), SAP provides integrators with their own proprietary APIs known as BAPIs (Business Application Programming Interfaces) to ensure smooth integration. These are interfaces that are built specifically to work with SAP’s data models and business processes only. It’s what allows accurate, secure, and efficient reading and writeback to either SAP ERP system discussed here, enabling seamless posting of documents to SAP systems. We’ll go into SAP’s BAPIs along with some associated function calls in more detail in Part 2 of this blog series. Come back next week!
We’ll cap off this blog with a brief word on how our solutions integrate with SAP – ECC or S/4HANA.
So How Do Nakisa’s Solutions Integrate with SAP Products?
Nakisa Lease Administration (NLA) and Nakisa Real Estate (NRE) software seamlessly and bidirectionally integrate with both SAP ECC and SAP S/4HANA through the native connectivity provided by Nakisa Cloud Connector (NCC). NCC is purpose built to handle the secure transfer of master data between Nakisa products and ERP systems; it is built from literally decades of experience creating smooth and efficient integrations between our solutions and SAP products. Nakisa heavily leverages BAPIs to ensure 2-way data exchanges between SAP ERPs and our own solutions, so that our clients can effectively manage lease administration and real estate processes within their ERP environment, regardless of whether they’re ECC or S/4HANA customers.
We’ll cover how we build NLA, NRE, and NCC to be natively bidirectionally integrated with SAP in Part 2 of this series. In the meantime, we hope we answered your questions about what to look for in third-party applications that truly integrate with SAP ERPs. Can’t wait for Part 2? Talk to our experts – they’re CPAs with years of field experience in accounting and SAP and are only too happy to help!