Manchmal fühlt sich die schöne neue Tech-Welt an wie eine Szene aus einem Roman von Franz Kafka, nur dass der unnahbare Beamte im Schloss heute ein Algorithmus ist. Und wenn dieser Algorithmus entscheidet, dass Schwarz eigentlich Weiß ist, dann ist das so. Widerspruch? Zwecklos. Eine besonders absurde Episode dieser Art hat diese Woche der Journalist und Fotograf Georg Berg durchlebt und akribisch dokumentiert. Es ist eine Geschichte, die jeden, der eine Kamera in die Hand nimmt, aufhorchen lassen sollte.

Googles „Won’t Fix“-Politik: Wenn gute Arbeit zum KI-Verdacht wird

Der Fall ist so paradox, dass man ihn kaum erfinden könnte: Georg Berg nahm ein authentisches Reportagefoto – vier ältere Herren in Schweizer Sennentracht – auf. Er bearbeitete es dann professionell in Lightroom, um die Personen präzise vom Hintergrund abzuheben. Eine handwerkliche Fleißarbeit, die jeder gute Fotograf kennt. Das Ergebnis? Googles KI-Detektor „SynthID“ stempelte das Bild als „KI-generiert“ ab. Die Begründung, wenn man sie so nennen möchte, liegt in der Präzision: Die saubere Maskierung erzeugte statistische Muster, die der Algorithmus als „unnatürlich“ und damit als Werk einer Maschine interpretierte. Ein Profi, der zu gut arbeitet, wird so zum Fälscher erklärt.

Das eigentliche Sahnehäubchen auf dieser Torte der Ironie ist jedoch, dass das Foto ein C2PA-Zertifikat (Content Credentials) besaß. Das ist quasi der digitale Herkunftsnachweis, der kryptografisch belegt, woher ein Bild stammt und wie es bearbeitet wurde. Und jetzt halten Sie sich fest: Google ist Mitglied ebenjener C2PA-Initiative, die diesen Standard entwickelt hat und von Adobe, der New York Times und Twitter ins Leben gerufen wurde. Man hat also einen Standard für Authentizität mitentwickelt, ignoriert ihn aber in den eigenen Produkten geflissentlich. Adobe erkennt das Bild korrekt als „menschlich“ – der Nutzer steht nun zwischen zwei konkurrierenden ‚Wahrheiten‘.

Als der Fotograf Berg diesen Systemfehler pflichtbewusst an Google meldete, kam die Antwort nach nur 60 Sekunden, was auf eine automatisierte Abfuhr schließen lässt: „Won’t Fix (Intended Behavior)“. Auf Deutsch: „Wird nicht repariert (beabsichtigtes Verhalten)“. Google teilt damit mit, dass es kein Fehler, sondern Absicht ist, wenn authentische Werke fälschlicherweise als KI-Produkt gebrandmarkt werden. Für Fotografen und Journalisten ist das ein Schlag ins Gesicht. Es bedeutet, dass der Algorithmus die Wahrheit definiert und es kein Recht auf Widerspruch gibt. Wenn der digitale Schiedsrichter pfeift, ist das Spiel aus – auch wenn er auf dem falschen Feld steht.

MFT-Allianz wächst: Sonida aus Shenzhen ist dabei

Während ein Tech-Gigant das Vertrauen in digitale Bilder untergräbt, gibt es an anderer Front handfeste und erfreulichere Nachrichten. Die Micro-Four-Thirds-Allianz (MFT), angeführt von OM Digital Solutions (ehemals Olympus) und Panasonic, hat ein neues Mitglied: die Shenzhen Sonida Digital Technology Co, Ltd. aus China. Wer jetzt die Augenbrauen hochzieht und „Wer?“ fragt, dem sei gesagt: Das ist potenziell eine sehr gute Nachricht für alle MFT-Nutzer.

