Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

heise conferences GmbH

(vormals SIGS DATACOM GmbH)

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de

Architekturreviews mit Generativer AI

Generative AI (GenAI) wird seit dem Erscheinen von ChatGPT vor ca. zwei Jahren unter Softwareentwicklern und -architekten sehr positiv aufgenommen. Es fragt sich, inwiefern GenAI heute schon bei der Beurteilung von Architekturen unterstützen kann. Dabei schwingt natürlich immer die Frage mit, wann GenAI Softwarearchitekten für solche Aufgaben ersetzen wird. Dieser Artikel zeigt an drei Beispielen das konkrete Potenzial und die Grenzen von GenAI für Architekturreviews. Der Artikel soll dazu anregen, GenAI schlicht einmal „auszuprobieren“.

Author Image
Wolfgang Keller

Individualsoftwareentwickler


  • 18.06.2025
  • Lesezeit: 14 Minuten
  • 435 Views

Der Autor hat zwei Bezüge zu dem Thema „Architekturreviews mit GenAI“. Als Autor eines Standardwerks über Unternehmensarchitektur [1] muss man sich bei der Überarbeitung heute klar fragen, welche Rolle GenAI in der Zukunft für die Arbeit von Unternehmensarchitekten und auch Solution-Architekten spielen wird [2]. Enterprise Architecture Management (EAM) soll aber hier nicht das Schwerpunktthema sein. Ein zweiter Bezug ergibt sich aus seiner praktischen Tätigkeiten als Reviewer: Der Autor bekommt pro Jahr ungefähr 30 Architekturdokumente zum Review und fragt sich heute automatisch, ob und wie GenAI bei diesen Reviews helfen und wie weit man bei der Automatisierung heute (im Februar 2025) schon gehen kann. Dieser Artikel gibt einige dabei gewonnenen Erfahrungen wieder.

Um diese Erfahrungen mit und die Eigenschaften von GenAI beschreiben zu können, wird hier der Ansatz verfolgt, drei praktische Beispiele zu verwenden. Das Problem dabei ist: Woher bekommt man Beispiele von Architekturdokumenten, die man mithilfe von GenAI testweise reviewen kann, ohne deren Vertraulichkeit zu verletzen.

Zum Glück gibt es einiges an Literatur rund um die Verwendung von arc42 [3], [4], die als Muster-Reviewobjekte dienen können. „Problem“ dieser Beispiele ist aber, dass sie deutlich sorgfältiger geschrieben sind, als Architekturdokumente aus der betrieblichen Praxis, die der Autor ansonsten zu sehen bekommt. Bei solchen Beispielen muss also berücksichtigt werden, dass die GenAI normalerweise deutlich mehr Fehler und Inkonsistenzen finden kann, als mit sorgfältig ausgearbeiteten Lehrbeispielen gezeigt werden kann.

Für den dritten Fall, der Beurteilung von Sotographie-Ergebnissen, gibt es leider deutlich weniger öffentlich zugängliches Material als Input als arc42-Musterdokumente. Aber lassen Sie uns das beim Fall diskutieren.

Eine letzte Vorbemerkung sei noch gemacht. Sie werden sehen, dass GenAI generell eher zu viele Vorschläge macht und bezüglich des Umsetzungsaufwands von Verbesserungsvorschlägen auffallend unkritisch ist.

Fall 1: Review von Qualitätsszenarien

Qualitätsszenarien sind ein kritischer Teil von Architekturdokumenten. Bei der Analyse und Generierung solcher Szenarien hat der Autor viele Erfahrungen gemacht. Dies bezieht sich sowohl auf die weitere Verbesserung an sich guter Szenarien als auch auf eine umfassende Auflistung relevanter Szenarien. Meist generiert GenAI hier deutlich zu viel und man kann als Architekt dann das heraussuchen, was man für relevant hält, und den Rest streichen. Um das einmal zu illustrieren, verwenden wir die Architekturszenarien aus [3], die man hier findet und die zu umfangreich sind, um sie hier komplett abzudrucken.

Der für die Analyse verwendet Prompt ist sehr elementar und kurz:

Prompt: Erstelle einen Review über die Qualitätsszenarien im Project Knowledge. Was könnte man daran noch verbessern?

