Daten als systemrelevante Größe behandeln

Systemrelevante Größen sind in der Softwareentwicklung wie auch sonst im Leben zu vermeiden. Dieser Meinung bin ich immer noch und sogar immer mehr.

Doch auch wenn wir sie vermeiden sollen, heißt das nicht, dass wir das immer können. Manches ist einfach systemrelevant, weil es die fundamentale Wahl für ein System repräsentiert. Es muss konstant bleiben - ansonsten handelt es sich um ein ganz anderes System. Für die westliche Welt sind das z.B. eine Demokratie oder Marktwirtschaft.

Für die Softwareentwicklung gibt es das auch. Da gibt es einen Aspekt, der ist so zentral, dass wir nicht um ihn herum kommen. Er ist bestimmend. Es ist unveränderlich.

Damit meine ich nicht, ein bestimmtes Betriebssystem oder eine Entwicklungsplattform. Im Gegenteil! Die müssen ständig disponibel.

Nein, ich meine die Daten. Die Daten einer Software bzw. eines Unternehmens sind aus meiner Sicht eindeutig systemrelevant. Sie sind förmlich das Fundament. Sie gilt es zu hegen, zu pflegen, zu erhalten. Nicht umsonst heißt es: data outlives application.

Anwendungen kommen und gehen über Jahre und gar Jahrzehnte. Doch die Daten bleiben. Sie wachsen nur. Allemal in Zeiten scheinbar unbegrenzten Speicherplatzes scheint es töricht, Daten zu löschen. Wer weiß, wann sie einmal nützlich werden könnten für eine Big Data Auswertung?

Wenn das aber nun so ist, dass Daten unvermeidbar systemrelevant sind, was bedeutet das für den Umgang mit ihnen?

Ich denke, systemrelevante Größen brauchen eine spezielle Behandlung. Sie stehen ja quasi außerhalb des Gesetzes. Wir sind von ihnen abhängig. Deshalb müssen wir darauf achten, dass sie uns keine Diktatur aufzwingen. Wenn eine Größe systemrelevant ist, dann ist sie ein Herrscher. Mit einem "guten König" lässt es sich da leben; aber einen unberechenbaren Nero wollen wir nicht über uns haben.

Letztlich sollte auch die systemrelevante Größe an einem guten Verhältnis mit ihren Untertanen interessiert sein. Denn die Abhängigkeit besteht letztlich in beide Richtungen. Ohne ein System, ist die Größe nichts.

Also, was bedeutet es für die Softwareentwicklung oder genauer: für die Softwarearchitektur, dass Daten eine unvermeidlich systemrelevante Größe sind?

Wie im richtigen Leben folgt daraus die Notwendigkeit zu Transparenz und Flüssigkeit, würde ich sagen.

Systemrelevante Größen müssen besonders offen und verständlich sein. Weil sie systemrelevant sind, können sie ja nicht ersetzt werden. Wenn man sie nicht mehr versteht, gibt es keine Alternative.

Systemrelevante Größen müssen besonders flüssig sein. Ihre Form muss sich verändern lassen. Sie dürfen sich nicht aus innerer Trägheit/Festigkeit dem Wandel widersetzen. Denn Wandel - soviel sollte gewiss sein - wird nötig sein. Systemrelevante Größen haben eine lange Lebensdauer, so dass Veränderungen in der Umwelt und deshalb Anpassung unvermeidbar sind.

Alles, was die Transparenz/Verständlichkeit und die Flüssigkeit beeinträchtigt, ist also zu vermeiden.

Was bedeutet das für Daten konkret?

Daten müssen in einer Weise gehalten werden, die transparent und verständlich ist. Klingt vielleicht einleuchtend - wird aber oft nicht beachtet. Einkaufspolitik, Tradition, Performance und andere Kräfte ziehen Daten oft in eine Form, die Transparent und Verständlichkeit reduzieren. So weit reduzieren, bis nur noch eine kleine Gruppe von Personen die Daten versteht. Die bestimmt dann über das Schicksal einer Organisation - ob sie will oder nicht.

Was Transparenz im konkreten Fall bedeutet, weiß ich nicht. Das ist von Fall zu Fall, von Datenbasis zu Datenbasis verschieden. Das eine große Unternehmensdatenmodell mit 1468 eng verwobenen Tabelle in einer Oracle Monsterserver ist aber sicherlich keine Lösung.

Eher sind es Daten in unterschiedlicher Organisationsform in verschiedenen Bounded Contexts, die transparent sind.

Daten müssen darüber hinaus auch in einer Weise gehalten werden, die es leicht macht, ihre Form immer wieder zu verändern. Formate und Technologien, die es schwer machen, zu exportieren und zu importieren, sind zu vermeiden. Lock-In jeder Art ist eine Gefahr für das System. Wer sagt, "Wir sind eine XYZ-Company!" ist schon auf dem falschen Weg. (Setzen Sie für XYZ ein Persistenzprodukt oder eine Technologie oder ein Paradigma Ihrer Wahl ein.)