Sonida ist kein unbeschriebenes Blatt, sondern hat bereits als sogenannter ODM-Hersteller Kameras für andere internationale Marken produziert. Sie wissen also, wie man Kameras baut. Unter der eigenen Marke „Songdian“ wollen sie nun MFT-kompatible Produkte auf den Markt bringen. Für das MFT-System, das oft als agiler Underdog gegen die Vollformat-Übermacht von Sony, Canon und Nikon antritt, ist das ein Gewinn. Jeder neue Partner stärkt das Ökosystem und verspricht mehr Auswahl bei Kameras und vor allem bei Objektiven. Und wer weiß, vielleicht sorgt ein neuer Spieler aus China ja auch für eine erfrischende Preisdynamik. Man darf gespannt sein, ob die Produkte so klingen, wie der Markenname vermuten lässt.

Zum Nachlesen: Wenn der Fehler Methode hat

Wer tiefer in die absurde Welt der KI-Detektion und Plattformverantwortung eintauchen will, dem sei der vollständige Bericht von Georg Berg auf seiner Webseite „Tellerrand-Stories“ wärmstens ans Herz gelegt. Er legt nicht nur den Fall dar, sondern liefert auch die komplette technische Analyse und die Beweiskette. Es ist ein wichtiges Dokument, das zeigt, warum freiwillige Selbstverpflichtungen von Tech-Konzernen oft nicht mehr wert sind als das digitale Papier, auf dem sie stehen. Ein Weckruf für alle, denen Authentizität in der Fotografie am Herzen liegt.

(tho)

In dieser Woche spannt die c’t-Foto-Community den Bogen weit – von nebligen Parkwegen über nächtliche Flusslandschaften hin zu alpinen Höhen. Immer wieder geht es um Reduktion. Klare Linien, gezielte Lichtführung und bewusste Leerräume strukturieren die Motive. Nebel schluckt Details. Dunkelheit rahmt helle Formen. So entstehen Bilder, die mit wenigen Elementen eine starke Wirkung erzielen.

Auffällig ist das Spiel mit Gegensätzen. Warmes Licht trifft auf eine kühle Morgenstimmung. Starre Architektur steht neben fließendem Wasser. Rasante Bewegung kontrastiert mit meditativer Ruhe. Auch technisch zeigen die Aufnahmen Vielfalt: Langzeitbelichtungen machen Geschwindigkeit sichtbar, Schwarz-Weiß-Aufnahmen reduzieren auf Form und Haltung und Makro- sowie Detailstudien lenken den Blick auf Struktur und Farbe. Sieben Bilder, die zeigen, wie bewusst eingesetzte Technik zur Bildaussage wird.

Frühsport im Nebel … von JeanFP

Ein Jogger läuft durch die Herrenhäuser Gärten in Hannover und verschwindet dabei fast im dichten Nebel. Die Allee zieht sich als klare Linie in die Tiefe und lenkt den Blick direkt zur zentralen Figur. Das gedämpfte Licht reduziert Farben und Kontraste und lässt Formen sanft wirken. Die Szene erzählt von Konzentration und Ruhe an einem stillen Morgen.

Supermoon Voyage on the Magdeburg Elbe von ShE 1981

Ein großer Vollmond schwebt tief über der Elbe und spiegelt sich im ruhigen Wasser. Das Bild ordnet Mond und Spiegelung streng vertikal an und nutzt den Fluss als klare Mittelachse. Die schwarze Umgebung rahmt die helle Mondscheibe und verstärkt den Kontrast. Die Szene wirkt geradezu surreal und erinnert an einen nächtlichen Traum.

Cowboy von NilsSch

Ein Mann mit Cowboyhut schreitet allein durch die Szene und hebt sich als dunkle Figur vom grauen Hintergrund ab. Die streng reduzierte Komposition setzt auf klare Flächen und viel Negativraum. Die Schwarz-Weiß-Darstellung verstärkt die grafische Wirkung und lenkt den Blick auf Form und Haltung. Das Bild spielt mit Klischees und wirkt zugleich zeitlos und ruhig.

Für Lars von Heike Maier

