Softwareevolution in Vielfalt

In einem früheren Posting habe ich über Rahmenbedingungen für die Evolution von Software nachgedacht. Den dort genannten möchte ich nun noch eine hinzufügen: die Vielfalt.

Ich glaube, dass Evolution eines Ganzen schwieriger ist, als die Evolution von Vielem, das eine Summe hat.

Das Leben auf der Erde ist nicht ein Organismus (auch wenn es die Gaia-Hypothese gibt), sondern es besteht aus unzähligen. Und es evolviert in jedem einzelnen.

Genauso ist ein Betriebssystem wie Unix oder Windows nicht “ein Ding”, sondern besteht aus Hunderten oder gar Tausenden kleinen “Dingen”, die erst in Summe das ergeben, was wir mit dem Namen “Unix” oder “Windows” betiteln.

Mein iPhone ist einerseits ein “Ding”, eine Hard-/Softwareplattform. Andererseits ist es etwas, das sich entwickelt. Die Summe einer wachsenden Zahl von Teilen, den Apps. Mein iPhone evolviert sozusagen; es passt sich meinen Bedürfnissen ständig an. Das ist ganz einfach möglich, weil es nicht monolithisch ein “Ding” ist wie mein vorheriges Handy. Die Evolvierbarkeit steckt in der Möglichkeit zur Vielfalt.

Ich kann meine Schreib-Anforderungen iterativ immer besser erfüllen, weil ich meine Schreib-Apps getrennt von den Diagramm-Apps und die wiederum getrennt von den Musik-Apps “weiterentwickeln” kann. Ich kann mit “Notizen” beginnen, zu “Nebulous” weitergehen, auf “Pen & Paper” umsatteln und schließlich bei bei “Simplenote” enden.

Die Erfüllung anderer Anforderungen, ist von dieser Weiterentwicklung nicht betroffen. Ich kann auch jederzeit meinen Fokus wechseln. Mal möchte ich beim Schreiben vorankommen, mal möchte ich die Fotonachbearbeitung verbessern.

Diese Offenheit zur Evolution eines Ganzen durch feingranulare Evolution einer Vielfalt von Summanden, halte ich für eine Voraussetzung für evolutionären Erfolg. Unix hat es in Software vorgemacht, der PC hat es in Hardware nachgemacht, das Web hat dieses Prinzip ins Extreme getrieben, das iPhone setzt wieder darauf.

Voraussetzung für eine derartige Evolution der Vielfalt ist eine Plattform. Bei Unix war es der Kernel, würde ich sagen, beim PC der Bus mit seinen Slots für die Erweiterungskarten, beim Web TCP+DNS+HTTP+HTML, beim iPhone Hardware+iOS+AppStore.

Und was bedeutet das für Ihre Anwendung?

Wenn der Kunde kommt und sagt, er wolle “eine Anwendung”, dann nehmen Sie das “eine” nicht so genau. Ihr Kunde will einen Anforderungsberg abgetragen bekommen. Klar. Aber letztlich ist ihm egal, ob das mit 1 Anwendung (lies: EXE) geschieht, solange es praktikabel und nachhaltig geschieht.

Denken Sie also nicht reflexhaft an 1 großes Fenster für die GUI, in dem sich irgendwie alles abspielt. Denn das zwingt den Code in schnell in 1 großen Kasten, in dem er leicht verklebt.

Stattdessen überlegen Sie, wie Sie die Lösung als Summe einer Vielfalt von Apps beschreiben können. Ja, ich meine App in der Linie von iPhone oder iPad Apps. Das sind kleine, sehr fokussierte Programme. Sie dienen einem überschaubaren Zweck. Ihre Usability ist zu dessen Erfüllung maximiert.

Deshalb sehen die Apps auch alle sehr unterschiedlich aus. Eine Foto-App ist ganz anders als ein Spiel und das unterscheidet sich von der Mindmap-App. Das nehmen wir ihnen nicht übel, sondern begrüßen es. Auch, dass wir auf dem iPhone nur jeweils 1 App zur Zeit sehen, stört uns meist nicht. Im Gegenteil: so fokussieren wir uns.

