Agility and stability - strategy interview

When it comes to the "gold treasure" of data, the term MDM, Master Data Management, or MDG, Master Data Governance, often comes up quickly. But these buzzwords and their functional scope fall far short when an ERP release change is pending.

If the ERP database also has to be replaced, as will be the case with Hana and S/4 by 2025, then you need much more than SAP's MDM and MDG.

E-3 Editor-in-Chief Peter M. Färbinger conducted the following strategy interview with Thomas Failer, founder of Data Migration Services.

Peter M. Färbinger: Mr. Failer, you and your company have specialized in the historization and migration of legacy data and documents for over 20 years, especially for SAP legacy customers. What has been the biggest change in the market during this period?

Thomas Failer: The biggest change is happening right now. The basic problem that it is far too expensive and time-consuming to continue operating legacy systems and migrate all legacy data and documents when switching to new software generations has always existed in IT. But the problem has never been as big as it is today.

Färbinger: Why is that?

Failer: The main reason is that several developments are converging. The protection of intellectual property and personal data is becoming increasingly important, both because of regulations - think of the European General Data Protection Regulation - but also because of the increasingly sophisticated attacks by cybercriminals and spies.

At the same time, companies can no longer shield this data behind thick and high walls. Because networking is the order of the day, along entire supply chains all the way to the end customer.

Färbinger: Are you alluding to the cloud?

Failer: That's more than an allusion. Because the cloud is indeed changing everything. It represents not only a new way of how and where IT is produced, so to speak, but also and above all how it is consumed.

The degree of flexibility, resource availability, speed and simplicity represents a quantum leap for companies. At the same time, this puts corporate IT under merciless pressure to move.

Because it has to become just as agile, flexible and fast as the big cloud providers. It must also offer the same ease of use.

Färbinger: Does that also apply to SAP's existing customers?

Failer: This applies equally to all. Existing SAP customers who are not up to cloud standards will not master digitization. Users will turn away and use services from public cloud providers. In extreme cases, managers would then have to outsource IT completely.

Färbinger: Are SAP's existing customers aware of this?

Failer: Yes, of course. They are keeping a close eye on SAP's cloud strategy. But the fact that many of them are hesitant to switch to the new software generation from Walldorf today rather than tomorrow is not because they question this strategy in principle.

Färbinger: But?

Failer: The hesitant attitude is an expression of deep consideration, but also of uncertainty, because companies know how complex the migration is. The heart of the company beats in the SAP landscapes.

This is where not only the crown jewels, the intellectual property, are located, for example in the form of construction plans, patents or recipes. Rather, very specific process knowledge is also cast in software, as it were.

SAP's existing customers have built up this knowledge over many years with a lot of time, effort and, of course, money.

Färbinger: And users want to transfer that to the S/4 Hana world as well?

Failer: Spontaneously, one is tempted to answer with an unequivocal and exclusive yes. The fact is, however, that this question is also currently being hotly debated in the community.

Certainly, customizing was, is, and will remain a top issue for SAP's existing customers. But from my conversations, I know that they are currently thinking very carefully about whether they want to use the transition to S/4 and Hana to redesign their processes.

This willingness to return to the specified process standard is likely to exist among ten to 20 percent of SAP's existing customers. Of course, this is the minority, but they are not few either.

Färbinger: Doesn't the decision in favor of the standard mean a head start in migration?

Failer: This cannot be said in such a general way. Because regardless of the approach chosen - whether a return to the standard, implementation of S/4 including greenfield customizing, or parallel operation of S/4 and Business Suite - all SAP legacy customers face one and the same fundamental problem: Few know how to handle the data and other information in their systems during migration.

This is the reason for the uncertainty and hesitation. The low and therefore lamented rate of S/4 Hana implementations that have already taken place is the logical consequence of this.

Färbinger: But IT was always supposed to support the business!

Failer: That is also true. But the term agility alone has only been in our mouths for a few years. Companies have to react ever faster to market changes.

They are constantly acquiring and selling business units or subsidiaries. They continuously adapt and restructure their internal processes. All of this happens much more frequently and faster than before. In the end, these constant changes must always be managed, mapped and supported by IT.

Companies breathe. IT must also be able to do this. This is especially true for the historically grown and therefore complex SAP environments.

Färbinger: What is there to do here?

Failer: The challenge is to resolve a fundamental contradiction that has been inherent in application landscapes up to now. In order for IT to support the business, it must be possible to change applications and services flexibly.

But the associated data and information don't like that at all. They need stability for both business and legal reasons. Data structures and contextual information must not be changed. The basic dilemma is: agility versus stability.

Färbinger: How can this contradiction be resolved?

Failer: The solution is to decouple the level of applications from that of data. This is the right approach. If both levels can be managed independently, IT can pursue the two conflicting goals independently. You don't untie the Gordian knot, you cut it.

Färbinger: Wasn't that the idea of a service-oriented architecture?

Failer: That is true, and with S/4 and Hana, this decoupling is also far more inherent in the architecture than it has been in the business suite world. But the problem underlying the dilemma between agility and stability goes a bit deeper. One must additionally make a subdivision at the data level itself.

Färbinger: Why?