Die Verbesserungsvorschläge, die das von Anthropic entwickelte Sprachmodell Claude.ai hier macht, sind allesamt gut nachvollziehbar, auch ohne den Input gesehen haben zu müssen. Auszüge finden Sie in Kasten 1.

Kasten 1: Verbesserungsvorschläge von Claude.ai zu Fall 1
Die vorhandenen Qualitätsszenarien sind bereits gut strukturiert und decken wichtige Qualitätsaspekte ab:
<< gekürzt >>
Funktionalität (F01-F04):
• Positiv: Deckt verschiedene Spielsituationen ab
• Verbesserungspotential:
o Die Szenarien könnten noch konkreter die erwartete Spielstärke definieren
o Es fehlen Szenarien für Spezialfälle wie Patt oder Remis
o Die "Intelligenz" der Engine könnte durch weitere strategische Szenarien präzisiert werden
Effizienz (E01-E02):
• Positiv: Klare Zeitvorgaben
• Verbesserungspotential:
o Hardware-Anforderungen fehlen komplett
o Ressourcenverbrauch (CPU, RAM) ist nicht spezifiziert
o Szenarien für verschiedene Spielphasen (Eröffnung, Mittelspiel, Endspiel) fehlen
<< gekürzt >>
Allgemeine Verbesserungsvorschläge:
1. Messbarkeit:
• Viele Szenarien könnten noch präziser formuliert werden, um die Erfüllung eindeutig überprüfbar zu machen
• Automatisierte Tests für die Szenarien sollten wo möglich ergänzt werden
2. Vollständigkeit:
• Sicherheitsaspekte fehlen komplett (z.B. Schutz vor manipulierten Eingaben)
• Performance unter Last ist nicht spezifiziert
• Dokumentationsqualität könnte durch weitere Szenarien präzisiert werden
3. Priorisierung:
• Eine Gewichtung der Szenarien fehlt
• Muss- und Kann-Kriterien sind nicht gekennzeichnet
<< gekürzt >>

Hier wird schon deutlich, dass GenAI einen eher hohen Maßstab anlegt. Einige der Vorschläge sind aber durchaus noch praktisch umsetzbar.

Fall 2: Review von Architekturbildern

Eine weitere sehr nützliche Fähigkeit von GenAI ist es, komplette Architekturdokumente auf Inkonsistenzen der Architekturdarstellungen untereinander durchsuchen zu lassen. Als Beispiel hierfür benutzen wir das Beispiel „biking2“ von Michael Simmons aus dem Buch „arc42 by Example“ [4].

Das Beispiel wurde aus dem Buch als PDF exportiert (45 Seiten) und in Claude Sonnet 3.5 zur Analyse hochgeladen. Der Prompt war auch hier extrem einfach:

Prompt: Prüfe die Diagramme in dem Dokument auf Konsistenz untereinander. Was könnte man verbessern?

Da es sich um ein Lehrbuchbeispiel handelt, sind die gefundenen Verbesserungsvorschläge vergleichsweise Kleinigkeiten. Die Experimente des Autors mit Dokumenten aus dem Alltag fördern hier regelmäßig deutlich drastischeres Verbesserungspotenzial zutage. Trotzdem illustriert Kasten 2 Teile der Ausgabe.

Kasten 2: Generierte Verbesserungsvorschläge zu Fall 2
<< gekürzt >>
Konsistenzprüfung zwischen Building Blocks Level 0 (S. 115) und Level 1 (S. 116):
Inkonsistenzen:
• Level 0 zeigt drei Hauptkomponenten (api, bikingFX, spa), während Level 1 nur die api-Komponente detailliert
• Die Beziehungen zwischen den Komponenten sind in Level 1 deutlich komplexer dargestellt als in Level 0 angedeutet
Konsistenzprüfung der Whitebox-Diagramme (S. 122-127):
Inkonsistenzen:
• Die Darstellung der Repositories und Controller folgt nicht durchgängig dem gleichen Muster
• Die Bezeichnungen der Schnittstellen variieren (z.B. "Api" vs "API")
• Die Detailtiefe der einzelnen Whitebox-Diagramme ist unterschiedlich
Verbesserungsvorschläge:
1. Vereinheitlichung der Notation:
• Durchgängige Verwendung der gleichen Bezeichnungen (z.B. "biking2::api")
• Einheitliche Darstellung von externen Schnittstellen
• Konsistente Verwendung von Stereotypen und Bezeichnern
2. Strukturelle Verbesserungen:
• Klare Hierarchie zwischen den Abstraktionsebenen zeigen
• Beziehungen zwischen den Diagrammen explizit machen
• Einheitliche Detailtiefe in den Whitebox-Diagrammen
3. Dokumentations-Verbesserungen:
• Legende für verwendete Symbole und Notationen hinzufügen
• Explizite Verweise zwischen zusammenhängenden Diagrammen
• Erklärung der Unterschiede zwischen den Sichten
4. Technische Verbesserungen:
• GPSBabel-Integration konsistent darstellen
• Klare Trennung zwischen internen und externen Komponenten
• Einheitliche Darstellung der Datenflüsse
<< gekürzt >>

