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.

Jahresendzeitveranstaltungen - Heiße Themen für einen kalten Winter

Die Außentemperaturen sinken trotz Klimawandel - aber für Entwickler bleibt die Jahresendzeit heiß. Denn drei heiße - oder coole? ;-) - Veranstaltungen liegen noch vor uns:

	Am 11. und 12. November findet im Vorfeld der prio das letzte öffentliche Rhetoriktraining für Softwareprofis des Professional Developer College statt. Noch sind Plätze zu den prio-Sonderkonditionen frei! Sicheres Auftreten, effektive Kommunikation des eigenen Wissens vor Kollegen und Community-Publikum ist erlernbar. Detailinfos findet sich hier und einen Erfahrungsbericht gibt es im Blog des College. Meine Co-Trainerin Renate Klein und ich freuen uns auf zwei intensive und spannende Tage.
	Am 12. November schließt das Rhetoriktraining vor der prio mit einer öffentlichen Abendveranstaltung ab. Die Teilnehmer des Trainings halten je einen Abschlussvortrag vor Publikum, um ihre neu erworbenen Fähigkeiten in einem realistischen Szenario unter Beweis zu stellen. Teilnehmer der prio, aber auch alle anderen Interessierten, sind daher herzlich eingeladen, am 12. November um 20h im Kurhaus Baden Baden kostenlos einem bunten Potpourri an Vorträgen zu lauschen. Wir als Trainer, aber auch die Seminarteilnehmer würden uns über ein reges und großes Publikum freuen! Auszug aus der Liste der Abschlussvortragsthemen: Agile Softwareentwicklung mit Scrum und VSTS SalsaFX - Mehr Nutzen durch mobile Intelligenz WinForms-Benutzeroberflächen automatisch testen Business Intelligence auf der Microsoft-Plattform
	Am 13. und 14. November findet dann die prio conference statt. Als Content Manager habe ich mich ins Zeug gelegt, um ein spannendes Programm zum Thema "Softwarequalität" zusammenzustellen. Noch sind auch hier Plätze für Kurzentschlossene frei. Also, auf nach Baden Baden! Im Casino kann man im November nicht nur Geld gewinnen, sondern auch viel Wissen ;-) Ich hoffe, wir sehen uns dort!
	Und am 17. Dezember findet dann noch eine Veranstaltung der besonderen Art statt. In Hamburg. Dort wird .NET im Kino gezeigt. .net goes to the movies oder kürzer: .net@movies. Mit dem Thema Web Security für .NET-Entwickler möchte Ihnen das Professional Developer College mit den Top-Referenten Dominick Baier und Christian Wenz nochmal so richtig für den kalten Winter einheizen ;-) Die Veranstaltung ist bewusst als "klein, aber fein" angelegt: max. 25 Teilnehmer können zu den eindringlichen Sicherheitsstrategiedemonstrationen und intensiven Diskussionen Einlass finden. Rechtzeitige Anmeldung sichert also hier ganz besonders einen Platz. Als Veranstalter dieses Events würde mich ganz besonders freuen, wenn wir uns dort sähen.

 

So, und jetzt, damit Sie nicht denken, ich würde immer nur in "Veranstaltungssphären schweben", hier noch der Beweis, dass ich mich immer noch mit Code beschäftige :-) In meinem englischen Blog habe ich einmal einen kurzen Überblick über die Instrumentierung von Code mit der .NET TraceSource gegeben. Das lag mir schon länger auf dem Herzen, denn gerade die Entwicklung von größeren, nicht visuellen Komponenten macht es manchmal schwer mitzuverfolgen, was eigentlich während ihrer Ausführung passiert. Wenn tausende Arbeitsschritte durchzuführen sind, verliert der Debugger einen Stück seines Wertes. Dann gilt es, "Muster in Signalen aus dem Code" zu finden. Mit einer TraceSource ist das aber gar nicht schwer.

Viel Spaß beim Ausprobieren. Und bis zu einer der Jahresendzeitveranstaltungen... :-)