Failer: S/4 brings completely new data structures, and the number of tables is reduced from more than 100,000 to perhaps 20,000 in large implementations. However, the data generated in existing SAP systems and the associated business logic must be retained unchanged so that companies can meet their legal requirements.

Consequently, the decoupling of applications and data will only succeed in the long term if the operational data is separated from that which is no longer needed in day-to-day business.

Färbinger: How have SAP's existing customers dealt with this problem so far?

Failer: As a rule, they have frozen their existing systems after the data transfer and transformation, cut their connections to the outside world and reduced resource consumption through virtualization, among other things. This gives them a handle on the legal side of things. But this does not make them agile.

Färbinger: Why not?

Failer: Imagine an audit. A tax auditor wants to access invoice data and documents contained in a system six years after it froze. Can you guarantee that the machine will boot up again as requested?

Or a business unit is sold. The buyer needs all legacy data, including business logic. Can you reliably identify this information in the frozen system, extract it exactly and hand it over to the buyer in a neutral format so that the buyer does not have to rebuild the legacy system one-to-one in order to be able to read the data at all?

Or a customer demands the deletion of his data according to the European Data Protection Regulation (EU-DSGVO).

Are you then able to identify all invoices that are older than ten years and thus may be deleted without much effort? Are you able to guarantee that all other invoices for this customer will be automatically deleted after their retention period has expired? As a rule, the answer to these questions is no.

Färbinger: That sounds as if there is no way out.

Failer: Yes, we do - and that's the reason why we exist at all. The idea arose during migration projects from R/2 to R/3 and has proven itself. If all data, including documents together with their business logic, are removed from the legacy systems and stored in a cross-platform format on a modern platform in an audit-proof manner, their entire life cycle can be managed independently of the original systems until they are deleted.

This is the basis for everything else: the transformation of the data and its subsequent migration, as well as the optimization of data quality and, in particular, the shutdown of the legacy systems. After all, it makes neither economic nor technical sense to transfer all legacy data and documents to the new world as well.

Not to mention that there aren't even enough migration experts to handle the switch to S/4 and Hana by 2025, the time frame set by SAP.

Färbinger: What is the difference between this and the frozen systems?

Failer: An independent platform for managing the lifecycle of legacy data and documents, including business logic, creates legal certainty on the one hand, because the scope and structure of the information remain unchanged.

It also allows the requirements of the EU GDPR to be met, especially for deletion at the individual record level. On the other hand, it provides more security, because it is a living system and can be maintained and patched regularly.

In addition, however, their operation is incomparably cheaper compared to the continued operation of the legacy systems, usually by 80 percent, sometimes even more.

Färbinger: But that still has nothing to do with migration.

Failer: Extracting and storing the information, including its business logic - we call this historization, by the way - is the prerequisite for a migration that makes sense from a technical, business and economic point of view. The platform is, so to speak, the springboard from which all other goals can be achieved.

Färbinger: You'll have to explain that in more detail.

Failer: It is our customers who have recognized this. Once all the information is legally secure on the platform, only the information that is needed for ongoing business operations needs to be transferred to the new system.

As a rule, this means a data reduction of 50 percent to 75 percent. The higher the quality of the data to be migrated, the greater this value.

This allows us to correct incorrect data records, delete duplicates and enrich the data records with information from other sources on the platform even before the migration. After all, every system change is an opportunity for more data quality!

Färbinger: How do you do that?

Failer: We divide the overall process from planning the S/4 Hana migration to operation together with our platform into four steps: Identify, Design, Execute and Operate.

So far, we have products for the Execute phase, which means the historization of the information and the subsequent migration. We are currently developing or bundling the tools for the other three phases.

Färbinger: How do you have to imagine that?

Failer: Simply put, Identify is about identifying the type and amount of information that does not need to be transferred to S/4 at the push of a button.

This is a potential analysis that additionally visually represents to the prospects what the information that will remain on our platform will look like. This builds trust, because they recognize very quickly that everything looks exactly as they know it from the inventory systems.

Potential and trust create the prerequisite for the fundamental decision that and how our approach is worthwhile for the path to S/4.

Färbinger: What happens in phase two?

Failer: Design is about the detailed planning. Here, the exact filter criteria for data selection and transfers are developed. Our approach here is to provide the exact filter rules as XML data. This gives customers the choice to decide which migration and conversion tool they want to use for the data transfer.

Färbinger: That still leaves the issue of Operate.

Failer: Basically, this is primarily an integration issue. Because in order to be part of the target landscape, we develop integrations to the Hana-based applications such as S/4 and C/4 or interfaces such as SAP Fiori.

While non-operational data doesn't need to be accessed that often, when it is for business reasons, users need to be able to do so as easily as possible from their familiar environment, without having to spend a long time searching for the information they need or changing their application environment. That's the kind of ease of use users are used to today, from the cloud and from their smartphone.

Färbinger: When will these tools be ready for the market?

Failer: The prototypes are currently being created. We want to complete finished packages for the highly automated migration to S/4 or C/4 by fall 2019. Our goal is to make our customers more agile.

This is also changing us. For example, due to the expanded product roadmap, we have converted our own development to agile methods in order to become faster without quality suffering - on the contrary.

Färbinger: Thank you for the interview.