Agility Versus Stability

Data is the new gold. But how can data agility and legal stability be reconciled? Only a few IT companies have thought about this problem. Data Migration Services did not only think about it, but also found a nearly perfect solution.

This series is available as PDF download at the bottom of the page.

When people talk about the treasure trove that is data, there are often quick to mention the term MDM, Master Data Management, or also MDG, Master Data Governance. However, these buzzwords and their corresponding range of functionalities are often not nearly enough for an ERP release change. What’s more, if the ERP database has to be replaced too, like in the case of Hana and S/4 in 2025, then customers need a lot more than SAP’s MDM and MDG. E-3 Editor-in-Chief, Peter M. Faerbinger, talks strategy in this interview with Thomas Failer, founder of Data Migration Services.

Peter M. Faerbinger: Mr. Failer, you and your company have been specializing in historization and migration of legacy data and documents for 20 years now, especially focusing on SAP customers. What has been the biggest change in the market in the past two decades?

Thomas Failer: Well, the biggest change is actually happening right now! The basic problem of how expensive and laborious it is to continue to operate legacy systems after changing to a new software generation has been bothering IT departments for a long time. However, this problem has never posed a greater challenge than today.

Why is that?

Failer: The primary reason is that different developments are converging right now. The protection of intellectual property and of personal data is becoming more important than ever before. This is not only due to specific regulations, like the European General Data Protection Regulation (GDPR), but also because attacks by cybercriminals and spies are getting ever more vicious. At the same time, companies cannot simply lock away data behind strong concrete walls anymore, as connectivity along the entire supply chain is the order of the day.

And by that you are hinting at the cloud, right?

Failer: It’s more than just a hint. The cloud is changing everything. It’s not just dictating the when and where of IT, but also the how – meaning how IT is consumed. The cloud’s flexibility, speed, simplicity, and availability of resources is a quantum leap for companies in terms of technology and innovation. However, at the same time, IT systems of companies are relentlessly pushed to keep up with the cloud. They have to be just as agile, flexible, and fast as major cloud providers. Furthermore, they have to provide the same comfort in use to customers.

Is this also true for SAP customers?

Failer: Yes, of course – this is true for everyone. SAP customers who are not on par with high cloud standards will not be able to tackle the challenge of digitalization. Customers and users will turn their back on them and leverage the services of public cloud providers. Worst case scenario: managers have to completely outsource IT.

Are SAP customers aware of this development?

Failer: Of course they are. They are watching SAP’s cloud strategy like a hawk. A lot of them are also hesitating to change to SAP’s new software generation, and would like to make the move rather later than now. However, this does not mean that they are entirely sceptical of its strategy.

What does it mean, then?

Failer: As I see it, their hesitation is not only an expression of profound consideration, but also of deep uncertainty. Because companies know how complex the migration will be. And their SAP landscapes are home to the heart of their entire organization. Of course, this is in part due to the data that resides there, the crown jewels, the intellectual property, like construction plans, patents, or formulas. However, SAP landscapes are also harboring highly specific processing knowledge in their software. SAP customers have acquired all of this knowledge over years and years of hard work, dedication, and, of course, spending a lot of money.

So what you’re saying is that users want to migrate all of this data to S/4 Hana?

Failer: At first, it may seem like it, and many people instinctively answer this question with a very strong yes. However, this question is also subject to heavy debate in the SAP community right now. Certainly, customization was, is, and will remain one of the top priorities of SAP customers. But they are also considering to make the most of this migration to S/4 and Hana and use it for redesigning their processes, as a lot of them have been telling me in personal discussions. At least 10 to 20 percent of SAP customers do actually have this willingness to fundamentally change their business processes to standard procedures. Of course, this is the minority, but it’s still a lot.

Doesn’t opting for standard processes also mean having advantages when migrating?

Failer: Well, I would say that this is a little too general. Because regardless of the chosen approach – whether it is returning to the SAP standard, implementing S/4 including customizing using the greenfield approach, or simultaneously operating S/4 and Business Suite – all SAP customers are confronted by one and the same problem: Only a fraction of them know what they should do with data and other information in their systems when migrating. This is the reason for the uncertainty and the hesitation. A logical consequence is the small number of successful S/4 Hana implementations that we are seeing right now.

But IT should always support business, right?

Failer: Yes, certainly. However, we have to think about how fast all of this is going. Even the term agility has only become popular in recent years. Companies have to react to changes in the market faster and faster. They are constantly acquiring and selling business units and subsidiaries. Consequently, they have to continuously adapt their business processes and are always restructuring. All of this is happening much faster and much more often than before. This constant change has to be accompanied, supported, and often executed by IT systems. You could say that companies are almost like living, breathing organisms. IT has to be able to do that, too. This is especially true for organically grown and therefore complex SAP environments.

What can SAP customers do?

Failer: They have to resolve the basic conflict that up until now has been inherent in application landscapes. For IT to be able to support business, it is necessary that applications and services are flexible, adaptable, and changeable. However, corresponding data and information do not like that at all. They need stability due to business-related as well as legal reasons. Data structures and contextual information cannot be changed. The basic conflict is therefore agility versus stability.

And how can SAP customers resolve this conflict?

Failer: The solution is to separate the application layer from the data layer. This is the right approach to resolve this conflict. If applications and data can be managed separately from one another, IT departments can pursue both goals – ability and stability – simultaneously. Just as you would not solve the Gordian Knot; you’d cut it.

Isn’t that the concept of a service-oriented architecture?