Aus diesem Beispiel wird ebenfalls deutlich, dass die GenAI auch bei schon recht guten Dokumenten Vorschläge macht, bei denen man dann in der Praxis dazu neigt, auch einmal „good enough“ zu sagen. Wenn Sie Beispiele aus Ihrer betrieblichen Praxis mit guter GenAI wie Claude.ai analysieren, werden Sie deutlich gravierendere Verbesserungspotenziale finden.

Fall 3: Analyse von Sotographien

In der Medizin gibt es inzwischen mehrere Studien, die untersucht haben, welche Leistungen GenAI bei der Analyse zum Beispiel von Röntgenaufnahmen erbringen kann. Die Leistungen sind sehr vielversprechend. Allerdings sollte auch dort ein menschlicher Experte die Ergebnisse verifizieren.

Auch bei der Beurteilung von Softwaresystemen gibt es „bildgebende Verfahren“, die die Strukturen innerhalb von Softwaresystemen sichtbar machen. Sie sind unter dem Stichwort „Sotographie“ bekannt. Dabei werden die Aufrufbeziehungen (meist zwischen Packages) in der Software sichtbar gemacht und es entstehen sehr oft die aus Architektur-Horrorgeschichten bekannten „Big Ball of Mud“-Bilder. Abbildung 1 stammt aus einem schon etwas älteren Whitepaper zu Sotographie [5].

Sotographie-Beispiel aus [5]

Abb. 1: Sotographie-Beispiel aus [5]

Im Vergleich zu arc42-Musterdokumenten sind Sotographie-Analysen und deren Verbesserungsvorschläge weniger gut dokumentiert. Die Analyse von Sotographie-Bildern mit GenAI scheint aber eine durchaus vielversprechende Idee zu sein analog zur Analyse von Bildern aus medizinischen, bildgebenden Verfahren. Abbildung 1 kann man Claude Sonnet 3.5 zur Analyse geben. Starten wir mit dem Prompt:

Prompt: Was kannst Du zu dem in der Abbildung enthaltenen Sotograph-Scan sagen. Mache Refactoring-Vorschläge.

Kasten 3 zeigt einen Auszug des Outputs. Die weitergehenden Vorschläge, die die GenAI generiert, wurden aus Platzgründen weggelassen. Der Output ist vielversprechend.

Kasten 3: Auszug des Outputs zu Fall 3
Die Abbildung zeigt einen Sotograph-Scan, der die Abhängigkeiten und Aufrufe zwischen verschiedenen Funktionsbausteinen visualisiert. Hier sind meine Beobachtungen und Refactoring-Vorschläge:
1. Strukturelle Analyse:
• Es ist eine kaskadenartige Struktur von links nach rechts erkennbar
• Der Haupteinstiegspunkt ist die Funktion "DOWNLOADPROGRAM" auf der linken Seite
• Es gibt mehrere Verzweigungen und Abhängigkeiten, die sich nach rechts aufteilen
2. Potenzielle Probleme:
• Hohe Kopplung: Viele Funktionen sind stark miteinander vernetzt
• Lange Aufrufketten: Die Tiefe der Aufrufe von links nach rechts deutet auf möglicherweise zu komplexe Abhängigkeiten hin
• Mehrfachaufrufe: Einige Funktionen werden von verschiedenen Stellen aufgerufen
3. Refactoring-Vorschläge:
a) Modularisierung:
• Die Funktionalitäten könnten in logische Module gruppiert werden
• Zum Beispiel scheinen die "CONVERTTOHTML"-bezogenen Funktionen einen eigenen Bereich zu bilden
• Die "DOWNLOAD"-bezogenen Funktionen könnten in ein separates Modul extrahiert werden
b) Schichtenarchitektur einführen:
• Klare Trennung zwischen Download-, Konvertierungs- und Ausgabefunktionen
• Einführung von Abstraktionsebenen zur besseren Wartbarkeit
c) Dependency Injection:
• Reduzierung der direkten Abhängigkeiten zwischen den Funktionen
• Einführung von Interfaces für bessere Testbarkeit und losere Kopplung
d) Facade Pattern:
• Einführung einer Fassade für häufig zusammen genutzte Funktionalitäten
• Vereinfachung der Aufrufstruktur für Client-Code
... hier abgeschnitten

