In diesem Artikel erkläre ich Ihnen innerhalb weniger Absätze einen KI-Algorithmus, den Sie danach von Grund auf verstanden haben. Dabei nutze ich keine Vereinfachung und keine Abstraktion. Und ich bin mir sicher: Wenn Sie diesen Artikel gelesen haben, werden Sie einen wichtigen Baustein der Künstlichen Intelligenz durchschauen. Und nicht nur das. Sie werden nämlich auch erkennen, warum viele der Prinzipien, die wir hier im Kleinen sehen, genauso für die großen, komplexen Systeme gelten, über die heute alle reden. Es geht dabei nicht um ChatGPT oder neuronale Netze. Es geht nicht um Sprachmodelle oder um Bilderkennung, sondern wir schauen uns stattdessen einen Algorithmus an, der so einfach ist, dass er in wenigen Schritten erklärt ist. Und gleichzeitig so tiefgehend, dass er die zentralen Ideen moderner KI in sich trägt. Und dieser Algorithmus heißt k-Means.

Das klingt unscheinbar, gar unspektakulär, ist aber ein perfektes Beispiel dafür, wie Künstliche Intelligenz tatsächlich arbeitet. Und warum gerade k-Means? Ganz einfach: Weil er in einer klaren und leicht nachvollziehbaren Form zeigt, worum es bei KI im Kern geht: Muster in Daten finden, Strukturen erkennen, die man auf den ersten Blick nicht sieht, und Entscheidungen treffen, die nicht eindeutig richtig oder falsch sind, sondern die auf Wahrscheinlichkeiten und Annäherungen beruhen. Und genau das ist es, was KI im Großen auch macht, nur eben mit sehr viel mehr Daten, sehr viel mehr Dimensionen und sehr viel mehr Rechenleistung.

Vielleicht denken Sie jetzt:

„Ja gut, aber so ein kleiner Algorithmus, was soll mir das denn bringen?“

Die Antwort ist: tatsächlich sehr viel. Denn wenn Sie einmal verstanden haben, wie k-Means funktioniert, dann werden Sie viele Eigenheiten von KI und von anderen Algorithmen wiedererkennen, die sonst wie Magie wirken: Warum Ergebnisse manchmal unterschiedlich ausfallen, warum die Wahl der Kriterien ausschlaggebend ist und warum Datenqualität über Erfolg oder Misserfolg entscheidet.

Ballungszentren finden

Stellen Sie sich eine Landkarte vor. Auf dieser Landkarte sind sehr viele Punkte eingezeichnet, und jeder Punkt steht für einen einzelnen Menschen, der irgendwo lebt. Manche Punkte liegen weit auseinander, manche hingegen dichter zusammen, und an manchen Stellen sammeln sich so viele Punkte, dass man sofort erkennt: Dort liegt ein Ballungsraum, dort ist eine Stadt oder eine Siedlung. Und die Aufgabe, die wir jetzt lösen wollen, klingt einfach: Wir wollen diese Ballungszentren finden (also die Orte, an denen sich viele Menschen häufen) – und zwar automatisiert. Genau hier kommt k-Means ins Spiel. Der Algorithmus macht nämlich genau das: Er sucht Gruppen in Daten, sogenannte Cluster.

Wie funktioniert das? Stellen Sie sich vor, wir setzen am Anfang wahllos ein paar Marker auf die Landkarte. Die Anzahl dieser Marker nennen wir k. Also k Marker für k Cluster (da kommt übrigens der erste Teil des Namens des Algorithmus her, deshalb heißt er „k-Means“). Diese Marker platzieren wir zunächst, wie gesagt, zufällig irgendwo. Das bedeutet, am Anfang haben sie noch nichts mit den tatsächlichen Ballungszentren zu tun, sondern sie stehen sozusagen einfach nur irgendwo in der Gegend herum.

