I have had a soft spot for architecture and especially high-rise buildings for around 25 years. It gives me great pleasure to collect as well as organize information about buildings. But over the years I have noticed that information is constantly changing:
- A building is erected or demolished.
- A real estate object is being renovated and its color is changing.
- An office property is converted into a residential building.
- A new tenant moves into a high-rise building or another moves out.
- Involved companies change their names, go bankrupt, merge or split.
But how do you best manage these constant changes? What about changes that you don’t notice at all or only after a certain period of time? How do you determine the number of office buildings in a city today, five years ago or in the future? What if there is different information about the same object? And when is a property actually an office building?
Changes in the real estate area (and of course beyond) are ongoing. And these changes have been my research field in IT for around 10 years. During this time, I took more than 100,000 photos to document and discover changes to buildings as well as things which are related to them. My observations allow these conclusions to be drawn: Change is happening all the time and is chaotic. Sometimes change happens abruptly, but mostly slowly. And change takes place in all areas of life according to similar processes. But the tools we use to address this change today in IT are relics from the past. As a result, virtually all companies not using automation work with incomplete, outdated or even incorrect information. Also, corporations who then sell this information as “market data” usually cause frustration among paying customers: not just because of the bad quality, but also because a lot of data is simply missing.
My research field data change management aims to consider change as an integral part of data management. Change is not a disruptive part of data storage, but just as important as the data itself. Today databases are primarily used for data storage – and they are used insufficiently. Databases were originally made to store data above all in a persistent and relational manner. The concepts that are mostly implemented with databases are designed today to reflect the best possible “state as of today” of the party who manages the data. But they are not used to
- make changes to the schemes without programming,
- integrally versionize changes to all data sets,
- update, rate or change data by self-imposing them,
- to show the status of the data at a different time than “today”.
Exactly these points flow into data change management. Changes to data are processed and displayed as they were best available at a certain time and from a certain point of view.
In recent years I have developed the theoretical concepts for a new form of evolutionary data processing, based on extensive observations of change processes and insights from evolutionary research. Information is not conventionally stored in several database tables, but in data stores which conceptually originate in genetics: in nucleotides and information strands RNA (simple information carrier) and DNA (complex hereditary material).