Jenseits von SOLID

In einem hübschen Artikel hat Mark Nijhof ein Refactoring nach SOLID beschrieben. Dem ist nichts hinzuzufügen – wenn man denn bei SOLID stehen bleiben will. Ich sehe SOLID aber nicht als sakrosankt an; für mich darf Code gern noch “cleaner” werden.

Hier zunächst die Code-Ausgangslage:

Eine Klasse mit eine Menge Verantwortungen. Mark löst sie im Sinne des Single Responsibility Principle (SRP) wie folgt auf:

Dagegen ist nichts einzuwenden. Es entstehen drei “Akteure”, d.h. Funktionseinheiten mit jeweils wiederum potenziell vielen Aufgaben. Hinweis darauf ist die Benennung mit Substantiven. Für den Moment hat Mark zwar Verantwortlichkeiten getrennt – doch das ist “Rückspiegelweisheit”: Bei Vorlage einer Brownfield-Klasse ist ihm die Vermengung von Verantwortlichkeiten in einer Klasse aufgefallen.

Wäre es aber nicht viel besser, bei einer Refaktorisierung Code zu erzeugen, der einer solchen Entwicklung von vornherein Widerstand leistet? Vorbeugen ist besser als Refactoring. Dazu bedarf es jedoch einer Idee von der Ursache der Verantwortungsanhäufung. Woher könnte die rühren?

Ich glaube, das hat nicht nur mit Unaufmerksamkeit der Entwickler zu tun, die zum ursprünglichen Stand von OrderProcessor beigetragen haben. Mitschuldig ist auch die Bennung der Klasse. Sie ist als Akteur ausgelegt, als Substantiv, d.h. als Funktionseinheit, die qua Name suggeriert “Stopfe mich voll mit allem, was mit der Auftragsverarbeitung zu tun hat.”

So machen wir es doch auch, wenn ein Mensch als Akteur vor uns steht. “Ach, kannst du das nicht auch noch machen?” Und schon hat er eine Verantwortlichkeit mehr am Hacken.

Um das Wurzelproblem anzupacken, fände ich es besser, die Namen anders zu wählen. Allemal die der Logik-Funktionseinheit. Sie sollte nicht OrderProcessor heißen, sondern Process_order. Denn nur darum geht es hier. Noch schöner wäre es, wenn dazu dann Send_confirmation_email und Save_order dazu kämen:

Lassen Sie Ihr Unwohlsein angesichts der merkwürdigen Methodenbezeichnung “_” kurz beiseite. Spüren Sie stattdessen einmal in sich hinein: Wir groß ist nun die Gefahr, dass Process_order oder eine der beiden anderen Klassen mit weiterer Funktionalität aufgeladen wird, die nichts direkt mit dem Klassennamen zu tun hat? Für mich ist da jetzt eine spürbare Barriere.

Nun aber zu einem noch wichtigeren Aspekt im wahrsten Sinn des Wortes, den Mark bei seinem Separierungsbestreben übersehen hat. Er ist schwer zu sehen, weil wir alle so traditionell OO-konditioniert sind. Wir halten den Code in dieser Hinsicht für normal. “So macht man das halt” denken wir und hat Mark gedacht.

Mit geht es um das, was in Process_order passiert. Ich greife es mal heraus:

Wieviele Verantwortlichkeiten hat Process()? Wieviele Gründe für Veränderung gibt es?

1. Muss die Methode “angefasst werden”, wenn die Bestätigungen per Fax statt der Email versandt werden sollen?
2. Muss die Methode verändert werden, falls nach der Email-Bestätigung auch noch ein Eintrag in ein Protokoll gemacht werden soll?
3. Muss die Methode überarbeitet werden, wenn sich die Bedingung für eine Email-Bestätigung verändert?

Die Antwort auf alle drei (!) Fragen ist Ja. Die Methode hat mithin nicht nur eine Verantwortlichkeit. Die Fragen gehören nämlich zu unterschiedlichen Verantwortlichkeitsbereichen:

1. Implementationsauswahl
2. Integration
3. Kontrolle

Die Methode kontrolliert die Integration konkreter Implementationen für Operationen. Sie stellt also nicht nur sicher, dass bestimmte Operationen in einer bestimmten Reihenfolge ablaufen, nein, sie entscheidet auch noch über diese Reihenfolge zur Laufzeit und instanziiert ganz bestimmte Ausprägungen der Operationen.

Zur Marks Ehrenrettung sei gesagt, dass er eine dieser Verantwortlichkeiten auch durch seine SOLID-Brille erkannt hat: die Implementationsauswahl. Sie löst er über Inversion of Control auf. (Dass er später auch noch einen DI Container einsetzt, ist nicht so wichtig.)

Also mache ich meine Code-Version auch IoC-konform:

Dabei bleibt es dann bei Mark. Er belässt die Verantwortlichkeiten Integration und (!) Kontrolle in der Methode. Er erkennt sie schlicht nicht. Sie liegen außerhalb seines Wahrnehmungshorizonts.

Dabei ist es so einfach: Wo eine Kontrollstruktur – nomen est omen – wie if oder for im Spiel ist, da werden Operationen nicht nur “hintereinandergeschaltet”, sondern auch darüber entschieden, wann die unterschiedlichen Pfade durchlaufen werden. Also muss man ein Augenmerk darauf haben, dass diese Entscheidung nicht ebenfalls in derselben Methode gefällt wird. Darum geht es beim Prinzip Single Level of Abstraction (SLA) – das allerdings nicht zu SOLID gehört. Schade.

Um konsequent SRP umzusetzen, muss die Bedingung, unter der eine Bestätigung gesendet werden soll, raus aus der Auftragsverarbeitung. Das kann zunächst in einfacher Weise geschehen:

Aber fühlt sich das wirklich gut an? Mich schüttelt es, weil nun ganz deutlich wird, dass die Bedingung zwei Verantwortlichkeiten hat. Nicht umsonst musste ich einen Namen wählen, der eine Konjunktion enthält. Nur Is_order_valid() hätte die Speicherung unterschlagen, nur Successfully_saved_order() hätte die Validation unterschlagen.

Das Ziel ist richtig, die Verantwortlichkeiten zu entzerren. Aber das Mittel ist falsch. Besser finde ich es so:

Jetzt ist deutlicher und ohne Schachtelung die Sequenz des Ablaufs zu sehen:

• Gültigkeit des Auftrags prüfen
• Auftrag speichern
• Email-Bestätigung senden

Hier könnte ich es gut sein lassen. Doch ich bin seit der Lektüre von “Clean Code” sensibel geworden. Die Verantwortungshäufung lauert überall. Vor allem lädt der obigen Code bei aller Sauberkeit immer noch (oder wieder) dazu ein, in ihm weitere Verantwortungen anzuhäufen. Wie schnell ist die Validitätsbedingung aufgebohrt und sieht dann z.B. so aus:

Schon wieder steckt die Kontrollverantwortung mit drin.

Und warum? Weil die Kontrollstruktur if in der Methode geblieben ist. Sie ist zwar relativ harmlos, solange sie nur eines tut, nämlich den Codefluss entsprechend eines Flags mal in dieser und mal in jener Richtung zu leiten. Doch wie ein Stäubchen in der Luft ist sie ein Kristallisationskeim: für Domänenlogik. Eben noch steckte die ausschließlich in IsValid, doch dann hat die sich ausgebreitet, weil grad keine Zeit war, über eine Methode auf Order oder sonst wo nachzudenken, die beide Bedingungsklauseln umfasst. Ja, so schnell kann es gehen. So entsteht Entropie (oder dirty code) in kleinsten Inkrementen.

Hört sich vielleicht nach Erbsenzählerei an. Mag sein. Aber wenn ein Container voller Erbsen zerbricht, kann das ordentlichen Schaden anrichten.

Ich meine also, dass die Verantwortlichkeit Integration solange nicht ordentlich herauspräpariert ist, wie in einer Methode noch Kontrollstrukturen stehen. Aber wie kann die Integration der drei Operation zu einem Ganzen – der Auftragsverarbeitung – erreicht werden, wenn sie einerseits von Bedingungen abhängig ist, andererseits jedoch keine Kontrollstrukturen dafür enthalten darf?

Die verblüffend einfache Antwortet lautet: mit Continuations. (Mit Erweiterungsmethoden ginge es auch. Aber damit würden wir uns auf statische Methoden festlegen.)

Meine Version der Refaktorisierung mit Continuations so aus:

Die Methode zur Auftragsverarbeitung ist jetzt ausschließlich für die Integration von Operationen im Sinne eines Verarbeitungsflusses zuständig. Und sie lädt niemanden mehr ein, Logik hineinzustecken. (Naja, wer will, der bohrt natürlich die Lambda-Ausdrücke auf. Aber das halte ich für weniger naheliegend als mal eben eine Bedingung zu erweitern.)

Validate_order() ist ebenfalls auf eine Verantwortlichkeit konzentriert: Kontrolle. Wer die Validitätsbedingung verändern will, ist dort genau richtig. Was anderes kann man dort aber auch nicht sinnvoll tun. Insofern muss der Ausdruck auch nicht in eine weitere Methode ausgelagert werden.

Zum Schluss noch zu den merkwürdig benannten Methoden der zum Speichern und Senden des Auftrags. Ich habe die Namen auf einen Unterstrich beschränkt, um den Code besser lesbar zu halten. Oder ist _save._() nicht besser zu lesen als _save.Process() oder _save.Save()?

Dennoch verstehe ich, wenn Sie bei “_” als Methodenname zucken. Er scheint so nichtssagend. Klar. Er muss ja auch nichts sagen, weil der Klassenname (und der davon abgeleitete Feldname) alles sagt.

Fallen Sie angesichts Ihres Unwohlseins nun aber nicht zurück in alte Gewohnheit. Prügeln Sie sich aber auch nicht, “_” als Methodenname zu akzeptieren. Sondern machen Sie den nächsten konsequenten Schritt, den Mark ebenfalls nicht vollzogen hat. Den Robert C. Martin sich vor ihm nicht getraut hat.

Denken Sie das Interface Segregation Principle (ISP) weiter.

