Klassische Architektur-Reviews beschäftigen sich mit dem Code: Architektur gibt dem Code schließlich Struktur. Diese Struktur ist zentral für die Änderbarkeit.

Metriken machen die Qualität dieser Struktur messbar und ermöglichen die schnelle Analyse auch großer Projekte. Ein System sollte in überschaubar große Bestandteile mit möglichst wenigen Abhängigkeiten aufgeteilt werden. Zu solchen Bestandteilen zählen Klassen, Packages (Sammlungen von Klassen in Java) oder Microservices. Die Größe der Bestandteile und die Anzahl der Abhängigkeiten kann man als Metrik messen und so die Qualität beurteilen.

Besonders schlimm sind zyklische Abhängigkeiten: Wenn beispielsweise zwei Packages wechselseitig voneinander abhängen, kann eine Änderung in einem der Packages das andere beeinflussen. Eigentlich sollten die beiden Packages also getrennt sein – in Wirklichkeit sind sie aber eins. So ein Zyklus ist eine Art „Todsünde“ in der Architektur.

Es gibt aber noch andere Metriken. Man kann auch die zyklomatische Komplexität von Methoden messen. Das ist die Anzahl der möglichen Ausführungspfade durch eine Methode. Jede Fallunterscheidung (if-Statement) ergibt einen weiteren möglichen Ausführungspfad. Mehr Ausführungspfade bedeutet, dass der Code komplexer und schwerer zu verstehen ist.

Aber treffen solche Metriken den Kern der Probleme?

Metriken haben wenig Aussagekraft

Metriken bergen fast immer Probleme. Nicht selten muss man von einem „Big Ball of Mud“ sprechen. Das ist ein System mit so schlechten Metriken, dass es eigentlich keine echte Strukturierung hat. Wenn niemand mit entsprechenden Werkzeugen die Metriken managt, ergibt sich fast immer ein unstrukturiertes System. Es ist dann trivial herauszufinden, dass ein System schlecht strukturiert ist. Wenn das so einfach ist – welchen Wert hat dieser Einblick?

Es stellen sich dann eher andere Fragen:

• Das Verschieben einer einzigen Klasse kann einen Zyklus auflösen. Wir haben dann eine „Todsünde“ beseitigt. Aber ist das System wirklich signifikant einfacher änderbar?
• Vielleicht kommt das Team mit dem System ausreichend gut zurecht, weil es sich an die schlechte Strukturierung gewöhnt hat. Wie kann man das erfassen?
• Ein System bildet eine Fachlichkeit ab. Wie hoch ist die minimale Komplexität, die für eine bestimmte Fachlichkeit benötigt wird? Wie viel überflüssige Komplexität hat das System dann?

Eigentlich interessiert uns die Änderbarkeit des Systems. Die Metriken können Hinweise auf eine gute oder schlechte Änderbarkeit geben, aber nicht mehr. Es ist durchaus denkbar, dass ein System mit schlechten Metriken dennoch ausreichend änderbar ist, weil das Team das System schon lange weiterentwickelt und sich an die Strukturierung gewöhnt hat.

Gute Metriken bedeuten auch nicht unbedingt eine gute Änderbarkeit: Wenn ein Team ein perfekt strukturiertes System ohne Übergabe und Wissenstransfer übernimmt, wird es das System dennoch nur schwer ändern können. Es gibt sogar Hinweise, dass selbst eine ausführliche und klare Dokumentation nicht ausreichend ist, um ein System sinnvoll weiterzuentwickeln, sondern das ursprüngliche Team zur Verfügung stehen muss.

Software ist ein soziotechnisches System

An diesem Punkt hilft eine andere Perspektive:

Softwaresysteme sind nicht rein technische Systeme. Sie sind soziotechnische Systeme.

Die Idee der soziotechnischen Systeme geht unter anderem auf die Untersuchung im britischen Steinkohlebergbau zurück. In diesem Bereich kann man nicht einfach nur die Maschinen und Technologien betrachten, sondern man muss die Menschen mit betrachten – und zwar als spezifische Individuen, nicht als austauschbare Ressourcen. Der Verdacht liegt nahe, dass die Betrachtung der individuellen Menschen im Bereich Softwareentwicklung noch wichtiger ist.

Orientiert man sich an dieser Idee, muss man bei Reviews anders vorgehen. Die zentrale Frage lautet dann nicht: Wie sieht die Architektur aus? Und wie gut ist sie? Wichtig sind stattdessen Fragen wie: Wie geht dieses Team mit dieser Architektur um? Welche Probleme hat es dabei?

Teams haben die Expertise für ihre Systeme

Das führt zu einem weiteren wichtigen Perspektivwechsel: Die Menschen, die täglich an einem System arbeiten, sind offensichtlich die Expertinnen und Experten für das System. Es lohnt sich, diese Expertise zu nutzen.

Interviews mit diesen Menschen werden daher zu einem zentralen Bestandteil des Review. Als Einstieg bieten sich offene Fragen an:

• Was sind die Hauptstärken des Systems?
• Was sind die Hauptherausforderungen?