Doch jetzt passiert der erste Schritt: Jeder Einwohner, also jeder Punkt auf unserer Karte, sucht sich den Marker aus, der ihr oder ihm am nächsten liegt. Und damit entstehen Gruppen: Jeder Punkt gehört nun zu genau einem Marker. Im zweiten Schritt bewegen wir dann jeden Marker in die Mitte seiner Gruppe. Das heißt, wir schauen uns alle Punkte an, die dem Marker zugeordnet sind, und verschieben ihn dorthin, wo der Durchschnitt liegt. Im Englischen heißt Durchschnitt übrigens mean bzw. im Plural means, und damit wissen Sie jetzt auch, wo der zweite Namensbestandteil des Algorithmus herkommt.

Dann wiederholen wir das Ganze: Jeder Punkt prüft wieder neu, welcher Marker ihm am nächsten liegt, und manche Punkte wechseln anschließend die Gruppe. Die Marker werden dann erneut in die Mitte ihrer jeweiligen Gruppe verschoben. Dieses Vorgehen wiederholt sich dann so lange, bis sich irgendwann nichts mehr ändert. Dann liegt das Ergebnis vor: Die Marker liegen genau dort, wo sich die Ballungszentren befinden.

Viele KI-Algorithmen arbeiten nicht deterministisch

Das Spannende ist: Dieses Verfahren funktioniert erstaunlich gut, obwohl wir am Anfang zufällige Startpunkte gewählt haben. Aber (und das ist wichtig): Diese Zufälligkeit hat natürlich einen gewissen Einfluss. Denn je nachdem, wo die Marker am Anfang stehen, können sich die Ergebnisse am Ende durchaus unterscheiden. Manchmal landen sie in sehr ähnlichen Positionen, manchmal aber auch in deutlich unterschiedlichen.

Genau hier liegt die erste wichtige Erkenntnis: KI ist nicht immer deterministisch. Gleiche Daten können zu unterschiedlichen Ergebnissen führen, und zwar einfach nur deshalb, weil die Startbedingungen anders waren. Das bedeutet: Zufall spielt eine Rolle und ist ein Faktor, der sich in sehr vielen Bereichen der KI wiederfindet. Wenn man das einmal verstanden hat, dann begreift man, dass KI nicht mit absoluten Wahrheiten arbeitet, sondern mit Wahrscheinlichkeiten und Annäherungen.

Ein komplexeres Beispiel

Nun können wir das Ganze aber noch ein bisschen komplexer machen: Stellen Sie sich vor, wir hätten keine Landkarte mit Einwohnern, sondern ein Whiteboard, auf das wir alle unseren persönlichen Lieblingssong schreiben. Irgendwohin, wo gerade Platz ist. Jeder Song ist wieder ein Datenpunkt. Und unsere Aufgabe lautet wieder: Wir wollen Gruppen bilden. Wir wollen herausfinden, welche Songs sich ähneln und welche sich unterscheiden. Doch nun wird es spannend, denn anders als bei der Landkarte gibt es hier keine natürliche räumliche Position. Wenn ich einen Song auf dem Whiteboard ganz links hinschreibe und einen anderen ganz rechts, dann sagt das über ihre Ähnlichkeit überhaupt nichts aus. Der Abstand auf dem Whiteboard hat keinerlei Bedeutung.

Das heißt, wir müssen Kriterien definieren, nach denen wir die Songs vergleichen wollen. Genau das macht k-Means, oder besser gesagt: Das müssen wir vorher festlegen, damit k-Means überhaupt etwas Sinnvolles machen kann. Welche Kriterien könnten das bei Musik nun sein? Da wäre zum Beispiel das Tempo, gemessen in Beats pro Minute (also BPM). Ein anderer Faktor wäre vielleicht die durchschnittliche Lautstärke, gemessen in Dezibel. Oder die Klangfarbe, also welche Instrumente dominieren. Oder ob es Gesang gibt oder nicht. Sie können sich leicht vorstellen, dass es noch zahlreiche andere Faktoren gibt, die man in Betracht ziehen könnte.