In Marks Artikel kommt das ISP in Bezug auf den Ausgangscode eigentlich gar nicht zum Einsatz. Er muss dafür weitere Einsatzszenarien erfinden. Das liegt daran, dass das ISP eben ein I-SP ist; es beharrt darauf, Dienstleistungen in Bündeln anzubieten und zu nutzen. Das IoC und der DI Container arbeiten auf Interfaces, obwohl im Beispiel von jedem Interface nur 1 Methode gebraucht wird.

Das ist nicht nur hier, sondern sehr oft der Fall. Integrationen bekommen Akteure mit vielen Dienstleistungen hineingereicht, nutzen davon aber nur sehr wenige, oft nur 1 oder 2. Warum also überhaupt Abhängigkeiten auf Interfaces basieren? Der Code könnte ohne auskommen, ohne IoC und DI Container zu vernachlässigen:

Voilà! Die Unterstriche sind verschwunden. Interfaces sind nicht mehr nötig. Process_order ist von keiner Implementation abhängig. Process_order.Process() hat weiterhin nur eine Verantwortlichkeit.

Fazit

SOLID ist gut. SOLID+SLA ist besser. Und SOLID+SLA+ISP2TheMax ist noch besser.

SOLID hat uns auf dem Weg zu Evolvierbarkeit voran gebracht. Wir sollten uns nun aber nicht ausruhen. Das Ziel ist nicht erreicht. Deshalb dard es gern noch konsequenter prinzipieller zugehen. Schauen Sie genau hin, hinterfragen Sie das Selbstverständliche und Überkommene. Die Kristallisationskeime für Dreck sind manchmal klitzeklein. Über die Zeit entfalten sie nichtsdestotrotz eine ungute Wirkung. Versuchen Sie deshalb, Code schon beim Schreiben in der Form so zu halten, dass an ihm Dreck nicht anhaften kann.

Continuations statt Kontrollstrukturen und Delegaten statt Interfaces sind ein Anfang.

Eine Technik zur Vermeidung von dreckigem Code von vornherein ist besser als eine Prinzip zum Aufspüren von Dreck im Code im Nachhinein.

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Mit dem Teppichmesser gegen Verlagsträgheit

Buchhandel und Verlage sind nicht die Schnellsten, was neue Technologien angeht. Ideen aus meiner Sicht als Leser, was der stationäre Buchhandel tun kann, um nachzuziehen und sich zu erhalten, um für mich attraktiv zu bleiben, habe ich schon geäußert.

Für die Verlage gibt es natürlich auch Ideen. Hier nur eine, wie ein cooles Buch 2.0 aussehen könnte.

Das scheint mir Lesen auf der Höhe der Zeit. Wie krude ist dagegen ein Kindle-Book oder ein Hörbuch.

Bis Verlage solche Produkte herstellen, wird allerdings noch einige Zeit vergehen. Auch nicht alle heutigen Verlage werden das schaffen. Andere werden an ihnen vorbeiziehen und die Gunst der Leserschaft erringen. Die Schnellen fressen die Langsamen.

Einstweilen wäre ich ja schon zufrieden, wenn Verlage ganz selbstverständlich jedes Buch auch als eBook herausbrächten. Für Romane und Fachbücher fährt der Zug in diese Richtung langsam los. Bei Sachbüchern und Schulbüchern scheint mir da aber noch einiges im Argen zu liegen.

Case in point: Das Französich Lehrwerk Découvertes von Klett, mit dem nun meine Tochter in der 6. Klasse beginnt. Der Verlag bietet keine eBook-Version an. (Warum nur? Weil Kinder keinen Computer haben? Das Gegenteil scheint mir der Fall. Alle haben ein Handy, fast alle haben einen Computer zuhaus. Meine Tochter – naja, wie könnte es anders sein ;-) - sogar zwei und noch ein eigenes iPad.)

Ich möchte nun mit meiner Tochter einen erneuten Anlauf nehmen, Französich zu lernen – aber natürlich auf meine Weise. Das heißt ich werde die Vokabeln mithilfe von FlashCards Plus Pro auf iPad und iPhone lernen. Und ich werde das Lehrbuch auf dem iPad und iPhone studieren – ob der Verlag das will oder nicht.

Wie das? Er bietet doch kein eBook an.

Ganz einfach mit roher Gewalt :-)

Bauanleitung – Aus einem Papierbuch wird ein eBook

Wenn der Verlag es nicht schafft auch nur das einfachste eBook herzustellen, dann schaffe ich das halt selbst: mit einem Teppichmesser, ScanSnap S1500, Abbyy FineReader, iPhone, pdfasm, Dropbox und GoodReader.

Schritt 1: Ich zerschneide das Lektionsbuch und das Grammatik-Beiheft mit dem Teppichmesser.

Schritt 2: Ich scanne die Seiten mit ScanSnap “Schnappi” S1500. Ein Hoch auf das papierlose Büro! Das Resultat sind PDF-Dateien. Da die Seiten als Bilder gescannt wurden, sind die Dateien natürlich sehr groß. 30 KB für 76 Seiten Grammatik-Beiheft. Deshalb zerlege ich das Lektionsbuch in Blöcke (Kapitel 1-3, Vokabeln + Index usw.).

Schritt 3: Ich lasse die Abbyy FineReader als OCR Texterkennung über die PDFs laufen, damit aus den Bildern echte Texte werden und ich in den PDFs suchen und markieren kann. (Abbyy liegt übrigens dem “Schnappi” bei.)

Schritt 4: Ich fotografiere noch einige Seiten des Lektionsbuches mit dem iPhone, die ich nicht durch den Scanner schieben konnte. Ist halt ein Hardcover, das Schulalltag standhalten muss. Die Photo-App meiner Wahl: Camera+

Schritt 5: Ich bündele einige PDFs mit den fotografierten Seiten, damit der Look hübsch einheitlich ist. pdfasm ist mein Freund – auch wenn die Bedienung etwas intuitiver hätte sein können. Da waren wieder mal Techniker die Gestalter der Benutzeroberfläche.

Schritt 6: Ich lege die PDFs in meine Dropbox, um von allen Devices (Laptop, iPad, iPhone) darauf zugreifen zu können. (Hoppla, aufpassen, damit die PDFs nicht ins öffentliche Verzeichnis geraten und ich durch Unachtsamkeit einen Link darauf in die Welt sende, auf dass auch noch andere Schüler, Eltern, Lehrer ein elektronisches Découvertes in die Hand bekommen.)

Schritt 7: Schließlich werfe ich den GoodReader auf dem iPad an, um mit der Lektüre der ersten Lektion zu beginnen.

Zeitaufwand für diese Aktion? Hm… ich habe es nicht gestoppt, aber ich schätze mal, dass es in Summe 2 Stunden gedauert hat. Zeitaufwendig war dabei allerdings nur die Texterkennung. Hat mich aber nicht gestört. Abbyy hat ja still vor sich hingepusselt im Hintergrund, während ich am Rechner weiterarbeiten konnte.

Fazit

Das war gar nicht so schwer. Den Verlag hätte es kaum mehr Aufwand gekostet bei besserem Ergebnis (kleinere PDFs, weniger Stückelung des Inhalts). Der hat den ganzen Content ja in Quark Xpress oder so und könnte ihn ganz leicht nach PDF exportieren.

Warum tut man das nicht? Ich kann nur einen Grund erkennen: ängstliche Unsicherheit. “Oh, mein Gott, was alles passieren könnte, wenn erstmal so ein PDF auf einer CD – nein, zu teuer! – oder im Internet auf unserer Homepage verfügbar wäre. Kriminelle Kinder könnten es verbreiten! Unsere Schulbuchverkaufe würden ins Bodenlose fallen. In 2 Jahren wären wir pleite. Arrghhhh! Das darf nicht passieren!” (Besonders verständlich ist so eine Denke natürlich bei Schulbuchverlagen, die garantierte Verkäufe dadurch haben, dass ihre Lehrwerke verbindlich durch Schulen oder Eltern in Papierform angeschafft werden müssen.)

So stelle ich mir die Verlagsredaktion vor – bis mir jemand plausibel macht, dass es ganz andere, mir als Leser total verständliche Gründe gibt, meine Lesegewohnheit nicht zu bedienen, obwohl es technisch möglich ist. Wenn dies also ein Verlagsmitarbeiter lesen sollte, möge er mich über solche Gründe bitte ins Bild setzen.

Nun, gut: Wie ich festgestellt habe, kann mir das Verhalten der Verlage ziemlich egal sein. Mit relativ wenig Aufwand habe ich mir mein eBook in “good enough” Qualität selbst hergestellt. Nächstes Mal mache ich das mit meiner Tochter zusammen. Daraus wird dann ein kleiner Event, die jährliche “School Book Slashing Party” oder so :-) (Vielleicht eine Anregung für Pädagogen, um Kindern eine Möglichkeit zum Ausagieren von Aggressionen zu bieten? Mit Teppichmessern auf Schülbücher statt auf Mitschüler oder später Flugzeugpiloten?)

In jedem Fall habe ich schon ein zweites Buch geordert, das ich mit dem Teppichmesser und den anderen Werkzeugen in ein eBook transformieren werde. Diesmal ist es ein Philosophiebuch: Das Prinzip Verantwortung. Suhrkamp verweigert hier die Veröffentlichung als eBook. Ob man meint, eine Existenz als eBook sei einem solchen Inhalt oder dem Klassiker-Status nicht würdig? Hm…

Naja, mir egal. Das Teppichmesser liegt schon bereit. Bei dem Buch wird es auch einfacher. Ist ein Paperback. Vielleicht kann ich das sogar komplett in Text umwandeln.

Aber nun kommen erstmal Sie: Machen Sie mit bei der großen Buchtransformation! Welchen Titel “rippen” Sie, um ihm die ewige Jugend als eBook zu schenken?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Ideen für den Buchhandel

Wie könnte sich denn nun der Buchhandel auf eine neue Art von Leserschaft einstellen?