Ich glaube, dass wir diesen Ansatz auf unsere “Geschäftsanwendungen” übertragen sollten. Wir sollten sie zerschlagen in eine Vielfalt von Apps. Und jede dieser Apps kann separat evolvieren.

Beispiel Faktura. Landläufig würde ein Softwarehaus für die Anforderungen, die hinter dem Begriff stehen, eine Anwendung bauen. Eine EXE, die auf allen Desktops im Büro installiert wird. (Und vielleicht noch ein SQL Server auf einem Server-Rechner.) Alle Funktionen würden über ein Hauptfenster erreicht und liefen im Faktura-Prozess ab.

Jede Änderung würde dann notwendig die eine Codebasis betreffen. Unschöne Kopplungen würden bei aller Mühe immer wieder entstehen. Die Evolvierbarkeit würde schnell sinken. (Ja, dagegen kann man sich mit Prinzipien und Praktiken stemmen, doch die grundlegend monolithische Sicht auf die Anforderungen macht es schwer für sie zu greifen.)

Wie anders würde die Entwicklung verlaufen können, wenn das Projekt mit evolvierender Vielfalt angegangen würde. Dann gäbe es eine App für die Rechnungslegung, eine App für die Stammdatenpflege, eine App für den Zahlungseingang, eine App für das Mahnwesen und eine App für den Chef. Vielleicht auch noch eine App für den Import und Export. Oder noch eine App für die Gestaltung unterschiedlicher Rechnungsvorlagen.

Es gäbe nicht mehr eine große Codebasis. Es gäbe ja nicht mehr eine Anwendung, sondern viele, ein Anwendungssystem. Die könnten Codeteile gemeinsam verwenden. Aber sie wären grundsätzlich sehr deutlich getrennt. Änderungen würden dann nicht mehr zu ungewollten Kopplungen in der Codebasis führen, da sie meist nur eine App zur Zeit beträfen. An manchen Apps würde mehr geschraubt als an anderen. Apps, die später in Angriff genommen würden, könnten intern anders aufgebaut sein, als frühere Apps, weil man schon aus Fehlern gelernt hat. Überhaupt müssten Entscheidungen nicht immer für “alles” getroffen werden; keine Notwendigkeit für 1 allumfassende Datenbank, 1 allumfassendes Datenmodell, 1 alle glücklich machende Persistenztechnologie, 1 GUI-Technologie usw.

Eine App könnte ihre Daten in SQL Server speichern, die andere in MongoDb. Die eine App könnte noch mit einer WinForms-Benutzerschnittstelle versehen sein, die andere WPF benutzen. Und wenn in einer App die Unwartbarkeit erreicht sein sollte, dann könnte die ganz unabhängig von allen anderen neu gemacht werden.

Ich kann nur Vorteile in einer solchen Vielfalt erkennen. Sie eröffnet Chancen, ohne einzugrenzen.

Es gibt lediglich eine Hürde: die in unseren Köpfen. Wir müssen Anwendungen so denken wollen. Technisch spricht nichts dagegen, sondern alles dafür. Auch sollten uns die genannten Präzedenzfälle ermutigen. Wir alle lieben Plattformen, die wir stückweise erweitern, die wir evolvieren können. Warum also nicht die Vorteile feingranularer Vielfalt für unsere eigenen Projekte nutzen?

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

PS: Einige Leser werden nun denken, ich würde damit vorschlagen, dass eine GUI-Shell oder ein Basisframework wichtig seien. Ohne etwas Gemeinsames unter allen Apps oder über allen Apps sei solche Vielfalt nicht zu machen. Nichts könnte mir jedoch ferner liegen. Anwendungsevolution durch eine Vielfalt an Apps hat keine Voraussetzung; nichts muss erstmal eingerichtet werden. Jede App kann unabhängig von anderen jederzeit begonnen werden. Das Betriebssystem als Plattform reicht.

