Mikrosystems vs. Mikroservices

Der Begriff Mikroservice ist IN. Nicht ohne Grund. Erfahrungen der letzen 10 Jahre, insbesondere mit großen Webanwendungen, haben dem Mikroservicegedanken den Boden bereitet. Zu große Anwendungen, zu komplizierte und seltene Deployments, unklare Verantwortlichkeiten dienen in der Diskussion als Begründung des neuen Architekturstils. Am Begriff Mikroservice haben sich einige Kontroversen entzündet. Mikroservice vs. Monolith: An die Stelle einer großen Anwendung, die als ganze deployt wird, treten viele kleine Services, die als deploybare Einheiten eine Anwendung in Fachlichkeiten dekomponieren. Mikroservice vs. Nanoservice: Wie viele Zeilen Code soll ein Service enthalten? 100? Ist die Frage sinnvoll – unabhängig von Programmiersprache und Kontext? Vielleicht ist sie nur Symptom der Frage: Wie weit kann und soll man die Mikrofizierung treiben?

Eine Differenz im Streit um die Mikroservices scheint mir neu zu sein. Während die Frage des Monolithen sich mit der Vergangenheit großer Systeme beschäftigt und die Suche nach der intrinsischen Grenze von Mikroservices (eben Nanoservices) eine Idee an ihre (syntaktische) Grenze treibt, ist die Kontroverse Mikroservice vs. Mikrosystem neu auf meinem Radar.

Worum geht es. Stefan Tilkov beschreibt es provokativ in der Software Engineering Radio Episode 210 so: Der Begriff Mikroservice beschreibe eigentlich nur den alten SOA-Gedanken mit neuen Worten. Ein neuer Ansatz entstehe erst, wenn der Mikroservice mit einem UI und einer Datenbank, also Zustand, versehen werde. Und das sei dann kein Service sondern ein System. Das nennt er dann Self-contained System.