Das Interessante ist nun: Je nachdem, welche Kriterien wir wählen, entstehen völlig unterschiedliche Cluster. Wenn wir nur auf das Tempo schauen, dann landen ein schneller Techno-Track und ein klassisches Stück im Presto-Tempo plötzlich im selben Cluster, obwohl sie musikalisch nicht allzu viel miteinander gemeinsam haben. Wenn wir dagegen aber nach Lautstärke gehen, dann stehen vielleicht eine ruhige Jazz-Ballade und ein Ambient-Track nebeneinander. Und wenn wir den Gesang als Kriterium nehmen, dann tauchen auf einmal eine Arie aus einer Oper und ein Rocksong in derselben Gruppe auf.

Damit kommen wir zur zweiten Erkenntnis: Die Ergebnisse hängen immer davon ab, welche Merkmale wir auswählen. Daten sind nicht einfach „die Wahrheit“. Sie sind vielmehr eine Sammlung von Eigenschaften, die wir interpretieren und gewichten müssen. Erst durch unsere Entscheidung, welche Dimensionen wir betrachten, bekommt das Clustering eine Bedeutung. Dieser Punkt zeigt sich bei komplexeren Daten noch weitaus stärker. Denn wenn wir über Sprachmodelle oder über Bilderkennung sprechen, dann geht es nicht mehr nur um zwei Aspekte wie beispielsweise Tempo und Lautstärke, sondern um hunderte oder gar tausende Merkmale, die man gar nicht mehr intuitiv erfassen kann. Aber das Prinzip bleibt dasselbe: Was am Ende herauskommt, hängt davon ab, wie wir die Daten beschreiben.

Einheiten, Skalen & Co.

Wenn wir noch kurz bei den Songs bleiben, dann wird noch ein weiteres Problem sichtbar: Manche Eigenschaften lassen sich nämlich problemlos messen, sind aber überhaupt nicht vergleichbar. Nehmen Sie zum Beispiel die Länge eines Songs in Sekunden und das Tempo in Beats pro Minute. Beides sind Zahlen, beide (vermutlich) dreistellig, aber die Bedeutung ist völlig verschieden. Ein Song mit 240 Sekunden Dauer ist nicht vergleichbar mit einem Song, der 240 Beats pro Minute hat. Trotzdem würde ein Algorithmus diese Werte ohne weitere Anpassung unter Umständen einfach nebeneinanderlegen, und schon entsteht ein schiefes Bild.

Das Gleiche gilt auch für Skalen. Das Tempo in BPM ist eine lineare Skala: 90 BPM sind 30 BPM schneller als 60 BPM, und 120 BPM sind nochmal 30 BPM schneller als 90 BPM. Der Unterschied bleibt immer gleich. Bei Lautstärke in Dezibel ist das aber ganz anders. Auch dort ist der Unterschied zwischen 60 dB und 90 dB rein rechnerisch 30 dB. Aber in Wirklichkeit bedeutet dieser Unterschied eine gewaltige Vervielfachung der Lautstärke, denn hier haben wir es mit einer logarithmischen Skala zu tun. Und wenn wir nun Werte dieser Skalen direkt vergleichen, dann hat das Ergebnis keinerlei Aussagekraft.

Deshalb müssen Daten üblicherweise zunächst normalisiert werden, das heißt, damit die Daten überhaupt sinnvoll verarbeitet werden können, müssen sie in vergleichbare Größenordnungen gebracht werden. Man sorgt also dafür, dass kein einzelnes Kriterium nur deshalb dominiert, weil es in einem größeren Zahlenbereich liegt. Ohne Normalisierung könnte zum Beispiel die Länge eines Songs alle anderen Eigenschaften überdecken, weil die Sekundenwerte oft größer sind als das Tempo oder die Lautstärke.

Hinzu kommt noch eine weitere Herausforderung, nämlich kategoriale Werte. Stellen Sie sich vor, wir wollen berücksichtigen, ob ein Song Gesang enthält oder nicht. Das ist ein Ja-Nein-Kriterium, das man leicht als Null und Eins kodieren kann. Aber sobald es mehr als zwei Werte gibt, etwa beim Genre, wird es schwieriger. Denn dann muss man sehr sorgfältig darauf achten, wie Abstände zwischen den Werten interpretiert werden, damit der Algorithmus daraus keine falschen Schlüsse zieht.