PPS: Das Ganze nicht als Monolith zu sehen, sondern als Summe von vielen Teilen, sollte sich natürlich durch alle Ebenen einer Software ziehen. Die ganze Anwendung besteht aus unabhängig evolvierbaren Apps. Jede App besteht aus unabhängig evolvierbaren Bausteinen. Und diese Bausteine wiederum sind unabhängig evolvierbar. Apps sind mithin Ausdruck der Selbstähnlichkeit von Software.

Bausteine für die Softwareevolution

Wenn wir Software naturnah entwickeln wollen, also als evolvierbares System, wie sollte sie denn dann aufgebaut sein? In meinem vorherigen Artikel habe ich mir Gedanken über eher organisatorische Voraussetzungen für naturnahe Entwicklung gemacht. Diesmal will ich die technische Seite angehen. Oder besser: wieder angehen, denn vor Jahren schon hatte ich in diese Richtung spekuliert [1]. Damals waren meine Idee eher im Konzeptionellen verblieben - heute habe ich eine Vorstellung von ihrer Implementation.

Voraussetzung Selbstähnlichkeit

Ich glaube immer noch, dass Software nur wirklich gut evolvieren kann, wenn ihre Struktur selbstähnlich ist. Das heißt erstens, dass es in Software mehrere Ebenen gibt. Und zweitens bedeutet es, dass der grundlegende Aufbau aller Ebenen gleich ist.

Ich möchte diese Ebenen jedoch nicht Schicht/Layer nennen. Der Begriff ist überladen und deutet deshalb in die falsche Richtung. Stattdessen wähle ich Stratum; damit lehne ich mich an Abelson/Sussman an, die von Stratified Design sprechen.

Selbstähnlichkeit hat den Vorteil, dass Erfahrungen und Denken nicht ebenenspezifisch sind. Man kann auf einer beliebigen Ebene beginnen und sich sowohl nach oben wie nach unten vorarbeiten, ohne einen konzeptionellen Bruch zu erleiden.

Methoden sind etwas ganz anderes als Klassen, die wiederum etwas anderes sind als Assemblies, die wiederum ganz anders sind als Prozesse. Wenn wir mit diese Mitteln Software in unserem mentalen Modell repräsentieren, dann ist das kompliziert, weil immer wieder anders.

Eine Reduktion auf Klassen allein jedoch ist nicht möglich, da Klassen konzeptionell nichts enthalten außer Methoden. Klassen sind nicht schachtelbar. Sie sind dafür gedacht, Zustand und Funktionalität zusammenzufassen. Das war´s. [2]

Selbstähnlichkeit ist für mich die Voraussetzung, dass Systeme sich entwickeln können. Sie können in der Breite wachsen (innerhalb einer Ebene) oder sie können nach oben wachsen (Abstraktion, Aggregation) oder sie können nach unten wachsen (Verfeinerung, Spezialisierung).

Voraussetzung Unabhängigkeit

Dann glaube ich, dass die Bausteine in den Strata einer Software, unabhängig von einander sein sollten. Abhängigkeiten – statische wie dynamische – sind der Anfang allen Unwartbarkeitsübels. Dependency Injection zum Zwecke der Bereitstellung von Dienstleistungen ist keine Lösung, sondern perpetuiert das fundamentale Problem.

In der Natur finden sich keine Dienstleistungsabhängigkeiten in der Form, wie sie in Software allerorten existieren. Keinem Organismus wird eine Abhängigkeit injiziert. (Nur Parasiten injizieren sich – wir denken an Sacculina, Juwelwespe oder Ridley Scotts Alien.) Organismen brauchen einander, aber nicht in Form von “Referenzen” oder “Handles”. Sie sind vielmehr auf ihre jeweils autonom hergestellten “Outputs” angewiesen. Das ist gelebte Entkopplung.

Dasselbe gilt für den Maschinenbau oder die Elektrotechnik. Einem Motor wird kein Benzintank injiziert, auch wenn er ohne den Treibstoff nicht arbeiten kann. Benzintank und Motor werden lediglich verbunden; es gibt Berührungspunkte, aber keine Abhängigkeiten.

