Aspektorientierte Unternehmensführung mit Soziokratie [OOP 2009]

Bei www.clean-code-developer.de beschäftige ich mich gerade mit Grundprinzipien professioneller Softwareentwicklung. Vielleicht ist das der Grund, warum Soziokratie in mir eine Saite zum Schwingen gebracht hat. Sie sieht für mich nämlich ebenfalls wie ein Grundprinzip aus. Nicht für die Entwicklung von Software, sondern für die Entwicklung von Organisationen die Software herstellen.

In meinem vorhergehenden Posting habe ich erklärt, warum ich die Softwarebranche für prädestiniert halte, sich die Soziokratie einmal näher anzusehen. Wir sind schon vertraut mit zwei Kernkonzepten der Soziokratischen Kreismethode (SKM): Lernschleife und Rekursion. Und darüber hinaus sind wir prädestiniert zu verstehen, was die Einführung von Soziokratie mit einem Unternehmen macht. Sie führt zu einer Separation of Concerns. Soziokratie ist Unternehmungsführung aspektorientiert.

In unserer Branche kann ich das so einfach schreiben. Was genau ich damit meine, verstehen Sie wahrscheinlich noch nicht. Aber das macht nichts. Zumindest gewisse Bilder entstehen in Ihrem Kopf, weil diese Begriffe in der Softwarebranche etabliert sind. Und das ist, was es aus meiner Sicht einfacher macht, SKM in der Softwarebranche zu studieren oder gar einzuführen. Wir sind vorbereitet.

Schon im brand eins Artikel, der für mich Anlass zur Beschäftigung mit der SKM war, wird deutlich, dass Soziokratie bei allen Vorteilen und einer grundsätzlichen Einfachheit doch einen Nachteil hat: sie lässt sich irgendwie schwer erklären. So finden zumindest auch viele Soziokratieexperten. Und ich stimme durchaus zu. Eigentlich ist SKM simpel - doch beim Erklären hakt es immer wieder.

Warum ist das so? Da lese ich die Literatur zu SKM, die das Soziokratische Zentrum mit Übersetzungsmühe zur Verfügung gestellt hat; die Liste der Grundprinzipien ist kurz; die Bilder sind einfach; die Beispiele bemüht lebensnah. Und doch... etwas hakt. Das merke ich auch, wenn ich mit Isabell Dierkes, der Vertreterin des deutschen Soziokratischen Zentrums skype. Einerseits verstehe ich sie - und andererseits laufen wir auch immer wieder in Missverständnisse.

Warum ist das so? Ich glaube, zumindest eine Ursache gefunden zu haben. Die Soziokratie setzt ein gewisses Verständnis davon voraus, wie Unternehmen funktionieren. Unglücklicherweise ist dieses Verständnis jedoch viel weniger verbreitet als angenommen. Deshalb stelle ich Soziokratie in anderer Weise dar, als die "kanonischen Dokumente" es tun. Ich fange damit an, was die Soziokratie als selbstverständlich voraussetzt.

Führung ist orthogonal

Lassen Sie mich versuchen, den "Ort für Soziokratie" im Unternehmen mit einer kleinen Beispielfirma zu illustrieren: Ein kleines Softwareunternehmen - die SoftWunder GmbH - hat einen Geschäftsführer, ein Entwicklungsteam, Vertrieb und ein Sekretariat. Das Entwicklungsteam arbeitet schon mit im "softwaretechnischen Kreisprozess" Scrum.

Wenn uns der Geschäftsführer und Inhaber sein Unternehmen vorstellen wollte, würde er sicherlich in einer hübschen Powerpoint-Präsentation auch ein Organigramm wie das Folgende zeigen:

Es beschreibt die groben Verantwortungsbereiche im Unternehmen, sozusagen seine Komponenten. Wenn wir hineinzoomen, sehen wir die Rollen, die es mit Leben füllen.

So ähnlich könnte das Personal von SoftWunder heute organisiert sein. Die Belegschaft ist nicht groß, so dass die Hierarchie flach sein kann. Zum Beispiel braucht das Unternehmen keine Sekretariatsleitung und die Architektur entwirft das Entwicklungsteam gemeinsam.

Auf Details im Organigramm, die Sie vielleicht anders erwartet hätten, kommt es auch nicht an. Wichtig ist nicht, was im Organigramm fehlt, sondern was das Organigramm verbirgt! Es verbirgt oder kaschiert nämlich etwas, das eigentlich deutlich sichtbar sein müsste.

Das Organigramm macht denselben "Fehler", den dieser Code für Sie ganz offensichtlich macht:

KundenListe SucheKundenNachPLZ(string plz)
{
    logger.Write("Suche Kunden nach PLZ: {0}", plz);

    if (cache.ContainsForKey(plz))
        return cache[plz];

    KundenListe liste = new KundenListe();

    SqlConnection conn = new SqlConnection("...");
    ...

    return liste;
}

Wo liegt das Problem in diesem Code? Er vermischt unterschiedliche Aspekte! Logging, Caching und Datenbeschaffung sind unterschiedliche Aspekte der Lösung. Indem sie eine Methode vermischt, wird der Code schwer lesbar und weniger evolvierbar.

Separation of Concerns, Aspekte oder Belange klar voneinander zu trennen, ist daher ein Grundprinzip guter Softwareentwicklung. Die Aspektorientierte Programmierung (AOP) hat dafür Werkzeuge entwickelt wie zum Beispiel PostSharp. Damit ließe sich der Code klarer formulieren, z.B. so:

[Log("Suche Kunden nach PLZ {0}", "plz")]
[Cache("plz")]
KundenListe SucheKundenNachPLZ(string plz)
{
    KundenListe liste = new KundenListe();

    SqlConnection conn = new SqlConnection("...");
    ...

    return liste;
}

Jetzt steht in der Methode ihr eigentlicher Zweck im Vordergrund: die Beschaffung von Daten. Die Aspekte Caching und Logging sind an sie über Attribute "angeheftet", die von einem AOP-Framework zur Compilezeit oder Laufzeit so eingewoben werden, dass sie wie im ursprünglichen Code ihren Dienst tun.

Das konzeptionelle Verhältnis zwischen den Aspekten, ihre Orthogonalität, mittels AOP einen passenden Ausdruck gefunden. Sie springt uns jetzt ins Auge. Wir verstehen den Code leichter, wir können ihn einfacher erweitern, weil die logische Entkopplung des Aspekte nun auch ihre Entsprechung in der Form hat.

Jetzt zurück zu SoftWunder:  Was bedeutet das nun aber für das Organigramm?

Wie gesagt, das Organigramm vermischt genauso wie der ursprüngliche Codeentwurf. Es vermischt ganz unterschiedliche Aspekte eines Unternehmens. Das typische Ogranigramm vermischt operatives Geschäft und Führung dieses Geschäfts. Es trennt nicht deutlich zwischen dem Tagesgeschäft und Management. Es trennt nicht zwischen der Organisation und den Prozessen, die produzieren und verkaufen und einfach den Laden schmeißen - und der Entwicklung all dessen.

Geschäftsführer Friedrich (oder in größeren Unternehmen der Vorstand und das mittlere Management) hat eine fundamental andere Aufgabe als Entwicklerin Rita oder Außendienstler Rolf. Friedrich denkt über das Unternehmen nach, er trifft Grundsatzentscheidungen, er definiert Geschäftsfelder und Grundsätze der Arbeit, er bestimmt das Organigramm. Rita und Rolf hingegen führen nur aus. Sie sind zwar auch verantwortlich in ihren Rollen, aber diese Verantwortlichkeit bezieht sich auf Prozesse des Tagesgeschäftes. Sie arbeiten im Konkreten, Friedrich arbeitet sozusagen auf der Metaebene.