Hier zeigt sich die Blüte einer roten Tulpe in voller Pracht. Durch die reduzierte und konzentrierte Bildgestaltung wird der Blick direkt zur Pflanze gelenkt. Das Licht betont die Struktur der Blütenblätter und lässt die Farben natürlich wirken. Das Ergebnis ist ein kontemplatives Makrobild, das große Wertschätzung für die Blume als Motiv zum Ausdruck bringt.

Eine Innenwelt von Thomas Brahtel

Hier führt der Blick ins Innere eines Heißluftballons während der Aufblasphase. Stoffbahnen wölben sich, Nähte zeichnen klare Linien und blaues Licht erfüllt den Raum. Der Fotograf nutzt die Symmetrie der Bahnen sehr gut: Sie lenken den Blick ins Zentrum und betonen die Tiefe. Das Glühen verwandelt den Ballon in einen stillen, beinahe organischen Raum.

Über den Wolken von Uschi Hermann

Auf einem Felsvorsprung steht ein einzelner Wanderer und blickt über ein dichtes Wolkenmeer hinweg zu den Gipfeln der Alpen. Die tief stehende Sonne taucht die Felsen und Wolken in warmes Licht und zeichnet klare Konturen. Der Mensch im Vordergrund setzt einen starken Maßstab und verleiht der weiten Landschaft eine menschliche Dimension.

Zu(g) schnell von Lightpix84

Ein Zug zieht als leuchtender Streifen durch die Landschaft. Wegen der Langzeitbelichtung sind zwar keine Details erkennbar, jedoch erkennt man den ICE sofort. Seine Geschwindigkeit ist geradezu spürbar. Horizontale Linien dominieren das Bild und verstärken den Eindruck von Geschwindigkeit. Der Hintergrund ist so bearbeitet, dass er ebenfalls verwischt und dem hellen Streifen Raum gibt.

(vat)

Legacy-System – kaum ein anderer Begriff schürt mehr Abneigung und Furcht im Herzen von Softwareentwicklerinnen und -entwicklern. Was einmal als flexible und einfache Anwendung begann, wuchs über die Jahre zu einem unüberschaubaren Monolithen heran, der sich nur noch unter größtem Aufwand weiterentwickeln, testen und deployen lässt.

Eine solche Anwendung ist ein typisches Beispiel für ein schlecht oder gar nicht modularisiertes System, bei dem eine Anpassung an einer Stelle weitere an anderen Stellen nach sich zieht. Architektinnen und Architekten sprechen von starker Kopplung. Sind alle Funktionen in einen großen, unstrukturierten Block Code gegossen, ist der Kopplungseffekt auch innerhalb dessen zu beobachten. Anpassungen können dann zu einem Fehlverhalten an einer unerwarteten, anderen Stelle führen.

Zerlegt man den Monolithen in lose gekoppelte Module, haben lokale Änderungen keine Anpassungen in anderen Systemen mehr zur Folge. Werden diese Module in Form von autonomen, aber miteinander integrierten Systemen umgesetzt, erhält man zusätzlich den Vorteil, dass sie weitgehend unabhängig voneinander deployt werden können. Dieser Ansatz ist der bekannte Microservices-Architekturstil [1], dem viele Architektinnen und Architekten allerdings inzwischen mit Skepsis gegenüberstehen, da die Komplexität schnell wächst.

Daneben gibt es noch einen einfacheren Ansatz, der ähnliche und noch weitere Vorteile verspricht: Self-contained Systems (SCS).

Was sind Self-contained Systems?

Die Self-contained-Systems-Architektur legt großen Wert auf eine hohe Unabhängigkeit verschiedener Module. Diese lose gekoppelte Systemarchitektur (siehe Textbox unten „Kleine Bausteine, lose verbunden“) verspricht, dass Teams einzelne Teile weitgehend unabhängig entwickeln und deployen. Während die relativ vage Definition eines Microservice als „unabhängig deploybarer Service, modelliert um eine fachliche Domäne“ [1] große Freiräume bei der Wahl des Architekturstils lässt, sind die Kriterien für Self-contained Systems klarer umrissen.