Mit meinem vorherigen Blogartikel habe ich erstmal nur ein wenig aufrütteln wollen. Mir liegt etwas am Buchhandel oder besser: an Buchgalerien, in denen ich in pBooks stöbern kann und von deren Auswahl und Präsentation an Büchern ich mich inspieren lassen möchte. Deshalb wollte ich dem Buchhandel einmal berichten, mit welcher Art von Lesern er es (auch) zu tun hat. Nämlich mit solchen, die ihn benutzen, ohne ihm etwas dafür zu geben. Klingt hart, ist aber so.

Vorgestern habe ich das wieder getan, diesmal in Münster. Die Thalia-Buchhandlung dort hat mir zwei schöne Lesetipps vermittelt. Die habe ich mir in meiner iPhone Amazon App gemerkt und bin wieder gegangen. Auf meine Frage ans Personal, wie sie es denn mit eBooks hielten, hatte man keine überraschende Antwort: “Die finden Sie im Internet.” Ach, ach was.

Also: Wie könnte es der Buchhandel denn besser machen? Das bin ich seit meiner Nachricht an den Buchhandel öfter gefragt worden. Denn besser als diese Thalia-Antwort geht es bestimmt.

Natürlich kenne ich kein Patentrezept. Die Silberkugel habe auch ich nicht gegossen. Allerdings bin ich mir in einem sicher: Wenn es besser werden soll, dann muss es anders werden. Ziemlich anders. Und das auch noch ziemlich schnell. Immerhin droht 40% der Buchhandelsfläche in den nächsten 5 Jahren das Aus, prophezeit Carl Halff, Chef des Weltbild-Medienversands. Und das, obwohl seine Einschätzung des iPads sehr, hm, konservativ ist:

“Für Bücher ist das iPad ungeeignet, zu unhandlich und zu schwer, um damit länger zu lesen, auch nicht blendfrei.”

Aus seiner Sicht liegt die Zukunft des Buchhandels im Multichannel geschäft, d.h. Buch allein bringt es nicht. Aber Buch + Notizbuch zum Buch + Tasse zum Notizbuch zum Buch + Schrank zur Tasse zum Notizbuch zum Buch usw., das bringts. Wirklich? Hm… Für mich verschwimmt da eher der Unterschied zum Kaufhaus immer mehr. Wenn ich heute im Supermarkt oder auch in der Videothek Bücher kaufen kann, wodurch zeichnet sich dann der Buchhandel der Zukunft aus, in dem ich Videos oder Nahrungsmittel kaufen kann?

Irgendwie mögen solche Läden dann Geld verdienen. Gratulation. Aber mit Buchhandel hat das dann für mich nicht mehr viel zu tun. Schon heute ist das Personal im Buchhandel meist recht unverständig. Man kann Bücher räumen und am PC bestellen. Aber beraten… das können die meisten nicht. Überblick – auch nur über eine Sparte –, den haben die meisten nicht. (Besser ist das nur in Antiquariaten. Dort sitzen Enthusiasten.)

Multichannel ist aus meiner Sicht also nicht die Lösung, sondern eine Unterwerfung. Wer als Buchhandel ein Problem hat und dann die Bücher, d.h. die Träger von Inhalten zurückfährt und auf Bauchladen umsattelt, der wechselt schlicht die Branche. Lidl hat kein Problem mit dem Buchverkauf, Karstadt auch nicht. Aber die haben dafür andere Probleme. Ob man also gut beraten ist, die Probleme des Buchhandels gegen andere auszutauschen?

Aus meiner Sicht schlägt Herr Halff also keine Lösung vor, sondern ein Ausweichmanöver für Unternehmen, denen letztlich egal ist, was sie verkaufen. Aus Vorstandsicht natürlich plausibel. Derzeit z.B. im Vorstand von Thalia: Albert Hirsch, der auch schon in Software und Mineralwasser gemacht hat, oder Oliver Reul, der aus dem Bereich Logisik zu kommen scheint und auch schon bei T-Mobile gearbeitet hat, oder Michael Weber, der Erfahrung bei Star Finanz, HanseNet und Tchibo gesammelt hat. Was soll ich als Buchfreund da denken? Dass diese Herren sich dem Buch, den Buchinhalten verpflichtet fühlen, dass sie ein genuines Interesse am Lesen und an Lesern haben? Nein, leider kommen solche Gedanken bei mir nicht auf.

Da lobe ich mir echte Buchhändler wie Andrea Nunne mit ihrem kleinen Laden oder die Geschwister Heymann mit ihrer kleinen Ladenkette in Hamburg. Denen geht es um die Inhalte. Und nur von denen erwarte ich in Zukunft auch echte Hilfe bei Selektion und Präsentation, weil es zukünftig vor allem darum geht: Inhalte. Bücher lagern, bestellen, verschicken ist keine Kompetenz mehr, die ein Buchhändler braucht. Alles, was mit der Form von Büchern zu tun hat, ist eigentlich nicht mehr sein Thema. [1]

Was kann der Buchhändler aber nun besser machen in Bezug auf sein Thema? Wie kann er die Umwandlung in einen Bauchladen vermeiden? Hier ein paar Ideen aus meiner Sicht als Leser:

Idee #1: Embrace

Wenn es weh tut, dann mach mehr davon. Diesen Rat an alle, die etwas verbessern/lernen wollen, kann ich nur dem Buchhandel geben. Wenn online Buchverkäufe weh tun, dann versucht mehr damit zu machen. Wenn eBooks weh tun, dann versucht, mehr davon zu verkaufen. Oder wenn nicht verkaufen, dann zumindest besser verstehen, mehr selbst nutzen.

Wenn´s im Bauch zwickt, muss man nicht sofort zum Arzt laufen. Mal einen Tag aushalten und schauen, ob es weggeht, reicht meist aus. Die Schmerzen durch online Buchhandel und eBooks sind aber nicht vorrübergehend. Soviel ist schon heute klar. Wer also noch aushält und darauf wartet, dass es von allein besser wird, der hofft vergeblich.

Wenn aber klar ist, dass Schmerzen Symptome einer ernstzunehmenden Krankheit sind – 40% Flächenverlust für Bücher scheinen mir ziemlich ernst –, dann ist Aktivität angezeigt. Dann muss schleunigst nach einer Kur gesucht werden. Dann darf man sich dem Problem nicht verschließen.

Im Falle des Buchhandels bedeutet das für mich: ausprobieren, mitmachen, selber machen, mehr machen, besser machen. Unvermeidliche Veränderung sollte begrüßt werden. Jeden Morgen ein Hoch auf die neuen Medien singen, ist das Mindeste. Jedem Angestellten ein iPad, Kindle, Smartphone oder sonstwas in die Hand geben. Bücher nur noch online im eigenen oder fremden Shop bestellen. Erfahrung sammeln als Leser. Sich aktiv in die Rolle der heutigen und zukünftigen Kunden versetzen. Als tägliche Pflichtübung für alle.

Damit geht dann einher, jeden Tag wieder zu überlegen, wie mit online und eBook usw. mehr Geschäft gemacht werden kann. Physische Bücher (pBooks) muss man nicht mehr anpreisen. Die verkaufen sich von selbst; ich meine, deren form factor verkauft sich von selbst. Gefragt sind Ideen, wie mit pBooks online oder eben mit eBooks Geschäfte gemacht werden können. “Wie kann ich den nächsten Kunden motivieren, sein Geschäft demnächst mit mir online zu machen oder ein eBook zu kaufen?”, diese Frage sollte sich jeder Buchhändler bei jedem Kunden stellen. Nur so wird das Neue wirklich ernst genommen. [2]

Der Grossist libri macht es jedem Buchhändler leicht, einen online Buchshop zu betreiben. Nunnes kleines Bücher & Co ist dafür ein Beispiel, aber auch die große Mayersche Buchhandlung. Das ist ein schöner Anfang. Technisch haben Buchhandlungen zunächst also nichts auszustehen. Doch dann… Gerade ein Gelegenheitskäufer findet nur schwer den Weg zum online Buchladen eines kleinen Geschäfts. Amazon hingegen ist in jedermanns Kopf verankert. Mit einem Shop von libri fängt die kreative Arbeit der Umarmung der “neuen Medien” erst an. Darauf kann sich niemand ausruhen.

Idee #2: Fokus

Wer als Buchhändler das Heil im Multichannel sucht, wird sich und seiner Kundschaft untreu. Aus meiner Sicht führt der ehrliche Weg im Buchhandel daher nicht in die Breite, in die Diversifikation, sondern in die Tiefe. Spitzer werden, fokussieren, auf das Wesentliche konzentrieren, das, so glaube ich, sollte die Strategie der Stunde sein.

Worin liegt die Aufgabe des Buchhandels, genauer: des Buchladens? Früher ging es darum, Bücher schlicht zugänglich zu machen. Ohne ausgefeilte internationale Logistik und ohne umfassende, frei zugängliche Verzeichnisse war der Buchhandel das Nadelöhr zum Buch. Er hat es beschafft – mit oder ohne eigenes Lager. Er hat es gefunden in dicken Katalogen. Darüber hinaus hat er sogar bei der Auswahl beraten. Die Präsentation vor Ort war immer nur ein klitzekleiner Ausschnitt.

Beschaffung, Lagerung, Nachschlagen: das alles ist heute aber kein Problem mehr. Jeder kann das genauso gut wie der Buchhändler (oder sogar besser, je nach Enthusiasmus). Und das auch noch von zuhause aus.

Worum geht es also heute beim Buchladen? Es bleibt nur der Inhalt. Es geht nur noch um die Vermittlung von Inhalten unabhängig vom Medium. Inhaltsproduzenten müssen an Inhaltskonsumenten vermittelt werden. Die vornehme Aufgabe der Buchladeninhaber ist dieselbe wie die guter Gastgeber: sie stellen Menschen einander vor – und ziehen sich dann zurück.

Wenn die Zusammengebrachten einander interessieren, dann wird mehr daraus. Sie treffen sich nach der Party wieder bzw. der Leser kauft Inhalte des Autors. Wie, wo, wann, wieviel… das sollte Gastgeber wie Buchhändler egal sein. Sie haben ihren Job getan, wenn sie ein Angebot einem Bedarf zugeführt haben.

Und dafür sollen sie dann auch entlohnt werden. Dem Gastgeber ist Beifall gewiss, der Buchhändler verdient dafür Geld.