Diese fundamental unterschiedlichen Rollen - Arbeiten im Konkreten und Arbeiten auf der Metaebene, Arbeiten in der Organisation vs Organisationsentwicklung - mache ich mal mit Farben im Organigramm deutlich. Dann sehen Sie die Aspekte schon etwas besser:

Geschäftsführer Friedrich sowie Entwickler, Außendienstler und Sekretariat haben klar getrennte Verantwortungen. Sie gehören eindeutig unterschiedlichen Aspekten an. Scrum Master und Vertriebsleiter jedoch sitzen quasi zwischen den Stühlen. Einerseits sind sie im Tagesgeschäft involviert, andererseits sind sie auch angehalten, darüber hinaus zu denken. Von ihnen erwartet der Geschäftsführer Weitblick und auch (moderate) Eingriffe in die unter ihnen "hängenden" Organisationsteile.

Hört sich alles selbstverständlich an, oder? So ist das halt mit Unternehmen. Oder allgemein: So ist das halt mit organisierten sozialen Systemen. Früher oder später, gewollt oder nicht nehmen sie eine hierarchische Form an. Das ist nicht nur in Unternehmen so. Auch Vereine oder die Politik sind so organisiert. Bestrebungen um flache Hierarchien ändern daran nichts.

Und all diesen Organisationen ist gemein, dass sie in ihren Selbstdarstellungen die Aspekte Operation und Reflektion nicht klar trennen. Das tun sie nicht, weil sie es selbst nicht anders denken. In ihrem Denken verschwimmen die Aspekte, weil die Aspekte mit den zugehörigen Rollen in Personen immer wieder notwendig zusammenfließen. Operieren und Reflektieren geschieht gerade in kleinen Unternehmen zwangsläufig oft in Personalunion.

An diesem Faktum ist auch nichts auszusetzen. Damit aber das Selbstbild, das Denken kontamieren zu lassen, das ist kontraproduktiv! Professionelle Softwareentwicklung braucht klare Prinzipien. Professionelle Unternehmenungen brauchen klare Prinzipien. Wenn drüben Separation of Concerns eine Tugend ist, warum dann also nicht auch hüben?

Größere Organisationen sind da klarer. Der Begriff Management bezeichnet eigentlich den Aspekt Organisationsentwicklung/Reflektion. Im Organigramm sind dann einige Hierarchieebenen rein blau - wenn denn das Organigramm überhaupt farbkodiert wäre. Ist es aber auch in diesen Organisationen nicht. Vielleicht ist es da nicht verwunderlich, dass "die Management-Kaste" in den letzten Jahren sich ins Kreuzfeuer manövriert hat. Vielleicht hat die Krise der Mangements damit zu tun, dass das Denken in den Organisationen nicht so klar ist, wie es sein sollte? Nun, darüber zu sinnen, überlasse ich Ihnen bei einem Bier... ;-)

Hier möchte ich das Organisationsbild im Sinne der Aspektorientierung verbessern. Ich wende einfach mal die Darstellung der Software auf die SoftWunder GmbH an:

Führung ist orthogonal zum Tagesgeschäft. Führung kümmert sich um die Organisation, nicht um die Erledigung eines Auftrages. Sie ist insofern nicht funktional! Führung ist kein Feature der Dienstleistungen eines Unternehmens.

Wenn Sie bei einem Pizza Bringdienst nicht nur à la cart bestellen, sondern auch eigene Pizzavariationen kreieren können, dann ist das ein Feature des Pizza Bringdienstes. Er erfüllt damit einen funktionalen Wunsch der Kundschaft. Wenn die "custom Pizza" auch noch superschnell kommt, dann ist das eine nicht funktionale Eigenschaft des Bringdienstes. Denn auch wenn sie 2 Stunden warten müssten, wäre Ihr funktionaler Wunsch nach einer "custom Pizza" immer noch erfüllt.

Aber woher kommt die hohe Geschwindigkeit? Sie ist resultat guter Unternehmensführung. Denn sie ist es, die die Organisation des Tagesgeschäftes definiert, die Prozesse bestimmt, die Mitarbeiter motiviert, so dass am Ende alle und alles reibungslos läuft.

Führung ist insofern sogar in doppelter Hinsicht nicht funktional: zum Einen ist sie selbst kein Feature des Unternehmens, zum anderen wirkt sie maßgeblich auf die nicht funktionalen Eigenschaften der Dienstleistungsfeatures des Unternehmens ein.

Ich denke, das ist ein weiterer Grund, warum Führung verdient, viel expliziter dargestellt zu werden. SoftWunder täte sich einen Gefallen, wenn es sein Organigramm wie folgt zeichnen würde:

Dem Betrachter wäre sofort klar, wer in die Entscheidungen über das Unternehmen eingebunden wäre. Der Betrachter wüsste sofort, dass überhaupt Reflektion stattfindet, da dieser Aspekt erkannt und explizit dargestellt wurde.

Soziokratie will explizite Führung

So, nach diesem Ausflug ins Grundsätzliche wieder zurück zur Soziokratie. Wenn ich jetzt sage, dass Soziokratie aspektorientierte Unternehmensführung ist, dann verstehen Sie was ich meine. Soziokratie ist eine Methode der Unternehmensführung. Und Soziokratie führt explizit, d.h. durch Ablösung des Aspekts "Führung" vom operativen Geschäft.

 

Die soziokratische Führung habe ich in diesem Bild in der kanonischen Form dargestellt. Die SKM spricht von einer "Kreisorganisation" der Führung, zeichnet aber Dreiecke. Wenn Sie das merkwürdig finden, dann sind Sie nicht allein ;-) Auch darin sehe ich ein Problem der Soziokratie, sich verständlich zu machen; sie ist mehr oder weniger subtil inkongruent in ihren Aussagen. Ich werde im Weiteren daher die Dreiecke nicht verwenden, selbst wenn ich mich damit gegen "die Weisen aus dem Holland" stelle ;-) (Die Geburtsstätte der Soziokratie ist in den Niederlanden, wo auch das soziokratische Hauptzentrum seinen Sitz hat.)

Das wesentliche Problem der Soziokratie sehe ich vielmehr - da bin ich mir nun ganz sicher - darin, dass sie nicht die Orthogonalität von Führung klar macht. Interessenten haben deshalb immer wieder das grundsätzliche Verständnisproblem, wo denn Soziokratie im Unternehmen zu verorten sei.

Darstellungen wie diese aus "Die Soziokratische Kreisorganisationsmethode" machen es da auch nicht besser:

Indem sie die soziokratische Kreishierarchie in ein bestehendes Organigramm einblendet, will SKM zwar einen wichtigen Punkt rüberbringen - steigert aber letztlich die Verwirrung. Denn so oktroiert SKM einer bestehenden Führung, die ja schon und noch im Organigramm steckt, eine weitere Führung auf. Das will sie natürlich nicht, sie tut es aber doch. Das ist tragisch.

Die aspektorientierte Darstellung vermeidet diese Verwirrung, indem sie zuerst und ganz allgemein Führung orthogonal zum operativen Geschäft zeigt - und dann (!) die traditionelle Führung durch die soziokratische ersetzt.

Führung in dieser Weise orthogonal zu denken und zu zeigen hat zwei Vorteile für die Soziokratie:

1. Es wird ganz klar, was Soziokratie will: führen, nicht operieren. Soziokratie hat den Anspruch, die bisherige Führungsorganisation durch etwas Neues zu ersetzen. Was das ist und wie das funktioniert werde ich in zukünftigen Postings beschreiben.
2. Es wird ganz klar, dass eine Organisation Soziokratie einführen kann, ohne zwangsläufig an der operativen (!) Organisation etwas zu verändern. Das senkt die Einstiegshürde. Denn woimmer innerhalb eines Organigramms Operation und Reflektion vermischt sind, können sie im ersten Schritt entkoppelt werden, um dann im zweiten Schritt die "herauspreparierte" Führung durch Soziokratie zu ersetzen.

Soziokratie ist also eine Führungsmethode, die auf Organisationen oder Teilorganisationen quasi beliebiger Größe angewandt werden kann. Bei SoftWunder könnte zum Beispiel nur der Vertrieb zukünftig soziokratisch geführt werden (soweit das unterhalb einer traditionellen Geschäftsführung möglich ist). Ist das erfolgreich, kann Soziokratie horizontal in anderen Abteilungen eingeführt werden oder eben auch vertikal, d.h. als Ersatz der kompletten bisherigen Führung. Soziokratische Führung kann in einem traditionellen Organisationsbaum von unten nach oben oder von oben nach unten "wachsen". Sie ist somit rekursiv. Ihre Bilder selbstähnlich.

Verstehen Sie jetzt, warum ich glaube, dass Soziokratie es in der Softwarebranche einfachener haben kann als in anderen? Aspekte, Orthogonalität, Separation of Concerns, Rekursion: das sind Begriffe, mit denen Sie täglich umgehen. Wir verstehen sie. Und ohne sie halte ich Soziokratie für viel schwieriger als notwendig verständlich.

Es ist also kein Wunder, wenn die Soziokratie-Proponenten bisher Schwierigkeiten mit ihrer Frohbotschaft hatten. Handwerksunternehmen oder einem Handelshaus Soziokratie SKM zu erklären, ohne solche begriffliche und darstellerische Schärfe, kann nur zu Missverständnissen führen.

Aber vielleicht nützen ja diese Gedanken hier, um das Konzept allgemein einfacher erklärbar zu machen und seine Verbreitung zu fördern. Ich glaube, dass SKM ein guter Schritt voran zu nachhaltiger Unternehmensführung ist.

Ausblick

Da nun die Positionierung der SKM klar ist, konzentriere ich mich beim nächsten Soziokratie-Posting auf die Wechselwirkung von SKM-Führung mit dem operativen Geschäft und der Organisation der soziokratischen "Kreis-Dreicke".

Agile Führung - Mit Soziokratie über agile Softwareentwicklung hinausgehen [OOP 2009]

Agile Softwareentwicklung ist die Antwort auf eine unvorhersehbare Umwelt. Wer ein Produkt herstellen will, dessen Anforderungen nur unvollständig bekannt sind und sich auch noch häufig ändern, der muss einfach anders vorgehen als jemand, der etwas klar Umrissenes und Stabiles produzieren soll.

Agile Vorgehensmodelle als optimale Lösungen

Im Kern der agilen Vorgehensmodelle steht deshalb "das lernende Team":

• Agile Teams bemühen sich um Nähe zum Kunden. Sie suchen sein unmittelbares und häufiges Feedback zu ihrem Produkt, der Software.
• Agile Teams setzen Feedback möglichst zügig und auf den Punkt um. Änderungen und Neuerungen werden unter ständiger Qualitätskontrolle implementiert.
• Agile Teams liefern in kurzen Abständen und verlässlich immer wieder an den Kunden. Sie setzen ihr Produkt seiner Prüfung aus.

Das "lernende Team" dreht sich also in einer nimmer endenden Schleife von Feedback - Implementation - Release. Oder allgemeiner ausgedrückt: Das "lernende Team" beobachtet seine Umwelt, es misst sie. Dann reflektiert es über diese Wahrnehmungen und passt sich bzw. sein "Modell der Umwelt" intern an. Schließlich handelt es wieder  in der Umwelt und überprüft damit die Stimmigkeit seines "Modells".

Lernen findet dabei insbesondere statt, wenn die Wahrnehmung nicht der Erwartung entspricht. Fehler sind die wahren Informationsquellen für "lernende Teams". Sie sind die "Unterschiede, die einen Unterschied machen" (Gregory Bateson).

Scrum ist hier für mich das minimalistische Vorgehensmodell in diesem Sinn. Die Lernschleife ist darin institutionalisiert. Alles dreht sich in Scrum im wahrsten Sinne des Wortes darum, das Richtige zu tun (die am höchsten priorisierten Backlog-Items implementieren), bald das Arbeitsergebnis in die Welt zu entlassen (am Ende eines kurzen Sprints) und dann Feedback über die Qualität der Arbeit einzuholen (über neue Backlog-Items).

Die zunehmende Verbreitung von Scrum gibt diesem Vorgehensmodell Recht. Es definiert mit seinen Rollen und Prinzipien eine Organisation und einen Prozess zur Bewältigung des Problems "Produktentwicklung in unvorhersehbarer Umwelt". Agile Vorgehensmodelle scheinen nach 60 Jahren Softwareentwicklung die optimale Lösung für diese konkrete Situation.

Optimale Lösungen gibt es nicht!

Für das konkrete Problem "Softwareentwicklung" ist Agilität im Allgemeinen oder Scrum im Speziellen die optimale Lösung. Zumindest im Augenblick.

Wie lange können wir aber sicher sein, dass das so ist? Wie können wir Lücken oder Unvollkommenheiten in der Anwendung eines Vorgehensmodell entdecken und korrigieren? Kann es überhaupt optimale Lösungen geben, also solche, die eben immer optimal sind? Kaum. Alle Vorschläge für ein Vorgehen bei der Softwareentwicklung sind eben nur Vorschläge. Sie definieren Ausgangspunkte für die eigene Suche nach der für die eigene Situation besten Lösung.

Und auch diese eigene Lösung ist nicht dauerhaft optimal. Optimal in einem statischen Sinn, ist nichts. Alle Vorgehensmodelle bzw. ihre Implementationen im eigenen Team sind nur vorläufig. Denn nicht nur Kundenanforderungen ändern sich ständig, sondern auch die allgemeine Situation, in der entwickelt wird. Veränderungen in der Teamgröße, neue Technologien oder Firmenfusionen können nahelegen, am aktuellen Vorgehen etwas zu ändern.

So ist es nicht nur in der Softwareentwicklung. Die Organisation eines Unternehmens insgesamt und seiner Prozesse sind ganz allgemein gesprochen nie optimal. Sie hinken immer irgendwie der Realität hinterher. Finanzkrise, Veränderungen der Wettbewerbssituation oder des Käuferverhaltens, neue Materialien und Technologien... all das und viel mehr kann ständig eine Veränderung der Unternehmensorganisation nahelegen. Es könnte nötig sein, mehr Menschen zu beschäftigen oder weniger. Es könnte nötig sein, mehr Marketing oder weniger zu betreiben. Oder vielleicht sollten Abteilungen zusammengelegt oder getrennt werden? Wie ist es mit der Entwicklung neuer Produkte? Oder lieber das Produktportfolio verkleinern? Expandieren? Fusionieren?

Ständig lautet die allgemeine Frage in einem Unternehmen: Wie sieht die beste Organisation, wie sehen die optimalen Prozesse aus?

Die Frage von Scrum ist allerdings: Wie sieht die optimale Organisation des Produktes aus und was sollte als nächstes getan werden, um maximalen Kundennutzen zu stiften? Die Organisation des Teams hingegen ist fix. Sie wird ja durch Scrum vorgegeben.