Damit sind wir bei der dritten Erkenntnis: Ergebnisse hängen nicht nur von der Wahl der Kriterien ab, sondern genauso stark von deren Skalierung, Normalisierung und Aufbereitung. Wenn die Daten unsauber sind oder die Skalen nicht vergleichbar, dann kann kein Algorithmus der Welt ein sinnvolles Ergebnis liefern.

Datenqualität ist essenziell

Aus diesen Gründen ist Datenqualität für mich persönlich ein so wichtiges Thema. Sie ist nicht irgendwelches schmückendes Beiwerk, sondern sie ist die Grundlage. Ohne gute Datenvorbereitung bleibt jede noch so komplexe KI ein reines Glücksspiel. Deswegen erwähne ich auch immer wieder, dass Event-Sourcing eine hervorragende Basis für KI sein kann, weil es saubere und nachvollziehbare Daten von Anfang an bereitstellt.

Wenn wir an dieser Stelle einmal kurz innehalten, dann sehen wir: Selbst ein so einfacher Algorithmus wie k-Means zeigt bereits eine ganze Menge an Prinzipien, die auch in komplexeren KI-Systemen gelten:

• Zufall beeinflusst die Ergebnisse.
• Die Auswahl der Kriterien bestimmt, was wir überhaupt messen.
• Die Skalierung, die Normalisierung und nicht zuletzt auch die Qualität der Daten entscheiden darüber, ob das Ergebnis sinnvoll oder völlig verzerrt ist.

Wenn wir das auf größere Systeme übertragen (also neuronale Netze, Sprachmodelle, Bilderkennung und so weiter), dann wird sofort klar, warum diese Verfahren so schwer zu durchschauen sind. Es gibt nicht mehr nur drei oder vier Kriterien wie Tempo, Lautstärke oder Songlänge, sondern plötzlich hunderte, tausende, manchmal Millionen von Dimensionen. Und jede Dimension beeinflusst das Ergebnis, aber niemand kann noch nachvollziehen, welche genau in welchem Maß ausschlaggebend ist.

Die Komplexität explodiert

Mit anderen Worten: Die Grundidee bleibt gleich, aber die Komplexität explodiert. Bei k-Means im zwei- oder dreidimensionalen Raum können Sie (im wahrsten Sinn des Wortes) noch sehen, wie sich die Marker verschieben, wie sich die Cluster bilden und warum bestimmte Punkte augenscheinlich zusammengehören. Bei neuronalen Netzen laufen nun zwar dieselben Mechanismen ab, aber so hochdimensional, dass man sich das nicht mehr vorstellen kann. Nähe und Abstand verlieren hier ihre intuitive Bedeutung, weil wir Menschen uns solche Räume nicht mehr vor Augen führen können.

Die Konsequenz daraus ist entscheidend: KI findet keine objektive Wahrheit, KI erkennt lediglich Strukturen, die in den Daten vorhanden sind, und bietet uns eine Annäherung und eine Wahrscheinlichkeit. Mehr Rechenleistung, größere Modelle und mehr Daten ändern dabei nichts am Grundprinzip. Sie verbessern zwar die Ergebnisse, machen sie stabiler und oft erstaunlich präzise, aber die Basis bleibt: Es sind Muster in Daten, keine absoluten Wahrheiten.

Aus diesem Grund ist es so wichtig, dass wir KI nicht blind vertrauen, sondern verstehen, wie sie arbeitet. Dass wir begreifen, dass das, was wie Intelligenz wirkt, in Wirklichkeit lediglich das Erkennen von Wahrscheinlichkeiten in einem Raum voller Datenpunkte ist. Wer das verstanden hat, die oder der kann Ergebnisse richtig einordnen, und das ist oft viel wertvoller, als sie einfach nur zu konsumieren.

Die entscheidenden Fragen

Nun waren das, was wir uns in diesem Artikel angeschaut haben, zwei sehr einfache Beispiele. In der Praxis sind die Daten natürlich nicht so schön übersichtlich wie eine Landkarte oder wie eine kleine Sammlung von Songs. Sie sind weitaus komplexer, vielschichtiger und oft voller Widersprüche. Außerdem sind üblicherweise auch die Anforderungen deutlich höher: Es reicht nicht, dass ein Algorithmus „irgendwie“ funktioniert, sondern er muss nachvollziehbar, zuverlässig und in eine bestehende Systemlandschaft integrierbar sein.