So kann man eine Unterhaltung starten, in deren Verlauf die Expertinnen und Experten einen nahezu automatisch zu den Hauptherausforderungen des Systems führen. Wenn das Review bestimmte Herausforderungen oder Fragestellungen untersuchen soll, muss man natürlich diese Punkte in das Gespräch einfließen lassen.

Wichtig ist außerdem eine Mischung unterschiedlicher Personen als Interviewpartner. Neben denjenigen, die das System umsetzen, sind auch Benutzerinnen und Benutzer sowie andere Stakeholder relevant. Schließlich sind sie die Quelle der Anforderungen, die dem Projekt und damit der Architektur zugrunde liegen. Wenn sich die Perspektiven der verschiedenen Gruppen sehr unterscheiden, ist das ein interessantes Ergebnis. Schließlich kann das Projekt wohl kaum erfolgreich sein, wenn verschiedene Gruppen das Ziel des Projekts unterschiedlich sehen.

Architekturprobleme sind oft soziale Probleme

So führen diese Reviews zu anderen Erkenntnissen.

Ein Beispiel: In einem Review beschwerten sich viele Interviewpartner über dieselbe Architekturentscheidung. Sie wurde als katastrophal empfunden. Interessanterweise konnte aber niemand eine Alternative oder eine Idee zu einer Alternative nennen, die unter den damaligen Randbedingungen funktioniert hätte.

Die eigentliche Erkenntnis war also nicht: „Die Entscheidung war richtig oder falsch.“ Sondern: „Das Team hat diese Entscheidung nie akzeptiert.“ Das ist ein völlig anderes Problem und muss völlig anders gelöst werden.

Ergebnisse

Ein Architektur-Review sollte nicht nur Erkenntnisse produzieren. Stattdessen ergeben diese Reviews eine konkrete Liste mit nach Dringlichkeit und Wichtigkeit priorisierten Empfehlungen für Handlungen.

Manchmal beginnt die Veränderung sogar schon während der Interviews. Menschen merken, dass ihre Perspektive ernst genommen wird, Probleme ausgesprochen werden und andere ähnliche Schwierigkeiten sehen. Dadurch entsteht häufig bereits eine Änderung. Oft geht das Review dann in eine Beratung über. Die Basis für den Erfolg der Beratung hat dabei die offene Kommunikation bei den Interviews und das daraus entstehende Vertrauen gelegt.

Wenn also wie in dem bereits genannten Beispiel eine Entscheidung nicht akzeptiert worden ist, dann kann die vertrauensvolle Kommunikation helfen, die Zusammenarbeit zu verbessern. Weil alle ihre Meinung einbringen und Alternativen vorschlagen konnten, können sich die Beteiligten vielleicht eher mit der Realität abfinden oder nach echten Alternativen suchen, die den Rahmenbedingungen tatsächlich gerecht werden.

Auch in einem anderen Fall ging das Review in eine Beratung mit der Arbeit an den identifizierten Herausforderungen über, die tatsächlich das Vorgehen in dem Projekt geändert haben. Eine andere Beratung hatte vorher mit einem viel größeren Team ein Review vorgenommen und einen Foliensatz erstellt. Sicher hat der Foliensatz interessante und relevante Erkenntnisse enthalten – sie nützen nur nichts, wenn sie das Projekt nicht verbessern. Bei der Effektivität ist ein soziotechnisches Review daher oft überlegen.

Fazit

Klassische Architektur-Reviews fokussieren häufig auf technische Artefakte. Aber Software entsteht durch Menschen.

Viele Architekturprobleme sind letztlich soziale Probleme. Deshalb lohnt es sich, Architektur als soziotechnisches System zu betrachten. Dadurch dringt man schneller zu den zentralen Herausforderungen vor, weil man sich durch die Expertise der Teams leiten lassen kann, statt ungesteuert das gesamte System im Detail zu bewerten. Gleichzeitig verbessern die Interviews die Kommunikation und führen oft auch zu mehr Vertrauen – eine wichtige Voraussetzung, um zu echter Verbesserung zu gelangen. Es gibt zu soziotechnischen Architektur-Reviews auch eine Episode bei Software-Architektur im Stream und eine Webseite.

Interviews mit offenen Fragen können auch in anderen Kontexten hilfreich sein: Wenn in einem Projekt eine Situation unklar ist, helfen vertrauliche Gespräche mit offenen Fragen oft weiter. Genauso kann man den Ansatz nutzen, um in einem unbekannten Kontext wie einem neuen Projekt die beteiligten Personen besser zu verstehen und mit ihnen eine gemeinsame Basis zu finden. Um solche Gespräche durchzuführen, kann das Cheat Sheet helfen. Regeln können tatsächlich dabei helfen, besser zu kommunizieren – und das Cheat Sheet enthält dazu einige Ideen, die aus den Interviews verschiedener Reviews entstanden sind und sich dabei bewährt haben.

(rme)