Der Buchladen der Zukunft sollte sich also genau darauf konzentrieren: Lesebedarf und Lesestoff zusammenbringen. Egal wie. Je genauer und verlässlicher, desto besser. pBook, CD, MP3, eBook… egal. Im Laden kaufen, online kaufen… egal.

Die Frage, die sich der Buchhändler jeden Tag stellen sollte ist: Wie kann ich die Inhalte, die es gibt, die sich jeden Tag vermehren, interessierten Lesern zuführen? Alles ist erlaubt. Alles kann in Frage gestellt werden.

Schon lange hat der Buchhandel ja erkannt, dass es besser ist, Kunden beim Stöbern zu unterstützen. Statt von der Kasse aus zu rufen, “Bitte das Buch vorsichtig behandeln!” lieber noch einen Stuhl unter den Kunden schieben und ihn zum Weiterblättern animieren. Vor 30 Jahren wäre das in Deutschland noch undenkbar gewesen – außer in einer Bücherei. In gleicher Weise könnte anderes bisher Undenkbares aber auch Realität werden:

Beispiel Probekauf: Warum nicht noch einen Schritt weitergehen und Kunden Bücher mit nach Hause geben? Sozusagen Kauf auf Probe. Bei Nichtgefallen kann das Buch innerhalb von 48 Stunden zurückgebracht werden. (Mit Umtausch kann man sich soetwas als Kunde natürlich heute schon erschleichen. Deshalb vergibt sich der Buchhandel nichts, diese Möglichkeit als Dienstleistung offiziell anzubieten.)

Beispiel Serienabo: Es gibt zunehmend Autoren, die Buchreihen schreiben. Da tritt immer wieder derselbe Protagonist auf oder sie drehen sich ums selbe Thema usw. Wer Dona-Leon-Fan ist, der will wahrscheinlich all ihre Bücher lesen, dito wer Fan von Inspektor Wallander ist oder Kay Scarpetta mag. Warum also als Buchhandel nicht ein Abo auf Bücher solcher Reihen anbieten? Ja, ich weiß, dass es eine Buchpreisbindung in Deutschland gibt. Ein günstiger Abopreis wird deshalb wohl schwer bis unmöglich sein. Doch mit Kreativität lässt sich da doch etwas machen, denke ich. Lesern geht es nicht immer um den Preis. Sie wollen Bequemlichkeit, sie wollen Aufmerksamkeit. Ich würde mich freuen, wenn der Buchhändler meiner Wahl mir versichern könnte, mir z.B. jedes Buch von Martin Suter bei Erscheinen als Taschenbuch sofort zurückzulegen, mich zu informieren oder mir sofort zuzuschicken als Probekauf. Wenn dann noch jedem Buch eine kleine Aufmerksamkeit beiläge… Was wollte ich mehr? Das Abo brächte mir doch schon Ruhe und Gewissheit, kein Buch zu verpassen.

Beispiel Kontextkontakt: Man kann Bücher einfach nur so lesen – oder man kann in sie eintauchen. Mein Eindruck ist, dass das immer mehr Menschen wollen. Sie lieben es, sich in andere Welten zu begeben. Warum diesen Trend nicht aufgreifen? Ich fände es ausprobierenswert für Buchhändler, zusammen mit Reiseveranstaltern Angebote zu Büchern zu erarbeiten. Beispiel: Für Dona Leon Fans die Venedig Reise zu den Originalschauplätzen der Bücher inkl. Treffen mit der Autorin. Oder für Kay Scarpetta Fans eine Führung durch die Rechtsmedizin. Oder für Fans von Fantasy-Büchern Rollenspielabende. Oder, oder, oder. Das wären dann keine direkten Buchangebote mehr, aber es ginge immer noch um den Inhalt, weil sich diese Angebote Kontakt zum Kontext des Inhalts böten. Der kann im Buchladen oder außerhalb stattfinden. Bücher kann man lesen – doch Bücher haben das Potenzial für mehr. Ihr Inhalt ist immer nur Ausgangspunkt. Am Ende will der Leser ein Erlebnis. Das ist nicht anders als bei Fußball, Musik, Film, Autokauf. Es geht immer ums Erlebnis, um Gefühle. [3]

Beispiel Rückkauf: Wenn schon pBook, warum dann als Buchladen nur einmal daran verdienen? Wäre es nicht toll, wenn man sein pBook am Ende statt ins Regal daheim wieder ins Regal im Buchladen stellen könnte, um ein anderes mitzunehmen? Warum dafür in die Bücherei gehen, die irgendwie nie das aktuelle Buch hat, das man gerade lesen will? Der Buchladen nimmt heute schon Bücher ungelesen im Umtausch zurück. Da wäre es ein kleiner Schritt, sie in einem gewissen Zeitraum nach Kauf und in einem gewissen Zustand auch gelesen wieder zurückzunehmen – natürlich zu einem geringeren Rückkaufpreis. Das würde den Buchhandel auch an die zunehmende collaborative consumption heranführen. Die stellt nämlich die nächste Gefahr für alle dar, die neue Waren an jeden verkaufen wollen. Amazon macht es im Internet vor; dort schämt man sich nicht, neben neuen auch gebrauchte Bücher anzubieten.

Das sind vier Beispiele für eine Erweiterung der Dienstleistungspalette, ohne gleich zum Multichannel-Höker zu werden. Hier geht es ganz klar um den Inhalt, wenn nicht sogar ums Buch. Andere Ideen für Umsätze durch mehr Fokus lassen sich bestimmt finden. Für diese hier habe ich ja nur 10 Minuten gebraucht als Laie. Auch geht es nicht um den einen Knüller, sondern um eine Bandbreite an Angeboten neben dem pBook/eBook, ohne gleich auf Tassen und Frühstücksbrettchen ausweichen zu müssen. Warum bei Leseecke und Leseabend stehenbleiben?

Idee #3 Selektion

An ein Vollsortiment ist im offline Buchhandel gar nicht zu denken. Auch eine große Mayersche Buchhandlung kann nicht alles auf Lager haben oder auch nur präsentieren. Ich glaube deshalb, dass es zukünftig mehr denn bisher darauf ankommt, als Buchladen zu selektieren.

Die Selektion könnte entlang von Genregrenzen verlaufen: Krimibuchladen, IT-Buchladen, SF-Buchladen usw. Sie könnte das Alte auswählen (Antiquariat) oder das Neue: Warum nicht ein Buchladen, der von allen Verlagen immer und ausschließlich nur das Neuste hat? Und ich meine wirklich nur das Neueste. Für einen begrenzten Zeitraum, z.B. 3 Monate. Oder man schießt sich auf die Klientel in einem Quartier ein?

In jedem Fall gehört zur gezielten Selektion, die wirklich Mut hat, Titel wegzulassen, eine echte Kompetenz. In Bezug auf die Selektion muss der Buchhandel kundig sein: Autoren kennen, Empfehlungen aussprechen können, abgrenzen können. Wie beim Outdoor-Laden käme es dafür nicht auf eine formale Ausbildung an, sondern auf Enthusiasmus und Erfahrung.

Wenn der Buchladen aufgrund seiner Selektion und seines Fokuses mir helfen kann, zu neuen spannenden Titel in jedem Format zu kommen, dann bin ich als Leser begeistert. Das kann im persönlichen Gespräch geschehen oder durch eine besonders hilfreiche “Regallandschaft” oder durch eine eigene “Suchmaschine”… egal.

Der Buchhandel, der 2 Regale Krimis, 1 Regal Kinderbücher, 1 Regal SF, 4 Regale allgemeine Romane usw. hat, wird wohl leider keine Zukunft haben. Ihm fehlt die klare Selektion, ein deutliches Kompetenzprofil. Nicht, dass er keine Kunden fände, aber ich glaube nicht, dass sie ihm reichen können. Ich wüsste einfach nicht, was ich von ihm erwarten soll als “das Übliche”, d.h. 95% das, was ich auch bei Thalia und Amazon sofort angeboten bekomme. So ein Sortimentsdurcheinander wird zukünftig nur immobile Leser befriedigen, die quasi auf diesen Buchladen angewiesen sind.

Für mich liegt die Zukunft des Buchhandels aber nicht bei denen, die nicht anders können, sondern bei denen, die gezielt einen Buchladen aufsuchen, weil sie anders können, aber nicht anders wollen. Sie wollen in das Geschäft, weil das Geschäft ihnen unwiderstehliche, womöglich einzigartige oder zumindest sehr persönliche Angebote macht. Kunden von Buchläden wollen keine Bücher mehr – also Seiten zwischen Pappdeckeln –, sondern “Leseerlebnisse” rund um Inhalte. Und da es von denen potenziell viele gibt, freuen sie sich, wenn sie auf dem Weg dahin Gleichgesinnte treffen und mit Leuten zu tun haben, die sie wirklich verstehen. Je undefinierbarer die Selektion einer Buchladens aber ist, desto weniger ist zu erwarten, dass ein solcher Kontakt entsteht.

Idee #4 Präsenz

Den Buchhandel macht aus, dass man dort Bücher in die Hand nehmen kann. Ob er viele irgendwo auf Lager hat, interessiert nicht mehr. Ob er sie schnell besorgen kann, auch nicht. Im Laden interessiert mich, was ich dort vor Ort durchstöbern kann, was präsent ist und zwar in einer Form, die mir mehr bietet als ein online Bookshop.

Ich denke daher, dass Buchläden ihr Angebot in Bezug auf Buchpräsenz optimieren müssen. Heute sehe ich hohe Bücherberge mit demselben Titel. Warum? Weil man an Leser denkt, die das Buch physisch sofort mitnehmen wollen. Dabei ist das doch nicht mehr das Problem. Jeder kann das Buch morgen in seinem Postkasten haben oder in 30 Sekunden auf seinem eReader.

Mir wäre lieber, die Buchläden würden in den Regalen eine größere Vielfalt an Büchern präsentieren, statt vom selben Titel viele Exemplare. Auf die Spitze getrieben hieße das: Im Buchladen der Zukunft ist entsprechend seiner Selektion jedes Buch nur 1 Mal vorhanden – als Präsenzexemplar. Das kann ich mir vor Ort ansehen, aber nicht sofort mitnehmen. Stattdessen bestelle ich es an der Kasse und bekomme es morgen geliefert oder kann es mir runterladen. D.h. auf dem Präsenzexemplar ist auch klar ersichtlich, welche anderen Formate es gibt: ePub, PDF, Kindle, MP3, CD.