Auf einer allgemeinen Ebene ist genau das aber anders. Bei gegebenem Unternehmenszweck - Gewinnerzielung mit bestimmten Produkten - ist die geeignete Organisation der Mitarbeiter in Bezug auf diesen Zweck nicht fix. Sie gilt es vielmehr immer wieder neu zu finden.

Lernende Organisationen

Mit Scrum lernt ein Team, für den Kunden passende Software zu produzieren.

Wie lernt aber ein Unternehmen, die passende Organisation zur Herstellung seiner Produkte aufzubauen? Liegt die auf der Hand? Es scheint so, denn wer wüsste nicht, dass ein Unternehmen Buchhaltung, Produktion, Lager, Vertrieb, Marketing, Management, Sekretariat usw. braucht?

Das ist natürlich nicht falsch. Je nach Branche braucht ein Unternehmen diese grundsätzlichen Verantwortungsbereiche im Sinne einer Arbeitsteilung. Trotzdem ist damit nicht viel über die Organisation eines Unternehmens gesagt. Der Teufel steckt im Detail! Denn nicht dass (!) es Lager, Vertrieb, Produktion usw. gibt ist problematisch, sondern wie diese Verantwortungsbereiche miteinander kommunizieren und wiederum intern organisiert sind. Arbeiten sie direkt und reibungslos zusammen? Oder ist das Verhältnis eher kühl und bürokratisch? Gibt es lange Dienstwege, die einzuhalten sind? Findet man nur schwer Verantwortliche im Falle von Kundenbeschwerden?

Im Detail ist es eben nicht leicht, für einen Unternehmenszweck die am besten passende Organisation mit optimalen Prozessen zu finden. Und je größer das Unternehmen, je komplizierter die Produkte, je volatiler der Markt, desto schwieriger wird es.

Das ultimative Ziel jedes Unternehmens ist es nun, nachhaltig zu agieren. Es will möglichst lange leben und Gewinne einfahren. Dazu muss es effizient sein, denn nur dann stimmt die Marge. Dazu muss es aber auch flexibel sein, denn nur dann kann es unter wechselnden Anforderungen effizient produzieren.

Solche Nachhaltigkeit setzt gut passende Organisation voraus. Ein nachhaltiges Unternehmen muss daher daran interessiert sein, seine Organisation und seine Prozesse immer nah am Optimum zu haben. Genauso wie ein Scrum Team ein Interesse daran hat, seine Software nahe am Optimum der Kundenzufriedenheit zu haben. Wie kann ein Unternehmen das schaffen?

Das Zauberwort heißt auch hier: Lernen. Das Unternehmen muss ein lernendes Unternehmen werden. Peter Senge hat dazu schon vor Jahren ein wegweisendes Buch geschrieben: "Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation" - leider bleibt es jedoch einige Antworten zur Umsetzung des Lernens schuldig.

Aber vielleicht gibt es einen ähnlich minimalistischen Ansatz für das Unternehmenslernen wie Scrum es für die Softwareentwicklung ist. Denn wo gelernt werden soll, da ist vor allem eines wichtig: die Lernschleife. Wahrnehmen, verarbeiten, handeln, wahrnehmen, verarbeiten, handeln usw. usf. nimmermüde.

Soziokratie als Organisationsevolutionsmethode

Scrum hat für mich viel Appeal in seiner grundsätzlichen Simplizität. Es verkörpert für mich die Essenz lernender Produktion. Allerdings findet das Lernen hier vor allem auf der konkreten Ebene, der Produktebene statt. In Lernschleifen soll das Produkt dem Kundenwunsch angenähert werden.

Für Unternehmen liegt das Problem hingegen im Allgemeinen und auf der Meta-Ebene. Sie sind nicht nur daran interessiert, dass ihre Teile (z.B. ein Team) lernen, sondern sie müssen als Ganzes lernen. Sie müssen lernen, aus welchen Teilen sie z.B. überhaupt bestehen sollten.

Das findet heute meist aber nur relativ dumpf oder vereinzelt statt. Eine Methode, um ein Unternehmen systematisch lernend zu gestalten, wird nicht gelehrt, wie es scheint. Wenn also Scrum in einem Softwareunternehmen zum Einsatz kommt, dann arbeitet zwar ein Team lernend - doch die Organisation drumherum ist deshalb noch lange nicht lernend aufgestellt. (Ja, auch wenn diese Organisation sich irgendwann verändert hat, indem sie Scrum einführte. Nicht systematisch lernende Organisationen leisten auch Gutes. Aber das könnte ja noch mehr werden, oder? Und in anderen Unternehmen könnte die Entwicklung zu mehr Organisationsqualität und damit Nachhaltig überhaupt ersteinmal beginnen.)

Neulich habe ich nun einen sehr interessanten Artikel (ab Ende Jan 09 im Volltext online) in der brand eins gelesen. Dort wurde eine Methode beschrieben, die mir so minimal wie Scrum erscheint, aber eben genau das Lernen in Unternehmen systematisch erzeugt, von dem schon Peter Senge geschrieben hat. Diese Methode schien mir einerseits im Geiste von Scrum, andererseits aber dazu komplementär. Scrum ist eine Methode mit einer definierten Organisation für das operative Geschäft. Doch die in der brand eins beschriebene Methode zielt auf die Entwicklung eben solcher Organisation ab.

Die Soziokratische Kreismethode (SKM oder auch kurz Soziokratie) ist insofern eine Methode zur Unternehmensführung. Und zwar eine Unternehmensführung, die bewusst lernend stattfindet, d.h. in deren Kern eine Lernschleife aus Messen, "Leiten" und Durchführen steht.

Das hat mich sehr beeindruckt. Vor allem, weil es nicht nur eine Theorie ist, sondern in der Praxis angewandt wird. In Holland können sich Unternehmen unter soziokratischer Führung sogar von der Pflicht zum Betriebsrat befreien lassen. Soziokratie ist dort also schon länger wohlwollend sogar auf dem Radar des Gesetzgebers.

Ansonsten gibt es mehrere soziokratische Zentren, die über die Methode informieren. Das deutsche ist unter www.soziokratie.org zu erreichen. Dort gibt es auch einiges zum Thema zu lesen. Aber ich werde versuchen, das Wesentliche der SKM in einigen Blog-Artikeln hier herauszudestillieren. Ich denke, das lohnt sich, denn wie die aktuelle Finanzkrise zeigt, findet nicht nur Softwareentwicklung in einer unvorhersehbaren Umwelt statt. Die Umwelt für jedes Unternehmen ist heute so unvorhersehbar, dass es angezeigt scheint, nun endlich mit der "lernenden Organisation" Ernst zu machen. Und wenn die SKM hält, was sie verspricht, dann hat sie das Zeug dazu, für Unternehmen als Ganzes das zu werden, was Scrum für die Softwareentwicklung als Teil solchen Ganzen ist. Es geht also um nicht weniger als eine Methode der agilen Führung von Unternehmen.

Clean Code Developer - Ein Weg zu mehr Professionalität [OOP 2009]

Softwareentwicklung ist zwar eine Profession - aber läuft sie auch immer professionell? Ich glaube - oder besser: Stefan Lieser und ich glauben, dass das leider nicht der Fall ist. Die Gründe dafür sind vielfältig.

Da ist zum einen die Jugend unserer Branche: in nur 60 Jahren hat sich bisher kaum ein Konsens herausbilden können, was denn nun wirklich professionelle Softwareentwicklung ausmacht.

Da ist zum anderen der ewige Fachkräfte-Notstand: weil soviele Softwareentwickler immer noch oder immer wieder fehlen, gibt es keine einheitliche Ausbildung. Unternehmen stellen ein, wer halt irgendwie demonstrieren kann, dass er es mit der Softwareentwicklung ernst meint.-