Zwei Jahre Arbeit sind in das neu erschienene SkiaSharp 4.148.0 geflossen. Dabei handelt es sich um die erste stabile 4.x-Version der Cross-Platform-2D-Grafik-API für .NET-Plattformen, die auf Googles Skia-Graphics-Bibliothek basiert. Sie bringt eine überarbeitete Engine für verbesserte Grafiken sowie erhöhte Performance.

SkiaSharp wird vom .NET-Team in Partnerschaft mit dem Uno-Platform-Team entwickelt und kommt in .NET MAUI, WebAssembly, WinUI 3 und Frameworks wie Uno Platform zum Einsatz.

Upgrade für die Engine

Die in SkiaSharp 4 auf den Chrome-Meilenstein m148 aktualisierte native Skia-Engine soll sich positiv auf bestehende Apps auswirken, ohne Codeänderungen zu erfordern. Unter anderem soll sie die Performance verbessern sowie für schärfere herunterskalierte Grafiken, automatische Fotoausrichtung und akkuratere Farben sorgen. Wie Microsoft in der Ankündigung betont, zeigen erste Tests im Vergleich zur vorherigen SkiaSharp-Version 3.119 ein um bis zu 24 Prozent schnelleres Rendering zentraler App-UI-Bestandteile, wie Schlagschatten und mehrschichtige Oberflächen. Dabei treten laut den Tests an anderen Stellen keine Regressionen auf.

Aufgeräumt und mit neuen Fähigkeiten

SkiaSharp 4 räumt darüber hinaus mit Legacy-APIs auf und behebt unter der Haube die Ursache für eine Klasse von Use-After-Free-Abstürzen durch einen neuen Umgang mit Singleton-Objektlebenszyklen. Daneben hat das Entwicklungsteam die Test-Suite auf xUnit 3 aktualisiert und jede gebundelte native Dependency mit den neuesten Security-Fixes versehen. Als ein neues Feature ist nun vollständige Kontrolle über OpenType-Variablen-Schriftachsen enthalten, ebenso wie animiertes WebP-Encoding mit SKWebpEncoder sowie Farbpaletten für Emoji- und Icon-Schriftarten.

Die interaktive SkiaSharp-Galerie zeigt die Möglichkeiten mit Blazor WebAssembly und Uno Platform. Beispiele mit .NET MAUI und weiteren Technologien sollen folgen.

SkiaSharp 4.148.0 steht beim .NET-Paketmanager NuGet unter MIT-Lizenz zum Download bereit. Weitere Informationen zur neuen stabilen Version

(mai)

Das chinesische KI-Unternehmen Zhipu AI (bekannt als Z.ai) hat mit GLM-5.2 ein Open-Weight-Modell veröffentlicht, das sich bei der Erkennung von Sicherheitslücken offenbar mit Anthropics Opus 4.8 messen kann.

Das haben IDOR-Benchmark-Tests der Cybersicherheitsfirma Semgrep ergeben. Da es sich um ein Open-Weight-Modell handelt, kann jeder GLM-5.2 herunterladen, lokal betreiben und modifizieren. Das eröffnet für Hacker weitere Möglichkeiten für kriminelle Einsätze.

Open Weight als Chance und Risiko

Die offene Verfügbarkeit von GLM-5.2 ist ein zweischneidiges Schwert. Sicherheitsfirmen, CERTs und interne Red Teams können das Modell in abgeschotteten Umgebungen für Code-Reviews und Penetrationstests nutzen, ohne sensible Daten an US-Clouds zu übermitteln. Für DSGVO-konforme Umgebungen in Europa ist das ein Vorteil.

Gleichzeitig können auch Angreifer GLM-5.2 ohne jede Aufsicht betreiben. Diese Eigenschaft macht das Modell attraktiv für Akteure, die nach Schwachstellen in kritischen Systemen suchen wollen. Lior Div, Chef der Cybersicherheitsfirma 7AI, fasste die Lage gegenüber dem Wall Street Journal zusammen: China sorge dafür, dass der Abstand zu den US-KIs „immer kleiner“ werde.

Zhipu AI selbst räumt in den Release Notes ein, dass GLM-5.2 während des Reinforcement-Learning-Trainings verstärkt sogenanntes Reward Hacking zeigte. Das Unternehmen habe daraufhin spezielle Anti-Hacking-Sicherungen für das Training und die Evalution des Modells integriert.

Geopolitische Dimension: USA unter Zugzwang

Die Entwicklung trifft die US-Regierung in einem heiklen Moment. Eines von Anthropics Modellen war kurzzeitig komplett gesperrt, weil die Trump-Administration den Zugriff durch ausländische Nutzer untersagte. Auch OpenAI bekommt von der US-Regierung Auflagen „aus Sicherheitsgründen“.

Für europäische Unternehmen und Behörden stellt sich mit der wachsenden Leistungsfähigkeit der KI-Modelle die Governance-Frage: Wie lässt sich der Einsatz solcher Werkzeuge in sicherheitskritischen Bereichen mit dem EU AI Act und nationalen Sicherheitsvorgaben vereinbaren – und wie geht man mit einem Modell um, das beim Schwachstellen-Finden brilliert, aber keiner Aufsicht unterliegt?

(rie)