Es folgen dann konkrete, exemplarische Verbesserungsvorschläge bis auf das Niveau von Interface-Definitionen. Wenn Sie den ganzen Text möchten, können Sie relativ schnell das Bild aus der Quelle [5] zum Beispiel von Claude.ai analysieren lassen. Oder vielleicht haben Sie ja in Ihrem Umfeld sogar Bilder von eigenen Analysen. Es lohnt sich, das einfach einmal auszuprobieren.

Es muss allerdings angemerkt werden, dass man hier weiter- und tiefergehende Analysen und eine detailliertere Beschäftigung mit dem Thema benötigen würde, um die gegebenen Sanierungsvorschläge beurteilen zu können.

Auswertung: Pros und Cons bei der Nutzung von GenAI

Bei einem meiner Reviews (keines der Beispiele aus dem Artikel hier, sondern eines hier nicht veröffentlichbaren Dokuments) habe ich der GenAI die Frage nach der Qualität des Dokuments gestellt. Die GenAI war mit dem Dokument im Großen und Ganzen zufrieden.

GenAI ersetzt noch selten das „gute Auge eines erfahrenen Architekten“

Ich habe dann die GenAI gezielt auf diverse Schwachstellen des Entwurfs hingewiesen und daraus entstand ein interessanter Dialog mit der GenAI (in dem Fall Claude Sonnet 3.5), die dabei ausführte, dass sie derzeit das Urteil eines erfahrenen Softwarearchitekten noch nicht ersetzen kann.

Man bekommt also, wenn man Dokumente der GenAI zur Prüfung gibt, was Lösungsansätze anlangt, oft noch ein zu positives Bild und muss die GenAI erst gezielt auf Probleme hinweisen. Dies passiert vergleichsweise häufig. Die Erfahrung war, dass sich GenAI oft auf formale Inkonsistenzen konzentriert und nicht auf grundlegende Entwurfsprobleme. Wenn man die GenAI dann allerdings im Chat genau auf solche „großen Probleme“ eines Entwurfs hinweist, wird man oft bestätigt und bekommt eine sehr gute Begründung für das Problem und sehr fundierte Ratschläge, um sie zu beseitigen.

GenAI macht meistens mehr Vorschläge, als mit limitiertem Aufwand sinnvoll umsetzbar sind

Gerade bei Qualitätsszenarien oder auch Entwürfen für Komponentenstrukturen bekommt man eher zu viele als zu wenige gute Ratschläge. Die GenAI listet eher zu viele Risiken auf. Es werden oft Qualitätsszenarien vorgeschlagen, von denen ein erfahrener Architekt sowieso weiß, dass sie kein Problem darstellen werden. Oder aber für einen Entwurf auf einem noch hohen Abstraktionsniveau wird angemerkt, dass man sich im Detail mit dem Logging und Monitoring beschäftigen möge. Auch hier ist gesundes Augenmaß eines erfahrenen Solution-Architekten hilfreich, um nicht in unwichtige Details oder Perfektionismus abzudriften und um nicht den Blick für das Wesentliche zu verlieren.

Die Rolle „guter Prompts“

Wie Sie oben gesehen haben, waren die verwendeten Prompts sehr kurz und einfach. Als Nutzer von GenAI lernt man mit der Zeit, dass man die GenAI auch dafür nutzen kann, um sich verbesserte Prompts vorschlagen zu lassen. Ich habe diesen Artikel natürlich ebenfalls von GenAI reviewen lassen. Und statt meines einfachen Prompts zu Qualitätsszenarien wurde mir der Prompt aus Kasten 4 vorgeschlagen.