ETL ist deshalb auch here to stay und wird weiter an Bedeutung gewinnen. Weil die Vielfalt der Optionen, der Anwendungen und Bounded Contexts wächst, mit/in denen Daten gesammelt und verarbeitet werden.

Event Sourcing halte ich aus diesem Grund auch für zeitgemäß. Denn damit werden Daten im Grunde von jedem Format befreit. Das macht sie maximal flüssig. Events sind quasi ein Granulat, das in immer neue Form je nach Bedarf gegossen werden kann.

Ja, ich denke, Transparenz und Flüssigkeit sind die beiden zentralen universellen nicht-funktionalen Anforderungen an die Datenhaltung. Sonst ist sie nicht nachhaltig. Sonst kommt es zu hemmendem Lock-In der einen oder anderen Art - und das kostet Geld.

Daten sind eben ein oder vielleicht sogar die einzige wirklich systemrelevante Größe in der Softwareentwicklung. Deshalb müssen wir mit ihnen in besonderer Weise umgehen.

JavaScript Unit Testing mit WebStorm Schritt für Schritt

JavaScript tut Not. Es hilft halt nichts. Lieber würde ich mich zwar mehr mit F# beschäftigen, doch dringender scheint mir JavaScript-Fingerfertigkeit. Denn mit JavaScript kann ich meine Reichweite vergrößern in Richtung Web und Mobile. Bisher bin ich ja eher der “Desktop GUI Guy” ;-) Und mit JavaScript kann ich coole Entwicklungen schneller mitmachen im Bereich Backend, z.B. node.js oder Cloud APIs. .NET Bindings werden da ja eher stiefmütterlich behandelt.

F# brächte mir zwar Vorteile bei der Strukturierung von Geschäftslogik. Doch da bin ich weniger Unzufrieden mit C# als bei Reichweite und Modernität.

Also mehr JavaScript. Hier ein bisschen, da ein bisschen. Vor allem aber auch gern testgetrieben.

Als Entwicklungsumgebung habe ich mir mal WebStorm von JetBrains angeschafft. Das war sehr preisgünstig beim letzten Cyber Monday und schien ordentlich.

Damit geht auch testgetriebene Entwicklung – nur ist die nicht so einfach zu starten, wie bei VS mit ReSharper. Deshalb hier ein Spickzettel zunächst einmal für mich selbst:

1. Verzeichnisse einrichten: In einem WebStorm Projekt zwei Verzeichnisse einrichten, eines für den Produktionscode, eines für Testcode.

Wie die Verzeichnisse heißen, ist eigentlich egal. Ihre Namen müssen nur korrekt im nächsten Schritt referenziert werden.

2. Konfigurationsdatei angelegen: Bei .NET findet ein Testrunner die Tests automatisch in den Assemblies eines Projektes. Bei JavaScript muss man dafür jedoch eine Konfigurationsdatei anlegen. (Zumindest für den JavaScript Test-Driver, der mit WebStorm ausgeliefert wird.) Der Name der Datei ist nicht so wichtig, die Extension muss allerdings .jstd sein:

Die Konfiguration ist simpel: Sie enthält die Adresse des Testrunners, der in einem Browser läuft. Und sie listet die Quellen für Produktionscode (load:) und Tests (test:):

server: http://localhost:9876