Und schließlich brodelt es bei den Technologien ständig so, dass es wichtiger scheint, etwas Neues zu lernen, als sich auf etwas als Branche einzuschießen. Objektorientierung und Agilität sind zwar gewisse Konstanten, doch von einem Konsens im Sinne von "So tut man es und nicht anders!" sind wir dennoch weit entfernt.

Wir meinen nun, dass solcher Konsensmangel bei allem Verständnis für seine Ursachen, immer kontraproduktiver wird. Denn da der Fachkräftemangel wieder einmal nach einer Zeit der Ruhe ganz offensichtlich ist, stellt sich ja auch die Frage ganz dringlich: Wer ist denn ein guter, ein wirklich professioneller Softwareentwickler?

Dazu kommt die Erkenntnis, dass Ausbildungen auf einer Plattform wie .NET oder Java oder in einem Paradigma wie der Objektorientierung eben nicht zwangsläufig auch zu gutem Code oder hoher Produktivität führen.

Gelegentlich der Lektüre des Buches "Clean Code" von Robert C. Martin sind Stefan und ich deshalb auf die Idee gekommen, es als Ausgangspunkt für eine Bewegung für mehr Professionalität zu machen.

Die dortigen Empfehlungen sowie einige andere scheinen uns so grundlegend, dass sie konsensfähig sind/sein könnten. Wir trauen uns also einfach mal, eine Reihe von Prinzipien, Regeln und Praktiken zusammenzustellen, von denen wir meinen, alle - ja, alle! - Softwareentwickler können und sollen sie beherzigen. (Naja, mit Ausnahme des einen oder anderen Prinzips, das doch eher mit der Objektorientierung zu tun hat. Dem mag dann ein C-Entwickler nicht folgen. Aber das ist unerheblich.)

Den, der diese Prinzipien, Regeln und Praktiken fleißig befolgt in seiner Arbeit, den nennen wir dann Clean Code Developer (CCD) als Hommagè an Roberts Buch.

Und was gehört zu unserem Kanon? www.clean-code-developer.de gibt Auskunft. Dort haben wir in den vergangenen Wochen unser Wertesystem, wie wir es nennen, zusammengetragen. Eine Übersicht zeigt diese Seite: http://www.clean-code-developer.de/wiki/CcdWertesystem. Detailseiten führen dann aus, was wir unter den einzelnen "Werten" verstehen.

Der Trick dabei: Wir haben unser Wertesystem in "Module" verpackt. Ganz nach Manier der Budo-Sportarten definieren wir Grade, die unterschiedliche Entwicklungsstufen bei der Einarbeitung in das Wertesystem beschreiben. Damit wollen wir keine besser-schlechter, schlauer-dummer Hierarchie aufstellen, sondern nur im Sinne iterativen Lernens "Meilensteine" setzen. Dass einer das ganze Wertesystem von jetzt auf gleich einfach beherzigen kann, glauben wir nicht. Also lieber Schritt für Schritt vorgehen. Ein Grad nach dem anderen. Ganz locker und unbürokratisch. Niemand muss dafür ein Fomular ausfüllen oder eine Prüfung machen. Wir appellieren an die Ehrlichkeit des Adepten. Zumindest sie sollte ja auch zur Professionalität gehören ;-)

Wer sich solcher Mühe unterzieht, soll natürlich auch stolz darauf sein. Deshalb haben wir uns - auch angeregt durch Robert C. Martin - überlegt, dass wir Armbänder tragen könnten. Sie sind in der Form Ausdruck des Willens zu mehr Professionalität und in der Farbe ein Hinweis auf den Grad, an dem ihr Träger arbeitet. Eine dezentes wie auch effektives Berufsabzeichen, wie wir finden. Aber: auch das ist kein Zwang, sondern nur Angebot. Wir fänden es allerdings toll, wenn wir bei den nächsten Entwicklerveranstaltungen eine wachsende Zahl von CCD-Armbandträgern träfen :-) (Für eine Kostenerstattung schicken wir Interessenten gern ein Armband zu; einfach hier den Bestellknopf drücken: http://www.clean-code-developer.de/wiki/CcdArmband)

Wie gesagt: Das CCD-Wertesystem ist nur ein Vorschlag. Wir hauen einfach mal einen Pflock in den Boden. Während Microsoft über zukünftige Technologien sinniert und die Ausbildungen in den vergangenen Technologien verharren, sammeln wir einfach mal, was wir für zeitlos und unverbrüchlich halten. Ganz technologieneutral und paradigmenfern. Wer meint, dass wir dabei etwas vergessen hätten oder zuviel des Guten täten, der kann das mit uns gern diskutieren. Dafür haben wir ein Clean Code Developer Forum aufgesetzt: http://groups.google.de/group/clean-code-developer.

Nach den Wochen der Ausarbeitung bin ich nun ganz gespannt, wie die Community unsere Idee aufnimmt. Gebt uns Feedback!

Aber noch besser: Fangt mal mit dem roten Grad an. Ist gar nicht schwer. Das kann eigentlich jeder .NET-Entwickler aus dem Stand. Vielleicht ist so ein Armband ja auch ein Mittel, um dem Chef mal zu vermitteln, dass zur Softwareentwicklung mehr gehört, als Kundenanforderungen irgendwie zu erfüllen?

PS: Wer nach Durchsicht des CCD-Wertesystems einen Vorschlag zur Verbesserung hat oder eine Frage oder einfach nur seine Meinung äußern möchte, der möge das am besten gleich im CCD-Diskussionsforum tun. Da ist mehr Raum, um wirklich darüber zu sprechen. Mit den Kommentaren hier ist das eher hinderlich und leistet am Ende einer Verletzung des DRY-Prinzips Vorschub ;-)

Twitter - Nur Versuch macht kluch [OOP 2009]

Früher war Brief. Dann war Telefon. Aber noch mein Vater hatte immer einen Blick darauf, dass niemand im Haushalt zu lange telefonierte. Dann Handy, SMS, Email - oder war die Reihenfolge anders? Schließlich Instant Messaging (IM), Blog, Wiki, XING. Alles habe ich bisher mitgemacht. Manches früher, manches später. Mit allem fühle ich mich wohl. Aber Twitter? Muss das sein?

Keine Ahnung. Aber es heißt ja, dass "die jungen Leute heute" inzwischen schon Email für "old fashioned" halten. Wenn ich also nicht frühvergreisen will... dann muss ich mich wohl mal mit Twitter beschäftigen. Eine Gelegenheit, bei der ich das Motto vom "lebenslangen Lernen" endlich mal gegen meine Neigung oder ein Verständnis für den unmittelbaren Nutzen leben kann.

Also Twitter: Ein Dienst, bei dem "man" mit kurzen Nachrichten (s)einen "Zustand" veröffentlichen kann. Andere können diese Zustandsmeldungen abonnieren, "man" kann die Zustände anderer abonnieren. Hm... Wo ist der Unterschied zu anderen Medien?

Twitter ist ein asynchrones Medium. Wer publiziert, erwartet keine Antwort, ja noch nicht einmal einen Leser. Insofern ist Twittern Monologisieren. Ohne konkreten Adressaten ähnelt Twitter einem Blog. Es ist eine Broadcasting-Plattform.