Kasten 4: Generierter Prompt zu Qualitätsszenarien
Prompt:
Analysiere die vorliegenden Qualitätsszenarien hinsichtlich:
1. SMART-Kriterien (Spezifisch, Messbar, Achievable, Relevant, Time-bound)
2. Abdeckung der relevanten Qualitätsattribute
3. Testbarkeit und Überprüfbarkeit
4. Realismus der Metriken und Schwellwerte
5. Vollständigkeit der Szenario-Elemente (Stimulus, Umgebung, Response)

Identifiziere:
- Fehlende oder unvollständige Szenarien
- Nicht messbare oder zu vage Formulierungen
- Unrealistische Anforderungen
- Inkonsistenzen zwischen Szenarien
Schlage konkrete Verbesserungen vor.

Dass dies noch deutlich detailliertere Ergebnisse liefern wird, dürfte einsichtig sein. Ein Vergleich würde den Umfang dieses Artikels sprengen. Aber es kostet wirklich nicht viel Zeit, dies bei Interesse einmal praktisch auszuprobieren.

Datenschutz bleibt eine Herausforderung

Der schnellste und einfachste Weg, um GenAI zu benutzen, ist es, eine der verbreiteten Lösungen wie ChatGPT oder Claude aus der Cloud zu verwenden. Man kann dort sehr große Modelle verwenden (700 Mrd. Parameter), die einen solchen Speicherbedarf für die Ausführung haben (bis zu ca. 1 TB Hauptspeicher), den man als Privatanwender oder kleineres Unternehmen eher nicht betreiben möchte.

Als Problem werden dabei oft die Datenschutzvereinbarungen angesehen. Die Betreiber der Lösungen behalten sich vor, Chats zu analysieren und für Trainingszwecke ihrer Modelle zu verwenden. Sie sichern dabei zwar Vertraulichkeit zu. Aber zum Beispiel personenbezogene Daten aus Deutschland darf man so nicht in den USA oder „sonst wo“ verarbeiten lassen. Das wäre ein Verstoß gegen Datenschutzbestimmungen. Und auch sonst sind die meisten Unternehmen dort eher restriktiv. Damit muss man dann entweder auf selbst gehostete kleinere Lösungen ausweichen oder aber sehr genau darauf achten, was man der GenAI zur Analyse übergibt.

Spezifisches Training der GenAI ist für die meisten Fälle und Firmen eher zu aufwendig

Wenn man nachfragt, wie viel es kostet, zum Beispiel ein großes pretrained GenAI-Modell nach dem Stand der Technik (hat heute typisch 700 Mrd. Parameter) mit 100 geprüften, hochwertigen und damit „guten“ Architekturdokumenten firmenintern nachzutrainieren, bekommt man als Antwort Preise von 10.000 USD für optimierte Methoden mit RAG (Retrieval-Augmented Generation) bis zu 500.000 USD für den „Brute Force“-Ansatz. Alles ohne den Personalaufwand für die Anwendung der Trainingsmethoden.

Ein solches Vorhaben lässt sich also nicht mehr „mal so nebenbei in der Freizeit“ betreiben, sondern es ist dafür tiefere Expertise notwendig und einiges an Aufwand für Planung und Durchführung. Außerdem muss man sich auch da wieder Gedanken zum Datenschutz machen, weil – wenn man die nötigen GPUs dafür bei Amazon Web Services anmietet – man sich auch hier wieder in der Cloud befindet.

Wenn Sie sich dafür interessieren, lassen Sie es sich einfach von der GenAI Ihres Vertrauens grob erklären. Als Prompt können Sie zum Beispiel das Folgende verwenden:

Prompt: Nehmen wir an, eine Firma möchte ihr Pretrained GenAI Model mit 100 Architekturdokumenten mit einem Umfang von jeweils 100 Seiten nachtrainieren. Weiter nehmen wir an, dass es sich um ein modernes Modell mit ca. 700 Mrd. Parametern handelt. Wie viel würde das Training in der Cloud ungefähr kosten?

Mögliche Kontextgröße als entscheidender Faktor

Wer ohne Training auskommen möchte, muss dem GenAI-System einen möglichst großen Kontext an passenden Hintergrunddokumenten mitgeben können, die ein Training teilweise ersetzen können. Claude 3.5 Sonnet kann nach eigenen Angaben ca. 200.000 sogenannte Tokens (je 4 Zeichen) oder bis zu 1,6 MB verarbeiten. Für Architekturdokumente mit ein paar Bildern ist das nicht viel. Für GenAI ist das allerdings schon ein guter Wert.