load:
  - src/*.js

test:
  - tests/*.js

Die Quellen nehmen Bezug auf die oben angelegten Verzeichnisse.

3. Tests werden im Testverzeichnis angelegt. Am besten zur weiteren Konfiguration des Testframeworks einen Probeweisen Test anlegen. Im ersten Schritt sieht der nur so aus:

Wichtig ist, dass angeboten wird, die Bibliotheksdateien des Testframework zu laden. Das sollte mit dem Shortcut getan werden. Dann sieht das Projekt so aus:

Durch die Referenzierung dieser Dateien steht für Tests Intellisense zur Verfügung:

Achtung: Tests müssen den Präfix “Test” haben!

4. Leider läuft der Probetest jetzt noch nicht einfach so. Es muss erst noch eine Laufzeitkonfiguration für das Projekt angelegt werden:

Hier wird die .jstd-Datei referenziert! Und der Name der Konfiguration taucht dann im Run-Menü auf:

5. Jetzt den Probetest ausführen lassen. Falls das nicht funktioniert, läuft der Testserver wahrscheinlich nicht. Der wird im Browser gehostet. Gestartet werden kann er über die IDE:

Durch Klick auf ein Browser-Icon wird der Testrunner-Server als Seite im Browser geöffnet:

Und nun – Wunder der Technik! – wird auch der Test über Run ausgeführt. Die IDE erstrahlt in frischem Grün:

 

Das war´s. Jetzt, da ich das Setup nochmal Schritt für Schritt durchlaufen bin, ist es gar nicht mehr so undurchsichtig. Aber wer weiß… Wenn ich mal wieder längere Zeit JavaScript nicht in die Hand nehmen sollte, hilft mir diese Erläuterung bestimmt, schneller wieder reinzukommen.

Und es bewahrheitet sich der alte Spruch, dass man durch Lehren, also Erklären, am besten lernt.

Zeitgemäße Architekturkompetenz

Die Frage, was denn die Aufgabe eines Softwarearchitekten sei, ist nicht tot zu kriegen. Eine Konferenz, die etwas auf sich hält, hat dazu mindestens eine Podiumsdiskussion.

Ich habe da jetzt keine Lust mehr drauf. Das ewige Diskutieren hält uns davon ab, das Wichtige zu tun, nämlich Softwarearchitektur zu betreiben.

Im Sinne des Cult of Done beende ich deshalb jetzt für mich die Arbeit am Begriff "Softwarearchitektur". I´m done.

Hier die Eckpfeiler der Definition, was Softwarearchitektur aus meiner Sicht bedeutet:

1. Softwarearchitektur dreht sich nur um nicht-funktionale Aspekte von Software. Ihre Ergebnisse spannen den Rahmen für Funktionalität auf.
2. Softwarearchitektur hat das Ganze im Blick. Ihre Aufgabe ist es, ein globales Optimum herzustellen und lokale Optima zu vermeiden [1]. Softwarearchitektur ist damit eine ökonomische Disziplin.
3. Da es nicht so einfach "das Ganze" gibt, sondern immer nur verschiedene Blickwinkel und unterschiedliche Werte, Anforderungen, Bedürfnisse, die sich auch noch über die Zeit verändern, kann Softwarearchitektur nicht einmal ein Optimum einstellen. Architektur ist daher ein Prozess, ihr Ergebnis ein dynamisches Gleichgewicht.

Die Invariante der Softwarearchitektur ist mithin der Wandel. Alles kann sich über die Lebensdauer einer Software verändern.

Deshalb ist für mich die Evolvierbarkeit die zentrale nicht-funktionale Anforderung, um die sich die Softwarearchitektur kümmern muss.

Natürlich beantwortet Softwarearchitektur Fragen zu...

• Produkten, z.B. "Soll Sql Server oder Oracle eingekauft werden?"
• Technologien, z.B. "Soll ein RDBMS oder eine NoSql Datenbank zum Einsatz kommen?"
• Paradigmen, z.B. "Sollen die Daten relational strukturiert werden oder dokumentenorientiert?"

Und viele weitere Entscheidungen trifft die Softwarearchitektur auch noch. Ständig muss sie dabei abwägen, um keine nicht-funktionale Anforderung aus dem Blick zu verlieren. Kann sie das eigentlich? Wer hat die Kompetenz, aus einer wachsenden Zahl von Optionen, die richtigen auszuwählen? Es scheint mir zunehmend schwieriger.

Dass 1 Person dies als Architekt dauerhaft kann, glaube ich nicht. Deshalb ist für mich zeitgemäße Architekturkompetenz eine Teamangelegenheit [2]. Dabei mag der eine mehr, der andere weniger Spaß daran haben - ohne dass am Ende jedoch alle zumindest verstanden und zugestimmt haben, sehe ich keinen hohen buy-in. Und ohne hohen buy-in, droht von vornherein Erosion der Architektur(vision).

Also: Es gibt viel zu beachten für die Softwarearchitektur. Kräfte ziehen sie in verschiedene Richtungen, Anforderungen sind im Wandel, Optionen entwickeln sich... Mir scheint es daher illusorisch, von der Softwarearchitektur Entscheidungen von Dauer zu verlangen.

Natürlich wünscht sich jeder, dass dies oder jenes endlich ein für alle mal entschieden wird: Hardware, Plattform, Paradigma, Technologie, Produkt, Methode... Damit Ruhe reinkommt, damit die Entwicklung planbarer wird, damit der Einkauf gute Konditionen aushandeln kann.

Doch hier scheint mir Software fundamental anders als alle anderen Produkte. Für Software lassen sich endgültige Entscheidungen immer weniger treffen. Nicht nur, weil Kunden notorisch schlecht sagen können, was sie eigentlich wollen, sondern weil die Branche sich mit ihrem rasanten Fortschritt selbst immer wieder Knüppel zwischen die Beine wirft. Es kommt einfach keine Ruhe rein. Vorgestern Desktop, gestern Web, heute Mobile. Gestern RDBMS, heute NoSql, morgen NoDb. Vorgestern Java Applets, gestern Silverlight, heute HTML5/JS, morgen... Und was sonst noch alles. Vor allem aber: Eigentlich stirbt kein Paradigma, keine Technologie aus.

So ergibt sich für mich als Schluss für die Architekturkompetenz eines als Kernaufgabe. Sie ist das zeitgemäße Fundament für die obigen Architekturpfeiler:

Die vornehmste Aufgabe für die Softwarearchitektur ist es, möglichst viele Entscheidungen reversibel zu halten [3].

Softwarearchitekten sind sozusagen eine Kartellbehörde, die ständig darauf achtet, dass keine Monopole entstehen, d.h. systemrelevante Größen, die alles dominieren. Keine Plattform, kein Paradigma, kein Hersteller, keine Technologie sollte so groß und alles durchdringend werden, dass sich der Rest nur noch demütig danach richten kann.

Nur wenn Softwarearchitektur ständig dafür sorgt, dass Entscheidungen im Grunde jederzeit nach neuer Erkenntnislage verändert werden können, kann sie angstfrei und zügig voranschreiten.

Solange noch die Angst regiert, ist Softwarearchitektur nicht frei. Solange muss umfänglich geprüft, statt geliefert werden. Solange muss verhandelt, statt Feedback generiert werden. Solange muss noch einer seinen Arsch absichern, statt Wert für den Kunden bzw. das Ganze zu schaffen.

Früher... ja, früher war das noch anders. Da bestand Architekturkompetenz in einmaligen Entscheidungen. Die Zahl der Optionen war deutlich geringer. Und der Mangel an quasi allem hat deutliche Grenzen gesetzt. Entscheidungen fanden im Konkreten statt. Heute tun sie das auch noch, klar. Einer muss sagen, ob z.B. Notifications via Pubnub oder XMPP verschickt werden sollen. Doch diese Entscheidungen sind nicht von solcher Dauer wie früher. Deshalb wandert zeitgemäße Architekturkompetenz auf die Meta-Ebene. Sie trifft Entscheidungen über Entscheidungen, nämlich wie die konkreten möglichst unbegrenzt vorläufig gehalten werden können.

Soweit meine Definition für Softwarearchitektur. Ich finde sie einfach verständlich und klar umrissen. Nach ihr zu handeln jedoch, ist nicht so einfach. Es erfordert viel Bewusstheit. Ich würde sogar sagen, es geht mehr um Bewusstheit als um technische Kompetenz.

Endnoten

[1] Dass Architekten mit allen möglichen Stakeholdern zu tun haben, ist damit selbstverständlich. Sonst können sie keinen "Bedürfnisausgleich" mit Blick auf ein globales Optimum herstellen.

[2] Über die Frage, ob "der Softwarearchitekt" codieren soll, kann ich mich nicht ereifern. Mir ist das egal. Erstens gibt es für mich nicht (mehr) denen einen Softwarearchitekten. Zweitens kann kein Teammitglied heutzutage mehr alle nötige Kompetenz für die ganzen nötigen Architekturentscheidungen auf sich vereinigen. Architekten als Universalgelehrte gibt es nicht mehr. Drittens müssen die, die Architekturentscheidungen fällen, nur irgendwie zu ihrer Kompetenz kommen. Wie sie das erreichen...? Wahrscheinlich, indem sie auch mehr oder weniger lange in den Codiergräben gekämpft haben. Aber wie lange, ob sie das heute noch kontinuierlich müssen... Das lasse ich dahingestellt. Wichtiger ist mir, dass die, die Architektur betreiben, sich ihrer Kompetenzgrenzen bewusst sind. Da können sie nämlich ggf. etwas dagegen tun.

[3] Reversibilität bedeutet hier natürlich, mit angemessenem Aufwand reversibel zu sein.

Futter für das Coding Dojo

Wie soll man eigentlich Profi in der Anwendung der Prinzipien und Praktiken von Clean Code Developer werden? Durch Übung :-) Und zwar zunächst einmal durch Übung an Übungen, d.h. nicht am Produktionscode des Tagesgeschäftes.

Woher aber solche Übungen nehmen? Es gibt einige Übungsvorschläge, die sog. Code Katas. Doch die sind meist sehr, sehr überschaubar. Es sind vor allem Übungen im Entwickeln kleiner Algorithmen. Das ist nicht schlecht – aber am Ende zu wenig. Damit kann man ein paar Prinzipien und auch die Methode TDD üben… Doch realistisch sind solche Übungen nicht. Sie bereiten insofern nur begrenzt auf das reale Leben vor.

Deshalb haben Stefan Lieser und ich nun angefangen, Übungen zu sammeln, die ein breiteres Spektrum abdecken. Wir setzen sie schon seit mehreren Jahren in unseren Trainings der Clean Code Developer Akademie ein. Und jetzt “lassen wir sie frei”. Ein kleines Geschenk an die Community.



Im “Coding Dojo” der Clean Code Developer School bauen wir ein Verzeichnis von Code Katas und anderen auf. Wir teilen dabei die Übungen in verschiedene Kategorien je nach Umfang. Am unteren Ende stehen “Function Katas”, bei denen die Aufgabe darin besteht, nur eine Funktion zu entwickeln, um einige Anforderungen zu erfüllen. Darüber liegen “Class Katas” und “Library Katas”. Und weiter geht es mit “Application Katas” und “Architecture Katas”. Sie stehen für umfangreichere Aufgaben, zu deren Lösungen Benutzerschnittstellen und Ressourcenzugriffe oder gar Verteilung gehören. Es sollte also für jeden Geschmack und jedes Zeitbudget etwas dabei sein.

Auf der Seite des “Coding Dojo” sind die Aufgaben in diesen Kategorien gelistet; die zugehörigen Dokumente befinden sich hingegen bei scribd.com, wie oben im Bild zu sehen. Wir nutzen gern die Cloud als Speicehrort ;-) Hier ein Beispiel:

Application Kata Taschenrechner by Clean Code Developer School

Das Verzeichnis der Übungsaufgaben soll natürlich ständig wachsen. Wir haben noch einige in petto, wir werden weitere bekannte und beliebte Aufgaben im Web “ernten” und aufarbeiten. Aber wir freuen uns auch, wenn Sie uns Ideen für Übungen mitteilen. Von einem umfangreichen und vielfältigen Verzeichnis an Katas können die Communities aller Plattformen nur profitieren.

Und nun: Auf zum Üben! Auf in ihr persönliches Coding Dojo!

Nehmen Sie sich (am besten regelmäßig) allein oder mit Kollegen ein bisschen Zeit dafür. Oder besuchen Sie uns in der Clean Code Developer School. Dort zeigen wir Ihnen in Ruhe, was wir unter sauberer und nachhaltiger Softwareentwicklung verstehen.

Gleich zu Gleich für Clean Code

Letzten Dienstag habe ich im wöchentlichen Unterrichtsblock der Clean Code Developer School (ccd-school.de) “TDD as if you meant it” anhand der Kata WordWrap vorgestellt. Dann wollten die Teilnehmer es selbst probieren. Als Aufgabe habe ich die Kata ToDictionary vorgeschlagen.

Leider führte die dann nicht in so geradliniger Weise zu “Refactoring-Druck”, wie ich es mir erhofft hatte. Es wollten nicht die schönen Wiederholungsmuster wie bei WordWrap auftreten. Mist.

Jetzt habe ich sie selbst nochmal durchgeführt. Hier ein Zwischenstand:

Es gibt ein Muster:

• Deutliche ist es zu sehen im zweiten Test, wo die Aufteilung einer Zuweisung (z.B. “a=1”) in Key und Value (z.B. “a” und “1”) mit anschließendem Eintrag in das Dictionary zweimal geschieht.
• Weniger deutlich ist es im ersten Test, wo das auch passiert, aber in etwas anderer Form.

Aber was für ein Refactoring-Druck entsteht dadurch? Sollte ich Split()+Add() in eine eigene Methode rausziehen? Dann würde die Erzeugung des Dictionary zurückbleiben. Hm… das fühlt sich nicht gut an.

Ebenfalls unschön ist, dass die Erzeugung des Dictionary im zweiten Test “weit weg” von seiner Nutzung steht. Mir wäre dies lieber:

Wenn früher in Sprachen Deklarationen am Anfang eines Unterprogramms stattfinden mussten, dann hatte das weniger mit sauberem Code zu tun, als vielmehr mit der Notwendigkeit zu simpleren Parsern, würde ich sagen. Heute ist das kein Thema mehr. Also können Deklarationen stehen, wo es für das Verständnis sinnvoll ist. Und das, so scheint mir, ist nahe ihres Gebrauchsortes.

Außerdem sollten Deklarationen nur die kleinstmögliche Reichweite/Sichtbarkeit haben. Das beugt unnötiger/zufälliger Kopplung vor.

Dito sollten die Verwendungen von Variablen nahe beieinander stehen. Sie sind ja natürlich kohäsiv. Deshalb würde ich auch die zweite Eintragung an die erste rücken wollen:

Selbiges gilt für den Zugriff auf assignments. Also sollten die Aufteilungen der Zuweisungen in Key und Value beieinander stehen:

Und schon sieht die Welt viel musterhafter aus, oder? Hier sind Wiederholungen zu sehen, die nach Zusammenfassung schreien. Mit Linq ist das ganz einfach, ohne neue Methoden erzeugen zu müssen:

Das ist dann vielleicht noch nicht so gut zu lesen wie eine weitere Kapselung:

Doch mit oder ohne eigene Methoden ist die Zusammenfassungen besser zu lesen. Indem ich Gleich und Gleich sich habe gesellen lassen, statt dem ersten Impuls nach Auslagerung eines Musters zu folgen, ist die Sauberkeit noch größer geworden, würde ich sagen. Nun sind die wesentlichen Aspekte der Problemlösung deutlich zu sehen. Es ist klar, wie die Lösung voranschreitet. Insbesondere bei weiterer Kapselung der Aspekte in Methoden ist ToDictionary() sehr leicht zu lesen.

Gewinnen durch Vorläufigkeit

Warum soll im Business eigentlich immer alles perfekt sein? Oder, nein, nicht perfekt, aber "effizient". Ein Beispiel dafür ist mir gerade im Rahmen eines Hobbyprojekts untergekommen: der hey! publishing Verlag.

Eine befreundete Autorin hat dort einen Roman veröffentlicht, "Die Martinis":

Der ist als eBook erschienen. Und das war´s. Weiter ist nichts geschehen (Stand Anfang Mai 2013), obwohl zum Autorenvertrag auch eine Taschenbuchausgabe gehört.

Der Verlag hat über mehrere Monate hinweg noch keinen passenden Partner für die Taschenbuchausgabe gefunden, sagt er. Gesucht wird, so nehme ich an, eine Druckerei, die print-on-demand bietet. hey! publishing möchte sich keine Exemplare auf Halde hinlegen.

Das finde ich völlig verständlich. In der heutigen Zeit tut das für ein simples Belletristik-Taschenbuch nicht mehr Not. Print-on-demand funktioniert gut: die Qualität ist hoch, die Lieferung schnell. Und immer mehr Menschen lesen ohnehin ein eBook. Allemal einen Roman.

Aber warum findet der Verlag keine Druckerei? Das verstehe ich nicht. Print-on-demand ist keine Neuigkeit mehr. Meine Vermutung: Man möchte die Kosten minimieren. Man möchte die billigste Druckerei finden. Das kostet wiederum Zeit, weil man vergleichen muss. Das kostet auch Zeit, weil man erstmal ein Verlagsprogramm aufbauen muss, um nicht nur mit 5-6 Titeln auf die Suche zu gehen, sondern mit einem größeren Programm. Das drückt ja weiter den Preis.

Das finde ich auch irgendwie verständlich. So hat man es immer schon gemacht.

Aber sollte man es auch weiter so machen?

Ich glaube, nicht. Ich glaube, man sollte nicht so auf Effizienz von vornherein schielen. "Wir bringen das Taschenbuch erst heraus, wenn wir die perfekte Druckerei gefunden haben!" Das halte ich für eine hausbackene Einstellung, die Chancen auf Gewinne ausschlägt.

Zum Vergleich ein anderes Buch von Nika Sas, "Der kastrierte Schokobär":

Dieses Buch habe ich mit Nika Sas im letzten Jahr zuerst im Rahmen eines Blogs online veröffentlicht. Und nun, da ich etwas Erfahrung mit dem Selbstverlegen durch mein eigenes Buch "Systematisch produktiver und zufriedener" gesammelt hatte, habe ich ihr geholfen, den Roman ebenfalls über amazon zu veröffentlichen.

Vom fertigen Manuskript bis zur Verfügbarkeit im amazon Shop hat das insgesamt ca. 8 Stunden Aufwand gebraucht:

• Konten und Titel bei createspace und Kindle Direct Publishing (KDP) anlegen
• Manuskript in createspace Template überführen
• Umschlag gestalten
• Umsetzungen durch createspace und KDP überprüfen
• Preise festsetzen

Dazu kamen noch ca. 2 Wochen Wartezeit auf Proofs, also Exemplare des Taschenbuchs, um die Qualität mit eigenen Händen zu prüfen.

Das war´s. Mit wenigen Stunden Aufwand ist Nika Sas mit ihrem Roman im Selbstverlag nun im Verkauf bei amazon sowohl als eBook wie als Taschenbuch. Das Geldverdienen kann beginnen. Und der Erkenntnisgewinn kann beginnen. Nika Sas kann durch ihre Präsenz Feedback generieren. Das halte ich für einen großen Vorteil.

Währenddessen sitzt hey! publishing noch an der Optimierung seines Titels. Man kann mit dem eBook etwas gewinnen. Aber mit dem Taschenbuch kann man nichts gewinnen. Es existiert nicht. Weder Durchsatz wird generiert noch Erkenntnisse.

Das halte ich für unzeitgemäß. Man optimiert einen Aspekt und verschenkt dabei Zeit und Gelegenheit. Wann der Aspekt optimiert ist, ist nicht absehbar. Autoren werden hingehalten, die Motivation sinkt. Wieviel die Optimierung im Vergleich zu einer suboptimalen vorläufigen Lösung mehr einbringt, ist auch nicht gewiss.

Was hätte der Verlag sich vergeben, wenn er zeitgleich mit dem eBook via createspace oder lulu.com oder epubli.de auch das Taschenbuch herausgebracht hätte? Klar, so hätte er weniger Marge gehabt. Aber wäre das so schlimm gewesen?

Wie gesagt: Mir geht es nicht darum, die Suche nach einer perfekten, nach einer effizienten Lösung aufzugeben. Wer meint, die finden zu können, der suche gern. Aber warum während der Suche nicht ein Zwischenergebnis veröffentlichen? Warum nicht mit Vorläufigkeit schon kleine Gewinne erzielen? Ein createspace Taschenbuch wäre für die Leserschaft ein Inkremente gewesen, das schon nutzt.

Ich denke, das ist ein Umdenken, das wir uns häufiger leisten sollten. Es geht um Sensibiliät für die mögliche Vorzeitigkeit von Optimierungen. Oder andersherum: Wir sollten den Mut haben, weniger als gewiss anzunehmen. Dann versuchen wir nämlich nicht, das vermeintlich Gewisse perfekt hinzukriegen, sondern nähern uns dem Ungewissen über vorläufige Schritte an. Das spart Geld, das stellt schneller Gewinn her. Mal "nur" Erkenntnisgewinn, mal aber auch schon ersten monetären Gewinn.

Mehr verdienen durch Experiment

Könnten Sie oder die Firma, für die Sie arbeiten, mehr verdienen? Ja? Wunderbar, dann los! Nein? Warum nicht? Woher weiß man das?

Auf diese Frage bin ich neulich bei einem Aufenthalt im Marriott Hotel in Zürich gestoßen. Dort fand ich nämlich dieses Angebot vor:

Zum Verkauf auf dem Zimmer standen solche 1 Liter Flaschen Wasser für 8,00 CHF (ca. 6,50 EUR) das Stück.

Ein stolzer Preis, oder? Vielleicht auch nicht, denn in der Schweiz ist ja so manches teuer. Vielleicht kostet Mineralwasser einfach so viel?

Ein Besuch im lokalen Migros Supermarkt hat mich dann allerdings informiert, dass eine Flasche vergleichbaren Mineralwassers dort nur 1,60 CHF (ca. 1,30 EUR) kostet.

Da habe ich mir dann eine gekauft und mehr als 5,00 EUR gespart. Davon kann ich mir dann zwei leckere Chai Tees in meinem Lieblingscafé in Hamburg leisten.

Ich will mich hier nicht über Mondpreise in Hotels empören. Das Marriott hat mich zu nichts gezwungen. Die 8,00 CHF für eine Flasche Wasser war wirklich nur ein Angebot - allerdings eines, das ich dankend und ohne nachzudenken ausgeschlagen habe.

Das Marriott hat keine 8,00 CHF Umsatz gemacht. Dem Marriott ist ein Durchsatz=Umsatz - variable Kosten von mindestens 7,50 CHR durch die Lappen gegangen.

Das erinnert mich an den Spruch der Börsianer: Nicht realisierte Gewinne, sind keine Gewinne.

Irgendwo beim Marriott hat jemand auf einen Durchsatz von 7,50 CHF spekuliert. "Lass uns das Wasser für 8,00 CHF pro Flasche verkaufen, dann können wir 7,50 CHF 'Gewinn' damit machen."

Leider ist dieser Fall nun wieder nicht eingetreten. Was hat die Chance auf den hohen Durchsatz also genutzt?

Viel gewinnen kann man auch beim Lottospiel. Aber der Erwartungswert ist sehr, sehr klein. Hat sich beim Marriott also mal irgendjemand Gedanken über den Erwartungswert gemacht? Ich bin im Zweifel.

Meine Vermutung: Das Marriott hat einen Anspruch. Man will Qualität bieten in der gehobenen Hotelklasse. Dafür kann man natürlich einiges an den Zimmer und beim Service tun. Und ich kann berichten, dass man sich da auch durchaus erfolgreich bemüht.

An der Qualität des Mineralwassers kann man jedoch nichts tun. Die ist auf dem Hotelzimmer dieselbe wie im Supermarkt.

Drückt dann aber vielleicht das Vorhandensein von Mineralwasser auf dem Hotelzimmer Qualität aus? Naja... diesen Service bieten auch 2-Sterne Hotels im Rotlichtviertel von Köln. (Ja, ja, da bin ich mal vor vielen Jahren gelandet, als die Hotelwahl über das Internet noch nicht so gut funktionierte.)

Eine Flasche Wasser auf dem Hotelzimmer ist also kein überraschender Service - insbesondere nicht, wenn dann so eine Flasche den fünffachen (!) Preis im Vergleich zum Supermarkt hat.

Dass eine Flasche Wasser oder Bier im Restaurant mehr kostet als im Laden, ist selbstverständlich. Über deren Verkauf muss sich das Restaurant finanzieren. Aber ein Marriott Hotel, das für eine Übernachtung im Einzelzimmer ohne weiteren Verzehr gern mal mehr als 400 EUR verlangt... das finanziert sich doch nicht über Mineralwasserverkauf.

Außergewöhnlicher Servicewille ist also nicht der Grund für Wasser zu 8,00 CHF auf dem Zimmer. Den hätte ich eher vermutet, wenn das Wasser kostenlos oder zum Ladenpreis angeboten würde.

Mir fällt daher leider, leider nur ein Grund für den hohen Preis ein: Gier.

Das klingt nicht schön, aber wie anders ist ein fünffacher Preis zu erklären? Ist die Leistung, das Wasser bereitzustellen und damit den armen Gästen den Weg zum fernen, fernen Supermarkt abzunehmen, 6,40 CHF wert?

Nein, tut mir leid, das ist für mich jenseits aller Angemessenheit. Das ist gierig und womöglich sogar respektlos gegenüber den Gästen. Man nutzt deren Unwissen über die lokalen Preise und ihre mangelnden Orts- und Sprachkenntnisse aus.

Aber wie gesagt, ich will mich gar nicht empören. Mich treibt vielmehr die Frage um: Wird die Gier befriedigt? Nützt es, gierig zu sein? Kann sich das Marriott die Hände reiben ob solch kluger Preisgestaltung?

Meine Antwort: Ich weiß es nicht. Und ich glaube, das Marriott weiß es auch nicht.

Womit ich beim Thema für diesen Artikel bin: Das Marriott weiß nicht, was es mit Wasser verdienen könnte, weil es nicht experimentiert.

Man mag mich eines Besseren belehren, doch bis dahin glaube ich, dass niemand im Marriott den Preis für maximalen Durchsatz "ausbalanciert" hat. Vielmehr hat irgendwer schlicht überlegt, "Welcher Preis passt zu unseren allgemein hohen Preisen? Und wo liegt gerade noch so eine Akzeptanzgrenze, dass man uns die Flasche nicht an der Rezeption um die Ohren haut?" Da klangen Preise über 10,00 CHF wahrscheinlich zu hoch und Preise unter 5,00 CHF zu billig. Und ist 8 nicht eine schöne runde Zahl?

Warum auch nicht den Preis so festsetzen? Irgendwo muss man ja mal anfangen.

Ich glaube nur, dass man da dann nicht stehenbleiben sollte.

So eine Festsetzung sollte nicht auf ewig sein, sondern als Experiment mit begrenzter Laufzeit betrachtet werden. Denn sonst kann man nicht herausfinden, ob ein anderer Preis mehr Erfolg bringt.

Auch wenn das Marriott mit 8,00 CHF pro Flasche im Jahr vielleicht 10.000,00 CHF Durchsatz macht, auch wenn man sich über diesen Durchsatz womöglich freut, heißt das nicht, dass 6,00 CHF oder auch 9,99 CHF pro Flasche pro Flasche nicht mehr Durchsatz produzieren könnten.

Ja, ich behaupte, das weiß dort keiner. Man orientiert sich an einem Anspruch und vergleicht vielleicht noch mit anderen Hotels derselben Klasse. Heraus kommt dann ein Preis, mit dem man sich wohl fühlt - aber keiner, von dem man weiß (!), dass er den Durchsatz maximiert [1].

Mein Vorschlag wäre, den Preis zum Beispiel für jeweils zwei Monate auf zum Beispiel 2,00 CHF, 4,00 CHF, 6,00 CHF und 10,00 CHF zu setzen. Wie oft das 8,00 CHF Angebot in zwei Monaten genutzt wird, weiß man ja heute. Aber wie oft würde Mineralwasser zu einem anderen Preis genutzt? Vielleicht verdoppelt sich der Verkauf für 6,00 CHF? Oder er bricht nur um 5% bei 10,00 CHF ein?

Ich habe da zwar eine Vermutung... doch das ist egal. Wenn das Marriott gierig ist, dann sollte es konsequent schauen, wie es die befriedigen kann. Das geht nur mit Experimenten.

Sie mögen nun denken, dass sich das doch für solch eine Nebensächlichkeit wie Mineralwasser nicht lohne. Da halte ich aber dagegen: Die Abwesenheit von Experimenten beschränkt sich nicht auf das Mineralwasser. Die ist vielmehr Symptom einer Haltung. Es wird nicht im Kleinen experimentiert, es wird nicht im großen experimentiert. Jedenfalls nicht, wenn man nicht muss.

Bei den Zimmerpreisen ist man quasi gezwungen zum Experiment. Da gibt es Wettbewerb, da ist die Auslastung schwankend nach Jahreszeit usw. Also variiert man die Zimmerpreise. Das tun alle und es kommt - so glaube ich - am Ende tatsächlich ein Preis heraus, der die Marge maximiert.

Aber wie ist es in anderen Bereichen? Gibt es Experimente im Restaurant des Marriott? Eher nicht.

Und wie ist es bei Ihnen im Unternehmen? Wer weiß (!), dass mit den aktuellen Preisen das Maximum an Marge erreicht ist?

Ich glaube, das weiß man nicht, sonder hat nur Vermutungen und handelt nach überkommenen Glaubenssätzen. "Das können wir nicht anders machen..." oder "Das war schon immer so..." halten Sie womöglich davon ab, mehr zu verdienen.

Warum also nicht ein paar Experimente wagen. Die müssen ja nicht verrückt sein. Sie müssen nicht alles aufs Spiel setzen. Aber ein bisschen "Mutation" in den "Preisgenen" kann nicht schaden, finde ich. Weniger auf den Wettbewerb schielen, mehr selbst herausfinden. Das wäre doch mal was, oder?

PS: Dass es auch anders geht, zeigt übrigens das schlossgut gross schwansee, welches ich am letzten Wochenende besucht habe. Dort hat man sich entschieden, das Mineralwasser als Service kostenlos anzubieten:

Meine Vermutung: Man hat realisiert, dass der Gewinn an Image größer ist als jeder monetäre Gewinn, den man durch den Verkauf zu welchem Preis auch immer erzielen könnte.

Endnoten

[1] Ich spreche ganz bewusst hier nur vom direkt mit dem Wasser umgesetzten Geld. Inwiefern sich ein Preis auf das Image niederschlägt, lass ich außen vor. Auch darüber könnte sich ja ein Marriott Gedanken machen:

Sind 8,00 CHF ein "würdiger" Preis, der das Image verbessert? Oder könnte es sein, dass dieser Preis dem Image schadet? Was würde ein Preis von 1,60 CHF für das Image tun? Was würde mit dem Image passieren, wenn man das Wasser - horribile dictu! - kostenlos anbieten würde?

Das sind alles Fragen, von denen ich glaube, dass sie nicht ernsthaft gestellt werden. Und wenn, dann sucht man nicht nach belastbaren Antworten.