Purpose and Function

Definition

Purpose (bei bewussten, menschlichen Systemen) und Function (bei mechanischen Systemen) ist das eigentliche "Warum" eines Systems. Das wichtigste Dogma des Systemdenkens lautet: Du erkennst den Zweck eines Systems nicht an seinem theoretischen Design-Dokument oder dem Leitbild an der Wand, sondern nur daran, wie sich das System tatsächlich verhält. Positiv ausgedrückt: Das, was ein System konsistent produziert, *ist* sein Zweck (auch abgekürzt als POSIWID - "The Purpose of a System is What it Does", nach Stafford Beer).

Systemmechanismus

Systemziele formen das Verhalten massiv. Wenn die strukturelle Anreizlogik (Incentives, Budgetierung, Beförderungen) eines Systems asynchron zu den bewussten Visionen läuft, gewinnt immer die Struktur. Ein Unternehmen kann "Innovation" an die Wand schreiben, tut aber sein Bonussystem einzig und allein auf Fehlervermeidung ausrichten. Ein System verstellt dann schleichend seine Prioritäten, und die ausgleichenden Schleifen erzwingen Risikoarmut.

Architekturbeispiel

Ein Architektur-Team ruft den Zweck aus: "Wir bauen die robusteste und am besten getestete Microservice-Landschaft." In der Realität werden Entwickler aber nur dafür gefeiert (und befördert), wenn sie schnell neue Endpunkte heraushauen, während Refactorings keine Anerkennung finden. Das tatsächliche, beobachtbare Systemverhalten ist die stetige Maximierung von schnellem, brüchigem Code. Der eigentliche *Zweck* (Purpose) der Architektur-Prozesse ist Feature-Velocity, vollkommen egal, was das Confluence-Dokument besagt.

Organisationsbeispiel

Eine klassische Qualitätssicherungs-Abteilung (QA). Ihr nomineller Zweck: "Wir sorgen für fehlerfreie Software." Wenn man jedoch beobachtet, wie sie agiert, sieht man Folgendes: Unzählige Pflichtenhefte, ewige Zyklen, Stoppen der Pipelines, Absicherung jedes noch so kleinen Restrisikos mit einem Reporting-Formular. Der *tatsächliche* Systemzweck (geleitet durch die Angst vor Fehlern) hat sich zu "Beweissicherung und Rechtfertigung für die nächste Eskalation" gewandelt. Die Funktion hat sich vom nominellen Zweck komplett entkoppelt.

Diagnosefragen

1.Was produziert unser Architektur-Prozess am zuverlässigsten, unbestechlich betrachtet über die letzten 12 Monate? Ist das wirklich der Zweck, den wir angeben?

2.Wo driften das, was wir tun (Verhalten), und das, was wir sagen (Leitbild), auseinander?

3.Welche verborgenen Metriken (z.B. Anerkennung, Budgetvergabe, Angst vor Schuldzuweisungen) treiben unser System heimlich in eine andere Richtung?

Diagramm

Warum dieses Konzept in Architektur hilft

Einer der stärksten Leverage Points (Hebel) nach Donella Meadows ist die Änderung des tief verankerten "System Purpose". Solange der implizite Hauptzweck einer Organisation lautet "Maximiere die kurzfristige Ressourcenauslastung jedes Einzelnen", werden isolierte agile Trainings kläglich untergehen. Erst wenn der Purpose knallhart per Metriken und Incentives auf "Minimiere die Durchlaufzeit (Lead Time) von Code bis zum Kunden" justiert wird, ordnen sich die Feedback Loops, Akteure und Architekturmuster um diesen neuen Kern neu an.

Woran du das Konzept von ähnlichen Themen unterscheidest

*Mental Models* bestimmen, wie ein Individuum oder ein Team die *Realität* kognitiv wahrnimmt. Der *Purpose* hingegen bestimmt die generelle Handlungsrichtung, das Endziel, auf welches die Systemmechanismen ausgreifen (Teleologie). Letzterer bestimmt das Design von Anreizen und Feedback-Schleifen maßgeblich.

Wie du das Konzept praktisch nutzt

Die brutalste Konfrontationsübung für Tech-Leads: Wende die "Was-sie-tun"-Linse auf deine eigenen Strukturen an. Schreibe auf ein Whiteboard auf der linken Seite "Unsere deklarieren Ziele" und auf der rechten Seite "Was wir tatsächlich am häufigsten messen und belohnen". Wenn beides auseinanderklafft, vertraue auf die rechte Seite. Um die Architektur fundamental zu transformieren, musst du die Struktur der Belohnungen (das "Was das System wirklich optimiert") ändern.

Erste Umsetzungsschritte

Verwende OKRs oder Flow-Metriken (Space-Framework) so, dass sie eng an dem tatsächlichen Architekturziel gekoppelt sind und lokale Silo-Verbesserungen unattraktiv machen. Vermeide "Eitelkeits-Metriken" (Vanity Metrics), die eine falsche Funktion vorspiegeln.

Woran du Wirkung erkennst

Beurteilen wir den Erfolg unserer Plattform-Initiative danach, wie viele PowerPoints geschrieben wurden (nomineller Zweck), oder daran, ob Produktteams messbar schneller ausliefern können (tatsächlicher Zweck)?

Quellen

Donella Meadows — Thinking in Systems, Kap. 1: Purpose within Systems

Russell Ackoff — Ackoff's Best: His Classic Writings on Management (Wiley, 1999)

Wikipedia: Teleology