Allemal gibt es keine so breiten Abhängigkeiten wie die durch Interfaces üblicherweise eingegangenen. Ein Motor ist nicht von einem Chassis oder einen kompletten Restauto abhängig. Er hat verschiedene Input-Kanäle, die nur irgendwie gespeist werden müssen. In einem Motorprüfstand wird deutlich, dass das auch ganz anders als mit einem Auto geschehen kann. Dasselbe gilt für einen menschlichen Körper, der ganz ohne Herz und Lunge auskommen kann, wenn an die Gefäße eine Herz-Lungen-Maschine angeschlossen ist.

Abhängigkeiten machen Systeme starr. Evolvierbarkeit setzt daher maximale Unabhängigkeit voraus.

Voraussetzung Nachrichtenorientierung

Die Verbindung zwischen Lebewesen ist immer “nachrichtenorientiert”. Wichtiger ist aber die Nachrichtenorientierung. “Daten” fließen unidirektional von einem Lebewesen zu einem anderen, gezielt oder diffus. Folgt man dem Konstruktivismus, dann ist die Welt (und damit andere Lebewesen) gar nicht direkt erfahrbar. Wir haben lediglich eine begrenzte Wahrnehmungsbreite und empfangen Signale. Die Ausgangspunkte dieser Signale selbst haben wir nie in der Hand. Wir konstruieren sie uns aus den Signalen.

Wenn das für die Evolution der Natur so zentral ist, dann scheint es mir vorteilhaft für Software, die ebenfalls hochgradig evolvieren muss. Ihre Bausteine sollten ebenfalls nur über Nachrichten kommunizieren. Das heißt, es gibt kein Call/Response, sondern nur unidirektional fließende Datenpakete. (Inwiefern die Referenzen auf den Zustand von Bausteinen enthalten können/dürfen, lasse ich hier mal dahingestellt.)

Softwarebausteine verstehen bestimmte Nachrichten, die sie von der Umwelt empfangen. Und sie senden eine bestimmte Menge von Nachrichten an ihre Umwelt. Sendung und Empfang sind in der Natur asynchron. Zwischen Softwarebausteinen würde ich Asynchronizität jedoch nicht zwingend voraussetzen.

Die Form evolvierbarer Software

Wenn ich diese Voraussetzungen zu einer Form für Softwarebausteine zusammenfasse, dann kommt das folgende Bild heraus:

Ich könnte diesen Softwarebaustein “Objekt” nennen, da er zustandsbehaftet ist und über Nachrichten kommuniziert. Aber “Objekt” ist so belastet, dass ich zumindest heute auf einen neutralen Begriff ausweichen möchte. Ich nenne ihn deshalb “Holon”. Das passt zur Selbstähnlichkeit; Holons sind “Dinger”, die gleichzeitig Teil und Ganzes sind.

Jedes Holon nimmt die Umgebung durch einen “Kanal” wahr und sendet über einen weiteren “Kanal” Signale an seine Umgebung, die dann andere Holons wahrnehmen können. Wahrnehmungen (Input) verarbeitet das Holon zu Zustand und/oder Signalen (Output).

Natürlich kann jedes Holon nur eine bestimmte Menge von Signalen verarbeiten und erzeugen. Signale bzw. Nachrichten bestehen daher nicht nur aus Daten, sondern haben auch noch einen Typ oder eine Bedeutung. Die Zahl 42 mag einmal die Bedeutung einer Antwort auf die ultimative Frage haben und einmal schlicht das Alter einer Person sein.

Aus Holons lassen sich nun Verarbeitungsstrukturen auf mehreren Ebenen (Strata) bilden:

Meine These ist, dass Software viel besser evolvierbar wird, wenn wir sie aus Holons aufgebaut denken. Die scheinen merkwürdig eingeschränkt gegenüber unseren heutigen OOP-Objekten. Ich behaupte aber mal, dass einen eventuelle Einschränkung mehr als kompensiert wird durch das, was wir bekommen. Und das wir nur bekommen, was wir wollen – viel mehr Evolvierbarkeit –, wenn wir uns einschränken.

