OOP 2008: Assimilieren statt Speichern - Networking für Daten in einer dynamischen Welt

Alles soll heute flexibel sein: Menschen, die sich auf Jobangebote bewerben, genauso wie Programmiersprachen. Statisch ist out, dynamisch ist in. Nur noch nicht so recht bei den Daten. Denn da regieren Strenge und Statik. Daten werden einmal in Klassen oder Tabellen verpackt - und dann ändert sich diese Anordnung am besten nicht mehr. Falls doch, muss solche Veränderung gut geplant sein, damit die fein ziselierten Datenstrukturen nicht inkonsistent werden.

Datenspeicherung gehört zu einer statischen Welt

Daten in Container zu verpacken, die einander referenzieren, ist eben ein Informationsmodell für statische Datenstrukturen. Die Daten mögen sich ändern, aber die Strukturen, die Zusammenhängen bleiben konstant. Das ist völlig ok. Allerdings dient das vor allem einem Zweck: der 1:1 Speicherung und Reproduktion von Daten. Das Mittel der Wahl ist dabei das Kopieren dieser Daten. Wenn Sie z.B. Personendaten bestehend aus Vorname+Nachname in einer Datenbank speichern, dann werden die Bytes von Vorname und Nachname mindestens einmal in der Datenbank unverändert abgelegt, wahrscheinlich jedoch mehrfach. Jeder Index multipliziert ja gespeicherte Daten.

Dass die Geschichte der Softwareentwicklung sich bisher vor allem mit solcher Datenspeicherung beschäftigt hat, ist verständlich. Wenn man etwas mit Daten der äußeren Welt tun will, dann holt man sie am besten erstmal 1:1 "ins System". Mit einer Sprache wie SQL kann man sie dann bei Bedarf in Form von Views umarrangieren; allerdings funktioniert das nur in Maßen, denn SQL kann die grundsätzliche Container-Referenz-Dichotomie nicht aufheben.

Assimilierung für eine dynamische Welt

Seit der Geburt der relationalen Datenbanken sind nun aber einige Jahrzehnte vergangen. Die Welt hat sich verändert. Die Welt und damit die Anforderungen an die Datenbanken sind dynamischer geworden. Zusammenhänge, die gestern galten, sind morgen veraltet. Die auf Statik angelegten Datenstrukturen in heutigen Datenbanken sind somit kontraproduktiv. Sie sind wie Sand im Getriebe, wie Kalk in Gelenken.

Das Problem sind zum Einen die festen Containergrenzen, in die Daten in großen Blöcken eingepfercht sind. Denn Daten in Containern lassen sich nicht mit Daten in anderen Container in neue Beziehungen bringen. Nur Container selbst können einander referenzieren. Zum anderen sind Referenzen als Teil der Daten in Containern ein Problem. Solange Referenzen in Container stecken, müssen Containerstrukturen nämlich verändert werden, um neue Beziehungen herzustellen. Solche Schemaänderungen widerstreben dann zurecht jedem Datenbankadmin, denn sie widersprechen dem grundlegenden Paradigma der statischen Strukturen aller Container-Referenz-Datenmodelle.

Um nun Daten fit für eine dynamische Welt zu machen, muss also das Datenspeicherparadigma aufgegeben werden. In einer dynamischen Welt ist nicht mehr die 1:1 Speicherung und Reproduktion von Daten der Hauptzweck von Datenbanken. Die Reproduktion von Datenstrukturen ist nicht mehr der Rede wert; sie ist selbstverständlich.

Der Hauptzweck der Datenverarbeitung ist heute vielmehr die Flexibilisierung von Daten. Sie müssen so gehalten werden, dass jederzeit neue Zusammenhänge zwischen ihnen hergestellt werden können. Daten müssen fähig werden zum Networking. Business Intelligence (BI) ist zwar schon eine Disziplin, die sich der Schöpfung von Werten aus neuen Zusammenhängen zwischen Daten widmet. Aber auch BI ist letztlich noch dem bisherigen Datenspeicherungsparadigma verhaftet.

Wahre Dynamik und maximale Flexibilität erreicht die Datenverarbeitung erst, wenn Daten nicht mehr gespeichert, sondern assimiliert werden. Denn Daten wie andere "Dinge" der realen Welt, sind immer nur so flexibel, d.h. "verformbar", wie sie aus "verschiebbaren" Einzelteilen bestehen.

Dynamik kommt also erst in die Datenhaltung, wenn wir Daten nicht mehr als zu festen Blöcken in erhaltenswerten Containern zusammengesetzt ansehen, sondern als "Säcke" voller "Datenatome". Was diese Datenatome dann sind, ist zunächst einmal egal. Es können einzelne Bits, einzelne Zahlen, einzelne Zeichenketten oder einzelne 2 MB Blobs sein. Je feiner die Granularität dieser "Atome", desto höher jedoch die Flexibilität des "Datensacks".

Und nicht nur das! Denn diese "Datenatome" können nicht nur innerhalb eines Sacks immer wieder neu arrangiert, sondern können maximal flexibel mit "Datenatomen" anderer Säcke in Beziehung gesetzt werden. Statt Datenblöcke also einfach nur 1:1 zu speichern, müssen wir sie "shreddern". Dann erhalten wir maximal verbindbare "Datenatome". Und diese "Datenatome" assimilieren wir in eine "Wolke" schon existierender "Datenatome".

Assimilation besteht damit aus zwei Schritten:

1. Datenblöcke in "Datenatome" zerlegen
2. "Datenatome" mit schon vorhandenen vernetzen

Und der zweite Schritt kann sogar beliebig oft wiederholt werden! Per definitionem ist nicht zu befürchten, die Struktur der "Datenatome" je verändern zu müssen. Es sind ja Atome; aus Sicht einer Anwendung haben sie daher keine weitere, für zukünftige Beziehungen relevanten internen Strukturen.

Wo vorher noch Daten in Containern waren, sind nach der Assimilation die Container verschwunden und die Daten in eine "Datenwolke" (oder ist es eher ein "Datenplasma"?) aufgelöst und mit schon existierenden "Datenwolken" verschmolzen. Assimilation speichert Daten also nicht einfach, sondern löst sie in einem größeren Ganzen auf. Wie bei sonstigen Lösungen verschwindet das Aufgelöste jedoch nicht, sondern verteilt sich nur bzw. wird hier in das Vorherige integriert. Die ursprünglichen Daten sind also auch in der Gesamtheit alles Assimilierten noch enthalten - nur eben nicht klar umrissen an einem Ort wie die Datenkopien bei der üblichen Datenspeicherung. Dennoch lassen sich aus einem "Assimilat" auch wieder die ursprünglichen Daten in ihren Containern zum Zeitpunkt der Anlieferung regenieren.

Um Daten wahrhaft flexibel zu halten, müssen wir also das Operationenpaar Speichern/Laden durch das neue Paar Assimilieren/Regenerieren ersetzen. Dem bisherigen Grundanspruch der 1:1 Datenhaltung wird damit immer noch Rechnung getragen. Doch darüber hinaus eröffnet die assimilierende Datenhaltung ganz neue Möglichkeiten zur Vernetzung von Daten, zur Bildung immer neuer Zusammenhänge.

Assimilation ist die Grundlage für Synergieeffekte zwischen Daten. Durch Assimilation werden Daten so flexibel, wie sie eine immer dynamischer werdende Umwelt braucht.

Oder passend zum Jahresschluss: Speichern war 2007... Assimilation ist 2008.

Mehr Klarheit für die Objektorientierung - Klassendiagramme entzerren

So, zum Jahresende muss ich eines noch loswerden: Klassendiagramme mag ich nicht. Oder genauer: so wie sie üblicherweise benutzt werden. Lange habe ich darüber gegrübelt, woran das liegt. Jetzt weiß ich es! Sie sind undurchsichtig, weil sie zweierlei vermischen. Sie widersprechen damit einem Grundsatz zur Bewältigung von Komplexität, dem "Separation of Concerns".

So wie UML Klassendiagramme üblicherweise benutzt werden, vermischen sie "Verwandtschaftsbeziehungen" mit "Arbeitsbeziehungen". Sie mengen Vererbungshierarchien mit Assoziationen/Aggregationen zusammen. Hier als Beispiel die übliche Darstellung des "Decorator" Entwurfsmusters:

 
Quelle: http://www.dofactory.com/Patterns/PatternDecorator.aspx

Wer steigt da zügig durch? Erkennen Sie auf Anhieb, was Sie zu implementieren haben? Sehen Sie gleich, wer wen nutzt? Ich nicht. Ich brauche immer eine ganze Zeit, um mich darin zurechtzufinden. Und das finde ich schlicht falsch. Ein Diagramm soll für einfache Zusammenhänge - und einfach ist das "Decorator" Pattern - auch einfach zu lesen sein.

Seitdem ich nun verstanden habe, was mich an den üblichen Klassendiagrammen stört, betreibe ich auch bei ihnen strikte Zwecktrennung oder "Separation of Concerns". Hier zur Erläuterung meine Version des "Decorator" Entwurfsmusters:

1. Arbeitsbeziehungen darstellen

Am wichtigsten finde ich es, die Arbeitsbeziehungen zwischen Klassen bzw. ihren Instanzen darzustellen. Welche Objekte brauchen welche anderen? Welche Objekte enthalten (aggregieren) welche anderen? Und das alles mit den richtigen Mengenangaben (Beziehungskardinalitäten: 1:1, 1:n, n:m).

Darauf zunächst reduziert sieht das "Decorator" Pattern so schön einfach aus:

Alles klar? Ich hoffe! Applikationscode ruft entweder Instanzen einer "Simple Class" direkt auf oder nutzt Objekte von "Enhanced Class", hinter denen jeweils eine "Simple Class"-Objekt steht.

Da Klassen bzw. Vererbung nicht einmal zum Kern der Objektorientierung gehören, ist die Darstellung von Vererbungsbeziehungen auch nicht essenziell. In Bezug auf den "Decorator" bedeutet das: Wesentlich ist nicht, welche Klassen hier gemeinsame "Vorfahren" haben, sondern dass der "Decorator" (Enhanced Class) genauso aussieht (!) wie das zu Dekorierende (Simple Class). Das lässt sich aber schon an den gleichen Methodennamen ablesen.

2. Zusammenarbeit beschreiben

Wenn die Darstellung der Arbeitsbeziehungen bzw. des Objektgeflechts noch Fragen offen lässt, dann untermauere ich sie mit einem Sequenzdiagramm. Die Nutzung eines Decorators sieht dann zum Beispiel so aus:

Alles klar? Ich hoffe! Denn auch hier liegt der Fokus auf dem, was am Nutzungsort in der Applikation relevant ist. Dort hat der Code mit dem Decorator und dem Dekorierten zu tun - und nicht mit irgendwelchen möglichen Basisklassen.

3. Verwandtschaftsbeziehungen darstellen

Erst ganz zum Schluss dokumentiere ich dann die Verwandtsschaftsbeziehungen zwischen den funktional relevanten Klassen. Dann geht es um Ableitungen oder Implementationen von Interfaces. Und dann beschreibe ich womöglich sogar Alternativen. Bei "Decorator" Pattern sind das z.B. diese:

Alles klar? Ich hoffe! Denn eine solche Darstellung, die sich auf Vererbung konzentriert, ist doch leicht zu verstehen.

In der Literatur findet sich übrigens nur die untere Ableitungsstruktur. Aber ich denke, eine Basisklasse für alle Decorators ist nicht nötig. Wesentlich ist lediglich, dass Domänenklasse/zu Dekorierendes und Decorator eine gemeinsame Herkunft haben. Die macht sie für den Applikationscode dynamisch austauschbar.

Fazit

Nachdem ich meine Software-Detailentwürfe von "vermengenden" Klassendiagrammen auf "separierte" Klassendiagramme umgestellt habe, machen mir objektorientierte UML-Darstellungen wieder deutlich mehr Spaß. Ich kann Ihnen also nur empfehlen, grundsätzlich Verschiedenes wie Arbeitsbeziehungen und Verwandtsschaftsbeziehungen ebenfalls zu so zu trennen. Sie machen Ihre Objektemodell viel besser verständlich.

OOP 2008: Wider die Wiederverwendbarkeit

Im OBJEKTspektrum 1/2008 hat Nicolai Josuttis einen Artikel zum Thema SOA geschrieben, der mir recht das Herz aufgehen ließ. Besonders hervorheben möchte ich hier von den vielen seiner Aussagen, denen ich beipflichte, allerdings zunächst nur diese:

"Beides zusammen führt dazu, dass sich Wiederverwendbarkeit nicht unbedingt als primärer Business-Case für SOA eignet."

Fast möchte ich darauf nur sagen: Amen.