Auch nicht jedes Buch muss physisch komplett vorhanden sein. Wo es eBooks gibt, reicht im Regal eine Karte, die aussieht wie das Buch, um mir Geschmack zu machen. Oder ein Booklet mit einem Auszug. Davon würden viiiiel mehr ins Regal passen. Wenn ich dann mehr will, nehme ich mir einen der rumliegenden eReader und lese damit weiter im Buch, bis ich weiß, ob ich es haben will oder nicht. Natürlich kann ich es damit auch sofort über den online Bookshop des Ladens kaufen. [4]

Fazit

Soweit mal vier Aspekte mit Ideen für eine Zukunft des offline Buchhandels, d.h. von Buchläden. Wie gesagt, darunter ist keine Silberkugel. Es gibt keine Wunderwaffe zur Rettung des Buchhandels. Aber ich denke, Fatalismus ist fehl am Platze. Es lässt sich eine Menge tun, wenn man etwas kreativ ist und Mut hat.

Die Zukunft des Buchhandels liegt im Nebel. Nur soviel ist gewiss: das Terrain vor ihm ist tückisch und das bisher Bewährte gibt wenig Sicherheit für den weiteren Weg.

Deshalb halte ich es für wichtig, den Nebel nicht aussitzen zu wollen. Stattdessen besser frisch voran. In kleinen experimentellen Schritten. In den Nebel hinein. Oder gar selbst zum Nebel werden, mit ihm verschmelzen. Agieren statt reagieren. Niemand ist Opfer des Wandels durch das Internet – außer man macht sich dazu.

Bei diesem mutigen Voranschreiten dann auf eines vertrauen: dem inneren Kompass in Richtung Inhalt. Denn darum geht es: Inhalte, “Leseerlebnisse” zu vermitteln. Wer daran nicht interessiert ist und im Grunde alles verkaufen könnte, um “am Leben zu bleiben”, der ist schon heute kein Buchhändler mehr. Also fokussieren auf alles, was mit Inhalten zu tun hat.

Da dieser Bereich jedoch eher wächst denn schrumpft, braucht es wieder mal Mut: um sich in der Auswahl zu beschränken und in Bezug auf diese Auswahl echte Kompetenz aufzubauen. Mich zumindest wird in Zukunft der Bauchladenbuchhandel nicht mehr interessieren. Von allem ein bisschen…? Das kriege ich bei Amazon besser. Wenn ich in den Buchladen gehe, dann will ich, dass man mich anspricht, mich versteht. Rundum. In Bezug auf Inhalte und auch die Form. Wer da verlegen lächelt, wenn es um das Thema eBook geht, ist raus.

Für mich liegt daher die Zukunft des offline Buchhandels in der Präsentation einer profilierten Vielfalt. Ich will möglichst viel dort “begreifen” können im Laden. Denn was ich im Laden “ausprobieren” kann, dass kaufe ich eher. “Try before you buy.” Mitnehmen muss ich es nicht unbedingt und schon gar nicht als pBook.

Und nun kommt ihr, liebe Leser. Wer hat noch andere Ideen für den Buchhandel? Wenn der sich selbst schwer tut mit dem Wandel, können wir ihm vielleicht aus Lesersicht auf die Sprünge helfen.

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat… (Den trinke ich dann auch gern in einer Buchhandlung mit Coffeeshop ;-)

PS: Noch ein Hinweis dazu, wie die Veränderungen angegangen werden können in den Buchläden: gemeinsam. Der Buchhändler, der glaubt, er könne die Zukunft vorausdenken für seine Mitarbeiter (wenn er noch welche hat), verschenkt Ideenpotenzial. Alle müssen an einen Tisch, weil alle im selben Boot sitzen. Dabei ist dann alles erlaubt. Es gibt nur eine Pflicht: mutig nach vorne denken und Veränderungen ernsthaft ausprobieren. Ja, ich meine ausprobieren, d.h. zunächst nur für begrenzte Zeit implementieren. Nicht alles auf eine Karte setzen. Manche Aktion läuft dann vielleicht 4 Wochen, eine andere 3 Monate, eine dritte ein ganzes Jahr.

PPS: Wer als Buchhändler noch nicht damit angefangen hat, sollte übrigens schleunigst einsteigen ins Sammeln von Kundenadressen. Hier ist der Begriff Kanal tatsächlich wichtig: einen Kommunikationskanal zu den Kunden aufbauen. Briefpost, Twitter, Facebook, Email-Newsletter… egal. Dem Buchladen müssen die Kunden per Adresse bekannt sein. Die Zahl anonymer Buchkäufe muss minimal sein. Auch hier ist also Kreativität gefragt: Wie kann der Buchkäufer überzeugt werden, sich zu erkennen zu geben zumindest mit einer Email-Adresse?

Fußnoten

[1] Es sei denn, es geht um neue Formen, bei denen Leser noch Hilfestellung benötigen. Doch gerade da schwächelt der traditionelle Buchhändler. Ich kenne jedenfalls nur solche, denen das gute alte pBook so lieb ist, dass sie eigentlich keine eigene Erfahrung mit eBooks haben, geschweige denn Fans von eBooks wären.

[2] Oder auch die Kundschaft fragen, warum sie eben nicht online kauft oder kein eBook liest. Auch das zu wissen, ist wichtig. Wenn da die Antwort ist, “Weil ich ihren persönlichen Rat als Buchhändler schätze”, dann ist das toll und ein Hinweis darauf, was in Zukunft ausgebaut werden muss. Falls die Antwort jedoch lautet, “Ach, ich kenn mich mit Computern nicht so aus”, dann ist klar, dass dieser Kunde nur gezwungenermaßen im Laden steht; er kann nicht anders – und wird aussterben. Ihn zu bedienen, ist natürlich selbstverständlich. Irgendwie. Auf ihn die Strategie auszurichten, wäre aber verfehlt. Außer man sieht es als Marktlücke an, für “internet challenge people” einen Laden zu machen so wie in anderen Ländern Schreibstuben für Leseunkundige.

[3] Deshalb ist der Buchladen eigentlich auch gut aufgestellt. Er hat den persönlichen Kontakt zum Erlebnishungrigen. Amazon hat den nicht. Wenn der Buchhandel zum Multichannel wird, nutzt er diese Chance nicht. Eine Tasse zum Buch ist kein Erlebnis. Eine Harry-Potter-Party aber, die HP-Sondervorstellung in einem Kino, der Zauberkurs für HP-Fans im Laden, die HP-Reise nach Schottland, das Twitter Re-enactment eines Quidditch-Spiels jedoch… das sind Erlebnisse. Die kann man online nicht bestellen.

[4] Hier wird deutlich, dass der Buchhandel Hilfe von den Verlagen braucht. “Buchpräsentationskarten” und Booklets stellen sich nicht von allein her. Auch könnten pBooks schon gleich mit Hinweisen auf weitere Formate bedruckt sein. Für Neuerscheinungen gibt es manchmal vorab Booklets; warum aber nicht konsequent für alle Titel? Die können ja ganz einfach gehalten sein. Damit könnten die meisten Verlage mit ihrem kompletten Programm vor Ort in jeder Buchhandlung sein. Zum Anfassen.

Nachricht an den Buchhandel

Wir werden immer mehr. Ich meine die Leser wie ich, die Bücher elektronisch konsumieren wollen. Vor einem Jahr war das für mich noch kein so großes Thema. Ja, da habe ich auch schon ab und an eBooks gelesen; doch seitdem ich iPad und iPhone habe, hat sich das Verhältnis umgekehrt. Heute lese ich 90% elektronisch und nur 10% auf Papier. Ein Papierbuch kommt mir nur noch in dein Einkaufskorb, wenn ich es nicht vermeiden kann – oder mich die Nostalgie übermannt.

Unvermeidbar ist ein Papierbuch für mich, wenn es entweder einen Inhalt hat, der sich auf Papier einfach besser rüberbringen lässt (Beispiel Bildband oder Schmuckband) oder der Inhalt aus heute eigentlich unerfindlichen Gründen (noch) nicht als eBook verfügbar ist, er mir aber unmittelbar wichtig erscheint.

Ich lese heute tagsüber meist auf dem iPhone und abends im Bett auf dem iPad. Das iPhone habe ich immer dabei, so dass ich mein Lesebedürfnis immer befriedigen kann, ohne einen Buchberg mitzuschleppen. Vorteil Mobilität, Nachteil kleines Display.

Das iPad habe ich nur zur Hand, wenn ich es extra einstecke oder eben daheim. Auch hier habe ich meine ganze Bibliothek im Zugriff. Vorteil Displaygröße, Nachteil geringere Mobilität.

Auf dem Laptop lese ich nur noch, was mir während sonstiger Arbeit darauf gerade vor die Augen kommt. Wenn ich es aber nicht sofort lesen muss, verschiebe ich es auf iPad oder iPhone.

Und Papierbücher… die liegen bei mir nur noch herum. Ich habe noch größere Mengen, von denen mir einige auch lieb und teuer sind. Ich leere jetzt also nicht zwanghaft meine Regale. Doch über die Zeit werden sich die Reihen lichten. Fachliteratur veraltet oder interessiert mich nicht mehr; Belletristik ist eh nur selten wert, aufgehoben zu werden. 22 Kartons (ca. 1000 Bücher) hatte ich schon ausgelagert in ein “Archiv” im Keller; davon sind nun 11 Kartons durch Überschwemmung wertlos geworden und schon auf dem Sperrmüll gelandet. Die anderen werden wohl bald folgen – auch ohne Überschwemmung. Weitere 1000 stehen vor der Selektion. Regalplatz ist knapp; außerdem habe ich auf alles, was im Regal steht, keinen Zugriff, wenn das Regal nicht zur Hand ist. Und das ist recht häufig der Fall, weil ich viel auf Reisen bin.