Wie Microservices sind sie mit einer streng gezogenen fachlichen Grenze versehen, häufig handelt es sich dabei jedoch um einen kompletten Bounded Context – also einen abgeschlossenen Bereich mit einer einheitlichen, aus der Fachdomäne stammenden Sprachgebung – im Sinne des strategischen Domain-driven Design (DDD). Dadurch sind sie tendenziell größer als Microservices, sodass weniger Aufwand für Integration und Infrastruktur anfällt.

Zudem gibt es für SCS eine Reihe an Best Practices zur Systemintegration. SCS sollen bevorzugt auf Nachrichten nach dem Credo „fire and forget“ setzen und nach dem Versenden nicht auf Antwort warten. Synchrone Request-Response-Kommunikation (zum Beispiel über RESTful-Services) sollte vermieden werden. Dann entsteht ein System, das bei Teilausfällen sehr resilient reagiert.

Die Nutzeroberfläche wird stets als ein Teil des Self-contained System behandelt (eine Idee, die im Rahmen der Micro Frontends ebenfalls in der Microservices-Welt Fuß gefasst hat). In erster Linie bleibt hierdurch mehr Arbeit innerhalb eines Teams und es entstehen keine Frontend-Monolithen als Flaschenhälse. Ein weiterer, oft überraschender Effekt ist, dass sich in vielen Fällen ein Austausch von Datenstrukturen zwischen UIs und die dadurch entstehende fachliche Kopplung über geteilte Datenformate komplett vermeiden lässt. Entwickler können stattdessen Teile der Nutzeroberflächen des einen Systems in einem anderen verwenden.

Damit die unabhängige Entwicklung der verschiedenen SCS nicht in einem unterschiedlichen Look and Feel oder einem Wildwuchs von Integrationsansätzen endet, fordert die SCS-Architektur von allen Systemen, sich an eine gemeinsame, koordinierte Makroarchitektur zu halten. Dazu gehören beispielsweise die Verwendung bestimmter Integrationstechniken, UI-Komponenten oder Styleguides. Sie ermöglichen ein weitgehend reibungsloses Zusammenspiel im System of Systems.

Gerade die Best Practices zur Systemintegration eröffnen Migrationspfade, um eine gewachsene Architektur in kleinen, inkrementellen Schritten zu einer SCS-Architektur umzubauen. Eine Umstellung nach dem Big-Bang-Muster ist nach Erfahrung des Autors nur in seltenen Fällen empfehlenswert oder wirtschaftlich.

Planung der Migration

Der erste Schritt vom Monolithen zu SCS ist es, die Teilstücke zu identifizieren, die sich in ein eigenes SCS überführen lassen. Da die Zielarchitektur aus fachlich geschnittenen Systemen besteht, ist die im Monolithen enthaltene Fachlichkeit genauer zu analysieren. Diesen Schritt sollten Entwicklerinnen und Entwickler nicht auf die leichte Schulter nehmen, da sich bei der Aufteilung der Applikation in ihre verschiedenen Bausteine entscheidet, wie stark oder lose diese gekoppelt sind (siehe Textbox oben „Kleine Bausteine, lose verbunden“).

Eine Möglichkeit, eine Analyse der Fachdomänen durchzuführen, ist das Event Storming zur Identifikation der Bounded Contexts. Abbildung 1 zeigt das Ergebnis einer solchen Analyse für eine fiktive Car-Sharing-Anwendung. Dort wurden die fachlichen Domänen „Nutzerregistrierung“, „Fuhrparkmanagement“, „Trips“, „Abrechnung“ und „Kundendienst“ identifiziert. Bei der Analyse entstehen bereits erste Ideen, wie die verschiedenen Fachlichkeiten miteinander interagieren und welche Nachrichten sie miteinander austauschen.

Hat sich im Dialog mit den Fachabteilungen eine Aufteilung gefunden, die die gewünschte fachliche, lose Kopplung widerspiegelt, beginnen Architektinnen und Architekten damit, Teile des Altsystems nach und nach durch neue SCS zu ersetzen. Diese arbeiten mit dem Altsystem zusammen, ohne dass Nutzer einen Unterschied feststellen. Das ist eine Herangehensweise, die auch Strangler Fig Application heißt, da eine neue Anwendung wie die namensgebende Würgefeige langsam aber sicher immer größere Teile des alten Wirtssystems überdeckt und es letztendlich abtötet (siehe Abbildung 2).