Denn Wiederverwendbarkeit - oder Neudeutsch: Reuse - halte auch ich für stark überbewertet. Nicht nur in Bezug auf SOA, sondern allgemein in der Softwareentwicklung. Seit die Objektorientierung ihren Siegeszug angetreten hat, lautet die Botschaft "Wiederverwendung ist gut, Wiederverwendung ist ein wichtiges Ziel!".

Irgendwie klingt das ja auch ganz plausibel, nein, geradezu zwingend! Besonders für alle, die ein Auge auf´s Geld haben wollen oder müssen. Wenn etwas wiederverwendet werden kann, dann amortisieren sich die darin getätigten Investitionen umso schneller. Wer wollte das nicht?

Nun, alle die etwas mehr Weitblick haben, wollen das nicht "einfach so". Die Welt ist nicht so simpel schwarz/weiß, wie Wiederverwendungsapostel es gern hätten. Wiederverwendbarkeit steht nicht einfach unökonomische Mehrfachentwicklung gegenüber. Wiederverwendbarkeit und Wiederverwendung haben ihren Preis - und müssen daher wie jede andere Investition abgewogen werden.

Kosten der Wiederwendbarkeit und Wiederverwendung

1. Wiederverwendbares zu entwickeln, kostet deutlich mehr Aufwand, als nur für einen konkreten Zweck zu entwickeln. Es ist Zeit aufzuwenden, um die vielen möglichen Wiederverwendungsszenarien zu sammeln und zu analysieren. Es ist dabei auch mehr Personal involviert. Und die Qualität des Wiederverwendbaren muss höher sein, d.h. mehr Planungs- und Entwicklsaufwand fließt hinein, weil mehr Parteien davon abhängen. Wann sich nun aber ein solcher Mehraufwand amortisiert haben wird, ist ungewiss. Hoffnungen und Wünsche sind oft die Triebfedern, nicht glasklare Kalkulationen.

2. Wiederverwendung ist nicht kostenlos. Sobald ein Zusammenhang entsteht, in dem etwas wiederverwendet werden könnte, der zum Zeitpunkt der Herstellung der Wiederverwendbarkeit noch nicht bekannt war bzw. nicht berücksichtigt wurde, entsteht Anpassungsaufwand. Per definitionem ist die Schnittstelle von etwas Wiederverwendbarem nicht optimal für den einzelnen Wiederverwendungsfall. Wer wiederverwendet, muss sich mehr oder weniger anpassen. Und im schlimmeren Fall muss sogar das Wiederzuverwendende ebenfalls nachgeführt werden.

3. Wiederverwendbares zu finden, kostet Aufwand. Sobald Wiederverwendung nicht in überschaubarem Rahmen abläuft, man also quasi im Hinterkopf haben kann, was denn potenziell wiederverwendet werden könnte, fallen Recherchekosten an. Bei allen Entscheidungen muss explizit geprüft werden, ob "Spezialentwicklung" oder Wiederverwendung angezeigt ist. Ist der Pool des als grundsätzlich wiederverwendbar Klassifizierten groß genug, kann der Rechercheaufwand sogar womöglich den Aufwand einer Spezialentwicklung erreichen. Nicht zu vernachlässigen sind auch negative Effekte auf die Motivation der Projektmitglieder, die ihren Sinn aus dem Entwickeln ziehen und nicht aus der Suche nach Wiederverwendbarem (s. "Implementing component reuse strategy in complex products environments", Ilan Oshri et al. in CACM 12/2007).

4. Wiederverwendung erhöht die Komplexität, denn Änderungen an etwas Wiederverwendbarem haben Auswirkungen auf eine große Anzahl von Verwendern.

Wenn sich eine Spezialentwicklung ändert, hat das potenziell nur Auswirkung auf wenige Nutzer. Wiederverwenbares jedoch muss immer im Blick behalten, dass eine große, womöglich sogar unbekannt große Zahl Nutzer zu Anpassungsaufwand gezwungen werden könnte. Das führt über kurz oder lang zur Versteifung von Wiederverwendbarem, weil die Konsequenzen von Änderungen immer schwerer zu überschauen sind. Dem Versprechen von Änderungen, die nur noch an einem Ort vorgenommen werden müssen, steht also eine Drohung des Kompatibilitätszwangs gegenüber.

5. Wiederverwendbarkeit entwickeln, ist nicht agil. Wer etwas auf Agilität gibt, kann eigentlich kein Freund der Entwicklung von Wiederverwendbarkeit sein. Denn Wiederverwendbarkeit lässt sich nur mit einem Blick in die Glaskugel erreichen. Es muss vom aktuell Nötigen extrapoliert werden. Gefragt ist dann nicht mehr, was jetzt, hier und heute ausreichend wäre, sondern was auch noch morgige potenzielle Fälle abdecken helfen könnte. Das läuft dem Gedanken zuwider, immer nur den aktuell angemessenen Aufwand zu treiben und alle weitere Aufwände bzw. Entscheidungen auf den spätest möglichen Zeitpunkt zu vertagen - weil sich ja bis dahin wieder Anforderungen oder schlicht Erkenntnisse (über Anforderungen oder Technologien) geändert haben könnten.

Wiederverwendbarkeit ist kein Ziel, sondern ein Mittel

Und nun? Wiederverwendbarkeit ist nicht schlecht. Ich mag sie auch - wo sie sich leicht herstellen lässt oder einfach ergibt. Wiederverwendbarkeit halte ich nur einfach für kein taugliches Ziel. Kräfte sollten nicht auf Wiederverwendbarkeit ausgerichtet sein nach dem Motto "Lasst uns erst schauen, was wir wiederverwendbar machen können!" Das mag sich für Controller zwar gut anhören oder Entwicklerpersönlichkeiten entsprechen, die sich gern mit Grundsätzlichem und vor allem Infrastruktur beschäftigen. (Wer würde nicht gern seinen eigenen Persistenzframework basteln und das Thema einfürallemal lösen, statt sich mit ewig wetterwendischen Kundenwünschen herumzuplagen?)

Stattdessen sollten alle Kräfte zu jeder Zeit darauf gerichtet sein, Komplexität zu meistern - und natürlich Kundenwünsche zu erfüllen. Wiederverwendbarkeit ist aber kein Kundenwunsch. Gemeisterte Komplexität jedoch, weil sie Langlebigkeit fördert. Und wenn sich dann an einem Punkt ergibt, dass die Komplexität durch Wiederverwendung sinken würde, dann ist das wunderbar. Dann ist Wiederverwendbarkeit lediglich ein Mittel. Dann ist es Zeit, durch Refaktorisierung Wiederverwendbarkeit herzustellen - falls dem nicht zu hohe Folgekosten entgegenstehen. Aber nicht früher.

Wiederverwendbarkeit und SOA?

Wiederverwendbarkeit und SOA haben deshalb soviel miteinander zu tun wie Wiederverwendbarkeit und Objektorientierung oder Wiederverwendbarkeit und Komponentenorientierung. SOA-Dienste können Einheiten der Wiederverwendung sein wie Objekte oder Komponenten. Mehr nicht. Es gibt keinen SOA-Grundsatz, der da lautet "Services should be as reusable as possible" oder dergleichen. SOA-Services können wiederverwendbar sein - aber ob das angemessen ist, steht auf einem ganz anderen Blatt.

SOA wie Komponentenorientierung - die Objektorientierung lasse ich einmal bewusst außen vor - haben vor allem ein Ziel: die Beherrschung von Komplexität. Große Systeme sollen verstehbar und evolvierbar sein und bleiben. Darum geht es. Und deshalb halte ich eine "System Oriented Attitude" für den wichtigsten Ausgangspunkt aller Softwareentwicklung.

 

PS: In der Entwicklungsgeschichte eines Systems kann es übrigens zu gegenläufigen Bewegungen kommen: Ähnliche Funktionalität kann zu Wiederverwendbarer zusammengefasst werden (Integration) - Wiederverwendbares kann aber ebenso wieder aufgespalten werden, wenn es versucht, zuvielen Herren zu dienen (Desintegration). Auch diese Möglichkeit gilt es im Blick zu behalten. Wahrhafte Agilität versteift sich nicht auf einen Zustand.

OOP 2008: Innovation und Wettbewerb

Michael Stal bricht in Reaktion auf mein Posting nochmal eine Lanze für Wettbewerb als Innovationsmotor. Was nun? Wie so oft, wenn These und Antithese sich gegenüberstehen, lohnt die Suche nach einer Synthese bzw. nach einem solch Gegensatz zugrundeliegenden Missverständnis. So auch in unserem Fall.

Ich denke, unser beider Positionen sind komplementär. Innovation braucht Mut, Einfühlungsvermögen, Sensibilität und (!) Wettbewerb! Na, wie ist das, Michael? ;-)

In meinem vorherigen Posting zu dem Thema hatte ich mich gegen Michaels Aussage gewandt, Wettbewerb sei die entscheidende Voraussetzung für Innovationen. Das finde ich nachwievor falsch. Innovation entsteht nicht aus dem Wettbewerb von Innovierern (einzelnen oder kollektiven). Denn Innovation hat nichts mit Wettbewerb zu tun, sondern mit Linderung von Leiden. Leiden lindert aber niemand, weil er darin besser sein will als jemand anderes, sondern schlicht, weil er sich davon einen direkten (Reduktion eigenen Leidens) oder indirekten Vorteil (Entlohnung für die Reduktion fremden Leidens) verspricht.

Insofern bleibe ich dabei, dass zunächst einmal für Innovationen all das wichtig ist, was Erkennen von Leiden und Heilung befördert. Wettbewerb gehört nicht dazu.

Allerdings: Wenn denn ersteinmal eine Innovation geboren ist, dann kann Wettbewerb einen positiven Effekt auf sie haben. Wettbewerb kann helfen, Innovationen besser genießbar zu machen, sie zuzuschleifen. Und Wettbewerb hilft nach unserem marktwirtschaftlichen Credo, den Preis für Innovationen zu senken.

Zeugung und Gestation einer Innovation profitieren nicht von Wettbewerb. Beim Wachstum einer Innovation jedoch, bei ihrer Reifung, da hilft Wettbewerb, weil Wettbewerb motiviert, sich nicht auf der initialen Innovation auszuruhen. So gut sie sein mag, sie ist zunächst noch roh. Wettbewerb macht dann sensibel für den Dialog zwischen Leidenden und konkurrierenden Innovierern. Denn kann helfen,die Innovation passgenau zu machen.

Wettbewerb hat also durchaus einen Platz bei Innovationen. Dennoch halte ich es für Bedenkenswert, wieviel Wettbewerb einer Innovation zuträglich ist. Und ich glaube weiterhin daran, dass Wettbewerb oft zu groß im Vergleich zu Kooperation geschrieben wird. Denn Wettbewerb hat mit Mauern zu tun. Wettbewerber sind ja gerade Wettbewerber, weil sie sich nicht in die Karten schauen lassen wollen. Das aber verhindert den Austausch von Erfahrungen, das führt zu genauso sinnlosen wie teuren Parallelentwicklungen, das steht Konvergenz (oder gar Standardisierung) entgegen.

Aber das rührt nun an ein anderes Thema - Evolution -, zu dem Michael allerdings auch eine Bemerkung gemacht hatte. Er sprach von Mutation und Selektion. Davon aber ein andermal. Denn auch die Bedeutung von Mutationen halte ich für übertrieben im Vergleich zur Symbiose. Aber davon ein andermal...

OOP 2008: Innovation braucht Einfühlungsvermögen und Sensibilität

Mich hat der "philosophische" Beitrag von Michael Stal im OOP-Blog gefreut. Das ist die Art Nachdenken, die mir gefällt: raus aus den technologischen Niederungen, Abstand vom Hype nehmen und einmal über Grundsätzliches nachdenken. Wie ist das also mit der Innovation in der Softwarebranche? Zugegeben, eine sehr allgemeine Frage, aber in jedem Fall bedenkenswert.

Michael konstatiert: "Es bedarf des Wettbewerbs der Ideen (Evolutionen) um Anreize für Innovation zu schaffen [...]". Ist das aber wirklich so? Braucht Innovation einen Wettbewerb? Nein, das halte ich für zwar verständliches, aber überkommenes Denken nach kapitalistischer/westlicher Väter Sitte. Dass Wettbewerb die stärkste Fortschrittskraft ist, ist längst schon als Illusion entlarvt. Kooperation statt Wettbewerb heißt die Zauberformel.

Woher kommen dann aber Innovationen, wenn sie nicht durch Wettbewerb "angestachelt werden"? Zunächst scheint es nützlich, zur Beantwortung dieser Frage zu überlegen, was Innovation eigentlich ist. Und da sage ich mal, Innovation steht dem Informationsbegriff nach Gregory Bateson insofern nahe, als dass sie einfach ein Unterschied ist, der einen Unterschied macht:

1. Unterschied: Innovation weicht vom Existierenden ab.
2. Unterschied: Diese Abweichung führt dazu, dass wir zunächst einmal ganz allgemein anders arbeiten als bisher. Im Speziellen nehmen wir diese Andersartigkeit jedoch positiv wahr.

Mit dieser Definition von Innovation kann die Frage nach ihren Quellen nun differenzierter gestellt werden:

1. Was sind Bedingungen, die zur Produktion einer Abweichung vom Existierenden führen?
2. Welche Abweichungen nehmen wir als positiv wahr?

Zu Frage 1: Schierer Wettbewerb kann natürlich der Antrieb sein, Unterschiede der ersten Art zu produzieren. In Wirklichkeit geht es dem Produzenten dabei jedoch nicht um diesen Unterschied in der Sache, sondern um einen Unterschied zum Wettbewerb bzw. seiner bisherigen wirtschaftlichen Position. Die Innovation ist dann nur Mittel zum Zweck. Das halte ich für die schlechteste aller Motivationen für Innovationen.

Viel wirksamer scheint mir hingegen die Motivation aus Leiden heraus. Wer am Existierenden leidet, sucht nach Wegen, dieses Leiden zu beenden. Oder volkstümlicher: Not macht erfinderisch. Allererster Innovationsmotor ist für mich daher Sensibilität! Sensibilität für die eigenen Leiden und Sensibilität für die Leiden anderer, d.h. der heutigen oder potenziellen Kundschaft.

Ob auch noch andere am Markt sensibel sind, ist dabei unerheblich. Ich würde sogar sagen, dass ein "Wettbewerb der Sensiblen" zunächst hinderlich für Innovation ist, da er die ursprüngliche Leidenssensibilität ankränkelt. Statt alle Kräfte auf Heilung des Leidens auszurichten, also einen in der Sache positiven Unterschied zu produzieren, motiviert Wettbewerb, Kräfte in einen Unterschied zu den Wettbewerbern zu investieren. Das schwächt die Innovation.

Zu merken ist diese "unechte" Motivation bei allen etablierten Produkten von Microsoft Office bis SAP. Wenn ihre neuen Versionen mit Veränderungen zur bisherigen oder Konkurrenzprodukten aufwarten, dann sind diese Veränderungen vor allem durch den wirtschaftlichen Zwang, d.h. den Wettbewerb motiviert. Das ist Innovation um der Innovation willen, weil sich sonst die Software nicht mehr im Rahmen des vorherrschenden Geschäftsmodells verkaufen lässt. Nüchtern betrachtet würde das Urteil wohl lauten: Viele etablierte Produkte sind am Ende. Sie sind für 80-90% der Kundschaft gut genug und müssen nicht weiterentwickelt werden. Echte Innovationen sind nicht mehr in ihnen oder mit ihnen möglich.

Zu Frage 2: Welche Unterschiede werden als positiv empfunden? Hier ist Einfühlungsvermögen gefragt und Domänenkenntnis. Wer Unterschiede der ersten Art produzieren will, die Unterschiede der zweiten Art machen, muss nicht nur sensibel sein, sondern sich in die Position seiner Kunden versetzen können. Was sind deren Wünsche, Sorgen, Nöte, Ziele? Beispiel: Möchte die Kundschaft einen schnelleren Rechner, weil die Datenbankzugriffe immer so langsam sind? Oder möchte die Kundschaft eine schnellere Datenbank? Oder möchte die Kundschaft einen leichter zu bedienenden Datenbank-API, der vor imperformanter Verwendung schützt? Oder möchte die Kundschaft überhaupt eine ganz andere Programmierplattform mit Persistenz, die noch umfassender vor imperformanter Fehlbenutzung schützt? Oder wäre die beste Lösung, auf Persistenz ganz zu verzichten und stattdessen alle Daten in-memory zu verarbeiten?

Wer nicht versteht, wo der Schuh wirklich drückt, der erzeugt womöglich Unterschiede an falscher Stelle. Der betreibt Symptomkur, statt zu heilen. Das bringt dann zwar auch eine gewisse Linderung, aber nicht wirklich dauerhafte Abhilfe.

Innovationen können aus meiner Sicht also nur da entstehen, wo Einfühlungsvermögen und Sensibilität zusammenkommen. Einfühlungsvermögen öffnet, Sensibilität registriert. Wettbewerb ist beidem jedoch abträglich, denn Wettbewerb hat mit Adrenalin zu tun. Und Adrenalin führt zu Regression, zu Tunnelblick. Wer unter Adrenalin steht, der ist aus evolutionsgeschichtlich guten Gründen gefühlstaub.

Soviel zu Michael Stals (Syn)These, dass Innovation Wettbewerb brauche. Ich verstehe, was er damit meint. Und im gegebenen Wirtschaftssystem bzw. bei den aktuellen Geschäftsmodellen für Software ist Wettbewerb auch unumgänglich. Auch im Sinne einer freundschaftlichen Herausforderung ist darüber hinaus nichts gegen ihn zu sagen. Dass Wettbewerb jedoch essenziell, geradezu der Katalysator für größte Innovationen sein soll... das kann ich nicht glauben. Da scheinen mir Einfühlungsvermögen und Sensibilität als Fundament viel wichtiger. Ihnen muss sich dann allerdings auch noch Mut zugesellen. Sonst bleiben Innovationen in der Schublade.

Mut zum Riskio, Mut zur Lücke, zum Fehler, Mut zum Nonkonformismus, Mut zum Imperfekten, zum Vorläufigen... Vielleicht ist der Mut sogar noch wichtiger. Ja, sogar ganz gewiss. Erst kommt der Mut, dann die Zuversicht, dann Einfühlungsvermögen und Sensibilität. Schließlich Beredtheit, also Wille und Fähigkeit, die Frohbotschaft der Innovation zu verkünden. Von der Sachkompetenz und fachlichen Qualifikation ganz zu schweigen. Den Wettbewerb hingegen, den braucht die Innovation nicht so recht.

OOP 2008: Reflexe sind schlecht für die Softwarequalität

IT Projekte stehen irgendwie immer unter Druck. Zeitdruck, Kostendruck, "Hoffnungsdruck" (Motto: "Die neue Software wird es schon rausreißen!")... wer wüsste das nicht. Und wenn Ihr Projekt heute gerade mal nicht unter Druck steht, dann sicherlich bald, wenn die Deadline näher gerückt ist.

Druck hat nun aber die unangenehme Eigenschaft, die Menschen auf ihr, hm, Stammhirn zu reduzieren. Unter Druck fallen wir zurück auf früheste und festeste Verhaltensmuster. Druck lässt uns regredieren; wir vergessen unter Druck sehr schnell, was wir gelernt haben. "Höheres Wissen" wird dann ersetzt durch "niedere Instinkte". Extrembeispiele sind Unfälle, Krieg, Panik, Katastrophen: das Denken setzt aus, Höflichkeit war einmal, Reflexe bestimmen die Handlungen. Nicht umsonst drillt jedes Militär der Welt seine Soldaten, auf dass sie unter Druck eben nicht planlos werden, sondern funktionsfähig bleiben. Druck erfahren, aushalten und unter ihm weiterhin angemessen und weitsichtig agieren, das macht den wahren Meister aus.

Weniger lebensbedrohliche Situationen sind dann Prüfungen, die auch so manchen Wissenden in aus der Leere in die Leere starren lassen. Oder nur der Wochenendausflug mit der Familie inkl. Schwiegermutter. Was da alles organisiert werden muss... und dann findet der Kleinste seinen Stoffhund und ist nicht mehr zu beruhigen... Da liegen die Nerven blank, da helfen dann nur Machtworte. Oder?

Druck führt zu "Spontanregressionen" in Bezug auf Handlungsoptionen und Umgangsformen. Druck erzeugt bekanntlich dann auch Gegendruck. Eine unheilvolle Spirale setzt sich in Gang.

So ist es kein Wunder, dass die Manager einer Branche, die ständig unter Druck steht, sich langsam aber sicher den Ruf von Krankmachern erarbeitet haben (Originalstudie). Denn Manager sind auch nur Menschen. Also verfallen sie bei anhaltendem Druck auch auf basale Verhaltens- bzw. Führungsformen: autoritäres Gebahren (24%), bürokratisches Verhalten (38%) und reaktives Handeln (45%) sind so alt wie die menschlichen Kulturen. Autoritär haben sich schon die Clanchefs in der Bronzezeit gebärdet, bürokratisch waren schon die mittelalterlichen Zünfte, reaktiv gehandelt hat schon die DDR-Regierung der letzten Tage.

Verständlich ist also solch Rückfall unter Druck auf Bewärtes oder eher Überkommenes. Aber ist es auch gut? Ist er den Projekten zuträglich? Nein, natürlich nicht. Autorität, eine gewisse Bürokratie (sofern man dem Begriff überhaupt etwas Positives abgewinnen kann) und auch Reaktion haben ihre Zeit, sind unter gewissen Umständen angemessen. Doch als Führungsinstrumente für Wissensarbeiter sind sie schlicht ungeeignet.

Komplexes wie Software lässt sich nicht mit Autorität erzwingen. Kreative Problemlösungen lassen sich nicht in einem bürokratischen Verhau finden. Und Reaktion statt vorausschauendem Agieren ist schlicht zu langsam in einer Welt, die ständig im Fluss ist.

Und insofern ist meine These: Wenn denn die Manager in unserer Branche sich wirklich so krankmachend verhalten - wobei ich keinen bösen Willen unterstelle, sondern schlicht Regression mangels ausreichendem Training -, wenn die Manger wirklich in so großer Zahl autoriät, bürokratisch und reaktiv sind, dann schaden sie damit massiv der Qualität von Software.

Reflexartiges Handeln, das unter Druck ganz normal, wenn auch außerhalb von physischen Notsituationen unangebracht ist, hat in der Softwareentwicklung nichts zu suchen. Das heißt natürlich nicht, dass alles immer bis zum letzten Handgriff durchgeplant und mit stoischer Ruhe abgewickelt werden muss. Nein, nein. Das heißt vielmehr, dass a) Manager ihre Führungswerkzeuge intensiver und auch unter Druck erlernen müssen, um sie auch im Ernstfall parat zu haben; und b) Manager müssen verstehen, dass Wissensarbeit und kreative Arbeit anders funktionieren als eine Manufaktur des 19. Jahrhunderts. Wer physische Anwesenheit von 9h-17h mit Arbeit gleichsetzt, der hat mindestens 60 Jahre Arbeitspsychologie verschlafen.

Manager müssen vor allem damit zurechtkommen lernen, dass sie keine Kontrolleure sind, sondern Ermöglicher. Sie können Wissensarbeit, d.h. Softwareentwicklung nicht zentral steuern wie ein Stahlwerk. Sie müssen vielmehr einen anti-autoritären, bürokratiearmen Raum schaffen, der zu Kreativiät und zum Agieren ermundert.

Wenn also schon der Druck nicht aus der Branche genommen werden kann, dann müssen wenigstens die Führungskräfte damit angemessen umgehen lernen. Das heißt, sie müssen Führungsinstrumente im Schlaf, nein, unter Druck beherrschen, die zu den Eigenarten der Softwareentwicklung passen.

Reflexe sind gut beim Tennisspielen. Bei der Softwareentwicklung geht es aber nicht um Gegnerschaft und Konkurrenz, sondern um Kooperation. Deshalb schadet reflexartige Führung auf dem Niveau der letzten 5000 Jahre der Softwareentwicklung besonders.

OOP 2008: Was kommt nach OLTP? - oder: Wo ist die Killeranwendung für Microsoft Oslo

Erst waren Batch-Anwendungen, nun sind OLTP-Anwendungen... und was kommt danach? Was ist denn der Unterschied zwischen beiden? Wo lag die Entwicklung bisher?

Batch-Anwendungen waren asynchron, nicht interaktiv und eher auf ein Rechenzentrum beschränkt. OLTP-Anwendungen hingegen sind synchron, interaktiv und durchaus auch global. Anwendungen haben sich also in ihrem grundsätzlichen Antwortzeitverhalten und der Reichweite verändert. Früher war Warten angesagt, heute regiert die Ungeduld; früher fand EDV unter Verschluss statt, heute soll sie von überall her erreichbar sein.

Soviel zu den Unterschieden zwischen zwei grundlegenden Arten von Software der letzten 50 Jahre. Natürlich hat sich noch mehr getan: von graphischen Benutzeroberflächen bis Business Intelligence. Doch mich interessiert eher, was sich nicht getan hat. Wo hat es eher keine Veränderung gegeben, denn dort liegt das Potenzial für größere Veränderungen.