Und genau hier wird es spannend: Denn die eigentliche Herausforderung liegt nicht primär im Algorithmus selbst, sondern in der Architektur, die ihn umgibt.

• Woher kommen die Daten?
• Wie werden sie aufbereitet?
• Wie stellen wir sicher, dass die Ergebnisse nicht nur in einem Experiment gut aussehen, sondern auch im Alltag tragfähig sind?

All das sind die Fragen, an denen viele KI-Projekte scheitern, und genau das sind die Fragen, die man beantworten muss, wenn man KI wirklich produktiv einsetzen will. Denn am Ende geht es eben nicht nur darum, einen Algorithmus zu verstehen, sondern darum, ihn zielgerichtet und lösungsorientiert einsetzen zu können.

(mai)

Es war einmal … eine wunderschöne Prinzessin. Jedes Jahr updatete sie ihr Alter, und nach einigen Jahren createte sie den Wunsch, die Welt zu entdecken, und updatete ihre Position in den großen, dunklen Wald. Dort createte jedoch der böse Wolf ein Meeting mit ihr und deletete sie. Das Königspaar updatete seinen Gemütszustand daraufhin auf „traurig“ und createte einen Auftrag für den Jäger. Dieser updatete seine Position ebenfalls in den großen, dunklen Wald, createte ein Meeting mit dem Wolf, deletete ihn – und wollte anschließend die Prinzessin undeleten – aber in CRUD-basierten Systemen gibt es kein Undelete.

Das heißt, stattdessen müsste man die Geschichte neu erzählen und sie nun aber derart ändern, dass der Wolf die Prinzessin nicht mehr deletet, sondern ihr isDeleted-Flag auf true aktualisiert. Zugegebenermaßen wird das Märchen damit aber nicht besser: Es ist jetzt schon absurd, klingt reichlich merkwürdig und eignet sich vermutlich eher dazu, Menschen zu verstören, als ihnen eine spannende Geschichte zu erzählen.

Warum das Märchen so merkwürdig klingt

Diese bewusst überspitzte Kurzfassung ist allerdings weit mehr als ein Gag. Denn sie macht erfahrbar, was in vielen Softwareprojekten tagtäglich passiert: Fachsprache und technische Sprache laufen auseinander. In der Domäne geschehen konkrete Dinge mit Bedeutung – der Wolf frisst die Prinzessin, der Jäger rettet sie –, während unsere Systeme dieselben Vorgänge auf die vier technischen Grundoperationen Create, Read, Update und Delete (kurz CRUD) reduzieren. Fachlich relevante Verben verschwinden hinter generischen Bearbeitungsschritten.

Dieses Auseinanderlaufen hat aber weitreichende Folgen:

• Verlust an Bedeutung: Ein Update sagt nichts darüber aus, welche fachliche Änderung eingetreten ist, geschweige denn, warum das passiert ist. Wurde ein Vertrag verlängert oder ein Konto gesperrt? Wurde eine Zahlung zurückgebucht oder ein Limit angepasst? Fachabteilungen erkennen ihre Welt in der CRUD-Sprache nicht wieder.
• Verlust an Historie: Das Überschreiben von Zuständen verwischt Spuren. Wie ist ein Zustand entstanden? Welche Abfolge führte zu einem Fehler oder zu einem Erfolg? Audits, Ursachenanalysen und Prognosen leiden, wenn die Vergangenheit nicht explizit dokumentiert ist.
• Fehlkonzepte und Workarounds: Wo Delete fachlich nicht zulässig ist, entstehen Soft-Deletes mit isDeleted-Flags. Wo Korrekturen nötig sind, wird ein Undelete herbeifantasiert – oder es entstehen Spezialpfade, die die Semantik weiter verwässern.
• Kommunikationsbruch zwischen Fachseite und IT: Wenn Entwicklerinnen und Entwickler über Updates sprechen, während Fachanwenderinnen und Fachanwender über Kündigungen, Rückgaben oder Eskalationen reden, steigt die Wahrscheinlichkeit von Missverständnissen – und damit von Fehlentscheidungen.