Die Kürze der Nachrichten jedoch macht es ähnlich SMS oder IM. "Romane" lassen sich mit Twitter nicht veröffentlichen - zumindest nicht in der traditionellen Form. (Allerdings: Ein Autor könnte eine Figur erschaffen, der er ein Twitter-Konto gibt. Der "Roman" ließe sich dann als Folge von Twitter-Updates spinnen, in denen die Figur ihre Erlebnisse protokolliert. Bram Stokers "Dracula" war seinerzeit hochmodern, weil die Figuren leading edge technology benutzten, um ihn zu spinnen: z.B. Schreibmaschine und Telegraph. Twitter & Co für heute zeitgemäße Literatur zu benutzen, wäre also angezeigt. Einige Alternate Reality Games versuchen sich daran ja auch schon.)

Kurze Statusnotifikationen in die Welt geworfen: Was kann das nützen? Ich denke, zwei Seiten sind zu unterscheiden: Twittern als Monolog und Twittern als Dialog.

• Als monologisierender Autor könnte der unmittelbare Nutzen darin liegen, dass Twitter mir unmittelbar hilft, meinen Tag zu strukturieren und zu protokollieren. Twitternachrichten als kontinuierlich fortgeschriebenes Tagebuch. Termine im Kalender sind Planung und Blick in die Zukunft. Ein Twitterprotokoll hingegen ist Retrospektive. Indem ich bei einer "Zustandsänderung" (z.B. Tätigkeit, Ort) ein Twitterupdate schreibe, halte ich einen Moment inne. Das gibt Reflektionen raum und trägt womöglich zur Entschleunigung bei.
• Sobald ich mich als Autor nicht mehr allein sehe, sondern als Knoten in einem Netzwerk, kommt weiterer Nutzen hinzu. Dann haben meine Twitterupdates nicht nur einen Effekt für mich. Wenn andere sie lesen, kann ich ihnen auch eine Botschaft mitgeben. Ich kann Aussagen machen (z.B. über Werkzeuge, die ich gerade benutze, oder Themen, die mich beschäftigen) oder Fragen stellen. Meine Aussagen mögen andere anregen, meine Fragen mögen mir Antworten bescheren. Einmal kann ich mich als Person oder gar Kompetenzträger darstellen, ein andermal als Hilfesuchender. Ganz zwanglos. Ohne Garantie auf "Erfolg". Aber eben auch mit quasi vernachlässigbarem Aufwand.

Twitter scheint mir damit ein Werkzeug zur Selbstorganisation wie auch zur Kommunikation. Mit Twitter können man sowohl nach innen wie nach außen gehen. Geradezu esoterisch mutet das an, denn der Strom meiner Twitternachrichten ist ja quasi ein "stream of consciousness", ein Gedankenstrom, und also ist Twitter ein Gedankenlesewerkzeug. Besser als bei der herkömmlichen Telepathie behalte ich die Veröffentlichungshoheit über meine Gedanken. Sie werden mir nicht "herausgelesen", sondern ich gebe sie freiweillig preis.

Es stellt sich also die Frage: Was kann sich alles entwickeln, wenn wir unsere Gedanken lesen können?

Wie Briefe und Telefon war Big Brother auch früher. Früher hatten viele Menschen Angst, sie würden ausgespäht. Heute hingegen muss sich niemand mehr die Mühe machen. Die Informationen über die Menschen liegen auf der Straße, weil sie sie selbst dorthin werfen. Twitter ist ein weiteres Medium dafür.

Aber ist das schlimm? Nein, ich finde, nicht. Im Gegenteil! Wer sich vor Big Brother fürchtet, macht zu. Wer sich zu macht, reduziert seine Kontaktoberfläche, seine Verbindungen. Wenn eines aber wichtig heutzutage ist, um in einer komplexen Welt fortzuschreiten, dann sind es mehr Verbindungen, einfachere Verbindungen. Dafür müssen wir aber offen sein, kontaktfreudig. Und das beginnt mit Angeboten, die wir machen. Bei der persönlichen Begegnung ist ein Lächeln ein Angebot. In der virtuellen Welt können es "Broadcasts" sein wie Blogs oder eben Gedankenströme in Twitter. (Dass dann solche Gedankenströme nicht einmal von einem Menschen, sondern von einer Software stammen können, ist womöglich zu vernachlässigen. Am Ende geht es um "Entitäten", um Informationsquellen, die für mich wertvoll und vertrauenswürdig sind. Das können auch Twitter-Bots sein, die die "Gedanken" eines Unternehmens "senden".)

Soweit ein paar Überlegungen zu Twitter. Ob und inwiefern sie mit der Realität zu tun haben, weiß ich allerdings noch nicht. Ich muss sie versuchen zu verifizieren. Am besten im Selbstversuch. Denn nur Versuch mach kluch. Also öffne ich mal meinen Kopf und eröffne einen Blick auf meine "Zustände". Zum Glück ist das mit Twitter weniger schmerzhaft als bei früheren Trepanationen ;-)

Wer mit auf meinen Gedankenströmen schwimmen will, kann sich als "Follower" bei mir in Twitter anmelden. Mein Twitter-Konto ist: http://www.twitter.com/ralfw.

Softwarearchitektur kompakt - prio.conference 2008

Als wie relevant das Thema Softwarearchitektur inzwischen in der Community wahrgenommen wird, hat die prio.conference der dotnetpro am 10./11. November gezeigt: mehr als 260 Teilnehmer hatten den Weg nach Baden-Baden ins Kurhaus gefunden. Das ist eine Zahl, die mich als Content Manager der prio sehr gefreut hat - und ich hoffe, dass nicht nur das Oberthema im Großen, sondern auch meine Auswahl von Vortragsthemen und -referenten im Kleinen dazu einen Beitrag geleistet hat.

Erstes Feedback stimmt mich da aber positiv. So ist zum Beispiel die Keynote des (wahrscheinlich) einzigen wirklichen Architekten vor Ort sehr gut angekommen. Prof. Dr. Christian Kühn aus Wien hat einen interessanten Bogen von seinem Metier der Bauarchitektur zur Softwareentwicklung geschlagen. Denn wenn sich schon die Pattern-Bewegung der Softwareentwicklung auf bauarchitektonische Patterns bezieht, ist es angezeigt einmal zu beleuchten, welche Relevanz die denn eigentlich haben. Und so haben die Anwesenden nicht nur erfahren, wie die Patterns schon vor Erich Gamma et al. ihren Weg in die Softwarebranche gefunden hatten, sondern auch, wie Prinz Charles mit Patterns verbunden ist.

Nach solchem Blick über den Tellerrand ging es dann aber mit "echten" Softwareinhalten los. In 30 Sessions haben die Referenten den Bogen vom Konzeptionellen wie der Definition von Architekturrollen und Dokumentation über eher unbekannte Technologien wie Microsofts CCR oder PostSharp bis zu handfesten Tipps zum Transport von veränderlichen Objekten per WCF gespannt.

Besonders haben mich die Kommentare zum Thema Jabber gefreut. Die Teilnehmer waren hocherfreut zu erfahren, dass es solch coole Kommunikationstechnologie gibt - und gleichzeitig erstaunt, dass sie bisher davon noch nichts gehört hatten. Denn Jabber kann vieles schon lange, was Microsoft erst heute mit seinem Communication Server anfängt zu realisieren. Und dabei ist Jabber bzw. seine Server und Clients vielfach kostenlos und reifer.

Ebenfalls über den Horizont der vielfach Microsoft-lastigen Welt der .NET-Community hinaus hat Referent Markus Völter mit seinen Vorträgen zum Thema Domänenspezifische Sprachen (DSL) geblickt. Er hat vorgeführt, wie auf der Basis der oAW Plattform mit Eclipse (!) schon heute eigene textuelle Sprachen inkl. Codegeneratoren realisiert werden können. Wer also nicht auf Microsofts Oslo warten will, der kann jetzt loslegen.