Bottom line: Pads und Smartphones sind ein Gottesgeschenk. Ich liebe sie, weil sie mir das Lesen vereinfachen. (Spezielle Lesegeräte wie OYO eReader oder Kindle Reader halte ich für vorübergehende Verirrungen. In 5 Jahren sind sie vom Markt verschwunden.) Durch die Digitalisierung lese ich also nicht weniger, sondern mehr. Damit meine ich Bücher und nicht ganz allgemein, was mir so im Internet vor die Augen kommt.

Und nun, Buchhändler, hergehört: Ich benutze euch, ohne, dass ihr davon etwas habt.

Klingt hart, ist aber so. Ich gehe gern in Buchläden. Da lässt sich so schön stöbern. Ein Buch anzufassen, darin zu blättern, Bücher ausgebreitet zu sehen, zwischen den Abteilungen einfach wechseln zu können… das ist toll. Ein Besuch im Buchladen ist immer total anregend, finde ich. Da schnappe ich ganz viele Leseideen auf.

Nur kaufen tue ich dort nichts mehr.

Wenn ich ein interessantes Buch im Buchladen sehe, dann scanne ich die ISBN mit der Amazon App. Die zeigt mir dann, ob es dafür ein Kindle-Buch gibt. Wenn ja, dann lege ich mir das in meine Amazon-Wunschliste. Wenn nein, dann schaue ich bei libri nach, ob es ein eBook (ePub oder PDF) gibt. Wenn ja, lege ich mir das dort auf die Wunschliste. Sollte es kein eBook (auf Deutsch oder Englisch) geben, dann merke ich mir die Papierbuchausgabe – und schaue nach einem eBook später mal, wenn ich es wirklich haben will.

Was hat der Buchhandel davon? Nichts. Er liefert mir nur ein nettes Ambiente und eine Form der Übersicht, wie sie mir kein online Shop bieten kann. Ich halte den Buchhandel, nein, besser: die physische Buchpräsentation, also nicht für überflüssig. Auf keinen Fall! Ich liebe Bücher zum Anfassen, Stöbern. Regale sind toll, um sich inspirieren zu lassen.

Nur weiß ich nicht mehr, warum ich dann so ein Papierbuch (pBook) dort oder überhaupt kaufen soll.

Papierbücher haben ein paar Vorteile. Aber sie haben auch eine Menge Nachteile. Die sollte man nicht versuchen, als Vorteile oder auch nur als notwendige Attribute von Büchern zu verkaufen.

Auf diese Nachteile der pBooks und die Vorteile der eBooks werden in den nächsten Jahren noch mehr Leser stoßen. Allemal, wenn die Verlage erkennen, dass eBooks ein Mittel zur Kostenreduktion und/oder Margensteigerung sind. Denn dann werden eBooks preisgünstiger werden. Das führt dann aber nicht zu weniger Umsatz, sondern zu mehr. Bei einem Fachbuch als e/pBook für 39,00 EUR und mehr überlege ich länger, ob ich es mir kaufe. Wenn das eBook dann aber nur noch 14,50 EUR kostet… dann überlege ich nicht mehr. Dann kaufe ich es, selbst wenn mich nur 50% oder gar 25% davon echt interessieren.

Mit eBooks bin ich sehr viel näher am Impulskauf als mit pBooks. Heute ist ihr Kauf schon leichter: ein Link, dem ich zu Amazon folge, ein Klick, mit dem ich kaufe, ein weiterer Klick und ich habe das Buch auf meinem Rechner. Das dauert 20 Sekunden. Dafür musste ich mich nicht aus dem Haus bewegen und noch nicht einmal warten.

Günstiger ist der Kauf allerdings noch nicht. Das hält mich manches Mal noch davon ab, drauf zu klicken. Kindle-Bücher, die mehr als ihr papierernes Pendant kosten, sind widersinnig und kontraproduktiv. Doch das ist ein Problem der Verlage, nicht des Buchhandels.

Bücher sind toll. Buchläden sind toll. Deshalb kaufe ich aber noch lange nicht im Buchladen. Das ist meine Botschaft an den Buchhandel. Ich nutze ihn gern, trinke auch mal ein Käffchen beim Stöbern – doch einkaufen tue ich nicht mehr im physischen Laden. Und damit bin ich sicherlich nicht allein.

Die schlechte Nachricht ist also, dass der Buchhandel an mir und vielen anderen nicht mehr mit seinem Hauptprodukt verdienen kann. Jedenfalls nicht so, wie in den letzten 200 Jahren. Umdenken ist also nötig. Besser schnell als langsam. Denn der breite Umbruch steht vor der Tür, wenn Smartphones wie Pads besser und preiswerter werden. Bisher sind iPhone und iPad ziemlich einsam in der Qualität, finde ich – aber noch recht teuer. Doch Android und WP7 schlafen nicht, sie zögern nur. In 2-3 Jahren sieht der Device-Markt sicher rosiger aus.

Wenn der Buchhandel dann nicht andere Angebote macht als eine billige Ecke mit ein paar abstrusen eReadern und 2-3 Büchern mit einer “Gibt es auch als eBook”-Banderole… dann wird es dunkel im Buchgeschäft.

Doch es gibt auch eine positive Nachricht: Ich und sicher auch viele andere lieben ja das Stöbern in langen, bunten Buchregalen. Wir haben also ein Interesse daran, dass es Buchläden weiterhin gibt. Wir möchten beides: bequem und preisgünstig mit unseren Devices lesen und (!) Bücher aufstöbern in angenehmer Atmosphäre.

Ich wünsche mir daher einen Dialog mit dem Buchhandel oder der ganzen Buchproduktionskette. Wo ist das Forum, in dem Leser, Buchhändler, Grossist und Verlage darüber diskutieren, wie für alle Beteiligten die Zukunft aussehen könnte?

Klar, es geht auch ohne Diskussion. Dabei wird es dann aber vor allem einen Gewinner geben: die Leser. Selbst wenn es radikal weniger Buchläden geben sollte, täte uns das nicht so weh wie den Buchläden selbst. Uns ist es relativ egal, ob wir Amazon oder libri unser Geld geben. Wenn wir aber unser “Stöbererlebnis” erhalten könnten, würde uns das noch besser gefallen.

Also, wann beginnt der Dialog zwischen der heute schon existierenden Zukunft der Leserschaft und dem Buchhandel? Wo ist der Buchhändler, der eBook-Leser wirklich ernst nimmt und uns ein unwiderstehliches Angebot macht? Apps wie “stories unterwegs” sind ja nett – deshalb kaufe ich aber kein pBook in dem Buchladen.

Und wann nehmen Verlage den Buchhandel als wertvollen Mittler zum eBook-Leser wahr? Derzeit sind die eBook-Margen marginal für den Buchhandel. Der ist also gar nicht motiviert, ein eBook statt eines pBook zu verkaufen. Er muss sich also quasi an die Planken des untergehenden Schiffs pBook klammern. Damit tun sich Verlage mittelfristig keinen Gefallen. Denn: Wenn der bunte Buchhandel vor Ort entfällt, konzentriert sich der Buchverkauf noch mehr auf die wenigen großen online Buchhändler, allen voran Amazon. Und die setzen dann die Daumenschrauben an. Ach was, das haben sie schon. Verlage sind also gut beraten, sich auch besser schnell als langsam mit dem lokalen Buchhandel zu verbünden zum Thema eBook.

Im Moment gehöre ich wohl noch zur Avantgarde der Buchleserschaft, wenn ich 90% als eBooks lese. Doch das ändert sich in den nächsten 5-10 Jahren. Ich würde mich deshalb freuen, wenn mir schöne Buchstöbererlebnisse auch darüber hinaus erhalten blieben. Noch ist es für den Buchhandel nicht zu spät. Ich hoffe, er kriegt die Kurve.

Design zur Diskussion gestellt

In der Software Craftsmanship Diskussionsgruppe geht es in einem Thread um die Frage, was denn Software Design sei oder Software Architecture. Die Antworten der Software Craftsmen sind für mich sehr überraschend. Hier ein Beispiel:

George Dinwiddie hat auf meine Frage also geantwortet, für ihn sei alles Design, was mit Entscheidungen zu tun hat während der Softwareentwicklung. Außerdem sei Architektur eine Sache, die habe nichts mit Softwareentwicklung zu tun, sondern mit Gebäuden.

Und Keith Brown, den wir für seine Bücher zu COM+ und Windows Security mögen, stimmt ihm zu.

Kann das sein? Ich zumindest kann kaum glauben, dass erwachsene Softwareentwickler so über ihre Zunft (es sind ja Software Craftsmen) denken.

Oder hier noch ein Beispiel:

Die Formulierung, auf Design und Implementation müsse man ständig gleichzeitig achten, hat er auch in anderen Postings der Gruppe benutzt. Allerdings ist er auf Nachfragen wiederholt eine Definition von Design schuldig geblieben. Auch mochte er noch nicht einmal Design gegenüber Implementation abgrenzen. Immer nur das Mantra, man müsse beides (und noch viel mehr) ständig im Blick halten.

Kann das sein? Immerhin ist das Ron Jeffries, einer der Gründerväter der Agilitätsbewegung. Und der mag als quasi schon fundamentalistischer Vertreter von TDD = Test-Driven Design (!) nicht definieren, was denn Design sei? Merkwürdig.

Gelinde gesagt bin ich verwundert. Was ist los in unserer Branche? Oder ist das nicht unsere Branche, sondern eben nur eine gewisse zeitgeistige Strömung? Hm… immerhin äußern sich hier prominente Vertreter unserer Kunst.

Oder verstehe ich da fundamental etwas falsch? Ich dachte immer, wenn man Begriffe benutzt, dann sollte man auch ziemlich genau wissen, was sie bedeuten. Wer also “Design” im Munde führt, der sollte eine Definition davon in Bezug auf unser Metier geben können. Dasselbe gilt für Architektur. Oder wer keine knappe Definition hinkriegt, der sollte zumindest typische Fragen benennen können, die zu Design oder Architektur gehören – und andere, die eben nicht dazu gehören. Aber auch das bleibt in dem Thread aus.

Ich bin also verwirrt. Aber vielleicht können Sie bzw. vielleicht kann mir die Leserschaft meines Blogs helfen?