Stellen SOA und Grid-Computing nicht ebensolche Veränderungen wie die Entwicklung von Batch zu OLTP dar? Nein, zunächst einmal nicht, denn SOA und Grids sind nur Architekturen und keine Anwendungsarten. Batch- und OLTP- haben zwar auch Architekturen, doch darüber hinaus stehen sie für eine bestimmte Form des Umgangs mit Computern und Daten. OLTP und SOA, das sind Äpfel und Birnen.

Aber: C/S und SOA zu vergleichen, das ergibt Sinn. Und damit rühre ich an einer Konstante, glaube ich. Bei aller Veränderung in unseren Anwendungen haben sie sich doch in einem Punkt nicht wirklich weiter entwickelt. Heute wie vor 50 Jahren sind die allermeisten Anwendungen immer noch zentralistisch. Trotz (oder wegen?) LAN und Internet liegen die Daten zentral und Geschäftslogik läuft auch zentral. Daran ändert letztlich auch eine SOA nicht viel.

Und mit diesem Zentralismus geht eine Arbeitsform einher, die sich ebenfalls nicht verändert hat: Daten werden von Menschen sequenziell bearbeitet. Da macht alle Multiuser-Fähigkeit unserer Anwendungen auch keinen Unterschied. Der eine kippt die Daten ins System, der andere holt sie raus und verändert sie, dann bearbeitet sie der nächste usw. An einem Gesamtdatenbestand arbeiten zwar gleichzeitig durchaus Tausende oder gar Millionen. Doch letztlich tun sie das alle isoliert voneinander. Ihre Zusammenarbeit ist über die Zeit gestreckt. Ich nenne das mal asynchrone Kollaboration.

Ob Batch oder OLTP, ob C/S, N-Tier oder SOA: Wir leben heute immer noch in einer Welt zentralistischer Anwendungen, mit denen wir asynchron kollaborieren.

Und nun kommt auch noch Oslo! Microsoft möchte mitspielen bei den großen Enterprise-Anwendungen. So produziert und projiziert man eine große Vision - fängt aber gleichzeitig an, sie schon im kleinen Umzusetzen. Die BizTalk Services (BTS) sind der Anfang. Das ist cool. Wo andere riesige Geldbeträge fordern für einen ESB, da verschenkt Microsoft gleich einen ISB (Internet Service Bus).

Aber was bringts? Ich glaube, das bringt erstmal nur "mehr vom Selben". Mehr Batch und mehr OLTP mit mehr SOA. Das ist natürlich nicht schlecht. Auch OLTP-Anwendungen können jede technologische Vereinfachung und jede Flexibilisierung vertragen. Aber einen so großen Sprung wie von Batch nach OLTP machen sie damit nicht.

Wenn wir jedoch BTS ernst nehmen und mal über den OLTP-Tellerrand schauen, wenn wir mal die bisherigen Konstanten in den Blick nehmen und fragen, ob sie denn weiterhin konstant gehalten werden müssen... dann kommen wir zu einer nächsten Veränderungen der Qualität unserer Anwendungen. OLTP "fühlt sich ganz anders an" als Batch, es ist eine andere Qualität. Aber was könnte sich nun wieder ganz anders anfühlen als OLTP?

Ich glaube, das erfahren wir, wenn wir die bisherigen Konstanten aufgeben: Zentralismus und Nacheinanderarbeit. Denn das wird mit einem ISB wie den BTS jetzt möglich.

Nach OLTP kommt SROC: Serverless Real-time Online Collaboration.

SROC-Anwendungen bieten wiederum eine neue Qualität: Sie machen die Zusammenarbeit von Menschen in Echtzeit an den selben Daten möglich, ohne dafür eine zentrale Infrastruktur aufsetzen zu müssen:

• Serverless: SROC-Anwendungen brauchen weder für die Kommunikation noch für die in Arbeit befindlichen Daten eine zentrale Infrastruktur. SROC-Anwendungen spannen zwischen kollaborierenden Instanzen ein ad hoc Verbindungsnetz auf und arbeiten darüber an einem gemeinsamen virtuellen Datenraum. Ihre Skalierbarkeit muss nur proportional zur Zahl der Kollaborateure sein und nicht zur Gesamtbenutzerzahl, wobei gilt Kollaborateurzahl << Gesamtbenutzerzahl.
• Real-time: In SROC-Anwendungen kollaborieren Benutzer gleichzeitig. Nur wer anwesend ist, kann auch kollaborieren. Ein Chat ist die einfachste Form einer solchen real-time Kollaboration. Das steht im Gegensatz zur bisher üblichen asynchronen Kollaboration in OLTP-Anwendungen, bei dem z.B. Auftraggeber und Auftragnehmer eben nicht gleichzeitig an der Anwendung arbeiten müssen, um dennoch das gemeinsame Ziel zu erreichen. Asynchrone Kollaboration skaliert deshalb sehr gut - aber in diese Skalierbarkeit ist nicht für alle Kollaborationsprojekte nötig oder gar kontraproduktiv. Das weiß jeder, der schon einmal versucht hat, einen Konflikt per Email statt durch persönliche Kommunikation von Angesicht zu Angesicht zu lösen. Aufgaben, die ad hoc Absprachen und Reaktionsschnelligkeit erfordern, wo die Kommunikation fließen muss - das beginnt bei der Terminvereinbarung und endet bei Rettungseinsätzen -, sie werden am besten in real-time bearbeitet.
• Online: Teams, die in Echtzeit an kreativen Problemlösungen aller Art arbeiten, sind heute immer öfter über die Welt verteilt oder finden sich spontan zusammen (z.B. an einem Unfallort). Sie können sich also nicht auf die Existenz einer lokalen Infrastruktur verlassen. Ihr kleinster gemeinsamer Nenner ist das Internet - via LAN und Router oder GPRS. Wenn solche Teams computergestützt zusammenkommen wollen, dann muss das also online, d.h. über das Internet geschehen können, ohne dass Firewalls sie unbebührlich behindern.
• Collaboration: Miteinander statt gegeneinander. Team statt Hierarchie. Das hat inzwischen auch der Letzte begriffen. Dennoch ist Zusammenarbeit nicht gleich Zusammenarbeit. Und auch Collaboration Tools sind nicht alle gleich. Das Thema Collaboration ist nicht neu, aber die bisher breit verfügbaren Kollaborationswerkzeuge jenseits von rundem Tisch, Whiteboard und Chat bieten noch nicht, worum es bei SROC geht. Email, die Änderungsverfolgung in MS Word oder document sharing mit MS SharePoint dienen alle der Kollaboration - aber die findet sequenziell, asynchron statt. Das ist auch wichtig, doch eben nicht genug. Asynchrone Kollaboration verschenkt Chancen, um mit der steigenden Komplexität der (Arbeits)Welt kräftesparend umzugehen. Denn asynchrone Kollaboration verhindert durch die zeitversetzte Interaktion das Entstehen von Synergieeffekten zwischen den eigentlich zusammenarbeitenden Individuen. Ungeplante Kommunikation als Quelle und Träger von Neuem und hilfreicher Redundanz gibt es bei asynchroner Kollaboration kaum. Die Vorteile der Virtualisierung werden dadurch zum Teil wieder zunichte gemacht.

Wie gesagt, nicht dass es bisher keine ausdrücklichen Kollaborationsanwendungen gegeben hätte. Email ist das beste Beispiel für asynchrone Kollaboration, Chat das beste Beispiel für real-time Kollaboration. Napster, Gnutella & Co allerdings weniger, auch wenn sie serverlos und online sind. Es geht dort einfach nicht um echte Zusammenarbeit an großen oder kleinen Projekten. Auch Subversion und Sourceforge sind natürlich Kollaborationswerkzeuge - allerdings serverbasierte. Und Groove... ja, auch ein Kollaborationswerkzeug, aber nicht für die real-time Kollaboration.

Ich glaube, dass SROC das "nächste große Ding" sein wird in der Softwarewelt. Die Menschen wollen zusammenarbeiten und sie wollen und müssen es öfter in Echtzeit tun, weil sie sonst ineffizient arbeiten. Nicht in Echtzeit zu kommunizieren, ist öfter als mal denkt, wie Sand im Getriebe. Aber Menschen wollen für eine Zusammenarbeit in Echtzeit nicht immer auch persönlich zusammenkommen müssen. Oder sie wollen, auch wenn sie zusammen sind, sich bei ihrer Arbeit durch ein Werkzeug unterstützen lassen.

OLTP ist gut, wenn ich bei Amazon bestelle. Batch ist gut, wenn ich Videos über Nacht komprimieren will. SROC ist gut, wenn ich mehr oder weniger ad hoc mit anderen zügig und kreativ ein Problem lösen will. SROC-Anwendungen sind daher ureigenst Anwendungen einer Wissensgesellschaft. Wiki und Chat sind nett... aber nur der Anfang.

Denn Wiki und Chat brauchen große Server oder sind dank Firewalls schwer zu programmieren. SROC-Anwendungen brauchen aber keine solchen Server mehr... und werden dank ISB viel leichter zu programmieren sein.

So glaube ich also, dass die wahren Killeranwendungen für BizTalk Services oder das größere Projekt Oslo nicht die nächste Runde von SOA-Services sind. Die werden sie auch nutzen. Klar. Aber viel spannender ist es, mit diesen Technologien etwas ganz neues zu machen. Und SROC-Anwendungen sind soetwas Neues. Heute gibt es sie nur vereinzelt, aber morgen könnte ihre Zahl explodieren, weil es soviel einfacher wird, ihre Instanzen zu vernetzen.

PS: Allerdings ist eine einfachere Vernetzung durch Firewalls hindurch nur ein erster, notwendiger Schritt. Ein nächster muss sein, die Zusammenarbeit in Echtzeit an dem Gemeinsamen zu vereinfachen. Wie hält eine Wolke von Instanzen einer SROC-Anwendungen, wie halten diese Kollaborateure einen gemeinsamen Zustand? Dazu mehr in einem späteren Posting... Hilfe ist auch hierzu unterwegs.

OOP 2008: Angst essen SOA auf

Schon mit SOA als "System Oriented Attitude" habe ich ja dafür plädiert, der Technik eine persönliche Haltung zu unterlegen. Und das 3. Gesetz der Softwareentwicklung hat mich zu quasi philosophischen Äußerungen hingerissen: Softwareentwicklung ist Arbeit am ewig Vorläufigen. Wenn ich mich nun also schon so wegkatapultiert habe von den harten Bits und Bytes, dann kann ich auch noch einen soziologischen Aspekt hinzufügen, oder? Also...

Prämisse 1: Software ist ein langlebiges Produkt mit Zwang zur ständigen Anpassung. Software ist nie fertig. Softwareentwicklung kommt nie wirklich an. Es gibt immer nur Zwischenstopps, Verschnaufpausen auf einem ständig sich windenden Weg. Software ist insofern einem Lebewesen ähnlicher als einem Auto. Softwareentwicklung ist eben Arbeit am und im ewig Vorläufigen. Das mag unserer Vorstellung von "Produkten" widersprechen und auch unserem Weltverständnis entgegenstehen, in dem es doch immer noch soetwas wie Objektivität und Wahrheit gibt, also feste Punkte, an denen man ankommen kann. Aber es hilft nichts: Software ist nicht so. Software kommt nicht an. Software ist eine ständige Baustelle. Sie befindet sich im ständigen Anpassungszwang.

Prämisse 2: Wir leben in einer Gesellschaft, die ein Problem mit Veränderungen hat. Wir leben in einer Kultur, die ein Problem mit Fehlern hat. Fehler, Scheitern und gar noch selbst Schuld daran sein... das sind kollektive Horrorvorstellungen in Deutschland. Abzulesen ist das an der Regelungswut des Gesetzgebers, am Stigma Insolvenz, an der geringen Selbstständigenquote, an falschen öffentlichen Ehrenworten und schlicht an der Realität der Softwareentwicklung, die keine Spielräume lässt. Denn Spielräume sind Eingeständnisse für das Potenzial von Fehlern. Fehler zu machen, wird nicht als unausweichlich menschlich angesehen, sondern als auszumerzendes Übel (oder zumindest zu leugnende Schwäche).

Da nun Veränderungen Entscheidugen voraussetzen, Entscheidungen aber richtig oder falsch sein können, Entscheider also Fehler machen können... deshalb fürchten wir uns kollektiv vor Veränderungen. Wir wollen einfach keine Fehler beim Entscheiden machen, keine Fehlentscheidungen treffen. Wer nichts verändert und zufrieden mit dem status quo ist, der hat kein Problem mit Fehlern oder Schuld. Ohne Veränderung kein selbstverschuldetes Scheitern. Wenn man dennoch scheitert, dann ist´s wenigstens die Schuld von jemand anderem.