Die prio hat somit nicht nur viele Facetten des Themas Softwarearchitektur beleuchtet, sondern bewusst weiter geblickt als die üblichen Microsoft-lastigen Events. Softwarearchitektur hat zwar immer mit Entwicklungsplattform zu tun, sollte sich von ihr aber nicht unnötig beschränken lassen. Relevante und interessante Entwicklungen gibt es jenseits von Linq, Entity Framework, WPF, Silverlight oder dem sich schon zur Welle hebenden OsloAzureWindows7.

Aber nicht nur das Fachliche hat Spaß gemacht. Der Abend stand wieder ganz im Zeichen der Heimat der dotnetpro: alle Teilnehmer trafen sich im Löwenbräu zu einem nah ans Oktoberfest-Original heranreichenden bayrischen Abend. Der war ausnehmend gemütlich - auch wenn er Sprecher und Veranstalter sich nicht nur entspannen konnten. Wie schon im Vorjahr galt das Motto der englischen Offiziersakademie Sandhurst: serve to lead - dienen, um zu führen. Und so bedienten Sprecher und Chefredakteur die Teilnehmer vor und hinter dem Thresen.

Das hat Laune gemacht und wieder ganz neue Einblicke in die Community gegeben :-)

Im nächsten Jahr wird die prio solche Gemütlichkeit jedoch nicht mehr "exportieren" müssen. 2009 findet die prio.conference in der dotnetpro Heimatstadt München statt. Das Thema steht auch schon fest. Es wird um "User Interfaces" gehen. Und es wird natürlich wieder technisch und praktisch und konzeptionell werden. Von Usability bis DataBinding Best Practices gibt es viel zum Thema zu sagen. Immerhin sind User Interfaces das Aushängeschild unserer Anwendungen.

Aber zur Softwarearchitektur wird die dotnetpro bis dahin sicher auch nicht stumm bleiben. Stay tuned!

Interrupt? Nein, danke! [OOP 2009]

Es ist schon erstaunlich, wie unterschiedlich Menschen sein können:

Situation 1: Auf der Straße unterhalte ich mich mit einer Nachbarin. Die hat ihren 5-jährigen Sohn dabei. Nach 2-3 Minuten Plauderei ruft der plötzlich "Mama, Mama, ich würde gern...". Die Mutter daraufhin sofort: "Nicht jetzt! Ich unterhalte mich gerade. Gleich bin ich aber für dich wieder da."

Situation 2: Im Café sitzen neben mir zwei Frauen ins Gespräch vertieft. Da klingelt plötzlich das Handy der einen. Sie zögert nicht, nimmt ab und plaudert mit dem Anrufer mehrere Minuten. Die andere blättert derweil klaglos zur Überbrückung in einer Zeitschrift.

Situation 3: Während eines Beratungsauftrags sitze ich mit einem Entwickler über einem Architekturproblem in seinem Büro. Plötzlich geht die Tür auf und der Projektleiter fordert ihn auf, sofort einem Kollegen bei der Lösung einer Aufgabe zu helfen.

Hm... was haben diese Situationen gemeinsam? Da sind Menschen in etwas vertieft und es tritt eine plötzliche Störung durch einen Dritten ein.

Und was unterscheidet diese Situationen voneinander? Nur in einem Fall entscheiden sich die ins Gespräch vertieften zu einer Abwehr der Störung. Nur das Kind wird als Störenfried in seine Schranken verwiesen. Die Mutter macht ihm klar, dass es nicht jederzeit Zugriff auf sie hat, sondern darauf achten muss, ob Mutter gerade offen für eine Ansprache ist. Sieht es hingegen, dass Mutter anderweitig beschäftigt ist, soll es sich gedulden.

Daran ist grundsätzlich nichts auszusehen, würde ich sagen. Es ist höflich, nicht zu unterbrechen. Das sollte ein Kind lernen.

Wie ist solche Lehre aber zu vereinbaren mit dem Verhalten der beiden Frauen im Café? Sie lassen sich ganz einfach durch einen Anruf unterbrechen. Sie nehmen das nicht nur in Kauf, sondern provozieren es geradezu, indem sie ihre Handys angeschaltet lassen. Dass sie Ärztinnen oder Bestatterinnen sind, die jederzeit auf Abruf zu erreichen sein müssen, war allerdings nicht zu erkennen.

Warum lassen sich erwachsene Frauen die Unterbrechung von einem Kind nicht gefallen, aber von jedem anderen, der noch nicht einmal anwesend ist? Hm... darüber kann man einen Moment nachdenken. Doch über die wahren Beweggründe für diese Unterbrechungstoleranz will ich hier gar nicht reden. Mir fiel angelegentlich dieser Situation nur die Diskrepanz zwischen Anspruch und Wirklichkeit auf.

Denn der allgemeine Anspruch ist ja, dass man nicht gestört werde, wenn man in etwas vertieft ist. So lautet die pädagogische Reaktion der Mutter. Auf der anderen Seite tolerieren oder provozieren wir jedoch die Unterbrechung. Im privaten Umfeld mag das auch unproblematisch sein. Im geschäftlichen jedoch wird das schnell teuer.

Wissensarbeit wie in Situation braucht nämlich eines: Konzentration. Um gute Wissensarbeit - und nichts anderes ist Softwareentwicklung - leisten zu können, müssen sie sich fokussieren können. Sie brauchen Störungsfreiheit. Entwickler durch "Chefanfragen" immer wieder in ihrer Arbeit zu unterbrechen, ist daher kontraproduktiv. Sie müssen ihren Fokus verlassen und später wieder aufbauen. 15min "Umschaltzeit" sind dabei durchaus keine Seltenheit.

Im Grunde wissen das auch alle vom Wissensarbeiter bis zum Top-Manager. Multitasking funktioniert nur sehr begrenzt. Dennoch verhalten sie sich aber alle anders.

Obige Situation 2 hat mir nun klar gemacht, woran das liegt. Das Unterbrechungsproblem in der Arbeitswelt kann nicht besser werden, solange wir es nicht konsequent umfassend angehen. Wer sich im privaten Bereich gern unterbrechen lässt, das Handy immer auf Empfang hat und verständnisvoll-verzeihend nickt, wenn andere angerufen werden, der darf sich nicht wundern, wenn am Arbeitsplatz auch immer wieder unterbrochen wird.

Die Gründe für solche Ambivalenz mögen verständlich sein. An den weitreichenden Auswirkungen der Ambivalenz ändert das jedoch nichts. Wer sich einem Kind gegenüber die Unterbrechung verbittet, sie aber im Freundeskreis toleriert oder gar erwartet, darf sich nicht wundern, wenn er dann am Arbeitsplatz keine "produktive Unterbrechungskultur" etablieren kann.

Ich möchte nicht ohne Handy, SMS, Email, IM usw. leben. Aber wichtiger als diese Medien ist mir immer noch mein Fokus. Und so habe ich kein Verständnis mehr für Unterbrechungswilligkeit. Ich schalte (spätestens ab heute) meine "Unterbrechungsmedien" ab, wenn ich im Gespräch bin. Und ich werde sonstige Unterbrecher höflich, aber bestimmt auf die Kontraproduktivität ihrer Unterbrechung hinweisen. Kinder und Manager machen da für mich keinen Unterschied. Das halte ich vielmehr für eine Grundlage höflichen und respektvollen Umgangs miteinander.

NETZ it! - Komponentenorientierte Software ausliefern leicht gemacht

