In today’s data-driven world, information lifecycle management (ILM) is so important. Strategizing a way to oversee your organization’s data—all the way from its creation to retirement—is an integral process of managing data in an organization’s IT ecosystem.
ASUG recently sat down with Iwona Luther, one of the authors of SAP Information Lifecycle Management: The Comprehensive Guide from SAP Press. She discussed some SAP ILM basics, ways customers can leverage SAP ILM in their organizations to maintain and oversee their data, and key takeaways from the book.
Iwona: My name is Iwona Luther. My official role is a bit tough to explain as I have the responsibility of this topic and others for over 20 years. My official role is director of Information Lifecycle Management (ILM), but I also have other assigned tasks, such as securing products in support of ILM. In this role, my office has the responsibility of ensuring all new application and updates delivered are ILM compliant. For example, we must review if the data is retention relevant and whether there is functionality provided so that it can be blocked, archived, or destroyed. I’m also responsible for the three customer training programs we have for this topic, the trainer for trainings, and the DSAG and ASUG user group contact person for ILM.
ASUG: Tell us a little bit about SAP ILM. What are some of its basic functions and how does it essentially help SAP customers?
Iwona: SAP ILM evolved from data archiving, which we now often call classical data archiving. It is still one of the cornerstones of SAP ILM. This means we still take care of the total cost of ownership and reducing the data being stored in the database to the data that's really needed for productive usage and putting out data needed maybe only for reporting or for audits out to archive files. That's one of the basic functionalities: data archiving.
The second cornerstone of SAP ILM is something like a magic box with retention rules. This is a tool where a customer can store retention rules for their retention-relevant data. And this is the first time that SAP provides such a framework. With the third cornerstone of SAP ILM we can see the legal case management, which is taking care of any litigation and legal hold, and helping customers with putting them into the systems.
The goal of SAP Legal Case Management is to prevent data still needed for any legal suit from being destroyed. Even if the retention period stored in the magic box expired, we keep the data as long as the legal suit exists. The next cornerstone of SAP ILM is the blocking of person-related data to meet the requirements of regulations like GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act).
Some further cornerstones of SAP ILM include some new tools like SAP ILM Notifications or the Data Control Rule Framework. Finally, there is also the Retention Warehouse functionality of SAP ILM.
ASUG: Can you tell us about some of the data destruction case capabilities in SAP ILM? Why are they important?
Iwona: If we look at this from the historical point of view, data destruction (sometimes we say deletion) was of primary importance because of the total costs of ownership. Why carry all the data over years or decades when there is a clear point in time where all retention periods are over for a sales order, as an example? Why keep this data in a system if no one needs it, especially if it may bring a danger of legal hold? This is one aspect of keeping only the data that customer has to keep according to retention periods. The second aspect which evolved over the last few years is all about regulations like GDPR and CCPA, where the regulation forced customers to destroy person-related data once the purpose for storing it is over.
ASUG: What are some of the retention management functionalities in SAP ILM and how can users effectively leverage them?
Iwona: Retention management is everything about entering, keeping up to date, and enforcing retention periods. This means it is important for the customers to use the tools we provide and enter (per industry, per country, and per data type) the retention periods for the different types of the data. This is important because SAP ILM can help customers enforcing those retention periods only if SAP ILM knows the customer-specific retention periods.
Entering the retention periods is homework for customers. A side note here could be that we have a project with the German user group, DSAG, to create a network that would allow customers to import and export some of their retention periods among customers taking part in this network.
To summarize, the first aspect of retention management is entering the retention periods. The second aspect that is important to mention is the blocking of person-related data. The third aspect is the destruction of the data after the longest retention period has expired. In between, the data can also be archived with the help of SAP ILM. For this SAP ILM offers, for example, a framework to define the so-called residence periods (you could say this is a second magic box—the first one was for retention periods) as well as the functionality of sorting the data by the retention period during the archiving process. With this, the customer can be sure that a particular archive file only includes data for which the same end of retention period has been calculated. With this, the customer always has a clear picture of which archive files can or must be destroyed on a particular day.
ASUG: Let's talk a little bit about simplified blocking. What are some of the steps that customers need to take in order to use this functionality?
Iwona: Yes, we call it “simplified blocking” or “simplified blocking and destruction with SAP ILM.” Our goal here was to offer one centralized approach (available for as many applications as possible) for blocking of personal data and in the next step destroying the data. Here we have introduced a few important terms like end of business (EoB) or end of purpose (EoP). End of business means, if you have bought a book, for example, once you paid for the book, you received it and are happy with it, this point in time is end of business. Additionally, you might have a time where you can send the book back, or maybe the company wants to do some reporting. End of purpose is the point in time when end of business is over, plus the additional time needed for reporting or guarantee is over.
As you could expect, once the personal data has been blocked (after the end of purpose), it means that only the auditors or people that have a legitimate interest can access and view the data. Let’s have a look at the next important aspect of simplified blocking and discuss how it works for master data and transaction data.
Blocking of transaction data (for example financial documents) means to archive transaction data, plus defining a specific authorization group in the customizing. Auditors, for example, shall have this authorization group assigned (in addition to the authorizations needed for archive access) in order to view the blocked person-related data included in the transaction data.
Blocking for master data (customer or vendor for example), in contrast, means to set a special blocking flag for this data but still keep it in the database without a need to archive it.
One final remark from my side for this topic is: as you could expect there are some exceptions to the above in regards to blocking. Some solutions like SAP HCM, for example, have a slightly different approach for blocking.
ASUG: How does SAP ILM connect with SAP S/4HANA and SAP S/4HANA Cloud?
Iwona: The very first ILM which we have developed is the ILM developed in NetWeaver. With this, it is available for all applications and products based on this platform. This is, of course, the SAP Business Suite along with both the cloud and on-premises versions of SAP S/4HANA. Here we offer exactly what we have just discussed today. We are currently building an ILM on SAP Business Technology Platform (BTP), which had the name SAP Cloud Platform previously.
ASUG: I'd like to hear a little bit about how blocking and destruction are different with SAP S/4HANA and SAP ERP HCM. How are blocking and blocking destruction different between those two solutions?
Iwona: Basically, in SAP S/4HANA Cloud all the new terms introduced for simplified blocking (for example, EoP and EoB) that we have already discussed, are valid, too. Also, the concepts for simplified blocking of master data and transaction data are the same. But the UIs—the UI technology—are different.
If we now come to SAP ERP HCM, it is important to understand that they have another concept for blocking. We describe the differences in a dedicated chapter in our book. The final destruction of the data (both master and transaction data), however, is the same. With this, SAP ERP HCM follows the standards here.
ASUG: Can you tell us a little bit about what an SAP ILM GDPR project is and what are the big steps involved with getting one of those projects set up?
Iwona: Here we thought it would be great to have the consultants who are supporting customers during those projects as co-authors of our book and describe what it takes to go through an SAP ILM GDPR project successfully. The result is the seventh chapter of our book.
One of the challenging steps in such projects is to decide in which systems, tables, and fields person-related data is stored. One further important step is to analyze a customer’s system landscape in order to describe which are the leading and which are the depending systems. This is important to implement proper blocking of master data in the leading system and the distribution of the blocking flag to the dependent systems. It is similar for the aspect of the final destruction of the data.
ASUG: Can you explain what a system shut down with Retention Warehouse is? When would a customer need to use this feature and how would they go about utilizing it?
Iwona: Retention Warehouse (RW) is what I’ve mentioned as the second flavor of SAP ILM. Retention Management was the first. The scenario here is that a customer might realize that they have a lot of systems that are not productive anymore, but legacy systems only. This situation can happen, for example, because of company mergers or acquisitions. Such legacy systems are important in the sense that they might still include data that's relevant for internal or external audits, for example, so those systems can’t be just shut down. The idea, in this case is, instead of keeping such systems alive (and we already had customers with over 100 legacy systems) and maintaining them so that if an auditor comes you can still access the data and interpret it correctly.
In one of the first steps, we create a brand-new system. This one we call the retention warehouse system. Inside this system we create separate spaces—new homes, so to speak—one by one for each of the systems to be decommissioned. You could say it's like a student's house where each student has a separate flat and can stay independent. In one of the next steps, we use data archiving to extract the data from a legacy system which must be retained and put it into the “flat” reserved/prepared for this legacy system in the retention warehouse system. We also apply the retention periods to this data. This is very important for the customer to be able to destroy the data—now living in the Retention Warehouse system—once the longest retention period expires.
We can say the idea behind the Retention Warehouse scenario of SAP ILM is interesting and valuable for many customers. At the same time, it’s a lot of work because, as you could imagine, it’s not only about bringing transaction data (financial documents and sales documents, for example) to the RW system. It’s also important to interpret that data and those documents. For this, you need the corresponding master data and some customizing data, too. A good example to illustrate this is that you must know that customer number 131 is this customer with this name and these settings. This means not only transaction data but also master data and customizing has to be extracted from the legacy system, put into archive files, and find its new name in a dedicated “flat” in the Retention Warehouse system. We describe the details in chapter eight.
One important final aspect is that there might be products also from other vendors who have solutions for decommissioning of legacy systems. With this, the SAP ILM Retention Warehouse solution from SAP is one alternative. It is, however, different with the SAP ILM Retention Management scenario for productive systems. Here SAP ILM is the best place to offer: a) the magic box for the maintenance of retention and residence periods for data stored in an SAP system, and b) the enforcements of those periods, which means archiving, blocking, and destruction of the data stored in SAP system.
ASUG: You end the book with a chapter on the management of data lifecycle of custom code in SAP ILM. Can you tell us a little bit about why this is important and how SAP customers can use SAP ILM to manage the data lifecycle of their custom code?
Iwona: Yes, that's a point which gets more and more important. Last week, I spent a few days with customers teaching them exactly this knowledge. It was a big German customer who has lots of tables and applications (as you said, code) in the customer namespace. The point is, as soon as customers realize that this data needs to be archived because of volume (TCO), that the data is retention-relevant and needs to be destroyed at a certain point in time, or that such tables include person-related data and need to be blocked, then in all those cases the customers have to do what SAP does for SAP tables. This means to provide the so-called SAP ILM enablement for such tables or applications.
I describe this topic in the last chapter, chapter nine in the book. We explain, for example, what it means to provide an archiving object, a destruction object, or an SAP ILM object. In other words, we describe what it means to offer the magic box for storing retention periods for customers’ own data and how to archive and destroy the data.
With these development efforts we all together (SAP for SAP tables and customer for tables in customer namespace) ensure that all retention relevant data can be archived or blocked and can be destroy after the end of the retention period.
ASUG: You wrote this great book for customers about SAP ILM. What are you hoping that readers take away from your book?
Iwona: I have realized over the last few years that I was spending more and more time with customers, providing trainings, giving presentations, and answering emails with important questions around the topics that we have discussed today. Based on this experience. I’ve decided that I cannot leave family and my development team more than I currently do and that it’s time to bring all this knowledge together and offer a book. With this, I’ve asked few great experts and my colleagues if they would have the time and the endurance to start the SAP ILM book project. I was lucky that they committed to do so as much as did the Rheinwerk Publishing Company, which supported us greatly, too. Without them saying yes to our plans we wouldn’t have the interview with you today.
Now having the book—and its electronic appendix which describes even the most recent new functions and enhancements SAP ILM provides—we hope customer’s ILM project can be significantly speeded up, making both our customers and their customers happier and successful.
Thank you very much for this interesting interview.
It’s that time of year again! ASUGFORWARD is right around the corner. ASUG members can join us online for executive programming on June 15‒17. Later, on June 21‒24, be sure to tune in for sessions from SAP customers and experts. Register now for the virtual event.