blogging about Oracle, APEX and other data related stuff

Select Page

The challenges

There is a lot of talk about GDPR rules and their implementation. And there is also a lot of work going on, but in most cases there is even more to be done.

There are few key points in the GDPR directive that are crucial. In this article you can see clearly explained the key changes that your company needs to implement to adhere to the GDPR requirements.

After the you have mapped the different systems where the customer data lives, the two biggest implementation challenges are concerning these two GDPR rules:

  • Right to Access
  • Right to be Forgotten

The reason that “Right to Access” and “Right to be Forgotten” are challenging is because the customer data is stored in so many different places. Due the ubiquity of your data, it might be really difficult to centralize the collection of the data and act on them in one shot, as you might have 5, 10 or more different systems involved in the process. You might have the procedures in place for each of those systems, but to aggregate all the procedures and make things happen in one place you need a custom process that aggregates all the data and make it possible all the activities in 1 step.

APEX to the rescue

For this purpose RAD tools (Rapid Application Development) might be the perfect solution. RAD tools (or Low Code Platform tools) make possible to quickly design and implement custom workflows that cannot be implemented in your main systems, without changing the current setup of your IT architecture and without spending a fortune (in fact the Oracle APEX license starts from 0 DKK!).

In Oracle APEX is possible for example quickly design a control panel where you have all the user infomation from you 10 systems aggregated and visualized. The main screen allows to performs the tasks required by the “Right to Access” and “Right to be Forgotten” as specified in the GDPR rules:

  • Report the customer data in the different systems
  • Export the data to be delivered to a customer
  • Delete all the data related to a customer

Here is a screenshot of how the tool could look like:

GDPR Control Center - example 1

GDPR Control Center – example 1

This is a screenshot of an actual application created in less than one hour (considering also the creation and “massage” of the fake data for the simulation). It simulates the control panel where you have information collected from 3 different systems (Active Directory, eBusiness Suite and SAP).

And this could actually be the very beginning of your action to take control over your customer data, where the data collection is performed using native database connectors, REST web services or any other connector exposed by the source system. The final result at the end of the interaction process may be very much different, but at least this is a start. Much better start than continue to worry about the 25 May, very long meetings with targets impossible to reach and endless discussions, without doing practically nothing.

Feel free to play with it here: GDPR Control Center

Try to click in the different places, the headers, the sandwich menus, the “Actions” buttons (for example to change the number of rows per page or try to export the data). You can change data or delete users, they will be recreated next time you sign in.

And remember: every actionable object in the interface is created automatically for you by APEX. Now imagine to implement these options (just to name few of them!) in the technology you currently use for your internal applications, and most of them are configurable by every single user:

  • adjust/reorder/sorting/filtering of the columns
  • search function (global and for each column)
  • variable pagination
  • responsive layout
  • charts on the fly
  • export to PDF
  • AD/LDAP login process (or database based)
  • REST interface
  • notification mailer
  • API for DevOps integration
  • … and a lot more…

There is no mismatch between what you see and what is going to be developed in the application: all you can see is actionable and need just the implementation of the right processes instead of the simulated ones, so the interface, after a real implementation, will react  exactly as you see here. Of course, unless you would like something different, which is the point of making a super-fast prototype:

Very fast interaction between the developer (one developer is enough for frontend and backend) and the users = AGILE.

Please let me know if you have further questions related to this demo 🙂


Comments on LinkedIn

Share This

Share This

Share this post with your friends!

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.