Kurz: CRUD ist eine technische Abstraktion, die fachliche Realität unsichtbar macht. Sie ist bequem für Tabellen, aber sie ist arm an Bedeutung.

Ein anderer Blick: Ereignisse statt bloßer Zustandsänderungen

Hier setzt Event-Sourcing an, ein alternatives Konzept zur Persistenz von Daten. Statt stets den aktuellen Zustand zu speichern und ihn regelmäßig per Update zu überschreiben, erfasst Event-Sourcing die Ereignisse, die im Laufe der Zeit zu diesem Zustand geführt haben – und zwar in der Sprache der Fachdomäne.

Im Märchen wären es Ereignisse wie: „Prinzessin betrat Wald“, „Wolf traf Prinzessin“, „Wolf fraß Prinzessin“, „Jäger hat Wolf getötet“, „Prinzessin wurde befreit“, und so weiter. Jedes Ereignis ist dabei ein unveränderlicher Fakt und bleibt dauerhaft erhalten. Der aktuelle Zustand (wie zum Beispiel, dass die Prinzessin noch beziehungsweise wieder lebt oder dass sie von ihren Eltern vermisst wird) ergibt sich als Projektion aus der Abfolge dieser Fakten.

Diese Sichtweise bringt handfeste Vorteile:

• Transparenz und Nachvollziehbarkeit: Jede Änderung ist datums- und ursachengenau belegbar. Sie können Point-in-Time prüfen, warum ein System heute so ist, wie es ist.
• Saubere Semantik: Ereignisse tragen fachliche Bedeutung. Statt generischer Updates sehen Sie Vertragsverlängerungen, Stornos, Rollentausche, Zahlungseingänge – exakt die Begriffe, in denen Fachabteilungen denken und sprechen.
• Korrekturen ohne Geschichtsfälschung: Fehler werden nicht durch rückwirkende Manipulation „unsichtbar“ gemacht, sondern durch kompensierende Ereignisse korrigiert. So bleibt die Datenlinie integer.
• Bessere Analysen: Ereignisströme bilden Verhalten über die Zeit ab. Das ist die Grundlage für Ablaufanalysen, Anomalieerkennung und Vorhersagen – und damit eine tragfähige Basis für Anwendungen im Bereich künstlicher Intelligenz.
• Entkopplung und Evolution: Ereignisse sind hervorragende Integrationspunkte. Weitere Systeme können sich andocken, ohne den Kern zu stören – ein zentraler Baustein moderner, vernetzter Architekturen.

Mehr Details, wie man mit diesem Ansatz Software entwerfen und entwickeln kann, finden Sie auf cqrs.com. Wenn Sie sich speziell für das Zusammenspiel mit Künstlicher Intelligenz interessieren – von der Ereignisaufnahme über Projektionen bis hin zu Features für Machine-Learning-Modelle, dann sei Ihnen eventsourcing.ai zur Lektüre empfohlen.

Warum wir trotz allem an CRUD festhalten

Dass CRUD trotz alledem so verbreitet ist, hat weniger mit fachlicher Eignung zu tun als mit Gewöhnung und Werkzeughistorie. Relationale Datenbanken, OR-Mapper und viele Frameworks begünstigen eine Sicht primär auf den Status quo. Sie ist für einfache Datenerfassung ausreichend und kurzfristig effizient. Mit wachsender Komplexität – mehrere Prozesse, Querverbindungen, regulatorische Anforderungen, analytische Nutzung – kippt der Vorteil jedoch: Die Semantik verschwindet im Code, und das System wird schwer zu erklären, zu prüfen und zu verändern.