1. Sind Software Design und Software Architecture nützliche Begriffe für unsere Branche?
2. Wenn ja, wovon sind sie abzugrenzen?
3. Wenn ja, was sind typische Fragen, die ein Software Design beantwortet?
4. Wenn ja, was sind typische Fragen, die eine Software Architecture beantwortet?
5. Wenn ja, was sind vielleicht Fragen, die beide eben nicht beantworten?
6. Wenn nein, warum nicht?

Ich bin gespannt, ob wir hier mehr Substanz für die Frage nach Relevanz und Definition dieser Begriffe zusammen bekommen.

PS: Jetzt ist noch dieser Beitrag zur Diskussion hinzugekommen:

Ron Jeffries spricht also für alle Craftsmen, wenn er sagt, sie glaubten an Design, haben jeder für sich eine persönliche Meinung dazu, was das wohl sei (“internal meaning of it”) und seien einfach zuversichtlich, dass diese vielen Meinungen ziemlich eng beieinander lägen (“close enough to the same thing”).

Leider lässt mich auch diese Äußerung wieder sprachlos zurück. Sehr öffentliche Figuren der Branche sind sich also nicht zu schade, ihre Arbeit auf unsausgesprochene Bedeutungen zentraler Begriffe zu gründen? Es reicht ihnen die Hoffnung, dass man in Diskussionen schon dasselbe meine? Und weil es nun schon ein halbes Jahrhundert so unscharf zugegangen sei, müsse man sich nun doch auch nicht mit expliziterer Definition quälen?

Nein, sorry, da komme ich nicht mehr mit. Hier verliert sich ein Zweig der Softwareentwicklung für mich in “Pseudowissenschaft”. Denn die beginnt, wo Behauptungen nicht falsifizierbar sind. Und Falsifizierbarkeit basiert auf klaren Definitionen.

Begrenzte Qualität – aber zackig!

Uncle Bob hat “crap code” den Kampf angesagt: “Craftsmanship over Crap” – zünftige Handwerksleistung soll für mehr Qualität in der Softwareentwicklung sorgen. Dagegen hat Nicolai Josuttis vor einigen Jahren den Gedanken geäußert, wir sollten endlich lernen, uns mit “crap code” abzufinden; er sei nicht zu vermeiden:

“So, when I say "Welcome Crappy Code", my point is not to force crappy code. My point is simply to face the reality. But, yes, you can consider my position as a view of resignation.”

Natürlich habe ich mich gegen eine solche Resignation gewendet. Nicht umsonst habe ich die Clean Code Developer Initiative mitgegründet. Ja, wir können “crappy code” aus der Welt schaffen! Wir müssen uns nur bemühen. CCD macht´s möglich.

Nun sind seitdem zwei Jahre vergangen und ich sehe die Welt ein wenig anders.

Es gibt viel Motivation in der Entwicklergemeinde, nicht länger “crap code” zu entwickeln. Die Zahl der Mitglieder in der CCD XING-Gruppe wächst ungebrochen. Das ist toll.

Ich glaube auch weiterhin daran, dass wir schlechte Qualität nicht fatalistisch hinnehmen sollten. Teams müssen besseren Code schreiben, wenn sie im Geschäft bleiben wollen. Und wir haben auch grundsätzlich die Kenntnisse, wie das geht, besseren Code zu schreiben.

Aber… ja, ich sehe da ein Aber. Der geballten Faust in der Tasche der Entwicklerschaft steht eine ökonomische und organisatorische und kognitive Macht gegenüber, die nicht zu vernachlässigen ist.

Softwarequalität (also innere Softwarequalität vor allem im Sinne von Korrektheit und Evolvierbarkeit) ist nur ein Wert unter vielen. So wie Ehrlichkeit auch nur ein Wert unter vielen ist.

Wo es aber ein Wertesystem gibt, also viele, auch noch konkurrierende Werte, da müssen Werte ausbalanciert werden. Wie in der Produktion muss das Optimum beim Ganzen eingestellt werden und nicht beim Teil.

Schon das bedeutet, dass wir nie zu optimaler innerer Qualität kommen werden. Sie wäre ein lokales Optimum, unter dem das Ganze leiden würde.

Dazu kommt, dass wir nicht einmal optimale Qualität herstellen könnten, wenn wir wollten. Wir verhalten uns in Bezug auf innere Softwarequalität nicht rational. Denn rational wäre, unsere Begrenzung durch Kosten bei ihrer Herstellung zu akzeptieren und danach abzuwägen.

Wir können nicht einmal rational entscheiden, weil neben ökonomischen und organisatorischen Gründen auch kognitive Gründe unsere Entscheidungen beschränken. Ich behaupte, dass wir nicht einmal wissen können, was die optimale Qualität wäre. Kein noch so langes Nachdenken und Diskutieren darüber würde uns zu einer eindeutigen Lösung bringen. Der Grund dafür liegt in der Volatilität der Anforderungen. In einer kleinen Serie zu den Gesetzen der Softwareentwicklung hatte ich dazu schon einmal etwas gesagt.

Es geht also nicht. Verabschieden wir uns von der Vorstellung hohe oder gar optimale innere Qualität herzustellen. Wir bewegen uns nicht im Bereich der Rationalität, sondern müssen unter Bedingungen Beschränkter Rationalität (Bounded Rationality) arbeiten.

Unser Ziel kann eingebunden in ein Netz von Werten nur eine genügend gute innere Softwarequalität sein. Wir müssen uns mit “good enough” bescheiden. Auf allen Ebenen: bei der Architektur, bei der Modellierung, bei der Implementierung. Immer kriegen wir nur “good enough” hin. Das sehe ich als Annäherung an Nicolais Standpunkt.

Also: Mehr Qualität, ja! Aber den Anspruch an die Qualität begrenzen.

Das bedeutet zum Beispiel, wir können uns das ganze Gerede über Eleganz sparen. Eleganz ist etwas für Leute mit viel Zeit. Eleganz ist Verfeinerung. Und damit gewinnt man keine Schlacht.

Ebenso können wir uns längliche Diskussionen über alle Prinzipien von Clean Code Developer sparen. Sollte die Methode auf dieser Klasse oder jener definiert sein, damit das SRP eingehalten wird? Solche Fragen müssen ohne Zweifel erörtert werden – doch am besten in einer Timebox. Wenn darüber nach 10 Minuten keine Einigung mit Argumenten erzielt werden kann, dann sollte der Code so bleiben, wie er ist. Die Zukunft wird zeigen, wer in der Diskussion Recht hatte.

Die Prinzipien und Praktiken von Clean Code Developer behalten ihren Wert – aber nun sehe ich noch eine Herausforderung, die darüber hinausgeht:

Wie kommen wir möglichst schnell zu einer “good enough” Softwarequalität? Eine Liste mit Werten und Prinzipien auf Kärtchen ist nicht genug. Gedruckt sind die nämlich geduldig. Und auch die Mahnung, man solle sich täglich um sie bemühen, ist geduldig. Im Tagesgeschäft ist das schwer. Und das nächste Refactoring ist immer weit. Und TDD ist auch nicht einfach.

Nein, ich glaube, wir müssen anders vorgehen, um schnell zu “good enough” zu kommen. Wir müssen das Schreiben der Software so verändern, dass quasi automatisch und ohne lange Diskussion “good enough” rauskommt. Alles, was nicht sofort beim Schreiben passiert, passiert nämlich tendenziell gar nicht.

Das hat TDD im Grunde schon begriffen – nur ist die Refactoring-Phase sehr unspezifisch.

Also: Wie können wir zügig begrenzte Qualität in unserer begrenzten Rationalität herstellen? Wie setzen wir uns sinnvoll Grenzen in der Entwicklung, um schlicht nicht mehr soviel falsch machen zu können?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Architekturvision braucht Visualisierung

Über den Begriff Architekturvision bin ich in letzter Zeit ein paar Mal gestolpert. Zuletzt in der “Hauszeitschrift” Ausgabe August/2011 von it-agile.

Es freut mich natürlich, dass das Thema Softwarearchitektur an Sichtbarkeit gewinnt. Doch irgendwie will mir nicht ganz schmecken, was da jetzt unter “Agile Softwarearchitektur” in Umlauf gebracht wird. In dem Topf wird schnell alles verrührt, was irgendwie im Umlauf ist: User Stories + TDD + DIP + CQRS, fertig ist die Architektursuppe. Hm… Aber darüber ein andermal mehr. Hier will ich mich auf die Architekturvision konzentrieren.

Auf Seite 27 des genannten Heftes findet sich eine Beispielarchitekturvision (ohne nähere Angabe einer Problemdomäne):

“1. Es handelt sich um eine Internetanwendung.
2. Als Programmiersprache wird Java verwendet und JavaScript für das Frontend.
3. Im Backend wird Spring als Dependency-Injection-Container verwendet.
4. Für die Persistenz wird ein relationales Datenbanksystem verwendet und Hibernate für die Anbindung an das Datenbanksystem.
5. Als View-Framework wird Spring Web MVC mit JSPs verwendet.
6. Quasar ist unser Architekturstil.”

Der Zweck dieser Architekturvision:

“In dieser sollten genau die technischen und architekturellen Eigenschaften des Produktes beschrieben sein, die sich im weiteren Entwicklungsgeschehen far nicht mehr oder nur sehr schwer ändern lassen.”

Die Architekturvision soll sich also mit nicht-funtkionalen Belangen der Aufgabenstellung befassen. Und sie soll sich auf Fixpunkte konzentrieren. Bei beidem stimme ich zu. Eine Architekturvision ist also von Natur aus auf einem hohen Abstraktionsniveau. Die Beispielvision konzentriert sich auf das Was und nicht auf das Wie. So weit so gut.

Was ist aber mit dem Warum? Das halte ich für sehr wichtig gerade bei Architekturentscheidungen. Der vorgestellte Architekturvision fehlt jede Begründung, warum die Entscheidungen so ausgefallen sind. Weder enthält sie eine Erklärung, noch enthält sie einen Kontext, aus dem eine Erklärung später abgeleitet werden könnte.