Da nun aber unzweifelhaft immer wieder Entscheidungen getroffen werden müssen, auch große und weitreichende, gilt ein (bisher) stillschweigendes Übereinkommen, dass diejenigen, die sie auf sich nehmen, dafür besonders entlohnt werden. Die großen Gehälter der wenigen "großen Entscheider", der Manager, der Konzernlenker stehen insofern wahrscheinlich einfach in Relation zur allgemeinen großen Furcht vor Entscheidungen der vielen Kleinen Nichtentscheider. Wir sollten uns also nicht über sie beklagen, solange wir selbst fehlerängstlich und entscheidungsunfreudig sind. Aber ich schweife ab...

Konklusion: Wenn nun Software ihrer Natur nach ständige Veränderung bedeutet, die Softwareentwickler und -architekten und Projektleiter und Kunden einer Kultur und Gesellschaft angehören, denen im Kern Veränderungen verhasst sind... dann kann das nichts Gutes für die Softwareentwicklung bedeuten.

Wie sollen Menschen in einem Milieu ohne Fehlerkultur, wie sollen Menschen, die ansonsten in ihrem Leben auf Konstanz, geradlinige Entwicklung und dauerhafte Werte (z.B. Haus, Yacht, Familie, gesicherter Ruhestand) ausgerichtet sind, wie sollen solche Menschen etwas produzieren, das die Antithese ihrer Haltung und ihrer Werte ist?

Ich glaube, das geht auf einer ganz fundamentalen Ebene nicht.

Und solange wir das nicht einsehen, werden wir immer wieder verständnislos vor Software jeder Größenordnung - vom Handy-Game bis zur Enterprise SOA - stehen und uns wundern, warum das nicht endlich mal läuft, wie es soll, nicht endlich mal fertig ist.

SOA im Speziellen oder Softwareentwicklung im Allgemeinen braucht, so glaube ich, also nicht nur eine angemessene technisch-fachliche Kultur, die ich "System Oriented Attitude" nenne. Nein, sie braucht auch eine der Natur der Software (s. Prämisse 1) angemessene ganz grundsätzliche Lebenskultur, die ständige Veränderung bejaht, die Fehler akzeptiert, in der es nicht um Schuld und Konkurrenz, sondern um Kooperation geht, die bewusst mit dem Spannungsfeld zwischen menschlichem Wunsch nach Sicherheit und Verlässlichkeit auf der einen Seite und der Notwendigkeit zur Anpassung und Flexibiltitä auf der anderen Seite umgeht.

Der Deutschen Gründlichkeit hat ja ihre Vorteile. Veränderungen wollen bedacht sein. Aber wo aus Nachdenken dann Bedenken und schließlich Bedenkenträgerei wird, wo Fehler ein Makel sind, wo die Spielräume für Korrekturen fehlen, wo Konkurrenz mit Schuldzuweisung arbeitet, wo die Angst in den Herzen sitzt... da kann eine SOA nicht wirklich gedeihen.

Eine Gesellschaft hat immer die Software, die sie verdient.

OOP 2008: Gesetze der Softwareentwicklung III

Abgesehen mal von der Frage, was eine gute, nein, eine optimale SOA ist, lohnt auch die Frage, wie denn ein Unternehmen überhaupt zu dieser SOA kommen kann? Ich glaube, zu ihrer Beantwortung können einige "Gesetze der Softwareentwicklung" beitragen.

Gesetz 1 sagt, dass optimale Strukturen, also auch optimale serviceorientierte Architekturen überhaupt nur für bekannte Anforderungen entworfen werden können. Das mögen Sie als trivial ansehen, dennoch ist es hilfreich, diese Basislinie zu haben. Und keine Sorge, Gesetz 2 macht die Sache schon spannender: Selbst wenn es für gegebene Anforderungen eine oder wenige gleichwertige optimale Strukturen geben sollte, dann lassen sich die nicht aus ihnen ableiten. Unser Verständnis bekannter Anforderungen ist einfach zu begrenzt. Ja, ich meine, dass wir selbst vorliegende Anforderungen allermeistens nur unzureichend verstehen; von den (noch) unbekannten Anforderungen, d.h. davon, dass Anforderungen immer im Fluss sind, also niemals vollständig bekannt, rede ich gar nicht erst.

Das glauben Sie nicht? Sie meinen, wasimmer Sie aus einem Kunden mit der Hebammenkunst des Requirements Engineering herausgekitzelt haben, verstehen Sie auch in seinen Implikationen und können deshalb eine optimale Struktur dafür entwerfen. Gut, dann unterliegt das Ergebnis der Implementation dieser optimalen Struktur immer noch

Gesetz 3: Optimale Strukturen werden nie verlustfrei implementiert

Sie kennen das Spiel: Am Anfang stehen gute Vorsätze, aber was aus ihnen wird, ist eine andere Sache. Wie Clausewitz schon sagte: Kein Plan überlebt den Kontakt mit dem Feind. Eine optimale Struktur ist aber ein Plan, ein Vorsatz für die Realisierung von Software. Und der Feind... der ist das Tagesgeschäft. Am Anfang einer Iteration/eines Release sind Motivation und Zuversicht groß. Am Ende, wenn es auf die Auslieferung zugeht, ist die Motivation hoffentlich immer noch groß, aber die Zuversicht hat Dämpfer bekommen. Meist werden Sie am Ende einer Timebox nicht die geplanten Features ausliefern. Sie werden (hoffentlich) immer noch Wert für den Kunden produziert haben, aber nicht den, den Sie anfänglich geplant hatten. Das betrifft nicht nur die Zahl der Features, sonder vor allem die interne Struktur ihrer Implementation.

Der Grund dafür ist einfach: Es existiert ein Wertekonflikt. Auf der einen Seite der Wert "Funktionalität für den Kunden" und auf der anderen Seite "Qualität der Implementationsstruktur". Und welcher dieser Werte wird, wenn die Zeit knapp ist, höher geschätzt? Sie wissen es aus eigener Erfahrung nur allzu genau. "Funktionalität für den Kunden" ist im Zweifelsfall immer der Gewinner. Wenn die Uhr merklich tickt, dann verfallen wir nicht nur in physischen Gefahrensituationen auf Verhaltensweisen, die sich seit der Steinzeit eingeschliffen haben, sondern auch wenns im Virtuellen brenzlig wird. Copy&Paste als Reflexhandlung, hier noch schnell etwas dazustricken, damit es läuft, dort mit "Ja, ich weiß, das ist jetzt nicht optimal und nicht so, wie wir´s geplant hatten, aber es funktioniert halt erstmal." entschuldigen. So funktioniert Softwareentwicklung in immer engen Zeitplänen auf der ganzen Welt. Nicht schön, aber is´ halt so.

Der Kunde ist König. Der Kunde sieht keine internen Strukturen. Also wird poliert, was der Kunde sieht und wünscht. Ob die langfristig optimalen Strukturen dabei erhalten bleiben, ist im Zweifelsfall egal. Zweifelsfälle, d.h. Entscheidungszwänge am Ende von Zeitplänen, sind allerdings die Regel. Also ist auch Suboptimalität die unvermeidliche Regel. Wider jeden besseren Willens.

In der Suboptimalität einrichten

Was bedeutet das für eine SOA? SOA, also Architektur im Großen, muss sich wie jede andere Softwarestruktur in der Suboptimalität und damit im Vorläufigen einrichten. Oder postmoderner ausgedrückt: Wer auf den SOA-Zug springt mit der Hoffnung, endlich der Wahrheit ein Stück näher zu kommen, der hechelt (wieder) einer Illusion hinterher. Es gibt sie nicht, die Wahrheit der Softwarearchitektur, die eine oder andere für das Unternehmen oder auch nur eine Applikation optimale Architektur.

Es gibt immer nur temporär angemessene Strukturen, die noch nicht einmal wie geplant implementiert werden können. Insofern ist jeder real existierender Code immer suboptimal in der einen oder anderen Hinsicht. Immer. Unausweichlich. Vor allem, solange man an ihm noch zu einem anderen Zweck als der Optimierung seiner Struktur in Bezug auf währenddessen konstante und durch langwierige Implementation inzwischen wohlbekannte Anforderungen hält.

Im Kern jeder SOA, d.h. der Manifestation der SOA-Prinzipien oder überhaupt irgendwelcher Architekturprinzipien muss daher Anpassungsfreundlichkeit stehen. Design for Change ist nie wichtiger gewesen. Design for Change ist quasi die Metaebene der Agilitätsgrundsätze.

Das bedeutet aber natürlich nicht, dass Sie keinen Plan haben sollten. Das bedeutet auch nicht, dass es keine guten oder weniger guten Architekturen für bekannte Anforderungen gibt. Es bedeutet nur, dass Sie kein Gefühl von Angekommen entwickeln sollten. Architektur ist die Kunst der Strukturierung und Ordnung des ewig Vorläufigen.

Egal, welche Technologie Sie heute einsetzen, egal, welcher Schule Sie folgen... das alles wird veralten und Ihre Implementationen sind zu erneuern.

Und was bedeutet das für schon existierende Strukturen? Dazu mehr bei Gesetz 4 der Softwareentwicklung.

OOP 2008: Mehr Produktivität und mehr Ausbildung statt Experteneinwanderung

Heute mal aus gegebenem Anlass nicht das Thema SOA im Zusammenhang mit der OOP 2008 ;-) Heute mal das Thema Fachkräftemangel. heute.de titelte neulich schon "Experten verzweifelt gesucht" und ich hatte gestutzt. Der IT-Fachkräftemangel hat natürlich auch vor meinem Tätigkeitsfeld nicht halt gemacht: .NET-Experten werden von vielen meiner Beratungskunden gesucht - aber ich kenne keinen .NET-Experten, der frei für einen Wechsel wäre. Stellenangebote suchen also Nachfrage. Doch die bleibt aus...

Gestutzt hatte ich dann ob des eiligen Lösungsvorschlags des Verbands Bitkom: gesteuerte Zuwanderung. Den halte ich nämlich für genauso kurzsichtig wie am Problem vorbei:

1. Selbst wenn die Zuwanderung von geeigneten IT-Experten tatsächlich in ausreichendem Maße motiviert werden kann (in Indien? oder in China? oder in Russland?), dann scheint es mir nicht genauso einfach, diese IT-Experten auch wieder los zu werden, wenn eine der unzweifelhaften Zukünfte "IT-Expertenüberschuss" oder "IT-Rezession" eintritt. Einfach einen IT-Experten-Hahn aufdrehen zu wollen, um einen akuten Mangel auszugleichen, ist schlicht naiv und kurzsichtig. Seit 1927 sollten solch pauschale Forderungen einfach nicht mehr zum Repertoire nachdenkender Wirtschaftsteilnehmer gehören.

2. Die vorstehende Bedingung "geeignete IT-Experten" halte ich für grundsätzlich nicht erfüllbar. Ausländische IT-Experten haben einfach nicht in genügend großer Zahl die sprachlichen und kulturellen Ausstattungen, um so prompt, wie es die IT-Branche gern hätte, denn auch tatsächlich einsatzfähig zu sein. Softwareentwicklung im Speziellen ist nicht "dumpfes einhacken von Quellcode", sondern Wissensarbeit in einem oder besser mehreren sozialen System. Die Kommunikationsfähigkeit, die persönliche Ausdrucksfähigkeit ist hier besonders wichtig. Und die profitiert wiederum von einer gemeinsamen Kultur. Wenn die schon zwischen Amerikanern und Deutschen in der Zusammenarbeit schwer zu finden ist, dann allemal zwischen Deutschen und Indern oder Kasachen usw. Das hat nichts mit Diskriminierung zu tun oder einem Zweifel an den geistigen Fähigkeiten der Bewohner kulturell entfernter Ländern, sondern schlicht mit der Realität von Kommunikation.

