SAP customers have to migrate to the new software generation S/4 Hana until 2025. That’s because after this deadline, the support for ERP/ECC 6.0 will end. Most SAP customers associate the migration with the goal of an agile application landscape which will allow them to tackle the challenges of digitalisation.
A word of caution, however: This goal is completely viable for applications, but not for data. Data from business applications has to be stored with its corresponding business context. This context has to be preserved for a legal retention period.
Furthermore, this context provides valuable information about the history and quality of business relationships with customers and suppliers, which could potentially be important for years to come.
Data therefore doesn’t need agility, it needs stability. For that exact reason, huge volumes of data accumulate in a company’s data center while migrating to new software generations of SAP or other providers. This enormous amount of data has to be preserved with legacy systems due to its business context – usually for many decades and a lot of money.
When migrating to S/4 Hana, companies struggle with the same old problem: the continued operation of legacy systems.
On the one hand, the migration of each and every document and set of data to S/4 is neither practical nor cost-efficient. Although memory chips and the like have been getting cheaper over the last couple of years, main memory and computing resources still require a lot of investments.
On the other hand, the structure of the data will fundamentally change during the migration to Hana. For example, the number of spreadsheets of bigger installations will be reduced from over a hundred thousand to fifteen thousand, twenty thousand max. Therefore, companies risk legal consequences if they do not have a tangible solution for their legacy systems.
A question of architecture
The most important question is therefore: How can you connect the two opposite ideas of agility and stability? The answer: with a new approach!
This new approach consists of a different architecture of the application landscape which separates old data and documents from the agile apps of the future. Consequently, legacy systems can be shut down, and new software generations can permanently remain agile.
Key for this new architecture is an system-independent environment for data, documents and business contexts that are no longer needed in operational systems. Such an environment guarantees the required stability of data. At the same time, it increases legal and IT security. Unlike many legacy systems, this environment can be patched and secured.
Furthermore, it is possible to manage the life cycle of old data and documents through new functionalities for retention management. This includes deleting purposefully and specifically – one of the fundamental requirements of the General Data Protection Regulation (GDPR).
A certification of the Institute of Auditors (Germany) means that auditors, accountants and tax authorities alike can trust this environment to store data and documents with their corresponding business context without changing them.
Saving money
Through aforementioned environment, it becomes possible to shut down legacy applications. This can lead to cost savings of up to 80 percent – and sometimes even more – compared to their continued operation.
Regarding the migration to S/4 Hana, another aspect is equally important. If business documents and data are transferred to this environment as soon as they are no longer needed, the current applications and systems remain agile and uncluttered.
As a rule of thumb, the operational data volume can be reduced by 50 to 70 percent. Every unnecessary baggage can therefore be avoided.
Why is this so important? Well, in the enterprise environment, approximately 5,000 man-days are needed for data migration. Even if an average of 2,000 man-days per project is assumed, a capacity need of 20 million man-days in the D/A/CH market alone would arise, which translates to 3.2 million per year.
Even if the entirety of the estimated 2,000 experts for data migration in German-speaking countries were to work 365 days a year, there would only be capacities available of 730,000 man-days a year.
And even if vacations and other leaves are out of the equation, five times the number of migration experts would be needed to complete all of the projects by 2025. This is simply not possible according to Cocker.
If no longer needed data and contents from operational applications are continuously transferred to a legally secure, system-independent platform, operational IT becomes much more agile. Consequently, it can support various business processes with very little effort.
Example 1: Purchasing and selling companies and business areas
Here, it is important to decide which applications of the acquired company should be applied, for example because they have more advantages than the enterprise-owned apps, and which should not. This corresponds with the question of which data and documents should be transferred to up and running systems.
The continued operation of legacy systems is a major reason for 80 percent of IT budgets being used up only for operation. What is more, there are compliance and security risks if the acquired systems are not maintained reliably or are not regularly secured through security patches.
Furthermore, the retrofitting of legacy systems to comply, for example, with GDPR is not even possible in most cases.
Example 2: Consolidation of heterogeneous application landscapes to central systems like SAP
The consolidation of SAP system landscapes is not just a technological project. Companies tend to associate it with business-oriented and strategic goals. For example, through the centralization, the complexity is supposed to be reduced, the corresponding maintenance, administration and cost decreased, and innovation accelerated.
Consequently, the consolidation of globally dispersed SAP systems makes it possible to implement changes and developments faster and make them available worldwide. This is only possible, however, if legacy systems are decommissioned.
Example 3: Consolidation of globally dispersed data centers
Consolidation projects concerning data centers typically start with a comprehensive analysis of application and system landscapes. Which one of them can be transferred to a central location without too many changes? Are there local laws and regulations in place which prohibit the transfer because specific data of transactions and people is not allowed to cross international borders?
All of these considerations are a threat to the pronounced goal of consolidation, the centralization, and they can make even a partial transfer very expensive. Many subsidiaries and branches cannot be shut down if there is no solution for old data and documents. They then continue to eat up a lot of money – without adding any value to the company.
Example 4: Quality of data
One customer, many sets of data: This is the current state in many companies. This is highly confusing, because the different sets of data are being associated with various customers, although all of them are from one and the same person!
To analyze data in detail is the foundation for optimized or new digital processes and services. If a correct overview of a customer’s history is not available, companies miss out on tailoring the customer experience according to their preferences and addressing them with the right offers.
To put it plainly: The foundation for digital business models is missing.
The future
Before as well as after the S/4 Hana migration, SAP systems will continue to grow. After a short time already, memory capacity has to be expanded and computing power increased so that requests of system users do not impact the performance.
For SAP customers, a new challenge arises. Their existing systems do not run on Hana yet, but on a common DBMS. In the future, however, they have to purchase volume-dependent licenses for Hana.
The Java-based platform JiVS is designed for these and other business scenarios. What is unique about it is that it stores not only data from decommissioned legacy systems, but also the corresponding documents with their business context for legal security.
JiVS can therefore be seen as the core element of an agile application landscape in companies. In case you were wondering: That’s the right approach.
Add Comment