Über mich
Über mich
Ich bin Luiz Claudio Hogrefe, Softwarearchitekt in Köln.
Ich veröffentliche als Luiz Hogrefe. Ich entwickle Software seit 2008, zuerst in Brasilien und seit 2014 in Deutschland. Die meisten dieser Jahre habe ich in Unternehmensprojekten verbracht, in denen eine Architektur Audits, Altsysteme und Übergaben überstehen muss, nicht nur ein erstes Release.
Heute liegt meine Arbeit dort, wo Softwarearchitektur auf KI unter Governance, semantische Interoperabilität und nachvollziehbare digitale Nachweise trifft. Mich interessiert weniger, was ein System in einer Demonstration kann, als das, was es verweigert, was es im Nachhinein belegen kann und wer es ändern darf.
Mein Weg
Ich begann 2008 als Programmierer bei Edusoft in Blumenau und arbeitete an den Finanz- und Studienverwaltungsfunktionen eines webbasierten Systems für die akademische Verwaltung. An der FURB, der regionalen Universität, war ich als Softwareentwickler und später als Systemanalytiker tätig und schloss dort meinen Bachelor in Informatik ab. Meine Abschlussarbeit wandte Ontologien auf die Entwicklung von Informationssystemen im Cloud-Computing an, ein Thema, das sich bis heute durch meine Arbeit zur Semantik zieht.
2014 zog ich nach Deutschland. Nach einem Praktikum in der Java-Entwicklung in Berlin und einer Stelle als Softwareentwickler bei einem Private-Cloud-Anbieter in Düsseldorf arbeitete ich selbstständig an Web- und Mobilanwendungen.
Von 2017 bis 2022 war ich Consultant bei Sopra Steria, in Projekten für Auftraggeber aus Energiewirtschaft, Bankwesen und Automobilindustrie. Die Arbeit reichte von der Entwicklung von Webanwendungen bis zur Architektur und Dokumentation einer Orchestrierungsplattform und zu Deployment-Konzepten. Nach einem Jahr in Brasilien im Interimsmanagement eines Familienunternehmens kehrte ich bei msg in Köln in die Beratung zurück, als Entwickler, Scrum Master und Testmanager.
2024 begann ich unabhängige Forschung zu semantischer Interoperabilität, digitalen Produktpässen und den europäischen Regeln, die sie verlangen werden. 2025 arbeitete ich bei Accenture im Quality Engineering, als Scrum Master und Tester in einem Enterprise-Programm. Von August 2025 bis April 2026 habe ich die Architektur von AnyImob entworfen, einem KI-Assistenten für die Immobilienvermittlung, und seine Entwicklung geleitet. Von Mai bis August 2026 war ich Softwarearchitekt im Bereich Standards der IW Consult in Köln und arbeitete an Architektur und Datenmodellen für digitale Produktpässe sowie an ECLASS als Semantik für digitale Zwillinge.
Seit September 2026 entwickle ich meine Forschung unabhängig im Rahmen von AnyLAI weiter, einem nicht kommerziellen F&E-Projekt.
Wie ich über Architektur denke
Architektur ist für mich die Menge der Entscheidungen, die sich nur teuer rückgängig machen lassen, aufgeschrieben dort, wo man sie prüfen kann. Ein Diagramm hilft. Eine Grenze, die die Build-Pipeline durchsetzt, hilft mehr.
In regulierten Umfeldern wird das konkret. Eine Anforderung aus der ESPR, der EUDR oder dem AI Act ist kein Etikett, das man einem System nachträglich anheftet. Sie ist eine Eingangsgröße wie Latenz oder Datenvolumen und muss sich in Datenmodellen, Schnittstellen, Prüfschritten und in den Nachweisen zeigen, die ein System aufbewahrt.
Leistungsfähige KI-Modelle verschieben, wo die schwierige Arbeit liegt. Wird die Implementierung billiger, gewinnen Absicht, Randbedingungen und Verifikation an Wert. An dieser These arbeite ich derzeit.
Wie ich arbeite
Fünf Prinzipien, die ich auf meine eigene Arbeit anwende. Es sind Gewohnheiten aus der Ingenieurspraxis, keine Naturgesetze.
- 01
Architektur statt Schlagworte
Ein System wird durch seine Grenzen beschrieben, durch seine Schnittstellen und durch das, was es verweigert. Eine Aussage, die sich auf nichts davon zurückführen lässt, ist noch keine Architektur.
- 02
Deterministische Grenzen um probabilistische Systeme
Modelle sind nützlich und fehlbar. Sie erledigen begrenzte Aufgaben hinter Regeln, die entscheiden, alles festhalten und sich reproduzieren lassen, und sie sind nie die Quelle einer Erlaubnis.
- 03
Nachweise, die andere prüfen können
Ein Ergebnis ist so viel wert, wie ein Leser prüfen kann, ohne seinem Verfasser zu vertrauen. Seine Quellen, seine Version und die dafür verantwortliche Person begleiten es.
- 04
Standards ohne Lock-in
Öffentliche Standards zuerst, etwa W3C Verifiable Credentials, UN/CEFACT und GS1, damit sich das, was ich baue, ohne mich prüfen, ersetzen oder übergeben lässt.
- 05
Mehrdeutigkeit explizit machen, bevor man sie automatisiert
Automatisierung verstärkt, was man ihr gibt. Aus einer mehrdeutigen Anforderung wird ein konsistenter Fehler. Deshalb schreibe ich die Mehrdeutigkeit zuerst auf und kläre sie mit den Menschen, die für die Anforderung verantwortlich sind.
Sprachen
Ich arbeite in vier Sprachen, und deshalb gibt es diese Website auch in vier.
- PortugiesischMuttersprache
- DeutschC1
- EnglischC1
- Spanischsicher im beruflichen Einsatz
Aktuelle Forschung
Meine Forschung entsteht und erscheint im Rahmen von AnyLAI, einem unabhängigen, nicht kommerziellen F&E-Projekt. Es ist kein Unternehmen, und nichts, was dort veröffentlicht wird, ist ein Angebot.
Bisher gehören dazu COADF, ein veröffentlichtes Framework, um KI-gestützte Software unter expliziter Governance zu bauen; ERQYO, eine Laufzeitarchitektur für kontrollierte Entscheidungen mit einer Referenzimplementierung; und AnyDPP, eine Forschungsumgebung für nachweisbasierte digitale Produktpässe.