Ein gutes Kriterium für die Wahl der ersten Fachlichkeit, die aus dem Legacy-System herausgelöst wird, ist der dadurch entstehende Geschäftswert [4]. Die Migration fügt beispielsweise dem Legacy-System zusätzliche Funktionen hinzu, etwa einen Check-in-Prozess sowohl für den Desktop als auch das Smartphone. Fachlichen Wert kann eine Migration auch stiften, wenn sie einen akuten Schmerz mit dem Legacy-System beseitigt: besonders unzuverlässige, fehleranfällige Funktionen.

Der Aufwand der Migration ist ein weiteres Kriterium. Spielt die Fachlichkeit an vielen Stellen im Monolithen eine Rolle, kann diese starke Verwebung eine Re-Integration erheblich erschweren. Beide Kriterien können in einer 2×2-Entscheidungsmatrix kombiniert werden (siehe Abbildung 3). Fachlichkeiten, die sich in der rechten, oberen Ecke befinden, sind gute Kandidaten für ein erstes SCS. Eine weitere Technik zur Analyse, die sich in der DDD-Community immer größerer Beliebtheit erfreut, sind Core Domain Charts.

Das erste SCS integrieren

Hat man sich für einen guten Kandidaten entschieden, ergeben sich eine Reihe technischer Fragen. Gerade hier wirken sich die Stärken der sehr losen Kopplung durch die SCS-Architektur positiv aus. Folgende Möglichkeiten gibt es:

Link Integration: Im einfachsten Fall springen Nutzer über einen Link im Altsystem in das neue. Eine kleine Menge von Daten sowie eine Rücksprungadresse für den Erfolgs- oder Fehlerfall können hier als Request-Parameter mitgegeben werden:


Zum Fahrzeug

UI-Inklusion: Auch eingebundene UI-Elemente erlauben eine sehr lose Kopplung zwischen zwei Systemen. Da nur Formate wie pures HTML und CSS ausgetauscht werden, muss das konsumierende System sehr wenig Details über Datenstrukturen oder deren Interpretation von dem Quellsystem wissen. Soll das System Kundendienst beispielsweise Stammdaten über ein Fahrzeug anzeigen, sind nicht die kompletten Datenstrukturen aus dem Fuhrparkmanagement erforderlich, vielmehr reicht eine kurze Beschreibung des Fahrzeugs (siehe Abbildung 4).

Die Vorteile liegen auf der Hand: Entscheiden sich Architektinnen oder Architekten beispielsweise, die Daten eines Fahrzeugs anders zu benennen oder weitere Merkmale wie Kennzeichen aufzunehmen, kann das konsumierende System bleiben, wie es ist. Diese sehr lose Form der Kopplung wird jedoch durch eine Abhängigkeit zur Laufzeit bezahlt. Ist das Fuhrparkmanagement-SCS nicht verfügbar, liegen nur noch Stammdaten aus dem Cache vor.

Messaging zum Datenaustausch: Ist Laufzeitabhängigkeit bei der UI-Integration nicht erwünscht oder muss das System die Daten nicht nur anzeigen, sondern auch auswerten, ist eine Integration erforderlich, die zu einer stärkeren Kopplung zwischen beiden Systemen führt. Zu den Grundsätzen der SCS-Architektur gehört, dass jedes System über eine eigene Datenbank verfügen soll, die alle Daten enthält, die es benötigt. Verwenden mehrere Systeme bestimmte Daten, wird es nötig, sie zwischen den SCS auszutauschen.