3. Das Problem des IT-Expertenmangels schein so eindeutig: Es fehlen Menschen, um Arbeit wegzuschaffen. Aber ist das wirklich so? Bei gegebener Menge kann die Arbeit ja auf zweierlei Weise erledigt werden: Mit vielen Menschen und niedriger Produktivität - oder mit weniger Menschen bei hoher Produktivität. Warum werden aber nur mehr Menschen gefordert und nicht mehr Produktivität? Ist die denn schon so hoch, wie sie sein könnte? Mit Verlaub, ich meine, an der Schraube könnte noch etwas gedreht werden. Damit will ich nicht einer 40+ Stunden Woche das Wort reden und meine auch nicht, dass Programmierer schneller tippen sollten. Ich glaube vielmehr, dass viele Softwareentwickler heute ganz einfach schlecht ausgebildet sind und deshalb vergleichsweise unproduktiv. Das wissen sie nur selber nicht und ihre Chefs wissens es auch nicht. Wie kann das sein? Es fehlt einfach ein Vergleich und es fehlt ein Erwartungshorizont. Vergleiche werden nur mit eigenen früheren Leistungen angestellt - aber nicht personen- oder gar unternehmensübergreifend. Der beste Beweis dafür ist der weit verbreitete Mangel an Produktivitätsmessungen als Grundlage für Projektabschätzungen. Welcher Entwickler misst denn schon, wie lange er für die Realisierung einer Aufgabe braucht? Und das ist ja nur der Anfang. Selbst wenn er messen würde, wüsste er nicht, ob er mit dieser Leistung über oder unter dem Durchschnitt (den niemand kennt) liegt.

Ich bin sicher, dass es gewaltige Produktivitätsreserven in der Softwareentwicklung gibt. Und die können gehoben werden, ohne neue Tools einführen zu müssen. Es ist alles schon da! Werkzeuge und Techniken und Technologien müssen einfach nur vernünftig genutzt werden. Dazu bedarf es aber - horribile dictu! - Aus- und Weiterbildung und Reflektion. Es bedarf harter und auch weicher Kompetenzen!

4. Aber auch nach einer Produktivitätssteigerung in der Softwareentwicklung wird wohl noch eine Fachkräftelücke vorhanden sein. Was tun mit der? Wie wäre es, wenn denn die Branche selbst mal mehr in die Ausbildung investierte? Sich auf Universitäten und BAs und Umschulungen zu verlassen, ist doch kein bewusster Umgang mit der wesentlichen Ressource Wissen bzw. Mensch. Gute Mitarbeiter wachsen nicht auf den Bäumen und werden auch nicht in Indien und anderswo in Retorten gezüchtet. Gute Mitarbeiter erhält man durch Ausbildung, durch eigenen Ausbildung, denn schließlich soll der Mitarbeiter ja möglichst passgenau sein. So lauten ja auch die - oft naiv optimistischen - Stellenausschreibungen. Da wird meist einer gesucht, der eigentlich nur im eigenen Unternehmen gefunden werden kann, weil er sonst eine spezifische Kompetenz gar nicht haben kann. Insbesondere müssen die Unternehmen in eigenen Ausbildung investieren, die Kompetenzen suchen, die die allgemeinen Curricula nicht abdecken. Wer auch nur ein wenig von der Wichtigkeit der Softskills für die Wissensarbeit verstanden hat, wird nicht umhin kommen, in sie zu investieren - denn sonst finden sie sich auf keinem Lehrplan und auch nicht in der "Schule des Lebens". Aber damit nicht genug! Der für mich besonders relevante Bereich der .NET-Kompetenzen ist in den allgemeinen Ausbildungseinrichtungen unterrepräsentiert. Wer also heute .NET-Entwickler sucht... der kann lange suchen. Besser er überlegt sich, wie er selbst ausbilden kann.

Dass ich mit dieser Ansicht nicht allein stehe, hat mir die Meldung "IT-Branche muss mehr ausbilden" zum Glück gezeigt. Es scheint, in der Politik ist noch nicht aller gesunder Menschenverstand verloren.

OOP 2008: Planlose Softwareentwicklung!

Angeregt durch die Diskussionen rund um SOA im Blog der OOP 2008 habe ich nochmal meine Gedanken schweifen lassen... Gewöhnlich beschäftige ich mich ja nicht mit den großen Enterprise Architekturen, sondern versuche erstmal die .NET-Entwicklergemeinde vom Wert bewusster Architektur im Kleineren, "nur" für ihre Anwendungen zu überzeugen. Aber wo die Diskussion zu SOA schon so lebhaft ist, kann ich mich ihr auch nicht ganz entziehen. Allemal nicht, da sie - unausgesprochen zwar, aber dennoch - etwas mit einem Thema zu tun hat, das mich auch schon interessiert hat: die Beherrschung der Komplexität von Software. Heute nun bin ich beim Gedanken schweifen lassen über eine verwegene Idee in dieser Hinsicht gestolpert:

SOA hat ja sicherlich einiges mit Komplexität zu tun. Oder überhaupt geht es bei großen und noch größeren Softwaresystemen immer um Komplexität, egal ob sie nun etwas mit SOA zu tun haben oder nicht.

Nun scheint es mir, als versuche man diese Komplexität durch gute Planung in den Griff zu bekommen. Hört sich doch auch vernünftig an, oder? Komplizierte, ja komplexe Produkte wollen geplant sein. Vom Auto über einen Airbus bis zur Unternehmenssoftware. In meinen Publikationen und bei meinen Beratungsterminen spreche ich auch immer wieder von Planung für gute Architektur, d.h. bewusster, kontrollierter Anordnung und Verbindung von Softwareartefakten.

Jetzt die verwegene Idee: Was, wenn eben diese Planung kontraproduktiv wäre? Was, wenn Planung umso kontraproduktiver wäre, je komplexer die Software ist? Was, wenn zentrales Vordenken von komplexer Software eine Kontrollillusion wäre? Die Phantasie von "Maschienenbauern" und ein Relikt aus dem 19. Jahrhundert?

Wie bin ich auf solch eine verwegene Idee komme? Ich hatte meinen Blick mal wieder über den Rand meines Laptop in die Welt gerichtet. Eine Stunde beim Sport hatte mir den Kopf freigepustet von überkommenen Softwareentwicklungsvorstellungen. Was ich dann jenseits meines Laptops sah, war eine Welt der Komplexität. Komplexe Systeme überall: vom Ameisenhaufen bis zur globalen Wirtschaft. Und all diese Systeme... ohne Planung.

Es gibt keinen Lenker der Ameisen und Bienen. Es gibt keine zentrale Planung unserer Städte. Auch die Bundesregierung plant nicht zentral. Die heute vorherrschende Ideologie von Demokratie und darauf aufsetzender Marktwirtschaft ist geradezu die Antithese jeder zentralen Planung und Kontrolle. Es gibt vielleicht eine gewisse Lenkung... aber Planung?

Eine Uhr, ein Auto, eine Fabrik... ja, die werden noch geplant. Aber die sind im Vergleich zu (großer) Software auch noch nicht wirklich komplex. Das liegt daran, dass deren Umwelten ungleich stabiler sind, als die von Software. Wirklich komplexe Situationen und "Gebilde" jedoch, die entziehen sich Planung und zentraler Kontrolle.

Auch wenn es Städteplaner gibt, so plant niemand Städte langfristig im Voraus. Oder zumindest werden sie nicht im Detail im Voraus geplant. Städte sind wachsende Gebilde, die vor allem von unzähligen individuellen Entscheidungen geprägt werden. Dasselbe gilt für die Wirtschaft. Das ist geradezu kafkaesk, denn damit ist das große Ganze, das wahrhaft Komplexe nicht mehr in der Verantwortlichkeit Weniger. In einem Schwarm ist bei einem Missstand "der eine Schuldige" nicht mehr auszumachen; es gibt ihn einfach nicht. Dafür ist der Schwarm flexibel, anpassungsfähig.

Auf die Softwareentwicklung bezogen ergibt sich aus dieser Erkenntnis die Frage: Versuchen wir immer noch oder schon wieder zuviel zu planen? Wäre mehr Planlosigkeit, die Abwesenheit eines klaren Planes eine bessere Strategie für Erfolg? Die Agilitätsbewegung hat ja schon in gewisser Weise den Plänen den Kampf angesagt. Inkremente statt Wasserfall, kleine Schritte statt großer Sprung. Aber ist das vielleicht immer noch zuviel? Müssen wir uns vielleicht noch radikaler vom Planen verabschieden?

Probate Mittel, um Komplexität zu beherrschen sind Hierarchien, Ordnung, Entkopplung. Die ultimative Strategie ist jedoch überhaupt die Abgabe von Kontrolle. Wo Komplexität nicht mehr beherrscht werden muss, stellt sie auch kein Problem dar. Dazu bedarf es natürlich des Vertrauens. Vertrauen in diejenigen, an die die Kontrolle abgegeben wird, die unendlich vielen kleinen "Rädchen im Getriebe", die lokale Entscheidungen treffen. Und Vertrauen an die grundlegenden Gesetzmäßigkeiten, die Rahmenbedingungen.

Meine verwegene Idee zum Umgang mit komplexer Software ist also, diese Software nicht mehr zu planen, sondern sie entstehen zu lassen, sie wachsen zu lassen. Komplexe Software braucht keine Planer, die tausende Webservices so oder anders schneiden. Komplexe Software braucht keine vorgedachte Architektur.

Statt eines Masterplans braucht komplexe Software vielmehr Grundwerte und -gesetze, einfache Rahmenbedingungen, die Möglichkeit zum Experiment und maximale Kommunikationsmöglichkeiten für die real-time Kollaboration zwischen allen Beteiligten. Komplexe Software braucht ein Ökosystem, in dem sie sich entwickeln kann. Und das bezieht sowohl Entwickler wie Anwender und Kunden mit ein.

Die Funktion komplexer Software ist dann kein Ergebnis mehr von zentralem Kundenwunsch gechannelt durch Analysten und Architekten, sondern emergent. Komplexe Software ist dann das Ergebnis eines Schwarms und spiegelt die Bedürfnisse und die Intelligenz der Masse wider.

Der Gewinn? Eine maximal flexible Software, die sich ständig den Umweltanforderungen anpasst.

Die Herausforderungen? Ganz ohne alle Vordenken geht es natürlich am Ende doch nicht. Aber die Planung ist verlagert auf die Meta-Ebene. Statt konkreter Artefakte werden allgemeine Regeln für Artefakte geplant. Führung bedeutet nicht mehr Kontrolle der Planeinhaltung, sondern Hilfe zur Regeleinhaltung. Und Führung muss sicherstellen, dass der Informationsfluss ungehindert ist.

Ich weiß, das klingt alles ein wenig utopisch/theoretisch. Wie genau so ein Zeitalter der Post-Agilität, der Schwarmentwicklung aussieht, weiß ich auch noch nicht. Es gibt sicher auch gewaltige technische Hürden zu überwinden; so ist das vorherrschende Modell von Software als Text dafür zu starr, Gleiches gilt auch für die Datenbankschemata.

Aber ich bin mir nach diesem Gedankenausflug recht sicher, dass die aktuellen Antworten auf den Trend zu immer leistungsfähigerer, immer komplexerer Software ungenügend sind - zumindest solange ein wie immer gearteter Drang zu steigender Kontrolle dahinter steht. Denn Kontrolle steht im Widerspruch zu Komplexität. Wenn aber eines sicher ist, dann ist es, dass die Komplexität unserer Software bzw. des Gesamtsystems Mensch-Software oder Unternehmen-Software weiter steigt. Die Kontrolle kann also nur geringer werden - ob wir es wollen oder nicht -, wenn wir passgenaue und überlebensfähige Softwaresysteme haben wollen.

Die Steigerung des Superlativs - oder: Rekursive Veranstaltungsprofilierung

Gerade flatterte mir der Flyer der nächsten Auflage eines bekannten deutschen .NET-Entwicklerevents ins Haus. Dass es in 2008 noch andere Veranstaltungen neben dem Hypermegasuperevent von Microsoft Deutschand anlässlich des Launch von VS2008 & Co geben könnte... das hatte ich schon fast nicht mehr auf dem Zettel.

Und auch der Veranstalter schien Mühe zu haben, sich mit der "Übermacht" zu arrangieren. Was bleibt denn auch noch zu sagen, wenn Microsoft drei Tage lang ein Feuerwerk zu .NET 3.5, VS2008, SQL2008, Windows Server 2008 und auch noch Sharepoint abfackelt? Da fällt die Profilierung auch eines etablierten technologieorientierten Events schwer.

Aber... der Veranstalter hat für sich einen Weg gefunden. Gibt es doch nichts Gutes, was nicht noch besser werden könnte, oder? In der Vergangenheit hat das ja auch schonmal funktioniert. Früher, in den 1990ern, da ging es bei Entwicklerveranstaltungen "nur" um Technologien und vielleicht mal um "Tipps und Tricks". Das war dann in den Jahren nach 2000 nicht mehr genug. Mehr Events stellten mehr Technologien vor. Wie also sich profilieren? Klar, Technologien kann jeder - aber nicht jeder kann sie auch wirklich gut einsetzen, hat wirklich, wirklich Erfahrung mit ihnen. Wohl also dem, der die besten (!) Wege zu ihrem Einsatz vermittelt. Und schon waren nicht mehr einfach nur Technologievorträge auf den Entwicklerveranstaltungen angesagt, sondern "Best Practice"-Demonstrationen. Ging es vormals um den Einsatz oder vielleicht sogar guten/richtigen Einsatz von Technologien, so zeigte man nun nicht weniger als ihren besten! Auf gut folgte also nicht besser, sondern gleich am besten. Wer will sich auch schon mit dem Komparativ abgeben, wenn man doch den Superlativ in der Tasche hat?

