Über mich

Im Jahr 2000 wechselte ich in die Industrie — sechzehn Jahre als Database Manager in einem namhaften Industrieunternehmen. Mein Aufgabengebiet war das Product Information Management, kurz PIM: die strukturierte Verwaltung von Produktdaten, dazu das Database-Publishing für die technische Dokumentation.

Wer tausende Artikel mit hunderten Eigenschaften verwaltet und daraus zuverlässig Kataloge und Dokumentationen erzeugt, lernt schnell: Ohne klare Struktur bricht das zusammen. Eine saubere, durchdachte Datenbasis ist nicht die Kür, sie ist die Voraussetzung für alles Weitere.

Diese Jahre haben meine Arbeitsweise geprägt. In der Industrie zählt nicht die schnelle Einzellösung, sondern das System, das verlässlich läuft, das sich pflegen lässt und das auch dann noch funktioniert, wenn jemand anderes daran weiterarbeitet. Dieses Denken — Struktur, Verlässlichkeit, der Blick auf das Ganze statt auf den Ausschnitt — nehme ich bis heute in jedes Projekt mit.

Als ich anfing, war Softwareentwicklung das Reich der klassischen Sprachen — Basic, C, Pascal, Assembler. Im Datenbankbereich war dBase III unter DOS weit verbreitet — die Datenbank, mit der wir damals auch die Postleitzahlen-Umstellung umgesetzt haben.

Mein eigentlicher Einstieg in die Datenbankentwicklung kam dann mit FileMaker Pro 2.0, das 1992 als erste plattformübergreifende Version für Mac und Windows erschien. Eine Datenbank-Umgebung, mit der man sofort produktiv werden konnte, ohne erst eine Programmiersprache lernen zu müssen — und genau das hat damals vielen den Einstieg in dieses Berufsfeld ermöglicht.

Mein Hintergrund als Mediengestalter prägt bis heute, wie ich Software entwickle: aus der Sicht der Person, die sie am Ende bedient. Das Beste, was im Hintergrund läuft, nützt wenig, wenn die Oberfläche im Weg steht.

Aus diesem Anfang wurde ein Beruf, der über die Jahre viele Namen trug — Datenbankentwickler, Database Manager, Backend- und Frontend-Entwickler. Wer heute beschreiben will, was ich tue, kommt mit einem einzelnen Begriff nicht mehr aus. Datenbanken entwickeln, Geschäftslogik schreiben, Oberflächen gestalten, Bedienlogik entwickeln, Schnittstellen bauen, Server betreiben, Sicherheit mitdenken, Prozesse analysieren, Auswertungen visualisieren, KI strategisch einsetzen — das sind heute zehn Berufsbezeichnungen mit meist englischen Namen.

Was sich in über dreißig Jahren nicht geändert hat, ist das Wesentliche: Software entwickeln, die Geschäftsabläufe abbildet — und zwar so, dass sie zuverlässig läuft, gepflegt werden kann und vom Server bis zur Auswertung in einer Hand bleibt.

Wenn das heute „Full-Stack“ heißt oder „Solution Architect“ — beides ist nicht falsch. Ich nenne es Softwareentwicklung.

Mein Schwerpunkt sind verkettete Systeme: Software, die Prozesse nicht in Insel-Lösungen zerlegt, sondern als zusammenhängende Abläufe abbildet. Eine Bestellung, die zum Auftrag wird, der in die Produktion geht, der das Lager bewegt, der die Rechnung auslöst — das ist kein Dutzend Einzelprogramme, das ist ein Ablauf. Software sollte ihn auch so behandeln.

Dazu gehört eine Arbeitsweise nach klaren Regeln. Struktur entsteht nicht von selbst — sie ist eine Entscheidung, die man am ersten Tag trifft und dann durchhält. Das gilt für klassische Entwicklung genauso wie für den Einsatz von KI: Ein Werkzeug ist nur so gut wie der Plan, nach dem es eingesetzt wird.

Ich arbeite gründlich und dokumentiere, was ich baue. Nicht, weil Dokumentation Selbstzweck wäre, sondern weil ein System, das man nicht erklären kann, irgendwann niemandem mehr nützt — auch dem nicht, der es gebaut hat.