Eine der Erfahrungen, die Stefan Tilkov hier verarbeitet, ist der Bau des neuen otto.de-Webshops, der auf den Projektnamen ‘Lhotse’ hört. Auf der QCon in London haben er und Oliver Wegner von Otto dessen Architektur vorgestellt. Der neue Webshop besteht aus separaten Systemen: ‘System architecture is vertical’. Jedes System bildet eine Phase der Aktivität eines Benutzers im Shop ab: Discover, Search, Assess, Order, Check. Jedes System hat ein UI und eine eigene Persistenz. Die Integration der Systeme erfolgt so spät wie möglich – im Browser oder im Webcache (als Edge-Side-Include). (Mehr zur Lhotse-Architektur findet sich hier

Ich finde die Differenz, die Stefan Tilkov hier macht und die meines Wissens noch keine Wellen geschlagen hat, sehr spannend. Zunächst scheint es als ob nur über eine zusätzliche Schicht gesprochen wird – soll der Service, besser: das System, ein UI haben oder nicht. Damit steht und fällt aber eine andere Entscheidung. Ist das System für den Kunden sichtbar oder ist es ein ‘internes System’? Wenn es für die Kunden sichtbar ist, kann das Team, das für das System zuständig ist, sein System an Kennzahlen und Tests mit echten Kunden im echten Betrieb optimieren. Wenn er – jetzt ist es ein Service – kein UI hat, gibt es noch mindestens eine andere Komponente, die seine Inhalte dem User präsentiert oder seine Inhalte mit den Inhalten anderer Services kombiniert und diese Mixtur an den User weiterreicht. Die Kundenorientierung des Teams, welches den Services entwickelt, ist höchstens eine mittelbare.

Die Unterscheidung, die Stefan Tilkov macht, lässt sich als: Ist das System für den Kunden sichtbar oder nicht reformulieren. Sein Standpunkt lautet: Jedes System muss bis zum Kunden reichen. Das ist zumindest für Webshops – die einzige Domäne mit der ich mich auskenne – eine Forderung mit Sprengkraft. Jeder Webshop – egal ob Monolith oder Schwarm von Services – spricht, um seine Arbeit zu verrichten, mit einer Vielzahl anderer Systeme: Logistiksysteme (Bestellungen abwickeln), Content-Datenbanken (Informationen über Artikel), Mediendatenbanken, (Bilder bereitstellen), Kundensysteme. All diese internen Systeme haben keine ‘wirklichen’ sondern ‘nur’ interne Kunden: der Webshop ist ihr interner Kunde, über ein Administrationsinterface haben sie oftmals interne Mitarbeiter als Kunden. Erfolg solcher internen Systeme zu messen, Metriken zu haben, die ‘in letzter Instanz’ dann auch mit echtem Kundenerfolg verbunden sind, ist für solche internen Systeme schwer und oftmals führen sie ein Eigenleben, welches nur sehr mittelbar mit den Anforderungen der ‘wirklichen’ Kunden verbunden ist.

Bläst man die kleine Differenz – Service vs. System – auf zu einem Paradigma: Jedes System muss ein UI haben und für ‘echte’ Kunden sichtbar sein, jedes Team braucht echte Kunden, um seinen Erfolg zu messen, taugt es als Richtschnur für die Restrukturierung einer ganzen Firmen-IT. An die Stelle von breiten Systemen, die eine Fachlichkeit in jeder Hinsicht kapseln, treten vertikale geschnittene Systeme, die in einer Hinsicht Fachlichkeiten integrieren und die bis zum UI reichen.

Was das heisst, ob das geht, welche Erfahrungen es schon gibt, könnte der Inhalt eines anderen Beitrages sein. Mir reicht es im Moment, mich am Knistern dieser elektrisierenden Differenz zu wärmen und die Funken, die sie schlägt, in Bilder zu übersetzen.

DDD: Ports und Adapter

Vaughn Vernon bespricht in seinem Buch Implementing Domain Driven Design verschiedene Arten, wie ein System intern geschichtet werden kann. Sein favorisiertes Muster ist ‘Ports und Adapter’ oder – wie es an der Quelle des Ansatzes dem Artikel von Alistair Cockburn heisst – Hexagonale Architektur. Die Begrifflichkeit, sowohl Ports und Adapter als auch Heaxagonale Architektur, verwirrte uns in der DDD-Lesegruppe zunächst. Was ist ein Port, was ein Adapter? Wo ist der ApplikationsService verortet? Mir half ein kleines Video von Martin Fowler. Er unterscheidet dort Hexagonale Architektur (Ports und Adapter) von der klassischen 3-Schicht-Architektur. Er visualisiert die Schichten durch Bücher. Die UI-Schicht ist das Buch JavaScript: The Good Parts, die Domänenschicht ist Domain Driven Design und die Persistenzschicht ist The Practical SQL-Handbook. In einer 3-Schicht-Architektur könne, so Fowler, jede Schicht alle Schichten unter sich sehen. Das wird durch die drei Bücher, die aufeinander liegen – JS, DDD, SQL -, visualisiert. Die Schichten sind jeweils von denen, die unter ihnen sind, abhängig. Umgekehrt kenne ein Schicht nichts von denen über sich. So ist die Domänenschicht unabhängig vom User-Interface und die Persistenz ist unabhängig von User-Interface und Domänenschicht. Wesentlich für das Ports und Adapter-Muster ist die Beziehung von Domänenschicht zur Persistenzschicht. Das Muster, in dem die Domänenschicht die Persistenz kenne und von dieser abhängig sei (klassische 3-Schicht-Architektur), sei ActiveRecord. (Fowler hat diesen Begriff in seinem Buch Patterns of Application Architecture vorgestellt. Das gleichnamige Rails-Framework ist die prominenteste Implementierung dieses Musters.) Wenn ich meine Domänenschicht aus dieser Abhängigkeit befreien möchte, wenn ich die Domänenschicht unabhängig von der Persistenz entwickeln und damit auch testen möchte, dann sei das das Pattern DataMapper (‘Patterns of Application Architecture’). Fowler bemüht im Video das Bild einer indischen Gottheit mit 6 Armen. Diese hält die Bücher. In der Mitte DDD. JS und SQL kreisen um diese Mitte. Die Modellierung der Domäne wäre unabhängig von der Persistenz. Die Aufgabe der Persistierung der Objekte übernimmt bspw. ein OR-Mapper (DataMapper-Pattern). Dieser residiere in der Persistenzschicht und wäre in der Domänenschicht gänzlich unbekannt.

Lange Rede kurzer Sinn: Um festzustellen, ob es sich bei der grundsätzlichen Aufteilung eines Systems eher um Ports und Adapter (Hexagonale Architektur) oder um eine klassische 3-Schicht-Architektur handelt, genügt es, die Frage zu beantworten: Ist die Domänenschicht abhängig von der Persistenzschicht oder nicht.

Das technische Mittel um diese Entkopplung zu bewirken ist Dependency Inversion. Die Domänenschicht definiert Interfaces für Repositories, die die fachliche Frage beantworten, mithilfe welcher Parameter möchte ich welche Objekte auffinden. Die Persistenzschicht implementiert diese Interfaces mit einer konkreten Persistenzmechanik wie z.B. Hibernate. Durch Muster wie Registry oder Dependency Injection Container kommen diese Implementierungen ins Spiel.

Kehren wir zum Ausgangspunkt zurück. Wenn UI und Persistenz um die Domäne kreisen, ähneln sie sich. Das ist der Kerngedanke von Cockburns Ansatz. Es gibt eine Domänenschicht, die von nichts abhängig ist. Über Ports und Adapter – Ports sind die Löcher in der Schale, Adapter die Anschluss-Implementierungen, die Loch und Lochprotokoll mit der Applikation verbinden (bspw. das HTTP-Loch, das durch einen Webadapter mit der Applikation verbunden wird). UI und Persistenz sind Verbindungen mit der Außernwelt. Die Symmetrie zwischen UI und Persistenz ist der zentrale Gedanke des Ansatzes. Die Persistenz ist genau so entkoppelt von der Appliktation wie in der klassischen 3-Schicht-Architektur das User-Interface. So wie man für Tests ein anderes Interface (programmatisch JUnit oder ein Kommandozeileninterface) wählen kann, lässt sich auch die Persistenz ersetzen, ohne die Funktion der Applikation zu beeinträchtigen. Im Test nutzt man eine Testdatenbank oder einen Imspeicherdatenbankmock und die Applikation ist leichter zu testen.

So intuitiv das Pattern zunächst scheint, so symmetrisch die kreisenden Bücher wirken, ganz verschwindet die Asymmetrie, der Unterschied von UI und Persistenz nicht. Cockburn spricht von links (UI) und rechts (Persistenz), von treibendenund getriebenen Ports. Das UI nutzt die Klassen der Applikationsschicht direkt, die Klassen der Persistenz kommen indirekt ins Spiel, indem sie die Interfaces der Domäne implementieren und in die Applikation injiziert werden. Hier liegt wahrscheinlich das Problem des Musters. Es führt eine Symmetrie ein: ‘Sind wir, die nicht zur Domänen gehören, nicht alle Ports und Adapter, die um die Domäne kreisen’, der sich die konkrete Erfahrung permanent verweigert. Das Aktiv und Passiv, das Getrieben und Treibend, das Links und Rechts ist für die Arbeit in einer Schicht so wichtig, dass das Gefühl der Ähnlichkeit von UI und Persistenz sich nicht einstellen mag, auch nicht in einem Hexagon.

Mir reicht es den Unterschied von Ports und Adaptern zu einer klassischen 3-Schicht-Architektur auf den von ActiveRecord und DataMapper zu reduzieren. Die Frage nach der Beziehung zwischen Persistenz und Domäne dient mir als Lackmustest. Cockburns Symmetriesierung ist vielleicht anregend, langfristig scheint sie mir nicht instruktiv.

Nachtrag (10.8.2014) Vaughn Vernon hat seine Beispielprojekte so gegliedert, dass es auf der obersten Ebene (unterhalb des obligatorischen Namespaces für das ganze Projekt) drei Pakete gibt: port.adapter, application und domain.model – das Hexagon von außen nach innen. (Er nutzt die Doppelnamen mit Punkt, um die Bezeichnung sprechender zu machen, in domain und port findet sich nichts bis auf ihre Unterpakete.) In port.adapter gibt es dann Unterpakete nach Schnittstellen: messaging, persistence und service.

DDD: Die Grenzen eines Aggregats

Auf der Arbeit kultivieren wir gerade Eat’n’Read. Jeden Freitag sitzen wir zusammen, essen und lesen Implementing Domain Driven Design von Vaughn Vernon. Vernon arbeitet die Gedanken auf, die Eric Evans in Domain Driven Design entwickelt hat. Ein paar Dinge sind neu – Domain-Events – andere werden anders strukturiert, Schwerpunkte sind verschoben aber im Großen und Ganzen versucht sich Vernon am Original (?) zu orientieren. Um so interessanter ist es sich die Frage zu stellen, wo nun die Unterschiede zwischen Evans und Vernon sind.

Bei der Darstellung eines Aggregats, genauer: seiner Grenzen, differieren die Bücher. Aggregate sind kleine Objektkomplexe, die ein Wurzelobjekt besitzen, dass den Zugriff auf die anderen Objekte des Komplexes kapselt und eine API für die Arbeit mit ihnen zur Verfügung stellt. Typische Beispiele sind Warenkörbe, die den Zugriff und die Verwaltung von Warenkorbeinträgen kapseln oder Produkte, die als Gipfel über einer Pyramide von Farb- und Größenvarianten thronen. (Vorsicht: das sind nur Beispiele, Vernon zeigt deutlichst, wie sich diese Aggregate unter gewissen Umständen in mehrere Aggregate zerlegen lassen, so dass es keine kanonische Struktur einer Warenkorbmodellierung geben kann.)

Wie nun erkennt man die Grenzen eines Aggregats? Für Evans sind es zwei Momente, die auf die Grenzen verweisen. Es ist zum einen die Infrastruktur, die mir Hinweise derart bieten könnte wie: ‘Sie verlassen den Sektor des Aggregats A und betreten den des Aggregats B.’ Und es ist die Disziplin der Programmierer, die sich davor hüten die Grenzen zu überschreiten. Konkret bedeutet das, dass ich im Hibernate-Mapping das Aggregat mit Eager-Loading lade und die Grenze zum nächsten mit Lazy-Loading markiere. Im Code wären die beiden Referenzen gleich, in der Infrastruktur wäre ihr Unterschied substantiell.

Vernon verfolgt eine striktere Strategie. Seine Aggregate sind im Code klar zu erkennen. Innerhalb eines Aggregats erlaubt er die Navigation via Referenz. Auf angrenzende Aggregat verweist nur eine ID. Wenn ich zu einem anderen Aggregat navigieren will, muss ich ein Repository bemühen. Am Repository kann ich die ID gegen ein echtes Objekt eintauschen. Die Grenze meines Aggregat ist klar markiert. In der Hibernate-Sprache hieße das, dass ich Relationen nur in einem Aggregat mappen darf. An den Grenzen muss ich eine neue Query bemühen, um an das angrenzende Objekt zu gelangen. In der Sprache von RubyOnRails ausgedrückt: Die ActiveRecord-Mappings ‘has_many’, ‘has_one’ und ‘belongs_to’ sind nur in einem Aggregat gestattet.

Liest man weiter, merkt man, dass die beiden Bücher einen Kontext mitbringen, der ihre Differenz erzeugt. In der Vorstellungswelt von Evans sind Datenbanken relational oder objektorientiert. In der Welt von Vernon sind sie relational oder es sind NoSql-Datenbanken, etwas genauer – in der Sprache von Martin Fowler – aggregatorientierte Datenbanken. In Evans Welt einer relationalen Datenbank ist der Übergang von einem Aggregat zu einem anderen ein gradueller, ein Join wird komplizierter. Seine Art von Datenbank hat kein originäres Konzept eines Aggregats. Das Aggregat wird durch einen Join in einer Query erzeugt. In der Welt von Vernon, in der aggregatorientierten Datenbank, gibt es Aggregate (tautologisch). Solange ich diese Aggregate lade, spielt die Datenbank ihre Vorteile aus. Überschreite ich die Grenzen eines Aggregats, wird es teuer und die Vorteile der Datenbank verkehren sich in ihr Gegenteil. Es ist nicht nur sinnvoll, sondern existentiell im Code große Warnschilder: ‘Achtung Aggregatgrenze’ aufzustellen.

Der Unterschied in der Modellierung – explizite oder implizite Grenze – (Ich bin fest davon überzeugt, dass es auch jenseits der Infrastuktur gute Gründe gibt für den einen oder anderen Ansatz zu votieren.) zeigt sich so zunächst als Reflex auf eine andere Infrastuktur, auf Entwicklungen, die im Bereich der Datenbanken in den letzten Jahren stattgefunden haben und man kann unterstellen, dass auch Evans heute eine Antwort auf diese Herausforderung finden müsste, wie auch Vernon vor 10 Jahren noch nicht in dieser Schärfe die Grenzen seiner Aggregate markiert hätte.

Conways Law Revisited

Wenn man in einer Woche zweimal in unterschiedlichen Kontexten mit einer Sache
konfrontiert wird, ist das ein Zeichen. Wofür auch immer. So ist es mir in der
letzten Wochen mit Conways Law ergangen. Bisher kannte ich Conways Law als
das Gesetz, das besagt, dass sich über kurz oder lang die Strukturen eines
sozialen Systems in einem technischen System wiederfinden werden. Wenn ich ein
Programm schreibe, mit dem später zwei Fachabteilungen arbeiten werden, wird
sich diese Trennung auch im technischen System – dem Programm – ausdrücken.

Die Wikipedia zitiert das Gesetz von Conway so: “Organizations which design
systems [...] are constrained to produce designs which are copies of the
communication structures of these organizations”. Die Strukturen richten sich
demnach vor allem an den Kommunikationsstrukturen aus. (Ich glaube ohne eine
Quelle zur Hand zu haben, dass es im Original vor allem um Compiler ging, die
von Komitees entwickelt wurden. Conway hatte festgestellt, dass die
Modulstruktur der fertigen Compiler den Arbeitsgruppen der Komitees
entsprach.)

Das Gesetz begegnete mir zunächst in einem Artikel von Brandon Byars. Dieser
publiziert gerade auf der Webseite von Martin Fowler einen Artikel über
Enterprise Integration using REST. Im Abschnitt Do not let systems
monopolize resources
 
diskutiert er die Frage, wie man größere Systeme schneiden soll. Soll man bspw. an einer Stelle das Wissen über ein Produkt zentralisieren? Man hätte
dann ein System, das eine Ressource monopolisierte. Und das verstoße gegen das
Gesetz von Conway, das da besage, dass die Architektur des Systems die
Struktur des sozialen Systems spiegeln solle. Im Konkreten würde das heißen,
dass es mehrere Produktbegriffe in mehreren Systeme gäbe und jedes Softwaresystem um ein soziales System, das durch einen einheitlichen semantisches Kontext (Bounded Context) gekennzeichnet ist, zu errichten wäre. Doch das ist eine andere Geschichte.

Für mich war an dieser Lesart des Gesetzes neu, dass es präskriptiv,
vorschreibend, und nicht deskriptiv, beschreiben, gelesen wurde. Bisher fand ich es immer interessant, an den entstandenen Systemen zu rekonstruieren, wie sich hier die
faktischen Kommunikationsstrukturen ausgedrückt haben. Das es praktisch der gleiche
Gedanke ist, vorher nach dem sozialen Systemen und den Kommunikationsstrukturen zu fragen und die Systeme so zu modellieren, dass sie sie abbilden, kam mir dabei
nicht in den Sinn. Bis zu dieser Woche, bis zu Brandon Byars.

Die andere Begegnung war folgende. Ich lass über das Wasserfallmodell, über all die Phasen und all die Artefakte, die jede Phase erzeugte. Das Modell beschreibt auch ein System. Es ist kein strukturelles, es ist ein temporales. Die Phase folgen einander.
Aber das Gesetz von Conway lässt sich ebenfalls anwenden. Das soziale System,
das bei der Softwareerstellung involviert ist, reflektiert sich im Phasenmodell. Jede Abteilung hat ihre Phase und ihre Dokumente. Die grundsätzlichen Anforderungen werden vom oberen Management festgelegt. Die Fachabteilungen erzeugen den Inhalt der Spezifikationen. Die Architekten schaffen den Systementwurf. Die Programmierer den Code. Die Tester den Testplan. Die Betreiber das Betriebskonzept. Die Stabilität des Modells besteht darin, dass jede Gruppe ihre Phase und ihre Artefakte hat. Jede Gruppe kann sich vergegenständlichen. Es gibt kein einheitliches Wasserfallmodell (es
gibt die unterschiedlichsten Ausführungen mit zwischen 6 und 18 Phasen), weil das
zugrundeliegende soziale System immer anders aussieht. Jedes soziale System
schafft sich seine Phase und sein Artefakt. Je stärker die Abteilung um so
ausgeprägter die Phase und wichtiger das Dokument.

Das Problem des Wasserfallmodells lässt sich aus dieser Perspektive folgendermaßen
charakterisieren. Es gibt N Systeme, N Phasen und N Dokumente (Artefakte). Im
Kontext des Systems I ist das Dokument I aussagekräftig. Die Welt des Systems
I verleiht dem Dokument I seine Bedeutung. Für alle anderen Systeme ist das
Dokument marginal, randständig, unscharf, weil alle anderen Systeme anderen
Sprachspielen und Kontexten gehorchen. Im Wasserfallmodell ist dieses
Übersetzungproblem nicht adressiert. Im Gegenteil, man könnte sagen, es ist
zementiert.

Zwei Anwendungen von Conways Law, die für mich neu waren. Im Kern geht es bei
beiden um das Verhältnis von sozialen und technischen Systemen. Einmal in
struktureller Hinsicht (Design von Subsystemen), einmal in temporaler
(Phasen). Ich vermute, das wird nicht das letzte Mal sein, dass ich auf dieses
Gesetz gestoßen bin.

Composed Method Revisited

Ich habe das erste Mal von Composed Method in dem Buch Smalltalk – Best Practice Patterns von Kent Beck (1996) gelesen. Das Buch ist eine Sammlung von Mustern für das Programmieren im Kleinen. Das Problem, das Composed Method adressiert, ist:

“Wie zerlegt man ein Programm in Methoden?”

Es handelt sich um ein zentrales Muster für die Programmierung. Die Frage nach der Zerlegung eines Programmes in Methoden, ist eine der wichtigsten Fragen. Was ist die Antwort auf das Problem, die Kent Beck gibt?

“Zerlege dein Programm in Methoden, die jeweils genau eine erkennbare Aufgabe ausführen. Sorge dafür, dass alle Operationen in einer Methode auf dem selben Niveau der Abstraktion liegen. Dieses Vorgehen wird ganz natürlich zu Programmen mit vielen kleinen Methoden führen, die alle nur ein paar Zeilen lang sind.”

Soweit Composed Method. Drei Jahre später bringt Jeff Langr ein Buch heraus: Essential Java Style. Das Buch ist die Übersetzung der Smalltalk-Pattern in die Sprache Java.

Im Jahre 2002 veröffentlicht Langr einen Artikel: Enlightened Java Style. Er hat sich in 3 Jahren vom ‘Wesentlichen’ zum ‘Erleuchteten’ Java-Style vorgearbeitet. Er empfiehlt sich die 30 Dollar für sein Buch zu sparen und eine CD oder ein Geschenk für einen Freund zu kaufen. Man hätte dann etwas handfestes. Was ist es, was seinen erleuchteten Stil prägt? Er schreibt er könne sich sowieso nur eine handvoll Muster merken und deshalb hätte er die vielen Muster seines Buches zu dreien reduziert: “Composed Method, Intention-Revealing Name and Comment” – wieder Composed Method als zentrales Muster.

Langr erklärt Composed Method so:

“Composed Method sagt aus, dass eine Methode Dinge auf genau einem Niveau der Abstraktion tun soll. Sie soll extrem kohäsiv (bindig, zusammenhaltend) sein. Sie soll eine Sache tun und die soll sie gut tun.” Und zusammenfassend: “Das schnelle Verstehen ist hier das Wichtigste. Es darf mich nicht mehr als eine Minute oder zwei kosten, um zu verstehen, was ein Entwickler mit dieser Methode bewirken wollte.”

Mit diesem Wissen im Hinterkopf war ich gespannt, wie Meister der Programmierung selbst ihre Pattern anwenden. Vor einem Monat haben wir auf der Arbeit einen Innovationstag durchgeführt. Allen stand frei sich einen Tag mit einem Projekt zu beschäftigen, Vorträge zu halten, Vorträge zu hören oder anderweitig ihre Erfahrungen auszutauschen. Ich habe diesen Tag genutzt, um mir den Code der ersten überlieferten Junit-Version anzuschauen. Junit lebt auf github unter: https://github.com/KentBeck/junit.git. Der erste Commit ist die Version 3.4 vom 3. Dezember 2000. Der Commit ist von Erich Gamma. Junit sei auf einem transatlantischen Flug von Kent Beck und Erich Gamma entstanden. Kent Beck hatte das erste Unit-Testframework geschrieben (Sunit in Smalltalk) und wollte Java lernen, Erich Gamma war bereits Java-Fuchs (im eclipse-Projekt aktiv) und wollte Unittesting kennernlernen. Daraus entstanden ist Junit – ein Projekt, das sie zusammen weiterentwickelt haben. Die Versionen vor dem ersten github-Commit gingen verloren: “the earliest versions are lost in the mists of time” (Kent Beck).

Um zu sehen, wie die beiden programmieren, habe ich mir den Code von Junit 3.4 angeschaut. Ich kann es jedem empfehlen an Stelle eines Buches mal einen alten Quellcode zur Hand zu nehmen und ihn zu lesen. Junit ist ein dankbares Exemplar, weil man weiß, wie man es anwendet, und weil es überschaubar ist. Man findet viele kleine Methoden, genau wie Kent Beck es oben als Auswirkung von Composed Method beschreibt. Aber – und das ist der eigentlich Aufhänger dieses Artikels – es findet sich eine Variante des Pattern, die in den Aufsätzen über das Pattern nicht beschrieben ist. Es handelt sich dabei vielleicht nur um eine Spezifik der Anwendung Junit, aber es ist ein Aspekt, der mir vorher nicht klar war, eine Dimension des Musters, die ich bisher nicht wahrgenommen hatte.

In den Projekten, in denen ich arbeite findet sich das Muster oft als Ergebnis eines Refactorings. Eine Methode erledigt viel zu viele konkrete Aufgaben, so dass es unmöglich ist, sie zu überblicken oder nur einfach zu lesen. Man muss sich eine viertel bis halbe Stunde in den Code vertiefen und dann hat man eine Vorstellung von dem, was sie tut. Diese Methode wird dann in einem Refactoring in Blöcke zerlegt, so dass sie am Ende nur noch delegiert. Sehr schematisch: Vorher hatte sie 30 Zeilen, jetzt hat sie nur noch drei und ruft drei Methoden auf, die jeweils 10 Zeilen der alten Methode beinhalten. Die Methode wurde von einer ‘Ich mach lieber alles selbst’ zu einer ‘Ich delegiere alles’-Methode. Wenn man den Kontrollfluss verfolgt, steckt hinter jeder Untermethode gleich viel Betriebsamkeit.

In Junit 3.4 ist das anders. Jede Methode – egal ob Main, Toplevel oder ganz unten in der Hierarchie – erledigt eine konkrete Aufgabe und delegiert anderes. Die Mainmethode erzeugt den Testrunner, startet ihn (Delegation) und kümmert sich um den Exitcode (konkret). Der Start des Testrunners parsed die Kommandozeilenargumente (konkret) und startet die TestSuite (Delegation). Das starten der Testsuite kümmert sich um die Zeitmessung der Tests (konkret) und startet die eigentliche Suite (Delegation). Uns so weiter und so weiter. Diese Variante von Composed Method würde ich so beschreiben, dass jede Methode eine konkrete Aufgabe auf ihrer Ebene ausführt und dann – und das ist für das Lesen des Codes extrem wichtig – genau an einer Stelle auf eine andere Ebene delegiert. Alle Methoden benutzen kleine Hilfsmethoden, aber der Hauptkontrollfluss geht in jeder Methode nur an einer Stelle in die Tiefe. Sehr angenehm!

Was ich mitgenommen habe? Wenn ich in Zukunft Methoden zerlege, versuche ich mir zwei Fragen zu stellen. Erstens: Gibt es eine konkrete Aufgabe, die diese Methode hier erledigen kann? Zweitens: Wie kann ich den Kontrollfluss durch die Methode möglichst einfach gestalten? Wie schaffe ich es, dass man beim Lesen nur an einer Stelle in die komplexe Struktur des Programms absteigen muss?

Selbstorganisation

Am letzten Freitag hatte ich das Glück am it-camp der oose teilnehmen zu können. Das Thema war Selbstorganisation. Der Referent war einer der führenden Köpfe systemischer Organisationsberatung und Therapie in Deutschland: Fritz B. Simon. Er erklärte in seinem Referat die Grundbegriffe der systemischen Organisationstheorie. Im Anschluss gab es ein Worldcafe, das sich sehr stark um alle Aspekte der Selbstorganisation von Teams dreht. Das Ende der Veranstaltung war ein Open-Space. Ich habe dort mit anderen versucht einige Verwirrungen um den Begriff der Selbstorganisation, wie er im Referat entfaltet wurde und wie er uns in den Diskussionen umtrieb, aufzulösen.
Das Einführungsreferat argumentierte sehr grundsätzlich. Selbstorganisation sei die Daseinsform von sozialen Systemen. Selbstorganisation sei ein Gegenbegriff zur mechanischen Kausalität und biologischen, psychischen und sozialen Systemen eigen. Er bedeute, dass diese Systeme ihre Interpretation ihrer Umwelt (was immer Interpretation für das jeweilige System – psychisch, lebendig, sozial – sei) selber schüfen. Mechanische Systeme könne man von außen anstoßen und steuern. Sie hätten Gesetze, die erklärten, was aus dem Anstoss würde. Selbstorganisierte Systeme könnten auch von außen verwirrt, gereizt, angestoßen werden, aber das was dann passiere liege in der Dynamik des Systems und sei nicht aus dem Reiz ableitbar. Diese Phänomen nenne man Selbstorganisaton. Wenn diese Systeme sich nicht mehr selbstorganisierten, dann wären sie tot, dann hörten sie auf als Systeme zu existieren.
Was uns in der Open-Space-Gruppe umtrieb war das Verhältnis von dem sehr grundsätzlichen Begriff der Selbstorganisation, wie ihn Fritz B. Simon entwickelt hatte und dem Begriff, der uns in unseren Debatten um die Selbstorganisation in unseren Teams umtrieb. Der systemische Begriff stellte so etwas wie die grundlegende Daseinsweise eines sozialen System dar. Die Frage wie selbstorganisiert ein soziales System sei, ist in diesem Kontext eine unsinnige Frage. Soziale Systeme sind immer selbstorganisiert – das sind sie qua Definition. Diese Art der systemischen Selbstorganisation ist nicht graduierbar – mehr oder weniger selbstorganisiert. Das jedoch war es, was uns in unseren Diskussion in den World-Cafe Runden umtrieb: Wie selbstorganisert sind unsere Teams, wie können wir dafür sorgen, dass sie sich noch besser selbst organisieren? Dieser – unser – Begriff der Selbstorganisation schien eher ein Gegenbegriff zu Fremdbestimmung zu sein.
In der Open-Space Gruppe waren wir ratlos. Wir hatten den Eindruck, es gäbe zwei Begriffe von Selbstorganisation, die sich zwar das Wort teilten, ansonsten – zumindest zunächst und für uns – wenig mit einander zu tun hätten. Zum einen war da der Begriff ‘Selbstorganisation eines sozialen Systems’, der auf eine grundlegende Bewegungs- und Existenzweise dieses Systems verwies zum anderen war da der Begriff, der unsere Diskussionen motivierte, der als Gegenbegriff zu Fremdbestimmung fungierte und die Frage nach einer Verbesserung unserer Selbstorganisation erlaubte. (Vielleicht so: einmal ein analytischer, kategorialer, einmal ein normativer Begriff.) Unsere Ratlosigkeit füllten wir mit ein paar Vermutungen. Vielleicht sei der systemische Begriff zwar völlig richtig, aber auch völlig unbrauchbar für unsere Debatte. Vielleicht müsse der systemische Begriff weiter entwickelt werden, bspw. in Form der Frage nach verschiedenen möglichen Mustern von Selbstorganisation, um anschlussfähig an die Frage nach der Verbesserung der Selbstorganisation im Team zu werden. Wahrscheinlich gäbe es auch die entsprechenden Weiterentwicklungen, aber uns blieben sie verborgen.

Software als Handwerk?

Ein Welle der Empörung überschwemmte Dan North in der letzten Woche. Sein Post: ‘Programmieren ist kein Handwerk’ (http://dannorth.net/2011/01/11/programming-is-not-a-craft/) entzündete eine breite Diskussion. Im Normalfall würden ein paar hundert Menschen seinen Blog lesen, dieses Mal seien es 20000 innerhalb weniger Tage gewesen. Nach 4 Tagen hatte der Post 150 Kommentare. Worum geht es?

Dan North schreibt Programmieren sei kein Handwerk (craft) sondern ein Beruf (trade). Wenn meine schwachen Englischkenntnisse und meine kurzen Recherchen mich nicht trügen, dann zielt der Begriff ‘craft’ in die Richtung Handwerk, Kunsthandwerk, Ehre des Handwerks (Arbeitsethos), während ‘trade’ mit Geschäft, Gewerbe, Handel verwandt ist. Der Gegensatz, auf den Dan North zielt wird vielleicht am deutlichsten in folgender Passage: “… I want an expert programmer enabling my business. What I don’t want, however, is a prima donna plumber who insists on talking about the elegance …” Dan North zielt auf einen latent in der agilen Softwareentwicklung verhandelten Gegensatz. Ist qualitativ gute Software essentiell für die agile Softwareentwicklung? Ist sie Selbstzweck? Ist sie Mittel zum Zweck?

Der Anlass für Dan North Bemerkung ist das Manifesto for Software Craftmanship (http://manifesto.softwarecraftsmanship.org/). Das Manifest lehnt seine Form an das Agile Manifest an. Es versucht die Qualität der Software stärker ins Zentrum der Bemühung von Programmierern zu rücken. Dan North hat es nicht unterzeichnet, wenn man seinen Post liest, weiss man auch warum.

Ich möchte nicht zu der Debatte Stellung beziehen, sondern zwei Gedanken äußern, die mir schon seit längeren durch den Kopf gehen. Der erste Gedanke hat unmittelbar mit dem Begriff Handwerk zu tun. (Handwerk in dem emphatischen Sinne, den craft meint.) Meine eigene Erfahrung ist, dass sich TDD nicht wie die Anwendung einer beliebigen Praktik erlernen lässt. TDD (also Test-First-Programming) erfordert eine längere Phase der Übung und diese Phase ist anstrengend. Erst nach einem disziplinierten mehrmonatigen Sich-selbst-immer-wieder-dazu-zwingen stellt sich so etwas wie eine Vertrautheit ein. Wenn die Umerziehungsphase zu kurz ist, fällt man wieder in die alten Praktiken zurück. Als Bild habe ich einen Berg vor Augen. Wenn man erst einmal den Gipfel überschritten hat, ist der Weg zurück ebenso verbaut. Nachdem ich mich daran gewöhnt hatte praktisch jeden, nicht völlig trivialen Code mit Tests einzubetten, war es ein komisches Gefühl in bestimmten Kontexten darauf zu verzichten. Ähnlich stelle ich mir auch den Lernprozess in einem klassischen Handwerk vor. Der Lehrling begleitet den Gesellen ein paar Jahre lang, schaut ab, macht mit, handelt selbst, wird korrigiert und irgendwann ist es ihm ‘in Fleisch und Blut’ übergegangen. Die Theorie dazu, das Warum, spielt dabei kaum eine Rolle. Das ‘Immer und immer wieder’ steht im Mittelpunkt. Deshalb mag ich Handwerk/Craft als Begriff, es drückt diese wichtige Erfaghrung aus.

Aber – ohne dieses Aber wäre das hier ja doch ein Plädoyer für eine Seite – aber, ein Gedanke, den ich bei Kent Beck gelesen habe, hat mich nicht mehr in Ruhe gelassen, ohne dass ich ihn schon umsetzen, anwenden ohne nur richtig einordnen könnte. Leider habe ich ‘auf die Schnelle’ keine Referenz gefunden. In der gemeinten Passage beschreibt Kent Beck, wie schwer es ihm falle Quick-and-Dirty zu programmieren. Aber, so geht der Gedanke weiter, es sei eben Verschwendung, wenn wir jedes Codestück mit einer Superqualität auslieferten. Es ginge vielmehr darum, schnell etwas auszuliefern, um mit diesem Experiment zu sehen, was geht und was nicht, was angenommen wird und was nicht. Und anhand der Ergebnisse aus diesem Experiment kann man sagen, ob überhaupt weiter programmiert werden müsse und in welche Richtung das gehen solle. Die Zweige, die sich dann als entwicklungsfähig herausstellten, seien mit aller gebotenen handwerklichen Qualität zu verfertigen, aber eben auch nur genau die. Ich finde diesen Gedanken sehr gut. Er ist aber schwer zu verwirklichen. Ich spüre einen Unbill sobald ich etwas ‘nur mal so dahinrotze’. Ein schlechtes Gewissen macht sich breit. Die Gefühle aus dem TDD-Umerziehungslager rumoren im Bauch. Softwarequalität als Selbstzweck lässt sich viel einfacher zum Maßstab machen. (Wohlgemerkt: zum Maßstab, was noch nicht verwirklichen heisst.) Wenn ich das ganze Kontinuum von Quick-and-Dirty bis vollständig-getestet-wohldesigned-stabil ausreizen wollte, müsste ich den Kontext stärker in Rechnung stellen, die Feedbackschleifen müssten kürzer, effektiver und bewußter werden. Es ginge darum Experiment zu formulieren und duchzuführen.

Mit meinen zwei Gedanken finde ich mich auf beiden Seiten des Gegensatzes wieder. Das Handwerk ist mir wichtig, weil es die Essenz des Programmierenlernens bedeutet. Die Rückkoppelung des Kunden ist mir wichtig, weil sie allein der Qualität als Maß dienen kann.

Monoglottes Programmieren?

Vor ein paar Jahren prägte Neal Ford den Ausdruck ‘Polyglottes Programmieren’. Er bezeichnete damit den Umstand, dass wir als Programmierer immer mehr genötigt sind mehrere Programmiersprachen gleichzeitig zu benutzen. Das klassische Beispiel ist eine Webanwendung. In der Datenbank sprechen wir SQL, die Applikationslogik ist vielleicht in Java implementiert und auf der Clientseite im Browser kommt JavaScript zum Einsatz. Um die Webseite zu strukturieren und darzustellen müssen wir uns in den Beschreibungssprachen HTML und CSS ausdrücken. Also mindestens 5 Sprachen um ein Datum aus der Datenbank im Browser anzuzeigen. Bei Neal Ford ist der Ausdruck durchaus nicht negativ gemeint. Er drückt das Aufatmen eines neugierigen Programmierers nach Jahren der Monokultur aus.

In meinem letzten Projekt habe ich eine interessante Erfahrung gemacht. Es handelt sich bei der Applikation um eine RubyOnRails-Anwendung. Die Datenbank ist eine MongoDB. Die Datenbank spricht also JavaScript und die Daten sind im JSON-Format abgelegt. Ein Teil der Logik unserer Applikation ist clientseitig im Browser implementiert. Es ist ein sehr geschmeidiger Prozess, die Objekte aus der Datenbank zu lesen und beim erzeugen der Webseite nur ‘to_json’ zu sagen, um die JSON-Objekte der Datenbank im JavaScript des Browsers als JavaScript-Objekte zur Verfügung zu haben. Veränderungen der Struktur der Objekte in der Datenbank wandern ohne Übersetzung, Transformation auf die Browserseite: Browser und Datenbank sprechen die gleiche Sprache.

Im Augenblick testen wir node.js (serverseitiges Javascript mit asynchronem IO) als Programmiersprache für Webanwendungen. express ist eine Framework für node.js, das die Funktionen eines einfachen Webframeworks (Rubys Sinatra war Vorbild) implementiert. Mit der Kombination MongoDB, node.js/express, Browser sprechen alle Komponenten der Applikation die gleiche Sprache. Die Datenbank spricht JavaScript und hält ihre Daten in JSON genau so wie auch die Applikationsschicht und der Browser.

Man ist versucht den Ausdruck ‘Monoglottes Programmieren’ zu prägen, aber da ist ein Beigeschmack. Das ‘Monoglotte’ ist nicht die Rückkehr zur alten Monokultur. Die Freude des ‘Polyglotten’ lebt im ‘Monoglotten’ fort. Vielleicht ist das so, weil die Technik so neu ist. Vielleicht ist es auch so, weil sich unter der gleichen Programmiersprache neue Paradigmen in die Programmierung mischen. Die Datenbank folgt jetzt nicht mehr dem relationalen Paradigma, sondern ist NoSQL (no = not only?). Das – NoSQL – ist noch kaum verstanden und die Diskussion um die Bedeutung für die Modellierung beginnt erst. Die Applikation arbeitet nicht multithreaded, sondern mit asynchronem IO: Ein Prozess im Loop und eine Programmierung mit vielen Callback-Routinen, die auf Events reagieren. Wenn NoSQL neu sein sollte, ist node.js noch ganz heiss.

Die Freude am Neuen, die der Ausdruck ‘Polyglottes Programmieren’ anzeigte, lebt im ‘Monoglotten Programmieren’ fort, weil es eigentlich ein ‘Polyparadigmatisches Programmieren’ ist. Aber wer wollte das noch sagen und dabei das Gefühl von Freude haben?

Die Zeit der Unschuld ist vorbei

Die Zeit der Unschuld ist vorbei
Die XPDays 2009 haben mich sehr beeindruckt. Eine Erkenntnis macht sich seitdem bei mir breit. Andreas Boes beschrieb sie in seinem Vortrag theoretisch, die anwesenden Kollegen von SAP aus praktischer Sicht. In einen Satz gebracht könnte man sagen: Mit der Verbidnung von agilen Praktiken als Managementmethode im Kleinen, Operativen und Lean-Management im Großen setzt sich im Bereich der Softwareentwicklung eine Prozessrevolution durch, die in ihrer Bedeutung mit der industriellen Revolution vergleichbar ist. Andreas Boes sprach bei der Durchsetzung der Leanpraktiken im Management von einer zweiten industriellen Revolution. Die Kollegen von SAP sprachen davon, dass durch Leanmanagement – durch entsprechende makroskopische Steuerung und Kennzahlen – erst das wirkliche Potential von agilen Praktiken in ihrer Firma zur Geltung gebracht wird.
Wenn dem so ist, wenn wir als agile Praktiker eines der Herzstücke eines neuen Produktionsparadigmas ins Werk setzen, dann müssen wir auch darüber nachdenken, wie sich dieses Gefüge Produktionskultur insgesamt verändert und was für eine Verantwortung wird dabei haben.
Was ich damit meine, will ich am Beispiel einer kleinen Geschichte, einer wahren Begebenheit, erläutern. In den 90er Jahre gab es eine linke Fraktion der KIF (Konferenz der Informatik-Fachschaften) die JOINT (Jährliche Oldenburger Informatik-Tage). Dort haben wir uns drei oder viermal zu einem Wochenende versammelt, um über die Themen zu debattieren, die auf der KIF zu kurz kamen. Zu einem dieser Treffen hatte sich ein Betriebsrat eines großen deutschen Elektronik- und Softwarehersteller Herstellers, der im Raum einer süddeutschen Großstadt ein großes Werk betreibt – nennen wir den Hersteller Sienix – eingeladen. Für uns war es sehr spannend zu hören, was sich in so einem großen Konzern tut. Sienix hatte begonnen die inneren Prozesse zu restrukturieren und dabei an die Stelle von großen Fachabteilungen kleine Crossfunctional-Teams gesetzt, die untereinander marktförmig verbunden waren und auch nach außen selbständig am Markt agierten. Was der Betriebsrat in diesem neuen Konstrukt feststellte waren vor allem zwei Dinge. Erstens: in einem Geflecht von selbständig miteinander interagierenden kleinen Einheiten hat ein Betriebsrat keinen Platz mehr. Historisch ist der Betriebsrat als Teil der Kommando- und Kontrollpyramide eines Unternehmenes entstanden. Er ist das interessenvertretende Gegenüber der operativen Unternehmensleitung. Wenn es diese zentrale Leitstelle nicht mehr gibt, dann verliert auch der Betriebsrat seinen Sinn, bzw. seine Art des Handelns funktioniert nicht mehr. Zweitens: die Mitarbeitenden bei Sienix – in der Regel Akademiker – entwickelten intrinsische Motivation an ihrer Arbeit. (Zur Erklärung: Intrinsische Motivation ist die Motivation, die aus der Sache selbst erwächst, den Gegensatz dazu bildet extrinsische Motivation. Wenn ich durch Gehalt und Freizeitausgleich motiviert werde etwas zu tun, was mir keinen Spass macht, handelt es sich um extrinsische Motivation.) Diese intrinsische Motivation führte dazu, dass ein ganzes Regelsystem extrinsischer Motivation, welches die innerbetrieblichen Prozesse regelte, ad absurdum geführt wurde und sich als dysfunktional unter den neuen Bedingungen erwies. Was das heisst lässt sich am Beispiel der Überstundenregelungen erklären. In deutschen Unternehmen, zumindest in größeren, müssen Überstunden durch den Betriebsrat genehmigt werden. Das ist eines der zentralen Druckmittel, mit denen der Betriebsrat seine Forderungen durchsetzen kann. Wenn nun aber Mitarbeitende mit ihrer Abteilung eigenständig am Markt agieren und ein eigenes Interesse entwickeln ihre Arbeit zu einem bestimmten Zeitpunkt fertig zu haben, dann greifen Verbote oder Erlaubnisse von Überstunden nicht mehr. Bei Sienix hatte das dazu geführt, dass Mitarbeitende am Wochenende die Zäune der Firma überstiegen um unerkannt an ihren Arbeitsplatz zu gelangen.
Was bedeutet das alles für uns, für die agile Bewegung? Wenn es so ist, dass sich agiles Arbeiten als zentraler Bestandteil eines neuen Produktionsparadigmas durchsetzt und wenn es so ist, dass dieses neue Paradigma die zentralen Mechanismen verändert, mit denen der soziale Organismus Betrieb bisher interpretiert und gesteuert wurde, dann tragen wir auch eine Veantwortung über die Konsequenzen unseres Handelns in einem umfassenderen Sinne nachzudenken als wir das bisher tun. Die Zeit der Unschuld ist vorbei! Der Sozialraum Betrieb hat in den letzten 150 Jahren ein umkämpfte Interpretion erfahren. Diese Interpretation ist immer temporär, sie drückt sich aus in den Regelungen und Institutionen, die die verschiedenen Interessen ausdrücken und schützen. So sind z.B. die Betriebsräte und ihr Handeln versuche die Interessen derjenigen im Betrieb zum Ausdruck zu bringen, die nicht qua Position oder Eigentum das Sagen haben. So sind viele soziale Regelungen, die uns oftmals als sperrig erscheinen, gesetzlicher Ausdruck der Interessen der strukturell Schwachen: Überstundenregelungen, Pausenregelungen, Auflagen für die räumliche Bedingungen, innerbetriebliche Genehmigunsverfahren.
Wenn Agilität und Leanmanagement zumindest partiell Command- and Controlmanagement durch Selbstorganisation und extrinsische durch intrinsische Motivation ersetzen, dann hebeln sie viele gewachsene Mechanismen aus, die in den neuen Strukturen nicht mehr funktionieren. Wenn dem so ist, müssen wir darüber nachdenken, was dann an die Stelle der alten Mechanismen tritt, wie wir den Sozialraum Betrieb gestalten wollen.

Die XPDays 2009 haben mich sehr beeindruckt. Eine Erkenntnis macht sich seitdem bei mir breit. Andreas Boes beschrieb sie in seinem Vortrag theoretisch, die anwesenden Kollegen von SAP aus praktischer Sicht. In einen Satz gebracht könnte man sagen: Mit der Verbindung von agilen Praktiken als Managementmethode im Operativen und Lean-Management im Großen setzt sich im Bereich der Softwareentwicklung eine Prozessrevolution durch, die in ihrer Bedeutung mit der industriellen Revolution vergleichbar ist. Andreas Boes sprach bei der Durchsetzung der Leanpraktiken im Management von einer zweiten industriellen Revolution. Die Kollegen von SAP sprachen davon, dass durch Leanmanagement – durch entsprechende makroskopische Steuerung und Kennzahlen – erst das wirkliche Potential von agilen Praktiken in ihrer Firma zur Geltung gebracht werde.

Wenn dem so ist, wenn wir als agile Praktiker eines der Herzstücke eines neuen Produktionsparadigmas ins Werk setzen, dann müssen wir auch darüber nachdenken, wie sich dieses Gefüge Produktionskultur insgesamt verändert und was für eine Verantwortung wird dabei haben.

Was ich damit meine, will ich am Beispiel einer kleinen Geschichte, einer wahren Begebenheit, erläutern. In den 90er Jahre gab es eine linke Fraktion der KIF (Konferenz der Informatik-Fachschaften) die JOINT (Jährliche Oldenburger Informatik-Tage) zu der ich mich zählte. Wir haben uns drei oder viermal an einem Wochenende versammelt, um über die Themen zu debattieren, die aus unserer Sicht auf der KIF zu kurz kamen. Zu einem dieser Treffen hatte sich ein Betriebsrat eines großen deutschen Elektronik- und Softwareherstellers, der im Raum einer süddeutschen Großstadt ein großes Werk betreibt – nennen wir den Hersteller Sienix -, eingeladen. Für uns war es sehr spannend zu hören, was sich in so einem großen Konzern tut. Sienix hatte begonnen die inneren Prozesse zu restrukturieren und dabei an die Stelle von großen Fachabteilungen kleine Crossfunctional-Teams gesetzt, die untereinander marktförmig verbunden waren und auch nach außen selbständig am Markt agierten. Was der Betriebsrat in diesem neuen Konstrukt feststellte waren vor allem zwei Dinge. Erstens: in einem Geflecht von selbständig miteinander interagierenden kleinen Einheiten hat ein Betriebsrat keinen Platz mehr. Historisch ist der Betriebsrat als Teil der Kommando- und Kontrollpyramide eines Unternehmenes entstanden. Er ist das interessenvertretende Gegenüber der operativen Unternehmensleitung. Wenn es dieses Gegenüber nicht mehr gibt, dann verliert auch der Betriebsrat seinen Sinn, bzw. seine Art des Handelns funktioniert nicht mehr. Zweitens: die Mitarbeitenden bei Sienix – in der Regel Akademiker – entwickelten intrinsische Motivation an ihrer Arbeit. (Zur Erklärung: Intrinsische Motivation ist die Motivation, die aus der Sache selbst erwächst, den Gegensatz dazu bildet extrinsische Motivation. Wenn ich durch Gehalt und Freizeitausgleich motiviert werde etwas zu tun, was mir keinen Spass macht, handelt es sich um extrinsische Motivation.) Diese intrinsische Motivation führte dazu, dass ein ganzes Regelsystem extrinsischer Motivation, welches die innerbetrieblichen Prozesse regelte, ad absurdum geführt wurde und sich als dysfunktional unter den neuen Bedingungen erwies. Was das heisst lässt sich am Beispiel der Überstundenregelungen erklären. In deutschen Unternehmen, zumindest in größeren, müssen Überstunden durch den Betriebsrat genehmigt werden. Das ist eines der zentralen Druckmittel, mit denen der Betriebsrat seine Forderungen durchsetzen kann. Wenn nun aber Mitarbeitende mit ihrer Abteilung eigenständig am Markt agieren und ein eigenes Interesse entwickeln ihre Arbeit zu einem bestimmten Zeitpunkt fertig zu haben, dann greifen Verbote oder Erlaubnisse von Überstunden nicht mehr. Bei Sienix hatte das dazu geführt, dass Mitarbeitende am Wochenende die Zäune der Firma überstiegen um unerkannt an ihren Arbeitsplatz zu gelangen.

Was bedeutet das alles für uns, für die agile Bewegung? Wenn es so ist, dass sich agiles Arbeiten als zentraler Bestandteil eines neuen Produktionsparadigmas durchsetzt und wenn es so ist, dass dieses neue Paradigma die zentralen Mechanismen verändert, mit denen der soziale Organismus Betrieb bisher interpretiert und gesteuert wurde, dann tragen wir auch eine Verantwortung, über die Konsequenzen unseres Handelns in einem umfassenderen Sinne nachzudenken als wir das bisher tun. Die Zeit der Unschuld ist vorbei! Der Sozialraum Betrieb hat in den letzten 150 Jahren umkämpfte Interpretationen erfahren. Diese Interpretationen sind immer temporär, sie drücken sich aus in den Regelungen und Institutionen, die die verschiedenen Interessen artikulieren und schützen. So sind z.B. die Betriebsräte und ihr Handeln Versuche die Interessen derjenigen im Betrieb zum Ausdruck zu bringen, die nicht qua Position oder Eigentum das Sagen haben. So sind viele soziale Regelungen, die uns oftmals als sperrig erscheinen, gesetzlicher Ausdruck der Interessen der strukturell Schwachen: Überstundenregelungen, Pausenregelungen, Auflagen für die räumliche Bedingungen, innerbetriebliche Genehmigungsverfahren.

Wenn Agilität und Leanmanagement zumindest partiell Command- and Controlmanagement durch Selbstorganisation und extrinsische durch intrinsische Motivation ersetzen, dann hebeln sie viele gewachsene Mechanismen aus, die in den neuen Strukturen nicht mehr funktionieren. Wenn dem so ist, müssen wir darüber nachdenken, was dann an die Stelle der alten Mechanismen tritt, wie wir den Sozialraum Betrieb gestalten wollen.