Laut it-agile ist eine Architekturvision eine simple Liste von Festlegungen. Das war´s.

Mir ist das zuwenig. Und auch die rein textuelle Fassung finde ich wenig hilfreich. Da gibt es zwar eine verbale Verortung von Technologien, doch letztlich muss sich jeder die Topologie des Systems zusammenreimen. Missverständnisse sind da vorprogrammiert.

Auch mit dieser Aussage stimme ich nicht überein:

“Folglich hängt der konkrete Umfang der Architekturvision von den Fähigkeiten des Entwicklungsteams ab.”

Das würde ja die Architekturvision von der Selbsteinschätzung eines Teams abhängig machen. Damit wäre letztlich jedes Team grundsätzlich legitimiert, die Architekturvision dünn zu halten, weil es sich einfach für erfahren und fähig hält. “Ach, das haben wir schon so oft gemacht. Das müssen wir jetzt nicht nochmal diskutieren und aufschreiben.” Ich höre sie schon die Teammitglieder, die alles lieber tun, als über eine Architekturvision zu diskutieren und sich dann auch noch festzulegen. Das ist doch einengend; wer weiß schon, was in der Zukunft kommt? Besser man spart die Zeit und hält sich alle Optionen offen.

Nein, mit so einer relativierenden Empfehlung bin ich gar nicht zufrieden.

Das soll natürlich nicht heißen, dass man Architekturvisionsdokumentenberge erzeugt. Doch ein wenig immer gleiche Systematik kann nicht schaden. Ich verstehe schon, dass die Architekturvision keine Doktorarbeit werden soll. Natürlich soll sie zügig hergestellt werden können. Dem dient aber die Reduktion von Missverständnissen. Und das kann erreicht werden, indem Sie sich eine kleine Checkliste für Architekturvisionen zurechtlegen. Die besteht für mich aus zumindest zwei Oberpunkten:

Architekturvision I – Das Big Picture

Zuerst sollten Sie sicherstellen, dass Sie das Big Picture vollständig im Blick haben. Darin betrachten Sie das zu realisierende Softwaresystem als Ganzes in seinem Umfeld.

Fragen Sie:

1. Wer benutzt das Softaresystem? Welche Rollen arbeiten damit, welche anderen Softwaresysteme benötigen seine Dienste? Es geht darum, wer von Ihrem Softwaresystem abhängig ist.

2. Wovon ist Ihr Softwaresystem abhängig? Auf welche Ressourcen greift es zu, seien das Dateien, Datenbanken, andere Softwaresysteme, Drucker, Maschinen usw.?

Mit diesen Information erstellen Sie ein erstes System-Umwelt-Diagramm:

Damit bekommt die Architekturvision eine erste grobe Form. Sie wird visuell, wie es sich für eine anständige Vision gehört ;-) So lässt sich eine Architekturvision auch viel besser kommunizieren – am Whiteboard oder auf einer PPT-Folie.

Daran hangeln Sie sich anschließend weiter, Rolle für Rolle, Ressource für Ressource. Zu jedem Umweltelement stellen Sie Fragen wie:

a. Mit welcher Technologie findet die Interaktion statt? Das können bei Rollen z.B. sein Desktop-Client, Smartphone App, Web-Client oder auch Webservice. Bei Ressourcen kämen z.B. in Frage ORM, Webservice, ESB.

a.1. In welchem Modus werden die Interaktionstechnologien betrieben, z.B. zustandslos/zustandsbehaftet, REST/SOAP, unterbrechungsfreie Verbindung usw.
a.2. Gibt es Vorgaben für das Format der Datenrepräsentation bei Rollen und Ressourcen? Dialogskizzen und Datenformate können wichtige Hinweise für Architekturentscheidungen sein. [1]

b. Welche nicht-funktionalen Anforderungen sind an die Interaktionen gestellt? [2]

b.1. Gibt es Geschwindigkeitsanforderungen (Performance)?
b.2. Gibt es Lastanforderungen (Skalierbarkeit)?
b.3. Ist die Interaktion abzusichern (Security)?
b.4. Soll die Interaktion eine bestimmte Form haben (Usability)?

Das sind nur einige nicht-funktionale Anforderungen, die in den meisten Fällen relevant sind. Andere könnten sein Internationalisierbarkeit, Austauschbarkeit oder Ausfallsicherheit.

Lassen Sie sich nicht irritieren, wenn Sie nicht zu allen Antworten gleich genau wissen, wie Sie sie genau umsetzen sollen. Darum geht es bei der Architekturvision nicht. Sie können sich für Internationalisierung eines WP7-Clients entscheiden, ohne eine Ahnung zu haben, wie das mit Sliverlight geht; oder Sie setzen auf REST-Kommunikation mit einer Ressource, auch wenn Sie noch nicht recht wissen, mit welchem API Sie das in der Software bewerkstelligen.

Bei der Architekturvision geht es um Entscheidungen für Prinzipien und Paradigmen und Techniken zur Bewältigung von nicht-funktionalen Anforderungen. Solange Sie beurteilen können, dass eine Entscheidungsoption in dieser Hinsicht etwas bringt, wählen Sie sie.

Je mehr Erfahrung Sie damit haben, desto besser natürlich. Hier haben Teams mit Übung natürlich einen Vorteil; sie können Entscheidungen schneller und besser fällen. Explizit fällen sollten sie sie aber nichtsdestotrotz.

Dokumentieren Sie anschließend Ihre Entscheidungen im System-Umwelt-Diagramm. Hier eine Umsetzung der Architekturvision aus dem it-agile Heft (inkl. einiger Angaben, die dort explizit nicht zur Architekturvision gezählt wurden, mir jedoch wichtig erscheinen):

Ist doch nicht schwer zu malen, so ein Diagramm, oder? Aber es bringt soviel mehr als eine simple Liste wie im Heft. Es macht Annahmen expliziter, es lässt sich besser kommunizieren und überblicken und es ist auch noch ausführlicher, ohne überladen zu sein. Das Diagramm kostet keinen Mehraufwand gegenüber einer Spiegelstrichliste. Also nehmen Sie den Kommunikations- und Erinnerungsvorteil mit.

Am besten fragen Sie sich bei jeder Entscheidung immer sofort: Wo in einem Diagramm verorte ich die Entscheidung? Wo hat die Technologie, das Paradigma, die nicht-funktionale Anforderung ihren Platz? Ich behaupte, dass Ihnen damit Architekturentscheidungen auch leichter fallen. Sie werden nämlich greifbarer.

Architekturvision II – Das System

Das System-Umwelt-Diagramm bietet allerdings noch nicht für alle Entscheidungen einen passenden Ort. Oben haben Sie sicher schon ein paar Punkte aus der Architekturvision vermisst.

Deshalb sollten Sie das System-Umwelt-Diagramm noch etwas verfeinern. Zoomen Sie hinein in das Softwaresystem und bestimmen Sie in einem ersten Schritt grob die beteiligten Maschinen und/oder Betriebssystemprozesse. Was läuft wo? Diese Frage sollten Sie beantworten.

Hört sich nach Detailarbeit an, aber mir geht es nicht um Details, sondern nur eine zunächst grobe Vorstellung und ausdrückliche visuelle Formulierung von Fixpunkten. Um eine erste Idee von der Verteilung Ihres Softwaresystems auf Maschinen und Prozesse zu bekommen, sollten Sie nicht lange nachdenken müssen.

Fällt es Ihnen leicht, ist alles in Butter. Detaillieren Sie das System-Umwelt-Diagramm. Fällt es Ihnen nicht leicht, können Sie überhaupt noch keine Architekturvision haben. Ihnen fehlen dann Informationen, um zentrale, “visionäre” Entscheidungen fällen zu können.

Für das Beispiel sähe das Systemdiagramm aus meiner Sicht so aus (Kleinigkeiten habe ich dazu erfunden, um die Vision etwas spannender/vollständiger zu machen) [3]:

Auch hier sind die Annotationen wichtig. Assoziieren Sie soviele Entscheidungen wie möglich mit distinkten Bildelementen. Lassen Sie sich von den Bildelemente sogar leiten. Nehmen Sie jede Linie, jeden Kreis als Anlass sich zu fragen: Was könnten hier für nicht-funktionale Anforderungen relevant sein? Müssen wir etwas jetzt entscheiden, weil es grundlegend und später schwer zu verändern ist?

Ja, das meine ich so: Nutzen Sie die obige Liste und die Bilder als Checkliste. Arbeiten Sie die Spiegelstriche ab und gehen Sie dann nochmal durch die Grafiken und schauen Sie, ob Ihnen bei diesem zweiten Durchlauf noch etwas einfällt.

Die Grafiken sind insofern nicht nice to have, sondern Denkhilfe. Ich garantiere Ihnen, wenn Sie solche Grafiken als Visionsdokumente an der Wand Ihres Teamrooms haben, fällt es allen leichter, sich an der Architekturvision auszurichten.

Bottom line: Architekturvision ist gut und agil. Wunderbar. Doch machen Sie sich das Leben leichter mit systematischem Vorgehen anhand von Checklisten. Nutzen Sie die “Kraft des Visuellen”, um das mentale Modell von Ihrer Software auch schon in einem frühen Stadium möglichst leicht im Team homogen zu entwickeln.

Vsisionen dienen der Kohärenz. Sie sollen Kräfte bündeln und auf ein gemeinsames Ziel ausrichten. Was könnte dem besser dienen, als ein wahrhaft sichtbares Ziel, also eine Visualisierung der Architekturvision?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Fußnoten

[1] Bei der Architekturvision sollte vor der Entscheidung eine Auslotung der Entscheidungsspielräume stehen.

[2] Je genauer und quantifizierter die Angaben, desto besser, z.B. bei Skalierbarkeit die Transaktionen pro Sekunde oder Benutzer pro Stunde oder bei der Performance die maximale Antwortzeit.

[3] Halten Sie sich übrigens nicht lange mit komplizierten visuellen Sprachen auf. Standardkonforme UML ist hier nicht nötig. Die visuelle Sprache, die ich hier und auch sonst benutze, besteht aus 4 Symbolen für Funktionseinheiten, Rollen, Ressourcen und Abhängigkeiten. Das war´s.