Nur, was kommt nach dem Superlativ? Früher wurde der Begeisterung mit Qualifikationen wie "toll" und "super" Ausdruck verliehen. Darauf folgte dann in den 1990ern "mega". Für die Zukunft bieten sich "giga", "tera" und "peta" an ("hyper" ist nicht wirklich salonfähig, oder?); um 2057 werden die Medien deshalb wohl vom "Peta Musikevent des Jahrtausends" berichten, wenn die altersgreisen Jungs (?) von Tokio Hotel auf die Bühne gerollt werden - oder so.

Die Veranstaltungen für die .NET-Community dürfen diese Entwicklung natürlich nicht an sich vorüberziehen lassen. Profilierung tut Not. Mit Microsoft Elefantenevent und auch ohne. Mit einem simplen "giga", "tera" usw. zur Qualifikation des eigenen Programms ist es aber natürlich nicht getan. Das wäre für diese Branche zu naheliegend. Der findige Veranstalter, dessen Flyer ich ins Haus bekam, hat sich daher eine ganz andere Strategie zur Steigerung einfallen lassen.

Seine Agenda enthält nicht mehr nur "Best Practice"-Vorträge. Nein, bei ihm gibt es jetzt... "Best of Best Practices"! Der grammatikalische Superlativ wurde durch eine Anwendung auf sich selbst auf eine neue Ebene gehoben: Das Beste vom ohnehin schon Besten wird es zu sehen und zu hören geben!

Welch ein Einfall! Er ist der Branche wahrlich würdig! Denn die Anwendung des Besten auf das Beste ist ja quasi eine Rekursion: p2008 = Best(Best(p2007));

Damit ist auch die ultimative Formel für alle Zukunft gefunden. Es gibt nun kein Profilierungsproblem mehr. Denn die Formel lautet für 2009 ganz einfach: p2009 = Best(Best(Best(p2007))); Ende nächsten Jahres werde ich also wohl einen Flyer im Postkasten haben, auf dem steht "Best of Best of Best Practices". So ist man Microsoft - und allen anderen - immer einen Schritt, äh, eine Rekursion voraus. Brilliant! Beneidenswert!

Oder...

Vielleicht auch nicht. Denn eine (grammatikalische) Steigerung bedeutet ja auch immer eine Filterung. Die Menge des Besten - wie z.B. in Best Practice - ist immer eine Untermenge des Vorhandenen oder des schon Guten. Wenn dann vom Besten wieder nur das Beste genommen wird... dann schrumpft die Menge weiter.

Was bedeutet das für einen Event, der im Umfang ja aber nicht schrumpfen will und kann? Es bedeutet, dass er eben nicht wirklich dem Motto "Nur das Beste vom Besten" treu sein kann. Schade.

Schade, dass die Profilierung nur über eine Steigerung versucht wird. Das ist wie bei den "Rabatt" und "Sonderpreis" und "Sale" Schildern in den Schaufenstern allerorten heutzutage. Nur der Preis zählt. Nur die besten Best of Best Practices zählen. Als gäbe es nichts außer Best Practices - von denen wir ja übrigens schon seit knapp 3 Jahren zum Thema VS2008 aka Oracs hören. Irgendwann müssen sie doch mal alle vermittelt worden sein die Best Practices und damit auch die Best of der Best Practices, oder?

Aber ich verstehe schon. "Best Practices" hört sich ja auch für die Zielgruppe immer wieder, immer noch höchst attraktiv an. Wer will denn schon selbst durch die Niederungen des Technologiekompetenzerwerbs gehen? Besser, man kann auf dem Erfahrungsniveau von Best Practices einsteigen. Und noch besser, man kann bei den Best of Best Practices einsteigen. Oder?

Am Ende aber... können auch Best of Best of Best of Best of Practices die eigene Erfahrung nicht ersetzen. Und sie leisten auch immer noch nicht den Transfer auf das eigene Projekt. Denn gewöhnlich werden selbst die Best Practices relativ zusammenhanglos, eben technologieorientiert dargestellt.

Ich würde also sagen: "Best Practices" sind genug. Der Superlativ darin reicht aus. Auf sie nochmal ein "Best of" zu setzen, ist unnötig und verwirrend. Es leistet einem quantitativen Denken Vorschub, das wir hinter uns lassen sollten. Wir brauchen nicht mehr, sondern Anderes. Wir brauchen neue Qualitäten, nicht größere Mengen. Innovationen stecken also leider nicht in "Best of Best of...".

OOP 2008: Transformers to the rescue

Im OOP 2008 Konferenz-Blog habe ich grad wieder einen Beitrag von Michael Stal zum Thema "SOA-Leichtgläubigkeit" gelesen. Der hat mich an eine Analogie gemahnt, die mir neulich nach einem Kinobesuch kam. Ich hatte den Film "Transformers" gesehen und war begeistert.

Nicht nur war der Film von seinen Spezialeffekten (wenn man sowas mag ;-) einfach toll - er hat mir auch etwas über Softwareentwicklung klar gemacht. Plötzlich hatte ich ein Bild für das in der Hand für ein weit verbreitetes Missverständnis.

Das Missverständnis ist: Software ist wie eine Maschine. Man kann sie so planen und bauen wie eine Uhr oder ein Auto.

Dieses Missverständnis halte ich für die Ursache vieler Probleme mit Softwareprojekten. Es übt einfach viel Einfluss auf Architekturen und Prozesse aus. Es macht sie starr und linear.

Software ist aber nicht wie eine Maschine, Software ist eher wie ein Lebewesen oder eine Stadt. Sie muss sich ständig neuen Anforderungen anpassen. Unter Beibehaltung ihrer Identität, muss sich ständig... ihre Form verändern, um sich neuen Anforderungen anzupassen. Die interne wie die externe Form.

Wenn schon Software mit Maschinen vergleichen, dann mit Transformers. Das sind nämlich Maschinen, die ihre Form verändern können: eben noch Roboter, werden sie zum Flugzeug oder Lastwagen, wenn es die Situation erfordert.

Wer also weiterhin der Vorstellung anhängen möchte, Software seien Maschinen doch so ähnlich, der schaue sich also den Film "Transformers" an und überlege einmal, wasfüreine Architektur denn so ein Transformer wohl hat, um so flexibel zu sein. Und dann gehe er oder sie noch darüber hinaus! Denn Software muss noch flexibler sein als ein Transformer!

Um auf Michaels Posting zurückzukommen: Wer flexible, evolvierbare, langlebige, anpassungsfähige Software haben will, der muss all diese Eigenschaften in sie von vornherein hineinplanen. Eine SOA kann daher nicht wirklich als "Zuckerguss" auf existierende Systeme "drübergegossen" werden. SOA beginnt vielmehr vor allen Tools im Kopf und zeigt sich in Planung wie Prozess. Eine SOAP-Schnittstelle und ein ESB machen noch keine SOA. Sie mögen vielleicht notwendige Voraussetzungen sein. Vielleicht. Aber sie sind keineswegs hinreichend.

Etwas überspitzt gesagt: Eine SOA implementieren - oder sogar noch allgemeiner: langlebige Software entwickeln - heißt, von den Transformers zu lernen ;-)

Impressionen von der prio 2007

Nun ist sie gelaufen, die prio conference. Seit dem Frühsommer hatte ich mich gedulden müssen, ob die von mir ausgesuchten Sprecher und Themen vom kritischen Publikum für gut befunden würden. Würde die prio 2007 als Konzeptkonferenz an den Erfolg im Vorjahr anschließen können?

Aber jetzt bin ich entspannt. Das Konzept der prio ist wieder aufgegangen. Schon am ersten Tag bekam ich spontan sehr positives mündliches Feedback von den Teilnehmern. Und auch nach der Konferenz wurden die Teilnehmer über ihre Feedbackbögen hinaus nicht müde, ihrer Begeisterung Ausdruck zu verleihen:

• "Erstmal Glückwunsch zur wirklich gelungenen Konferenz. Die Vorträge die ich gesehen habe fand ich alle gut bis sehr gut.", Boas Enkler
• "Mir hat diese Konferenz viel Spaß bereitet wie auch viel neues Wissen vermittelt und interessante Anregungen gegeben.", Andreas Hönick
• "Die Vorträge und die Organisation waren super.", Jürgen Wäldele

Puh. Da fällt mir ein Stein vom Herzen. Sprecher und Inhalte sind bei den Teilnehmern gut, nein, sehr gut angekommen. Mit der Wahl des Konzeptthemas "Softwarequalität" haben wir also richtig gelegen. Das hat dann zwar nicht ganz die 300 vom Veranstalter Penton gewünschten Teilnehmer anziehen können... aber das hatte ich persönlich auch nicht erwartet. Sich mit "Softwarequalität" zu beschäftigen, erscheint einfach nicht so lohnend wie mit den neuesten Hype-Technologien. Doch die anwesenden Teilnehmer haben deutlich gemacht, dass die prio zurecht darauf gesetzt hat, dass es genügend Entwickler mit Weitblick und Professionalität gibt, die über den Tellerrand der tagesaktuellen Technologien schauen und nach Wegen suchen, die Qualität ihrer Software nicht nur durch ein neues Tool zu steigern.

So sind denn auch eher theoretische Vorträge wie "Architect to test" von Stephan Maier (links) und "Softwarequalität durch das richtige Vorgehen steigern" von Christian Bunse (rechts) gut angekommen, die sich auf den üblichen technologieorientierten Entwicklerveranstaltungen nicht finden.

Das galt übrigens auch für den Softskill-Vortrag, den Renate Klein und ich zusammen gehalten haben. Im letzten Vortragsslot des ersten Konferenztages haben wir ganz untechnisch 75min darauf verwandt, harten Softwareprofis die Wichtigkeit "weicher Kompetenzen" nahezubringen. Mit Erfolg, wie sich herausstellte. Niemand hat den Saal verlassen und wir bekamen anschließend einiges ausdrücklich positives Feedback.

Neben in der .NET Community eher unbekannten, nichtsdestotrotz aber guten Sprechern - als besonders kompetent (wenn auch manchmal angesichts seines sehr französischen Akzents schwer verständlich) habe ich Patrick Smacchia empfunden, der sein Architekturbewertungswerkzeug NDepend vorgestellt hat -, waren aber natürlich auch genauso gute wie beliebte Sprecher wie Christian Weyer (links) oder Dominick Baier (rechts) mit von der Partie.

Das Engagement der Sprecher endete aber nicht - wie sonst üblich - mit ihren Vorträgen! Nein, bei der prio waren die Sprecher auch noch nach der fachlichen Teil der Konferenz für die Teilnehmer da. Bei der Abendveranstaltung am ersten Konferenztag legten sie sich beim Ausschank und beim Servieren im Baden-Badener Löwenbräu mit Bierschürze hinter und vor der Theke ins Zeug.

dotnetpro-Autor Jörg Neumann (link) war sogar eigens für diesen Einsatz angereist. Und Neno Loje (rechts) war - wie man sieht - auch ganz in seinem Element.

Tilman Börner - Chefredakteur der dotnetpro und "Schirmherr" der prio - und ich waren denn auch sehr zufrieden mit dem Einsatz der Sprecher bei Tag und bei Nacht.

Nach der prio ist aber natürlich vor der prio ;-) Und so stürzen wir uns denn auch umgehend in die Planung der nächstjährigen Konferenz. Seien Sie gespannt auf´s Thema... Ich hoffe, wir sehen uns dort.

OOP 2008: SOA = System Oriented Attitude

Implodiert der SOA-Stern aufgrund von Überfrachtung mit Erwartungen bald? Endet er als schwarzes Loch und reißt viele Investitionen mit sich? Hm... Solange SOA als eine Sache von Technologien angesehen wird, kann ich mir solche eine dunkle Zukunft durchaus vorstellen.

Ich habe natürlich nichts gegen Technologien wie Web Services, ESB und Standards wie SOAP, WSDL. Alles ganz wunderbar. Dass die sich nicht alle in gleicher Weise durchsetzen und jetzt zum Beispiel REST und POX in aller Munde sind, macht ja nichts. So läuft halt die Evolution. Sie lässt sich nicht am Reißbrett planen. Nur weil SOAP eine gute Idee war, heißt das nicht, dass es auch alle glücklich macht.