Wir denken mit Holons nicht mehr über Abhängigkeitsverhaue nach. Wir haben einen ganz regelmäßigen Aufbau von Software von der kleinsten Codeeinheit bis zur größten. Wir können ganz natürlich Stratified Design betreiben. Und wir bekommen Bausteine, die sich von Hause aus für asynchrone/parallel Verarbeitung eignen.

Klar, das bedeutet, wir müssen unsere Denkstrukturen ändern und Gewohntes über Bord werfen. Der in Aussicht gestellte Gewinn scheint mir jedoch groß genug, um es damit zu probieren. Und so schwer ist es ja auch nicht, es auszuprobieren. Hier das universelle Interface für Holons:

interface IHolon {
  void Process(IHolonMessage input, Action<IHolonMessage> output);
}

Im Grunde reicht sogar ein Delegat, um jeden Baustein in jedem Stratum zu beschreiben:

delegate void Holon(IHolonMessage input, Action<IHolonMessage> output);

Und die Nachrichten, die zwischen den Holons fließen, sind auch ganz einfach:

interface IHolonMessage {
    string Type {get;};
    object Data {get;};
}

Kaum zu glauben, aber ich denke, dass mit solch einfachen Mitteln sich grundsätzlich alle Softwarelösungen ausdrücken lassen. [3] Diese einfachen Mittel stellen für mich das Rückgrat evolvierbarer Software dar.

PS: Wenn in der Softwareentwicklung Eleganz wirklich einen hohen Stellenwert hat, dann wage ich mal keck zu hoffen, dass eine Softwarestruktur dieser Art doch einigen Appeal hat. Ich zumindest finde sie in ihrer Einfachheit elegant.

PPS: Ich weiß, die Holons sehen aus wie Funktionseinheiten des Flow-Designs. Natürlich gibt es da auch einen Zusammenhang. An dieser Stelle überlege ich jedoch grundlegender. Deshalb haben Holons auch nur einen Eingang und einen Ausgang.

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

Fußnoten

[1] s. ältere Artikel in der Rubrik “Software als System” in diesem Blog, insbesondere diesen und diesen Artikel.

[2] Das heißt nicht, Objekte seien nutzlos für evolvierbare Software. Nein, ich denke, wir müssen keine neue Programmiersprache erfinden, sondern die vorhandenen nur besser einsetzen.

[3] Natürlich meine ich damit nicht, dass Software bis hinunter zu Ausdrücken aus Holons aufgebaut werden sollte. Mir geht es um das Herunterbrechen von Funktionalität bis zu einer Granularität, dass man begründet zuversichtlich sein kann, ein Blatt-Holon mit wenigen Zeilen konventionellen Codes umsetzen zu können.

Voraussetzungen für sich entwickelnde Softwarestrukturen

Liegt die Zukunft der Softwarearchitektur in Emergent Architecture und Growing Software? Diese Frage wurde in zwei Open Space Gruppen auf der SoCraTes Konferenz 2011 behandelt. Das hat mir gefallen, da ich ja mit meinen Softwarezellen auch schon einmal eine naturnahe Metapher gewählt hatte.

In den Diskussionen wurde ich das Gefühl jedoch nicht los, dass wir bei allem Appeal der Metaphern noch zu wenig darüber nachgedacht hatten, was es denn wirklich heißt, naturnah Software entstehen zu lassen. Wie entwickeln sich natürliche Systeme? Was lässt sich davon auf Softwareentwicklung übertragen? Welche Voraussetzungen sind nötig?

Struktur entspricht gegenwärtiger Umwelt

Ganz zentral für naturnahe Softwareentwicklung ist, dass wir die Rolle der Umwelt richtig verstehen. In der Natur ist alles so wie es ist, weil es so am besten zur Umwelt passt. Das ist der Kerngedanke der Evolutionstheorie, würde ich sagen. Alles an allen Organismen hat einen Zweck, den es erfüllt, so wie es ist. Da ist nichts zuviel, nichts zuwenig.