Dabei hat sich eine Übertragung in Form von Domain Events bewährt. Dabei erzeugt ein System bei bestimmten Ereignissen (etwa beim Abschluss eines fachlichen Vorgangs) ein Domain Event mit allen relevanten Informationen (aber nicht mehr!) und publiziert es. Das konsumierende System kann auf die Publikation durch eigene Logik reagieren und seine eigene Kopie des entsprechenden Datensatzes anlegen oder anpassen. Bei der redundanten Speicherung ist es wichtig, genau festzulegen, welches System die Wahrheit definiert. Nur aus dieser Quelle sollten nachlaufende Systeme Daten konsumieren oder ändern.

Das oben beschriebene Event Storming hat bereits mögliche Events zur Integration identifiziert (siehe die orangefarbenen Kreise in Abbildung 1). Es gilt, diese zu relevanten Zeitpunkten aus dem Legacy-System heraus zu publizieren, sodass die neuen SCS sie konsumieren können.

Manchmal möchte ein System an anderer Stelle verortete Daten ändern oder anlegen. Am besten lässt sich das durch eine UI-Integration lösen: Muss etwa der Kundendienst einen Eintrag im Fuhrpark korrigieren, ist ein Sprung in die UI des Fuhrparkmanagements mit einem Rücksprung in das Kundendienst-SCS die beste Wahl. Ein Gegenbeispiel, bei dem diese Taktik nicht funktioniert, wäre die automatische Sperrung eines Benutzers, der seine Rechnungen nicht bezahlt. Hier kann ein Command (in Abbildung 1 grün) das Quellsystem anweisen, eine Änderung der Daten vorzunehmen. Das Quellsystem kann diese Anfrage jedoch ablehnen, wenn sie gegen die eigenen Regeln verstößt.

Integration über synchrone API-Aufrufe: Auch über eine RESTful API lässt sich ein anderes System direkt ansprechen. Da diese Methode Systeme zur Laufzeit stark aneinander bindet und zu einer fehleranfälligen, schwer abzufangenden Kaskade an blockierenden Aufrufen führen kann, gilt sie als letzter Ausweg. Sie kommt etwa dann zum Zuge, wenn die Daten aus dem Quellsystem viel zu umfangreich sind, um sie über Events zu replizieren, oder wenn sie nur durch die Anwendung fachlicher Logik quasi ad-hoc generiert werden können.

Fazit

Auch nach der Wahl und Planung eines ersten SCS-Kandidaten bleiben Fragen offen: Wie soll in Zukunft ein gemeinsamer Look and Feel zwischen den Self-contained Systems und dem Monolithen hergestellt werden? Wie lässt sich eine gemeinsame Nutzer- und Rechteverwaltung etablieren? Diese und noch viele weitere Fragen müssen Architektinnen und Architekten nicht sofort oder zumindest nicht sofort richtig beantworten.

Ein wesentlicher Vorteil der inkrementellen Migrationsstrategie ist, dass die Konsequenz einer Fehlentscheidung nicht katastrophal ist. Solange nur ein oder zwei Systeme laufen, ist Zeit zum Lernen, welche Entscheidungen wirklich für alle Systeme als getroffen gelten (Stichwort Makroarchitektur) und welche besser lokal zu fällen sind (Mikroarchitektur). Viele Ansätze zur Integration, Sicherstellung der UI-Konsistenz oder für Single Sign-on hängen von den konkreten Gegebenheiten ab.

Die Makroarchitektur wächst mit jedem weiteren Self-contained System, während das monolithische System weiter schrumpft. Unterstützung in Form von Best Practices für die Makroarchitektur unabhängiger Systeme finden sich auch in den Prinzipien der Independent Systems Architecture, die mit SCS sehr gut harmonieren.

Mit Beharrlichkeit und einem Fokus auf Geschäftswert werden Architektinnen und Architekten eher früher als später eine Landschaft von gut modularisierten, lose gekoppelten SCS und die damit verbundenen Vorteile genießen lernen. Und eventuell werden sie feststellen, dass manche Teile ihres Systems gar keiner Migration bedürfen.

Quellen

[1] Sam Newman; Building Microservices: Designing Fine-Grade Systems; 2021
[2] David Parnas; On the Criteria To Be Used in Decomposing Systems into Modules; 1972
[3] Eric Evans; Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003
[4] Sam Newman; Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith; 2019

(who)