Wer also Architekturreviews im quasi „industriellen Umfang“ betreiben möchte, wird sich doch mit Training und RAG befassen müssen. Dasselbe gilt noch viel stärker, je weiter man sich in das Gebiet von EAM vorwagen möchte. Hier ist der Kontext quasi die komplette Dokumentations- und Codebasis eines mitunter sehr großen Unternehmens.

Lohnt sich also der Einsatz von GenAI für Architekturreviews?

Dies lässt sich auf jeden Fall bejahen. Ähnlich wie bei guten Checklisten bekommt der Architekt mindestens eine zweite Meinung und wegen der Neigung, eher zu viel zu schreiben als zu wenig, bekommt er ein Angebot an Vorschlägen und Diagnosen, aus denen er dann selbst auswählen kann. Was man allerdings (noch) nicht bekommt, ist die „gute Nase“ eines erfahrenen Architekten, der die „Bad Smells“ von Lösungen mit Verbesserungsbedarf quasi „riechen“ kann.

Wenn Sie also mit dem Einsatz von GenAI für Ihre Architekturreviews beginnen möchten, sind die praktischen Tipps:

  • Seien Sie sich bewusst, dass die GenAI Sie produktiver macht und auch gründlicher. Aber behalten Sie dabei den Blick dafür, was bezahlbar bleibt und was an Verbesserungen noch mit vernünftigem Aufwand machbar ist.
  • Seien Sie sich bewusst, dass GenAI nicht besonders gut beim Entdecken von „Bad Smells“ ist. Benutzen Sie sie als Ergänzung, aber verlassen Sie sich nicht allein auf das Urteil einer GenAI.
  • Beachten Sie die Datenschutz-Problematik. Personenbezogene Daten müssen Sie sowieso entfernen. Bei Architekturdokumenten müssen Sie sehr genau überlegen, ob es sich dabei um vertrauliche Unterlagen handelt oder eher nicht.
  • Fangen Sie mit Teilaspekten von Architekturdokumenten an – zum Beispiel, wie gezeigt, mit Qualitätsszenarien.
  • Konsistenzchecks zwischen Abbildungen sind ein weiteres Gebiet, das es sich lohnt, mit GenAI zu behandeln.
  • Experimentieren Sie auch einmal damit, dass GenAI Ihnen verbesserte Prompts selbst vorschlagen kann.

Ich hoffe, Ihnen damit einige nützliche Anregungen gegeben zu haben, und wünsche viel Erfolg und auch Vergnügen bei Ihrer Architekturarbeit mit GenAI.

Literaturangaben

[1] W. Keller, IT-Unternehmensarchitektur, dpunkt.verlag, 4. Auflage, 2024

[2] W. Keller, Towards The Use of Generative AI in IT Enterprise Architecture Management, White Paper published via LinkedIn, Juni 2024, siehe: https://www.linkedin.com/posts/wolfgangkeller_towards-use-of-ai-in-it-enterprise-architecture-activity-7207853144536453120-EtVB

[3] S. Zörner, DokChess als Beispiel für arc42, siehe: https://www.dokchess.de/

[4] G. Starke et al., arc42 by Example, leanpub publishing, 2023, siehe: https://leanpub.com/arc42byexample

[5] C. Heppner et al., Sotographie. Code-basierte Analyse, Bewertung und Sanierung komplexer ABAP-Systeme, Workplace Solutions, Whitepaper, 27.5.2016, siehe: https://files.wps.de/pdf/wps-loesungen-softographie-whitepaper-abap.pdf

. . .

Author Image

Wolfgang Keller

Individualsoftwareentwickler
Zu Inhalten

Wolfgang Keller bezeichnet sich als „gelernten“ Individualsoftwareentwickler für große Unternehmen. Er hat vor langer Zeit Informatik studiert und in ca. 30 Jahren viele Stationen meist im Bereich von Versicherungssoftware durchlaufen: Entwickler, Solution Architect, Enterprise Architect, Delivery Manager, Project Manager oder Linienmanager. Softwarearchitektur ist dabei immer sein Hobby geblieben. Momentan arbeitet er als Qualitätsmanager und Integrationsarchitekt. E-Mail: wolfgang.keller@objectarchitects.d


Artikel teilen