Vor allem ist nicht so entwickelt wie es ist auf Vorrat. Alles ist nur einer gegenwärtigen Umwelt mit ihren über Generationen erfahrenen Schwankungen angepasst. Kein Lebewesen besitzt eine Eigenschaft nach dem Motto “Aber was wäre, wenn Umweltparameter X in der Zukunft ganz anders aussehen würde?”

Leben ist insofern “lean”, d.h. frei von “Fett”. Es gibt keine “Eigenschaftenpolster”. Selbst die Anpassungsfähigkeit ist begrenzt, obwohl sie die wichtigste Metaeigenschaft ist.

Wenn wir wirklich naturnah Software entwickeln wollen, dann müssen wir konsequent auf den Blick in die Glaskugel verzichten. Erfahrung, die uns verleitet zu sagen, “Aber ich weiß doch, dass Kunden in den meisten Fällen noch Y wollen…”, darf nicht zu Anreicherungen in der Software führen. Das höchste der Gefühle ist, dem Kunden einen solchen Gedanken vorzulegen, um durch seine Antwort die gegenwärtige Umwelt besser zu verstehen. Das oberste Prinzip naturnaher Entwicklung ist mithin YAGNI.

Jede Entscheidung darf sich nur vom gegenwärtigen Kenntnisstand leiten lassen. Dann ist die Entscheidung erstens schnell getroffen und zweitens das Ergebnis so schlank wie möglich.

Evolution ist ohne Ziel

Wenn Evolution sich nur an der gegenwärtigen Umwelt orientiert, dann bedeutet das in verschärfter Formulierung, dass Evolution kein Ziel hat. Und das bedeutet, Evolution kann nicht vorplanen. Es gibt kein Vordenken, sondern nur Reaktion, Anpassung. [1]

Das bedeutet für die Softwareentwicklung ein viel größere als bisher übliche Konzentration auf das Hier und Jetzt. Geradezu buddhistisch muss für naturnahe Entwicklung gelten “live in the now”.

Weder Strukturen noch Schritte sollten über das unmittelbar Sichtbare und Notwendige hinaus ausgelegt sein. Zu YAGNI tritt KISS als Leitprinzip.

Evolvierbarkeit ist ein Ergebnis von Evolution

Als Ergebnis der Evolution sehen wir vor allem die umweltangepassten Eigenschaften von Lebewesen. Wir haben verstanden, dass diese Eigenschaften sich durch Feedback ausprägen. “Survival of the fittest” nennen wir das. Eigenschaften entstehen und müssen sich gegenüber der Umwelt behaupten. Passen sie nicht, sinkt die Wahrscheinlichkeit zur Weitergabe der Eigenschaften an die nächste Generation; unpassende Eigenschaften sterben aus. Das Feedback der Umwelt ist gnadenlos.

Auf die Software haben wir das inzwischen in Form iterativen Vorgehens übertragen. Wir stellen Software mit bestimmten Eigenschaften her, von denen wir meinen, dass sie zur Umwelt (den Anwendern) passen – und suchen dann das Feedback der Umwelt. So nähern nähern wir die Eigenschaften in kleinen Schritten der Umwelt an bzw. co-evolvieren Software mit der Umwelt.

Hinter den sichtbaren Eigenschaften evolvierender Systeme gibt es allerdings noch eine unsichtbare Eigenschaft: die Evolierbarkeit. Wie jede Eigenschaft unterliegt auch sie einem Zwang zur Passgenauigkeit.

Meinem Empfinden nach haben wir diese Eigenschaft als ebenfalls zu entwickeln nicht auf dem Zettel. Wir unterwerfen sie in unseren Projekten keinem Feedback. Wir unterwerfen sie nicht einmal branchenweit einem Entwicklungsdruck (oder allenfalls einem nur vergleichsweise schwachen).