Wenn SOA scheitern sollte - wobei zunächst zu klären wäre, wie "Scheitern" eigentlich erkannt werden kann, was es bedeutet -, dann liegt das meiner Meinung nach nicht an diesen Technologien und Konzepten. Ein Messer ist nicht schuld, wenn ich mich mit ihm schneide. Meine unsachgemäße Nutzung des Messers ist dann mein Problem. Dasselbe gilt für die ESB, SOAP, WCF & Co. Ein Messer kann ich richtig und falsch nutzen. Genauso die SOA Technologien/Konzepte. Und ein Messer macht noch keine "Ente a l'orange". Für ein leckeres Mahl muss man Kochen können und nicht nur Werkzeuge haben.

Können die Unternehmen und Projektteams, die auf den SOA-Zug gesprungen sind, aber nun auch kochen? Die Industrie hat ihnen eine ganze Werkzeugpalette für SOA-Menüs in die Hand gedrückt - doch wie steht es mit dem Kochen? Da habe ich nämlich meine Zweifel, ob die Befähigung zum Kochen auch schon genauso weit verbreitet ist, wie die Werkzeuge.

Nicht, dass die SOA-Köche nicht die Knöpfe an den Werkzeugen bedienen könnten. Das lernen sie in teuren Schulungen. Mir geht es eher um eine noch grundlegendere Haltung. Als Hobbykoch kann ich auch irgendwie Messer und Pürierstab bedienen. Aber was kommt am Ende raus? Das big picture, der ganzheitliche Blick aufs Kochen, der fehlt mir. Solange ich nur irgendwie satt werden will, ist der auch egal. Aber wenn ich ein wirklich schönes Menü zusammenstellen und auch noch zubereiten will... dann muss ich einen solchen Blick haben.

Dito beim Thema SOA. Nein, bei SOA ist das sogar noch viel wichtiger. Denn Software ist soviel komplexer als selbst ein Meistergericht. Ich glaube deshalb, dass SOA solange kein wirklich breiter Erfolg wird, solange es mit bestimmten Werkzeugen und einer gewissen Softwaregröße assoziiert wird. SOA als Service Oriented Architecture zu bezeichnen, empfinde ich deshalb als kontraproduktiv. "Service" suggeriert, dass es um spezielle Technologien geht. "Architecture" suggeriert, dass damit nur ab einer bestimmten Größenordnung zu rechnen ist.

Dabei kann SOA nicht wirklich ein Erfolg werden, wenn man sich nur darum kümmert, wie Software im Großen gebaut und zusammengeschaltet werden soll. Genausowenig kann ökologisches Verhalten eine Sache von Großunternehmen allein sein. Ökologisches Verhalten beginnt bei jedem Einzelnen im täglichen Leben... und kommt dann auch bei großen Institutionen an. Auf die Softwareentwicklung übertragen bedeutet das: Solange "Serviceorientierung" nicht eine Sache jedes einzelnen Entwicklers ist, wird sie im Großen keinen nachhaltigen und breiten Erfolg haben.

"Serviceorientierung" im Kleinen, d.h. für jeden Entwickler, ist aber natürlich nach derzeitiger Definition ein Widerspruch in sich. Deshalb plädiere ich für eine Neuinterpretation des Akronyms "SOA". Ich würde es gern als "System Oriented Attitude" verstehen. "Attitude" steht dabei für Haltung, d.h. eine ganz grundlegende Sicht auf die Welt der Softwareentwicklung im Allgemeinen. Und "System" steht für eine Betrachtung von "Software als System" und zwar als komplexes System mit vielen Hierarchie-/Abstraktionsebenen. Und auf jeder dieser Ebenen muss ständig gegen die (schleichende) Zunahme von Komplexität (oder Entropie) gekämpft werden. Das ist keine Sache von Enterprisearchitekten, sondern jedes Entwicklers. Immer.

Services sind da nur ein Mittel auf einer Hierarchieebene. Komponenten sind ein anderes, kaum wirklich genutztes. Klassen ein weiteres. Solange Anwendungen aber Spaghetti-Klassenmodelle enthalten und binäre Komponenten nicht wirklich zur Strukturierung von Software eingesetzt werden und noch Unsicherheit über die Rolle eines SQL Servers, der C#-Code ausführen kann, herrscht... solange ist nicht zu erwarten, dass die bisherige SOA-Idee es schon in den Olymp der Softwareentwicklung geschafft hat. SOA ist mehr als ESB und SOAP. Wer SOA nicht als systemorientierte Haltung begreift und sie bei jedem Projekt - ob klein oder groß - von vornherein atmet, der wird keinen wirklichen Erfolg mit serviceorientierten Architekturen haben.

Meine Empfehlung daher: Wer Serviceorientierung haben will, der fange mit einer Beschäftigung mit der Systemtheorie  und systemischem Denken an. Als durchaus ernüchternden Start kann ich Dörners "Logik des Misslingens" empfehlen. Das Buch macht sensibel für Komplexität.

OOP 2008: Agilität + Architektur?

Im Blog der OOP 2008 fragt Michael Stal nach der Lösung für die Addition "Agilität + Architektur". Architektur setzt er dabei vor allem in Bezug zur Zahl der an ihr beteiligten Köpfe vom einzelnen Architekten bis zur ganzen Entwicklergruppe eines Projektes.

Ohne nun sagen zu wollen, dass Agilität oder Softwarearchitektur leichte Geschäfte seien, habe ich bei dieser Frage aber doch gestutzt. Warum scheint sie überhaupt so schwer zu beantworten? Sie zu stellen suggeriert geradezu einen Gegensatz zwischen Agilität und Architektur. Wenn Agilität mit Flexibilität zu tun hat, steht dann Architektur für Inflexibilität? Hm...

Ich glaube, um die Addition zu lösen, ist zunächst ein Schritt zurück notwendig. Agilität und Architektur müssen von ihrer Absolutheit befreit werden. Weder Architektur noch Agilität sind Selbstzwecke. Hier mein Versuch der Reduktion auf das Wesentliche:

Agilität ist vor allem eine Haltung, die Unsicherheit und Unwissen eingesteht. Sie erkennt an, dass Software sich ständig einer wechselnden Umwelt anpassen muss. Softwareentwicklung ist für sie nur als Handlung-Feedback-Kreislauf denkbar, da Software und Umwelt rekursiv gekoppelt sind. Agile Softwareentwicklung bedeutet konstantes bewusstes Lernen mit allem, was dazu gehört (z.B. eine Vielfalt von Wahrnehmungsorganen, Reflektion, Fehler).

Architektur beschäftigt sich mit Plänen. Pläne sind Abstraktionen für Zukünftiges und Gegenwärtiges. Eine Softwarearchitektur ist zunächst die Beschreibung der zukünftigen Struktur einer Software. Und später ist sie (im besten Fall) nah an ihrer Implementation und dient als Landkarte. Beide Funktionen erfüllt sie durch Abstraktion: Die Architektur ist nicht die Implementation, sondern beschreibt sie nur vereinfacht.

Und was bedeutet das konkret? Wenig. Denn diese Definitionen haben nicht den Zweck, Konkretes zu liefern. Eine agile Haltung mag zum Konzept der Iterationen führen - aber über die Länge einer Iteration kann und soll sie keine Aussage machen. Und Architektur mag zwischen lokalen und entfernten Aufrufen unterscheiden - aber über die zu nutzende Technologie macht der Begriff Architektur keine Aussage.

Sowenig Konkretes mag nun den einen oder anderen verwundern oder gar ärgern. Was nützen denn allgemeine Konzepte für die harte Projektrealität? Oder ist denn nicht eine Collective Code Ownership der beste Weg zur gemeinsamen Arbeit an Software?

Sicherlich, am Ende müssen konkrete Handlungsanweisungen stehen. Doch zur Beantwortung der allgemeinen Ausgangsfrage nach der Summe von Agilität und Architektur bzw. dem Verhältnis zwischen beiden, sind nur gleichfalls allgemeine Definitionen hilfreich.

Agilität ist also quasi ein Synomym für Lebendigkeit, das Leben, denn Leben heißt permanente Anpassung, heißt konstantes Lernen, funktioniert nur durch Versuch und Irrtum. Doch Achtung: Eine Bakterie, ein Molch, ein Elefant, sie alle leben und verhalten sich doch ganz unterschiedlich. Alle sind angepasst an ihre Umwelt. Im Umkehrschluss bedeutet das, Agilität tut gut daran, wenn sie sich dem Lernen verpflichtet fühlt, keine Absolutheiten zu verkünden, sondern zunächst "nur" zur Ermittlung (!) angemessener Verhaltensweisen zu animieren. Was angemessen ist, bestimmt die Umwelt, zu der die Verhaltensweisen passen müssen.

Architektur auf der anderen Seite ist ebenfalls ein Synonym für Anpassung. Sie beschreibt das, was nach aktuellen Kenntnisstand über eine Umwelt eine zu ihr passgenaue Software ist. Doch nicht nur das! Architektur ist auch ein Synonym für Nachhaltigkeit und damit ein Gegengewicht zum "sprudelnden Leben". Zwar führt "sprudelndes Leben", also autopoietische Systeme ohne externe Kontrolle, auch zu Passgenauigkeit - aber das nur unter hohen Verlusten und über lange Zeiträume. Um Passgenauigkeit in kürzerer Zeit zu erreichen, ist Bewusstheit nötig. Und die liefert Architektur. Architektur ist insofern eine zutiefst menschliche Disziplin. Sie verlangt Vorausschau und balancierte Entscheidungen.

Vor dem Hintergrund dieser Betrachtungen, wird die Antwort auf die Ausgangsfrage plötzlich recht einfach:

Agilität ohne Architektur ist möglicherweise das Ideal. Die Architektur einer Software ist dann emergent; sie "mendelt sich aus" in einem evolutionären Prozess. Allerdings braucht das viel, viel Zeit und viele, viele Irrtümer. Die genetische Programmierung kann davon ein Lied singen. Mit Agilität ohne Architektur einen Kunden zu seinen Lebzeiten zufrieden stellen zu wollen, ist nur für triviale Projekte realistisch. Agilität ohne Architektur ist also eine Utopie.

Architektur ohne Agilität ist wie die Reflektionen eines Einsiedlers in seiner Höhle. Bewusstsein ohne Handlung und Feedback und Fehlerkorrektur ist nutzlos und realitätsfern - wenn nicht sogar ein Widerspruch in sich. Der Wasserfall war insofern immer eine naive Kontrollphantasie.

Agilität + Architektur ist damit keine Frage, sondern die Antwort. Software-Entwicklung, d.h. ein Prozess der bei einem Ausgangspunkt startet und dessen Ende meist möglichst weit in der Zukunft liegen soll, ist ein Bildungsprozess. Und Bildung passiert nicht einfach, sondern muss sich an den Gesetzen des Lebens orientieren - es gibt z.B. keinen Nürnberger Trichter - und ein Ziel haben, d.h. Vorstellungen darüber, wie das Ergebnis aussehen soll. Agilität liefert die Lebendigkeit und Architektur die Zielvorstellung für den Software-Bildungsprozess.

Wie lang in diesem Prozess dann ein Handlung-Feedback-Zyklus ist, bestimmt die Umwelt. Wieviele Köpfe über einer Architektur zu zerbrechen sind, bestimmen Problem und Umwelt. Wer unabhängig von konkreter Umwelt und konkretem Problem aufsteht und sagt, so und so lang muss eine Iteration sein oder so und soviele Personen müssen die Architektur definieren, der handelt wider das Leben. Der ist dogmatisch. Das ist zwar auch eine Haltung - aber eine, die eher früher als später auf Ungereimtheiten und Widerstände stößt.

Sicherlich lassen sich aus den allgemeinen Definitionen von Agilität und Architektur Rahmenbedingungen oder gar Gesetzmäßigkeiten ableiten. Sie setzen sinnvollen Antworten auf Fragen wie nach der Länge einer Iteration oder der Zahl der Architekten Grenzen. Doch diese Antworten sind weniger universell als viele vielleicht gern hätten.

So bleibt am Schluss nur die Feststellung: ohne Agilität+Architektur geht es nicht. Aber wirklich einfach wird das Geschäft der Software-Entwicklung dadurch noch nicht. Wer Software entwickeln will, muss sich damit anfreunden, dass es nicht um schnell hergestellte tote Maschinen geht, sondern um langlebige, komplexe Systeme für eine sich im steten Wandel befindliche Umwelt. Software-Entwicklung hat mit Leben + Planung, mit Lebensplanung zu tun. Und das schließt Ungewissheit und Unsicherheit, also auch Fehler mit ein.