"Soooviele Assemblies???" ist der ungläubige Ausruf, den ich oft höre, wenn ich ich über Komponentenorientierung spreche. Denn damit komponentenorientierte Entwicklung wirklich ihre Vorteile ausspielen kann, ist es nötig, Software nicht nur logisch in Komponenten zu zerlegen, sondern die auch noch physisch getrennt zu implementieren. Das bedeutet, jeder Komponentenkontrakt und jede Komponentenimplementation wird zu einer eigenen Assembly. Die Zahl der Assemblies einer Anwendung ist also immer mindestens doppelt so groß wie die ihrer Komponenten.

Das hört sich viel an. Oder zumindest ungewohnt. Schon bei 3 Komponenten kommen 5 oder 6 Assemblies zusammen, wie die nebenstehenden Beispielanwendung zeigt. Und größere Anwendungen bestehen schonmal aus 50 oder 100 Komponenten und damit 100 oder 200 Assemblies.

Einen "materiellen" Nachteil hat das jedoch nicht. Der .NET Framework kommt damit ganz gut zurecht. Nur Visual Studio nicht. Es macht keine Freude, in einer Visual Studio Projektmappe mehr als vielleicht 10 Projekte zu verwalten. Aber das soll man ja auch nicht.  (Insofern entspricht die Abbildung links nicht dem Ideal; ich habe die Projekte nur für eine einfachere Darstellung so zusammengefasst.)

Echte Komponentenorientierung bedeutet vielmehr, dass alle Komponenten in je eigenen Projektmappen entwickelt werden. Wenn Sie an einer Komponente arbeiten sollen Sie nicht abgelenkt werden durch Implementationsdetails anderer Komponenten, die in derselben Projektmappe liegen.

Doch auch wenn es keinen "materiellen" Nachteil hunderter Assemblies für eine Anwendung gibt, verstehe ich, dass sie dazu angetan ist, den Überblick zu verlieren. Vor allem wollen Sie womöglich dem Kunden gegenüber solche Detailfülle nicht offenlegen. Die Abbildung rechts zeigt, wie ich die Beispielanwendung eigentlich ausliefern müsste: als "Sack von Assemblies". Das ist zwar einfach, aber mag sich eben zumindest merkwürdig anfühlen.

Krücke ILmerge

Nun habe ich aber noch nie behauptet, dass die Zahl der Assemblies zur Entwicklungszeit der zur Zeit der Auslieferung gleich sein müsse. Immer schon habe ich auf die Möglichkeit hingewiesen, sie mit Microsofts ILmerge zusammenzufassen. Aus den 7 zur Anwendung gehörenden Assemblies (inkl. DI Framework Infrastruktur) rechts im Bild könnte mit ILmerge ganz leicht eine werden.

Sie anders zusammenfassen, wäre allerdings nicht unproblematisch. Zum Beispiel könnten Sie nicht nur alle Kontrakt-Assemblies vereinigen, weil Sie damit die Referenzen darauf in den Komponentenimplementationen invalieren würden. Die beziehen sich ja auch konkrete Assemblynamen, die es dann nicht mehr gäbe.

ILmerge funktioniert zwar grundsätzlich. Ist aber letztlich nur eine Krücke, weil es nicht genügend Freiheitsgrade bietet. Außerdem mag es nicht jedem schmecken, dass ILmerge den IL-Code "anfasst". Zugegebenermaßen ein Vorgang, bei dem mehr falsch laufen könnte, als wenn man Assemblies, so wie sie sind, irgendwohin kopiert.

NETZ to the rescue

Aber diese Zeit der Krückenlösung ist nun vorbei! Durch einen News-Schnippsel in einer Entwicklerzeitschrift bin ich auf das Open Source Tool NETZ gestoßen. Das ist echt cool für die komponentenorientierte Entwicklung! Und es ist auch noch eines aus deutschen Landen - ein seltener Umstand bei Softwareentwicklungstools.

Was bietet NETZ? Zusammenfassung und Kompression von Assemblies. Mit NETZ können Sie Assemblies wie mit ILmerge zusammenfassen, allerdings ohne Eingriff in den IL-Code. NETZ verpackt die Assemblies einfach nur als Ressourcen in eine von ihm generierte.

Für die Komponentenorientierung unwichtig, aber für Sie dennoch vielleicht interessant, komprimiert NETZ die Assemblies während der Zusammenfassung auch noch. So kann der in den Ressourcen steckende IL-Code nicht mehr so einfach decompiliert werden. Ohne Obfuscation erhalten Sie also einen ersten Schutz gegen beiläufige Ausspähung von Implementationsdetails.

Die obige Beispielanwendung in eine Assembly zusammenzufassen, ist mit NETZ ganz einfach. Eine Kommandozeile wie diese reicht (sie ist nur der Lesbarkeit wegen hier in mehrere Zeilen geteilt):

netz -z -s
  frontend.exe
  -d logic.dll dataaccess.dll
       contracts.logic.dll contracts.dataaccess.dll
       Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll

Mit ihr verpackt NETZ alle Assemblies in eine neue Assembly (-s), die auch eine DLL zur Dekompression enthält (-z). Alle Assemblies können auch dynamisch geladen werden (-d) - das ist für die Nutzung eines DI Frameworks nützlich sein mag. Das Resultat: eine Assembly mit Namen frontend.exe und einer Struktur wie in der nachstehenden Abbildung. Der Start-Code wurde komplett durch NETZ generiert (Methoden auf der linken Seite), die Anwendungsassemblies sind zu Ressourcen geworden (rechts). Der NETZ-Code sorft dafür, dass beim Laden einer Assembly, die die CLR nicht selbst findet, die Ressourcen herangezogen werden.

Schon bis hierhin bietet NETZ also mehr als ILmerge. Nicht nur Zusammenfassung von Assemblies, sondern gleichzeitig Kompression - und das ohne Eingriff in den Assembly-IL-Code.

NETZ kann aber noch mehr! NETZ kann die Assemblies auch in externe Ressourcen verpacken. So können Sie sie beliebig gruppieren. Auf die Referenzen hat das keinen Einfluss. Bilden Sie also beliebige Gruppen von Assemblies. Die Beispielanwendung habe ich z.B. einmal so zusammengefasst wie rechts zu sehen. In frontend.exe steckt die ursprüngliche EXE mit den Microsoft Unity DI Infrastruktur-Assemblies. Die contracts-Ressourcen enthalten die Kontrakt-Assemblies, die components-Ressource die Implementationen. Ganz einfach ist damit einem Batch wie diesem:

netz -z -s frontend.exe Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll
netz -xr contracts contracts.logic.dll contracts.dataaccess.dll
netz -xr components dataaccess.dll logic.dll

move *-netz.resources frontend.exe.netz

Der -xr Switch weist NETZ an, die Assemblies nicht zu einer EXE, sondern zu einer externen Ressource zusammenzufassen. Der NETZ-Start-Code sucht in solchen Ressourcendateien im selben Verzeichnis sogar zuerst nach Assemblies.

Lassen Sie sich durch 50 oder 100 Assemblies nicht in Bockshorn jagen. Fassen Sie sie für´s Deployment mit NETZ einfach so zusammen, wie Sie es möchten: alle zu einer großen Assembly oder Kontrakte und Implementationen getrennt oder Kontrakte zusammen mit ihren Implementationen oder alle Assemblies einer Kategorie (z.B. alle Domänenlogik-Assemblies getrennt von allen Aspekt-Assemblies). Mit NETZ ist das alles sehr einfach möglich. Und kostenlos dazu! Mein herzlicher Dank gilt Vasian Cepa, dem Entwickler! (Der ist übrigens sehr bemüht; innerhalb eines Tages hatte er eine Verbesserung eingebaut, auf die ich ihn angesprochen hatte.)

Ich arbeite jetzt nicht mehr ohne NETZ in meinen komponentenorientierten Projekten.