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.
• etc.

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).

In my spare time I am programming the prototype of a software that is supposed to solve some serious problems with data management that has been prevalent so far. One of the special things about the concept is that a radically simplified organization of data storage allows a limitless complexity of elements involved in data evolution. The challenge, however, is not to store data, but to breathe basic functionality into the system. There is the chicken and egg problem here: certain system components are required to make the system functional, which in turn are based on system components. So it’s like with real organisms: there needs to be an origin.

I am currently aligning the software to reliably process information about buildings. Separate fields of information will be added once the system has proven to work, for example in the area of insurance. That’s because processes behind changes are very similar everywhere. In this regard, my goal is to create reliable and self-organizing data organisms.

One of the interesting insights from my research work is that static primary keys, which are today widely used for data exchange, do not meet the requirements for evolution, because practically all the information associated with an entity can change at any time. A system that can say ‘goodbye’ to static IDs is therefore required for the reliable exchange of information, but at the same time it must allow different alternative forms for identifying and matching data records.