Wenn wir über naturnahe Softwareentwicklung sprechen, ist das eine große Nachlässigkeit, da im Kern der gesuchten Naturnähe ja gerade die Evolvierbarkeit steht.

Wie müsste also das Feedback aussehen, um Evolvierbarkeit zu entwickeln?

Ob unsere Software schon performant, skalierbar, sicher genug ist, stellen wir fest, indem wir sie immer wieder auf die Probe stellen. “Los, zeig uns, wie schnell du bist!”, “Ha! Kommst du auch mit dieser größeren Nutzerlast zurecht?”, “Nimm diese Sql Injection Attacke, du Software, du!”

Aber wie ist es mit der Evolvierbarkeit? Was ist eine Herausforderung für sie?

Ich denke, das sollte auf der Hand liegen: Evolvierbarkeit wird durch unerwartete Anforderungen auf den Grill gelegt. “Pass dich dieser überraschenden Anforderung an, Code!”

Das erste, was Evolution lerne musste war die Unvorhersehbarkeit der nächsten Umweltveränderung. Von der hat sie ihre grundlegenden Bausteine, die Moleküle (DNA, RNA), Organellen und Zellen formen lassen. So existiert Leben am tiefsten Meeresgrund genauso wie im Darm und auf dem Mount Everest.

Für die Softwareentwicklung ist das noch eine Aufgabe, denke ich. Unsere grundlegenden Bausteine sind noch nicht wirklich evolutionsunterstützend. Allemal können wir noch viel zu leicht anti-evolutionäre Strukturen damit herstellen, wie die Massen an Brownfield-Code zeigen.

Das bedeutet, wir müssen mehr Druck auf die Evolvierbarkeit ausüben. Sonst hinkt ihre Entwicklung der anderer Eigenschaften hinterher – und behindert deren Evolution. Wir müssen also geradezu auf die Evolvierbarkeit zuallererst Evolutionsdruck ausüben, weil sie für alles andere fundamental ist. Wie soll das aber geschehen?

Nach meinem Gefühl ist das gar nicht schwer. Wir müssen erstens die Frequenz der Änderungsanforderungen drastisch erhöhen. Und zweitens müssen wir die Vorausschau drastisch begrenzen.

Ganz konkret bedeutet das für mich: Software ist jeden Tag mit überraschenden Änderungswünsche zu konfrontieren. Und jeden Tag ist Software auszuliefern. Nur so entsteht auf ihre Anpassungsfähigkeit soviel Druck, dass die wirklich geschmeidig wird. Das gilt für die allgemeine Form von “Softwarebauteilen” wie für die konkrete Struktur einer Lösung. Ohne diesen Druck werden wir nicht dahin kommen, die Prinzipien und Praktiken für dauerhafte Evolvierbarkeit zu erkennen und zu leben.

Evolution geht aufs Ganze

Wer hätte je einen Magen oder ein Gehirn oder eine Hand getrennt von einem Lebewesen sich entwickeln sehen?

Evolution findet immer am ganzen Organismus statt. Ein Lebewesen ist entweder als Ganzes an seinem Umwelt angepasst oder gar nicht. Das beste Herz nützt nichts, wenn das Nervensystem unangepasst ist.

Auf die Softwareentwicklung übertragen bedeutet das, es gibt keine Infrastrukturentwicklung. Jedes Mal, wenn sich Software der Umwelt aussetzt – also am Ende einer Iteration –, setzt sie sich als Ganzes aus. Sonst ist sie nicht “anschlussfähig” gegenüber ihrer Umwelt. Das muss sie aber sein, sonst bekommt sie kein Feedback. Und Mangel an Feedback bedeutet Stillstand und dann Tod.

Alle Arbeit an Software muss deshalb sagen können, inwiefern sie an die Umwelt anschließt, welches konkrete Bedürfnis der Umwelt sie erfüllt. Ein Team als Ganzes muss zu jeder Zeit auf die Software als Ganzes konzentriert sein. (Ein einzelner Entwickler kann sich im Rahmen dessen natürlich auf ein Detail fokussieren. Er dient damit ja einem Ganzen.)