Failer: Yes, exactly. S/4 and Hana need this separation between applications and data even more than the Business Suite did. However, the root of the conflict between agility and stability is an entirely different problem. To address it, you have to make a separation also on the data layer itself.

But why?

Failer: Because S/4 brings with it completely new data structures. The number of tables of big implementations is reduced from more than 100,000 to maybe 20,000. However, the data generated in SAP systems and the corresponding business context have be stored without changing anything so that companies can comply with legal requirements. Consequently, the long-term separation of applications and data only works if operation data is additionally separated from the data that isn’t needed in day-to-day operations.

Agility versus Stability (Fig. 1)

How have SAP customers been dealing with this problem up until now?

Failer: Generally speaking, SAP customers had to suspend their legacy systems after data migrations or transformations. This means that they simply cut their connection to the outside world and reduced the resource consumption through, for example, virtualization. From a legal perspective, this approach is totally fine. However, it prevents them from becoming completely agile.

Why?

Failer: Well, imagine an audit. A tax auditor wants to access all invoicing data and receipts six years after the system has been suspended. Can you guarantee that the machine will boot up without any problems? Or imagine that you are selling a business unit. The buyer needs all legacy data including business context. Can you reliably access this information in the suspended system, precisely remove it, and provide it to the buyer in a neutral format so that they do not have to rebuild the entire legacy system to be able to at least read it? Or imagine that a customer wants his data deleted in accordance with the European General Data Protection Regulation (EU-GDPR). Can you then identify each and every invoice that is older than ten years and can therefore be deleted? Can you guarantee that the other invoices of this specific customer are automatically deleted after their respective retention periods end? More often than not, the answer to all of these questions is the same: no.

That sounds like there is no way out.

Failer: There is one – and that’s the reason why Data Migration Services even exists. We came up with the concept while overseeing migration projects from R/2 to R/3, and it has prevailed to this day. If all data including documents together with their corresponding business contexts are transferred tamper-proof and in a neutral format to a modern platform, their entire lifecycle up until their eventual deletion can be managed independently of the legacy systems they were coming from. This is the foundation for everything that comes after: the transformation of data, their subsequent migration as well as the optimization of data quality and especially the decommissioning of legacy systems. Because it is neither economically nor technologically advisable to migrate all legacy data and documents to the new software generation. Not to mention that there aren’t nearly enough migration experts to manage the transfer to S/4 and Hana until 2025, the deadline set by SAP itself.

How is this platform different from suspended legacy systems?

Failer: An independent platform for lifecycle management of legacy data and documents including business context provides legal certainty, because size and structure of information remain unchanged. Furthermore, the requirements of the EU-GDPR can be complied with, especially concerning the deletion of individual data sets. The platform also provides additional security as it is a living and breathing system that can be regularly maintained and patched. Moreover, its operational costs are a lot less than those of the continued operation of legacy systems – usually 80 percent less, sometimes even more.

But so far, this has nothing to do with migration.

Failer: Transferring and storing information including its business context – we call that historization, by the way – is a prerequisite for a technologically and economically reasonable migration. The platform can be seen as a stepping stone from which companies can reach all their other goals as well.

You might have to explain that further.

Failer: Our customers were the first to notice it. If all information is stored legally watertight on this platform, only the data and information needed for daily operations must be transferred to the new system. This usually means a data reduction of 50 to 70 percent for customers. What’s more, this percentage is even higher if the quality of the data that has to be migrated is higher as well. Before migrating, we can correct erroneous data sets, delete duplicates, and enrich data sets with information from other sources on the platform. This just goes to show that every system change opens up the possibility of even more data quality!

How do you do that?

Failer: We divide the overall process, ranging from the planning of a S/4 Hana migration to its operation together with our platform, into four key steps: Identify, Design, Execute, and Operate. Up until now, our products focused more on the third step, Execute, meaning the historization of information and the subsequent migration. However, we are currently working on tools to accompany the other three steps.

Can you explain the different steps in a little more detail?

Failer: Of course! Let’s start with step one, Identify. Identify means to detect the format and scope of information which do not have to be transferred to S/4 Hana at the press of a button. This is an analysis of potential which additionally shows customers how the information which will remain on our platform will look visually. This creates trust, because customers are usually quick to realize that everything looks exactly like they are used to on their legacy systems. Potential and trust are the prerequisite for the decision if and how our approach for the road to S/4 is suitable for customers.

What happens next?

Failer: We move on to step two, Design. Design means finetuning. It is here that we develop specific filtering criteria for data selection and transfer. Our approach to this is that we provide the exact filtering criteria and rules as XML files. This lets customers decide for themselves which migration and conversion tools they want to use for the transfer.

You already described briefly what the third step, Execute, is about. That leaves us with the fourth and final step, Operate.

Failer: Basically, Operate is heavily connected to the topic of integration. That’s because we develop integration solutions to Hana-based applications like S/4 and C/4 or to an interface like Fiori to be part of the application landscape. Customers don’t always have to access legacy data that’s not necessary in day-to-day operations – very rarely, even. However, if they have to access it because of business-related or legal reasons, it should be possible without leaving their familiar system environment. We believe in simplification – this means that accessing legacy data should be possible without endlessly searching for the necessary information or leaving the familiar application environment. This is the level of comfort that users and customers are used to now, in part because of the cloud and smartphones.

When will these tools be available?

Failer: The prototypes are created as we speak. We want to provide customers with finished packages for the highly automated migration to S/4 and C/4 until the fall of 2019. Our goal is to help our customers get more agile. This is having an impact on us as well. Therefore, because of our extended product roadmap, we changed our development processes to agile methods to become even faster without decreasing quality – quite on the contrary.