Die Märchenanalogie bringt genau das auf den Punkt: Wir zwingen eine fachliche Geschichte in vier technische Verben – und verlieren dabei die eigentliche Geschichte. In realen Systemen passiert tatsächlich dasselbe, nur subtiler. Aus „Kunde widerruft Bestellung“ wird ein Update, aus „Rolle wird delegiert“ wird ein Update, aus „Risiko wird neu bewertet“ wird ein Update. Am Ende bleibt ein Zustand – aber das Wissen, wie und warum er entstanden ist, geht verloren.

Event-Sourcing auf dem Software Architecture Gathering

Wenn Sie die vollständige Argumentation, konkrete Muster und praktische Umsetzungshinweise sehen möchten, lade ich Sie herzlich zum Software Architecture Gathering des iSAQB ein. Dort erkläre ich in meinem Vortrag „… and Then the Wolf DELETED Grandma“ im Detail, warum CRUD für Märchen wie für Unternehmen gleichermaßen ungeeignet ist, wo genau die Reibungsverluste entstehen und vor allem, wie Event-Sourcing diese Brüche auflöst. Es geht um Sprache, Modelle und Architektur – und darum, wie Sie Systeme gestalten, die sowohl für Fachanwender als auch für Entwicklerinnen erklärbar, prüfbar und erweiterbar bleiben.

Dabei bespreche ich typische Einwände („Ist das nicht zu aufwendig?“, „Wie migrieren wir?“, „Wie liest man effizient?“, …), zeige, warum Projektionen keine Notlösung, sondern ein Gestaltungsmittel sind, und warum Ereignisse eine robuste Grundlage für Analytik und KI bilden. Das Märchen bleibt als Leitmotiv erhalten – die fachlichen Konsequenzen stehen im Mittelpunkt.

Ich würde mich freuen, Sie in Berlin auf dem Software Architecture Gathering persönlich zu treffen – und gemeinsam zu diskutieren, wie wir Geschichten in Software endlich wieder mit den richtigen Verben erzählen können.

(rme)

Microsoft hat angekündigt, dass die Visual-Studio-Erweiterung GitHub Copilot for Azure die öffentliche Preview-Phase erreicht hat. Sie ist für Visual Studio 2022 ab Version 17.14 verfügbar und bietet neue Möglichkeiten direkt aus dem Copilot-Chat heraus – dank Model Context Protocol (MCP).

Die Features der Extension

Wie Microsofts Entwicklerblog zu entnehmen ist, bietet GitHub Copilot for Azure ein Set an kuratierten Azure-Entwicklertools, die sich über MCP innerhalb des GitHub-Copilot-Agentenmodus in Visual Studio verwenden lassen. Die Erweiterung installiert und verwaltet den Azure-MCP-Server automatisch und ermöglicht somit unter anderem die Diagnose von Schwierigkeiten und das Ausführen von Azure-CLI-Befehlen. Die Toolsuite erlaubt die Interaktion mit zahlreichen Azure-Bestandteilen, darunter die Azure-App-Konfiguration, die Azure-CLI-Erweiterungen, die Azure Container Registry (ACR) und der Azure Data Explorer.

Als Beispiel-Prompts nennt Microsoft unter anderem „Suche eine WebApp namens ‚‚. Hatte sie kürzlich eine Downtime?“ oder „Finde heraus, zu welchen Tenants ich Zugang habe und welche ich derzeit verwende“.

Voraussetzungen und Installation

Um die Extension nutzen zu können, ist Visual Studio 2022 17.4 die Mindestversion. Ebenfalls sind ein aktives GitHub-Copilot-Abonnement und der in Visual Studio aktivierte Copilot-Chat nötig. Schließlich ist auch ein Microsoft-Account mit Azure-Zugang notwendig.

Sind alle Bedingungen erfüllt, lässt sich GitHub Copilot for Azure for Visual Studio 2022 (Public Preview) aus dem Visual Studio Marketplace herunterladen und installieren. Im Copilot Chat wählen Entwicklerinnen und Entwickler dann den Agent Mode aus, klicken anschließend auf Select tools und wählen dort das entsprechende Häkchen an, um die Azure Extension zu aktivieren. In den Prompts sollen sie laut Microsoft Details zu Ressourcen (Subscription, Ressourcengruppe und Ressourcenname) einfügen, um bessere Resultate zu erzielen.

(mai)