Naturnahe Entwicklung bedeutet also Entwicklung in Durchstichen. In jeder Iteration ist eine ganze, besser angepasste Software abzuliefern. [2]

Evolution ist Verfeinerung

Schließlich scheint mir ein wesentliches Merkmal von natürlicher Entwicklung die Bewegung vom Groben zum Feinen. Evolution ist Differenzierung, ist Verfeinerung.

Die Entscheidung zwischen bottom-up und top-down Entwicklung können wir zur Ruhe betten. Diese beiden Pole sind unwichtig. Wir können die Herangehensweise wählen, wie wir mögen, wie es uns in Bezug auf eine Problemstellung passt.

Worüber wir aber nicht nachdenken sollten, das ist coarse-to-fine oder simple-to-complex Entwicklung. Software sollte schrittweise “schärfer” oder detaillierter werden.

Auch breadth-first vs. depth-first ist hier zweitrangig. Die Verfeinerung kann in der Breite in geringem Maß stattfinden oder in der Tiefe in hohem Maß. Wie es der Kunde mag. Er bestimmt die Prioritäten.

Nach jeder Iteration kann er sich wünschen, ob Feature A verfeinert werden soll oder lieber Feature X grob angegangen werden soll. Vor dem Hintergrund des täglichen Drucks auf die Evolvierbarkeit bedeutet das, der Kurs der Entwicklung kann sich prinzipiell jeden Tag ändern. Und warum auch nicht? Der Kunde, die Anwender: das ist die Umwelt. Der gilt es sich anzupassen.

Naturnahe Entwicklung findet deshalb in kleinsten Schritten statt. User Story, Use Case, ja selbst Feature sind dafür zu groß. Würden sie pro Iteration komplett umgesetzt, würde zu schnell zu viel Detail entstehen. Das wäre keine Evolution mehr, sondern Setzung.

Wenn es jedoch jeden Tag an quasi beliebiger Stelle in der Software ein Nutzenstückchen weiter geht, dann entsteht kontinuierliche Anpassungsfähigkeit. Dann kann auch nie mehr als die Arbeit eines Tages umsonst gewesen sein. Tägliches Feedback korrigiert ja den Evolutionsweg unmittelbar.

Fazit

Agile Softwareentwicklung ist schon ein Schritt in Richtung naturnahe Softwareentwicklung. Erreicht ist das Ziel mit ihr jedoch noch nicht. Wenn wir naturnahe Softwareentwicklung als Tugend ansehen, dann müssen wir ein paar Schrauben noch mehr anziehen. Evolution ist rigoroser als Agilität.

Fußnoten

[1] Ziellosigkeit mag merkwürdig klingen, da doch anscheinend mindestens der Kunde ein Ziel hat. Er möchte schließlich eine Software für einen bestimmten Zweck. Wie oft ist es aber der Fall, dass am Ende der Entwicklung genau das herauskommt, was am Anfang in den Anforderungen drin gestanden hat? Wie oft sind Anforderungen vollständig? Ich halte es deshalb für besser, die Idee von der Zielhaftigkeit im Sinne einer sichtbaren Zielmarke aufzugeben. Softwareentwicklung ist vielmehr ziellos – hat jedoch ein Ende. Beendet ist sie, wenn der Kunde sagt “Genug!”

[2] Mit “ganze Software” meine ich natürlich nicht, dass vom ersten Tag an eine komplette Buchhaltung oder eine ganze Textverarbeitung ausgeliefert werden soll. Wie sollte das auch gehen? Nein, “ganze Software” bedeutet, dass die Software für den Anwender als etwas sinnhaftes wahrnehmbar ist, zu dem er Feedback geben kann. Für eine Buchhaltungssoftware bedeutet das nicht mal, dass es ein GUI geben muss, sondern am ersten Tag vielleicht nur einen Prüfstand, mit dem der Anwender Feedback zum Datenimport geben kann.

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

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.