Über mich
René Gerling
IT-Architekt und Entwickler.
Seit über 15 Jahren arbeite ich an Software, die Unternehmen im Tagesgeschäft tragen muss – meist an Systemen, die über viele Jahre gewachsen sind und die niemand mehr vollständig im Kopf hat. Gerling Solutions ist daraus entstanden.
Hintergrund
Enterprise-Umfeld, nicht Greenfield: Systeme mit langer Historie, echten Anwendern und einem Betrieb, der nicht stehen bleiben darf.
Mein Schwerpunkt liegt auf IT-Architektur und Systemdesign: der Übersetzung fachlicher Anforderungen in Strukturen, die auch in fünf Jahren noch änderbar sind. Dazu gehört die unspektakuläre Arbeit, die selten in Vorträgen vorkommt – Bestandsaufnahme, Schnittstellen entwirren, Abhängigkeiten sichtbar machen, Migrationen so schneiden, dass sie einzeln zurücknehmbar bleiben.
In dieser Arbeit sieht man immer wieder dasselbe Muster: Das Wissen darüber, wie ein Unternehmen tatsächlich funktioniert, steht nicht in der Dokumentation. Es steht im Sourcecode, verteilt über Jahre und über Entwickler, von denen manche längst nicht mehr im Haus sind. Wer eine Auswertung braucht, braucht in Wahrheit jemanden, der dieses Wissen noch hat.
Ich arbeite als Einzelanbieter. Das heißt: Sie sprechen mit der Person, die auch umsetzt – kein Wechsel zwischen Vertrieb, Konzept und Entwicklungsteam. Für große, parallelisierbare Vorhaben ist das die falsche Aufstellung, und ich sage das dann auch.
Entstehung
Warum aus der Beratung ein Produkt geworden ist.
Als Sprachmodelle brauchbar wurden, war die naheliegende Idee auch in meinen Projekten schnell da: die Datenbank anschließen und Fragen stellen lassen. Der erste Versuch funktioniert dabei fast immer – und genau das ist das Problem.
Ein Modell, das nur das Schema sieht, erzeugt Antworten, die plausibel aussehen. Ob ein Status wirklich „offen“ bedeutet, ob eine Tabelle Gegenwart oder Historie enthält, ob Stornos mitzählen: Das steht nicht im Datenmodell. Eine falsche Zahl fällt in einem Bericht niemandem auf, der die Größenordnung nicht ohnehin kennt.
Das eigentliche Problem war nie der Zugriff auf die Daten. Es war die fehlende Beschreibung dessen, was sie bedeuten.
Daraus ist die semantische Schicht entstanden: der Versuch, dieses Wissen einmal sauber aufzuschreiben, statt es in jedem Prompt neu mitzugeben. Dass das funktionieren kann, musste dann allerdings gemessen werden – an einem echten System und zur Gegenprobe an fremden.
Schwerpunkte
Womit ich täglich arbeite. Die Liste ist eine Beschreibung, keine Aufzählung von allem, was schon einmal vorkam.
- Architektur
- Zielarchitekturen, Schnittstellendesign, modulare Monolithen und Microservices, Domain-Driven Design, Architekturentscheidungen mit nachvollziehbarer Begründung.
- Backend
- Java und Spring Boot, REST- und GraphQL-Schnittstellen, Persistenz gegen Oracle, PostgreSQL und MySQL, Security mit OAuth2 und OpenID Connect.
- Frontend
- React und TypeScript, UI-Architektur, Komponentenbibliotheken, End-to-End-Tests.
- Plattform
- Docker und Kubernetes, CI/CD-Pipelines, Deployment-Automatisierung, Betriebsstabilität für geschäftskritische Anwendungen.
- Daten
- Relationale Datenmodellierung, gewachsene Schemata, Migrationen – und seit einiger Zeit die semantische Beschreibung solcher Modelle für KI-Systeme.
Arbeitsweise
Vier Punkte, an denen Sie mich messen können.
Ehrliche Einschätzung vor angenehmer Auskunft
Wenn ein Vorhaben in der geplanten Form nicht tragfähig ist, sage ich das vorher. Das kostet gelegentlich einen Auftrag und spart regelmäßig ein halbes Jahr.
Entscheidungen, die begründet sind
Architekturentscheidungen sollen nachlesbar sein – auch von jemandem, der erst in zwei Jahren dazukommt und wissen muss, warum etwas so gebaut wurde.
Bestand ernst nehmen
Gewachsene Systeme sind selten schön und meistens aus gutem Grund so geworden. Der Weg führt über Verstehen, nicht über Neuschreiben.
Verantwortung statt Empfehlung
Ich begleite Umsetzungen bis zum laufenden Betrieb, statt ein Konzept zu übergeben und den schwierigen Teil anderen zu überlassen.
Zusammenarbeit
Zwei Wege, die sich nicht ausschließen.
Der eine ist die klassische Zusammenarbeit als IT-Architekt und Entwickler: Bestandsaufnahme, Zielarchitektur, Modernisierung, Umsetzung. Der andere ist das Produkt – die semantische KI-Datenschicht, die aus dieser Arbeit entstanden ist.
In der Praxis hängt beides zusammen. Wer die Daten seines Systems auswertbar machen will, stellt dabei fast immer fest, wie viel über das eigene System niemand mehr weiß.
Am schnellsten klärt sich in einem Gespräch, ob ich für Ihr Vorhaben der Richtige bin.