„Wie verändert die Digitalisierung bestehende Industrien und Branchen? Das ist eine der spannendsten Wirtschaftsfragen unserer Zeit“, schreibt Neunetz-Blogger Marcel Weiss.

„Die Musikbranche wurde dank der MP3 als erste Branche am härtesten getroffen. Zuerst haben wir die kreative Zerstörung gesehen: Filesharing hat das Geschäftsmodell der Musiklabels, einer der bestimmenden Unternehmensklassen der Branche, aus den Angeln gehoben. Dann kam erstmal lang nichts. Nicht zuletzt, weil jede legale Alternative von den Musiklabels über den Lizenzweg ausgeblutet wurde. Nun sehen wir langsam, vielleicht auch weil die Majorlabels nicht mehr die Macht haben, die sie einmal hatten, wie erfolgreiche Musikdienste abseits der Simulation des Analogen (Dateiverkauf bei iTunes und Amazon MP3 zum Beispiel) entstehen. Turntable.fm, Spotify, Soundcloud, um nur drei zu nennen. Aus diesen neuen Angeboten heraus verändert sich die Organisation der Musik, wie sie im industriellen Zeitalter sinnvollerweise stattfand.“

Ich möchte noch einmal auf die Eingangsfrage eingehen unabhängig von den Veränderungen des Musikmarktes, die Marcel in aller Ausführlichkeit in seinem Blogpost beschreibt und am besten dort nachzulesen sind. Also: Wie verändert die Digitalisierung bestehende Industrien und Branchen? Und: Abschied von der analogen Dienstleistungsökonomie: Was wir vom Rant eines Google-Mitarbeiters lernen können – dieses Thema möchte ich gerne weiterentwickeln für meine Freitagskolumne. Als Grundlage greife ich auf ein Stück zurück, das nur zufällig im Netz gelandet ist. Spiegel Online hatte darüber berichtet:

„In der englischen Sprache gibt es ein Sprichwort: ‚Eat your own dogfood‘, was wörtlich übersetzt ‚Iss Dein eigenes Hundefutter‘ bedeutet. Tatsächlich ist es ein Leitsatz für Unternehmen, die Produkte der eigenen Marke auch ausführlich selbst nutzen. Ausgerechnet im Hause Google wird diese Maxime derzeit nicht eingehalten.“

Es geht um eine ausführliche Analyse des Google-Mitarbeiters Steve Yegge, die nur durch ein Versehen auf Google+ öffentlich abrufbar war und später gelöscht wurde – allerdings ohne großen Erfolg. Ein Versehen. Das Stück ist aber nicht nur wegen der vielen Insider-Infos lesenswert. Es zeigt auch, wie hart Facebook, Amazon, Google und Co. um die digitale Vorherrschaft ringen und welche Bedeutung gut durchdachte Plattformstrategien für das Onlinegeschäft haben. Besonders in Deutschland gibt es wohl kaum eine Firma, die sich so intensiv und radikal mit Service-Design auseinandersetzt wie Amazon (auch wenn Jeff Bezos in dem Rundumschlag von Yegge charakterlich nicht sehr gut wegkommt). Da wird lamentiert, auf Vorgestern-Technologien gesetzt und abfällig vom Social Dingsbums-Hype gefaselt. Unterdessen rutscht immer mehr Geschäft ins Internet – quer durch alle Altersklassen und Gesellschaftsschichten. Gibt es darauf eine schlagkräftige Antwort? Es wird bei uns zu viel lamentiert.

Welche Plattform-Strategie fürs Online-Geschäft benötigen wir? Die Analysen von Steve Yegge findet Ihr unten in deutscher Übersetzung. Ist ziemlich lang.

Statements, Expertenmeinungen, Kommentare zum Thema bitte hier posten oder per E-Mail an: gunnareriksohn@googlemail.com

Steve schreibt:
Ich war ungefähr sechseinhalb Jahre bei Amazon beschäftigt. Vergleichbar lange bin ich nun auch bei Google tätig. Eine Sache, die mir sofort bei den zwei Unternehmen auffiel – und die sich fast täglich als Eindruck verstärkte – ist die, dass Amazon alles falsch macht, während Google alles richtig macht. Dies mag nach einer weitreichenden Generalisierung klingen, ist jedoch ein erstaunlich akkurates Urteil. Es ist schon verrückt. Da gibt es wahrscheinlich hundert oder gar zweihundert verschiedene Möglichkeiten des Vergleichs zwischen beiden Unternehmen. Und Google ist – wenn ich es richtig in Erinnerung habe – in allen Bereichen bis auf drei Ausnahmen der überlegene Partner. Ich habe zu diesem Thema einmal eine Excel-Tabelle erstellt. Die Rechtsabteilung war dagegen, dass diese Tabelle Externen gezeigt wird. Die Personalabteilung war davon jedoch ganz angetan.

Ich möchte Ihnen nachfolgend einen kurzen Einblick gewähren: Der Rekrutierungsprozess bei Amazon weist einige fundamentale Mängel auf. Es gibt Amazon-Teams, die eigenständig ihre Rekrutierungen vornehmen. Das Ergebnis ist, dass teamübergreifend völlig unvereinbare, widersprüchliche Einstellungsmodalitäten vorliegen – trotz diverser Bemühungen, diese Diskrepanz auszugleichen. Auch ihre Arbeitsmethoden sind chaotisch; sie verfügen über keine wirklichen SREs und die Ingenieure sind bei ihnen quasi für alle anfallenden Tätigkeiten zuständig. Dadurch verbleibt fast gar keine Zeit für die Datenkodierung. Natürlich variiert dies innerhalb der einzelnen Gruppen. Letztlich ist es reine Glückssache und man muss es so nehmen wie es kommt. Bei Amazon interessiert sich absolut niemand für soziales Engagement. Ob Spenden für karikative Zwecke, Unterstützung von Bedürftigen, Communities oder ähnliches: Amazon ist all dies völlig egal. Wenn es überhaupt ein Thema ist, wird soziales Unternehmensengagement nur ins Lächerliche gezogen. Die Werke bei Amazon sind von einer Schmutzschicht überzogene Großraumbüros mit Trennwänden. Dabei hat man nicht einen einzigen Cent in die Inneneinrichtung oder für Gemeinschaftsräume der Mitarbeiter investieren wollen. Mitarbeitervergütungen und Zuschüsse sind ziemlich mies; in letzter Zeit ist dies allerdings besser geworden. Der Grund: die Konkurrenz durch Google und Facebook auf dem lokalen Markt. Sie bieten allerdings nicht unsere Boni-Zahlungen oder Tantiemen, sondern orientieren sich lediglich an den Zahlen des Angebotsschreibens – und nehmen diese als oberste Grenze. Ihre Code-Basis ist ein Disaster. Es fehlen jegliche technische Standards, abgesehen davon, was einzelne Teams aus eigener Entscheidung umgesetzt haben.

Um fair zu sein und einmal etwas Positives zu nennen: Amazon hat ein gut versioniertes Bibliothekssystem, an dem wir uns wirklich orientieren sollten. Außerdem haben sie ein schönes Publish-Subscribe System, mit dem wir nicht mithalten können. Aber in den meisten Bereichen arbeiten sie mit einer Handvoll „nutzloser“ Tools, die Informationen der Zustandsmaschinen lesen und in ein relationales Datenbanksystem einspeisen. Selbst wenn wir sie gratis bekämen, würden wir die meisten dieser Tools nicht einsetzen.

Ich glaube, dass das Pubsub-System und das Bibliothekssystem zwei der insgesamt drei Dinge sind, bei denen Amazon besser abschneidet als Google.

Meines Erachtens ließe sich noch darüber diskutieren, ob Amazons Tendenz zur frühzeitigen Markteinführung und wie verrückt durchgeführten Iterationen zu den guten Dingen zählt, die das Unternehmen macht. Es gibt Argumente, die dafür und dagegen sprechen, je nach Perspektive. Die frühzeitige Markteinführung hat klare Priorität gegenüber allen anderen Aktivitäten. In der Bedeutung rangiert sie sogar höher als Kundenbindung, Ingenieursdisziplin und eine Reihe anderer Dinge, die langfristig gesehen substanziell sind. Obgleich ihnen die frühe Lancierung einen gewissen Wettbewerbsvorteil im Markt verschafft, sind dabei eine Handvoll anderer Probleme aufgetreten, sodass man hier nicht wirklich von einem Slam Dunk sprechen kann.

Trotz allem gibt es eine Sache, die Amazon wirklich und wahrhaftig gut macht, und die ALLE politischen, philosophischen und technischen Verfehlungen des Unternehmens wieder wettmacht.

Jeff Bezos ist ein berühmt-berüchtigter Mikro-Manager. Er ist zuständig für das Mikro-Management jedes einzelnen Pixels von Amazons gewerblicher Website. Erst hat er Larry Tesler abgeworben. Tesler war Wissenschaftlicher Leiter bei Apple und wahrscheinlich der renommierteste und respektierteste Experte für Mensch-Computer-Interaktionen weltweit. Nachdem er ihn eingestellt hatte, ignorierte er jedoch alles, was Tesler sagte. Nach drei Jahren traf Tesler daraufhin die finale und weise Entscheidung, das Unternehmen zu verlassen. Tesler hatte mittels umfassender Usability Studien zweifelsfrei bewiesen, dass absolut niemand diese “bizarre” Website verstehen kann. Bezos konnte oder wollte sich aber einfach nicht von seinen Pixeln verabschieden, von all den Millionen Semantik-geladenen Pixeln auf der Landing-Page. Die Pixel waren für ihn wie Millionen seiner eigenen hoch geschätzten Kinder. Das Ergebnis: Die Pixel sind noch da, Larry Tesler aber nicht mehr.

Übrigens ist Micro-Management nicht die dritte Sache, die Amazon besser macht als wir. Obgleich Amazon wirklich gut im Micro-Management ist, würde ich das nicht als eine besondere Stärke bezeichnen. Ich versuche lediglich, den Kontext herzustellen, um Ihnen den Sachverhalt nachvollziehbar vor Augen zu führen. Wir sprechen hier über einen Mann, der allen Ernstes bei diversen öffentlichen Anlässen betont hat, dass die Leute ihn dafür bezahlen sollten, dass er bei Amazon arbeitet. Falls die Leute anderer Meinung sind als er, reicht er ihnen kleine gelbe Sticker mit seinem Namen drauf. Auf diese Weise erinnert er die Leute daran, „wer das Unternehmen leitet“. Der Mann ist ein regelrechter … , sagen wir mal, Steve Jobs, ohne dessen Mode- und Stilbewusstsein verinnerlicht zu haben. Bezos ist dabei absolut schlau und gerissen, verstehen Sie mich bitte nicht falsch. Er hat aber leider die Angewohnheit, normale Kontrollfreaks wie bekiffte Hippies aussehen zu lassen.

Eines Tages erteilte Jeff Bezos einen Auftrag. Das macht er natürlich fortwährend. Die Mitarbeiter reagieren dann wie die sprichwörtlichen Ameisen, die wie von einem “Gummihammer zerquetscht” herumkriechen und sich wälzen. Bei einer Gelegenheit, etwa im Jahre 2002, beziehungsweise ein Jahr früher oder später, erteilte Bezos einen Auftrag, der absolut unglaublich war, gewaltig, massiv und so gewichtig, dass seine anderen Aufträge im Vergleich dazu wie unerbetene Peer Boni aussahen.

Sein Großauftrag beinhaltete in etwa folgende Punkte:

1) Alle Teams werden ab sofort ihre Daten und Funktionsfähigkeiten über Service Schnittstellen offen darlegen.

2) Alle Teams sind ab sofort verpflichtet, über diese Schnittstellen miteinander zu kommunizieren.

3) Eine andere Form der Interprozesskommunikation ist den Teams nicht gestattet. Konkret bedeutet dies: keine direkte Vernetzung oder Austausch, kein Einloggen in den Datenspeicher eines anderen Teams, keine Nutzung eines Shared-Memory Modells, keine Hintertür-Kommunikation in welcher Form auch immer. Die einzige Kommunikationsform, die erlaubt ist, läuft über die Service Schnittstelle des Netzwerks.

4) Es ist völlig gleich, welche Technologien das Team nutzt. Ob HTTP, Corba, Pubsub, Benutzerdefinierte Protokolle – Bezos ist das völlig egal.

5) Alle Service Schnittstellen, ohne Ausnahme, müssen von Anfang an so konzipiert sein, das sie auch extern genutzt werden können. In anderen Worten, das Team ist angehalten, die Service Schnittstellen so zu entwerfen und zu konfigurieren, dass sie von externen Entwicklern eingesehen werden können. Hierbei sind keine Ausnahmen zulässig.

6) Derjenige, der sich nicht an die Regeln hält, kann nach Hause gehen.

7) Vielen Dank; ich wünsche Ihnen noch einen schönen Tag!

Ha, ha! Sollten Sie zu den ca. 150 Ex-Amazon Mitarbeitern gehören, werden Sie natürlich sofort gemerkt haben, dass die Bemerkung unter Punkt 7 ein kleiner persönlicher Scherz von mir war. Denn eins ist klar: Bezos interessiert sich nicht einen Pfifferling dafür, ob Sie einen schönen Tag haben oder nicht.

Punkt 6 entsprach jedoch der absoluten Realität, was dazu führte, dass die Mitarbeiter sich aktiv an die Arbeit machten. Zu diesem Zweck beauftragte Bezos extra ein paar “Leitende Bulldoggen”, deren Aufgabe es fortan war, das Engagement der Mitarbeiter zu überwachen und sicherzustellen, dass die Arbeit Fortschritte machte. Leiter des “Bulldoggenkommittees“ war der Uber-Chef-Bär Rick Dalzell. Rick ist ein Ex-Army Ranger, zugleich Absolvent der West Point Academy, Ex-Boxer sowie ein ehemaliger “Chef-Folterer” d.h. ein CIO bei Wal Mart. In anderen Worten, er ist ein großer, genialer, aber Furcht einflößender Mann, der den Ausdruck „gestählerte Schnittstelle“ häufig benutzt und geprägt hat. Dabei war Rick selbst eine laufende, sprechende und gestählerte Schnittstelle. Es erübrigt sich, zu erwähnen, dass sich jeder einzelne Mitarbeiter extrem bemühte, DEUTLICH MESSBARE Fortschritte zu machen und dabei sicherzustellen, dass Rick davon erfuhr.

Im Verlauf der folgenden zwei Jahre entwickelte sich Amazon intern in eine Service-geprägte Architektur. Während dieser Verwandlung hat ein signifikanter Lernprozess stattgefunden. Dabei gab es eine Unmenge an Dokumentationen, Regeln und Weisheiten über SOAs. In Anbetracht der schieren Größe des Unternehmens Amazon war dies jedoch so zielführend als würde man Indiana Jones empfehlen, nach beiden Seiten zu schauen, bevor er die Strasse überquert. Amazons Entwicklungsteam machte während dieser Zeit eine Vielzahl neuer Entdeckungen. Ein winzig kleines Beispiel des Entdeckungsspektrums führe ich nachstehend für Sie auf:

– Die Pager Eskalation gestaltet sich deutlich schwieriger. Der Grund: Ein einzelnes Ticket könnte durch 20 Service Calls „schliddern“, bevor der wirkliche Eigentümer identifiziert ist. Wenn jeder „Ticket-Sprung“ durch ein Team mit einer 15-minütigen Antwortzeit läuft, kann es Stunden dauern, bevor das richtige Team es herausfindet – es sei denn, man schaltet eine Vielzahl an Systemgerüsten, Metriken und anderen Parametern dazwischen.

– Jedes einzelne Mitglied Ihres Peer Teams wird plötzlich zu einem potenziellen DOS Angreifer. Niemand wird in der Lage sein, einen nennenswerten Fortschritt zu leisten, es sei denn, man führt für jede individuelle Dienstleistung eine stringente Quoten- und Reduktionsregelung ein.

– Monitoring und QA sind das Gleiche. Man versteht diesen Zusammenhang erst dann, wenn man versucht, eine große SOA zu erstellen. Aber wenn Ihr Service Ihnen sagt „Oh ja, mir geht es gut“, ist die Wahrscheinlichkeit groß, dass das einzige noch funktionierende Element im Server die kleine Komponente ist, die Ihnen in einer fröhlichen Droiden-Stimme mitteilt: „Mir geht es gut, roger roger, over and out“. Um genau überprüfen zu können, ob der Service wirklich reagiert, ist es unerlässlich, einzelne Anrufe zu tätigen. Das Problem bleibt so lange rekursiv, bis Ihr Monitoring-System eine umfassende Semantik-Überprüfung Ihres gesamten Service- und Datenbereichs vornimmt. Zu diesem Zeitpunkt gibt es keine Differenzierung mehr zwischen dem Monitoring und der automatisierten QA. Beide stellen ein Kontinuum dar.

– Wenn Sie Hunderte von Services zur Verfügung stehen haben und Ihr Code MUSS mit dem Code anderer Gruppen unter Einsatz dieser Services kommunizieren, benötigen Sie einen Service-Suchmechanismus. Nur so können Sie die einzelnen Services wiederfinden. Dieses wiederum setzt das Vorhandensein eines Service-Registrierungsmechanismus voraus, und schon sprechen wir von einem weiteren Service. Amazon verfügt also über eine universelle Registerservicestelle, über die man reflexive und programmatische Informationen über jeden einzelnen Service erfahren kann, so zum Beispiel über die APIs und auch, ob und wo der Service gegenwärtig eingesetzt wird.

– Die Problemanalyse wird durch die Nutzung des Codes einer anderen Person wesentlich erschwert und ist eigentlich nicht mehr durchführbar. Sie ist nur dann möglich, wenn man auf eine universelle Standardmethode zurückgreifen kann, bei der jeder einzelne Service über ein Debug-Sandbox-System läuft.

Dies ist nur ein kleines Beispiel von Dutzenden, vielleicht sogar Hunderten individueller Lektionen, die Amazon während dieser Zeit auf natürliche Art und Weise erfahren musste. Hinzu kamen zahlreiche weitere verrückte Beispiele, die sich auf die externe Nutzung der Services bezog. Die Zahl war jedoch nicht ganz so astronomisch hoch, wie Sie sich das vielleicht vorstellen. Die Organisationsstruktur der Services hat die Teams gelehrt, sich gegenseitig mit Vorsicht und Misstrauen zu begegnen, und damit ein ähnliches Verhalten an den Tag zu legen, das sie auch externen Entwicklern gegenüber zeigen sollten.

Der Lernprozess hielt noch an und war bereits recht weit fortgeschritten zu dem Zeitpunkt, als ich Amazon Mitte 2005 verließ, um zu Google zu gehen. Von dem Moment an als Bezos die Verordnung erließ bis zu dem Zeitpunkt meines Weggangs, hat sich Amazon kulturell in ein Unternehmen verwandelt, bei dem der Service-Gedanke bei allen Aktivitäten an vorderster Front steht und höchste Priorität genießt. Jetzt ist die Design- und Konzeptionsphase das entscheidende Kriterium. Hierzu gehören auch die internen Designs für Gegenstände, die wahrscheinlich nie von der Außenwelt wahrgenommen werden.

Zu diesem Zeitpunkt agierten die Mitarbeiter Amazons nicht mehr ausschließlich aus der Befürchtung heraus, entlassen zu werden. Natürlich haben sie immer noch Angst davor; es ist einfach Teil des alltäglichen Arbeitslebens, für einen gefürchteten “Seeräuber” wie Bezos zu arbeiten. Letztlich haben sie den Dienstleistungsgedanken verinnerlicht, da sie verstanden haben, wie überlebenswichtig Services für ein Unternehmen sind. Zweifelsohne gibt es bei der SOA-Methode Vor- und Nachteile, wobei einige der Nachteile ziemlich gewichtig sind. Insgesamt betrachtet ist es aber das Richtige – denn mit dem SOA-Design werden Plattformen kreiert.

Das hat Bezos natürlich mit seiner Verordnung im Visier gehabt. Bezos hat sich niemals auch nur einen Pfifferling um das Wohlergehen der Teams geschert, geschweige denn sich dafür interessiert, wie und mit welchen Technologien sie arbeiten, solange niemand pfuscht. Eine Sache erkannte Bezos jedoch lange Zeit vor der Mehrheit aller Amazon-Mitarbeiter: nämlich, dass Amazon eine Plattform braucht.

Eigentlich würde man denken: Wozu braucht ein Online Buchladen eine ausbaufähige, programmierbare Plattform?

Gut, zunächst realisierte Bezos, dass die Infrastruktur, die Amazon für den Verkauf und Versand der Bücher und anderer Sortimentsartikel aufgebaut hat, sich in eine exzellente, einem neuen Zweck zuführbare Computer Plattform transformieren ließe. Die Ergebnisse sind: Amazon Elastic Compute Cloud, Amazon Elastic MapReduce sowie der Amazon Relational Database Service, und darüber hinaus eine Vielzahl weiterer browsbarer Services unter aws.amazon.com

Diese Services hosten die Backend-Systeme einiger ziemlich erfolgreicher Unternehmen. Mein ganz persönlicher Favorit ist der Social News Aggregator Reddit.

Die andere große Erkenntnis, die sich Bezos in diesem Zusammenhang erschloss, war die Realisierung, dass es nicht immer möglich ist, genau das Richtige zu konzipieren. Ich glaube, dass Larry Tesler eine Saite bei ihm zum Klingen brachte, als er sagte, dass seine Mutter nicht in der Lage sei, die “verdammte” Website zu nutzen. Dabei war es nicht ganz klar, auf welche Mutter er sich bezog. Aber das ist ja auch unwesentlich, da offenkundig keine Mutter von irgendjemandem die Website als nutzerfreundlich bezeichnen würde. Auch ich finde die Website furchtbar abschreckend, und das, obwohl ich dort mehr als ein halbes Jahrzehnt gearbeitet habe. Ich habe einfach gelernt, meinen Blick zu defokussieren und mich dafür auf die Millionen von Pixel in der Nähe der Seitenmitte über dem Knick zu konzentrieren.

Ich bin mir allerdings nicht ganz sicher, wie Bezos zu dieser Erkenntnis und der Einsicht kam, dass er mit der Konzipierung eines einzigen Produktes nicht alle Nutzer gleichermaßen zufriedenstellen kann. Aber das ist ja auch egal. Was zählt ist, dass er es verstanden hat. Für dieses Phänomen gibt es übrigens einen offiziellen Ausdruck. Er heißt „Accessibility“ (Zugänglichkeit/Barrierefreiheit) und ist das absolut Wichtigste in der ganzen Computerwelt.

Das absolut Wichtigste

Falls Sie nun denken “Sie meinen Zugänglichkeit auch für blinde und taube Menschen?“, sind Sie mit diesem Gedanken nicht allein. Ich habe gelernt, dass es ganz ganz VIELE Menschen so wie Sie gibt: Menschen, für die diese Vorstellung nichts mit der wahren Zugänglichkeit zu tun hat. Falls Sie auch so denken, ist die Botschaft noch nicht zu Ihnen durchgedrungen. Das fehlende Verständnis dafür ist genauso wenig Ihre Schuld wie es die Schuld der Behinderten ist, taub, blind oder eingeschränkt in ihren Bewegungsabläufen zu sein. Wenn die Software, oder in diesem Fall die “Idea-Ware” aus irgendwelchen Gründen für irgendeine Person nicht zugänglich ist, liegt die Fehlfunktion bei der Software oder der fehlerhaften Übertragung der Grund-Idee. Dann spricht man von einem Accessibility Fehler.

Genauso wie andere große, bedeutende Dinge im Leben, hat auch die Accessibility einen “bösen Zwillingsbruder”, der sich durch die ungleich verteilte Zuneigung seiner Eltern in der Jugend zurückgesetzt fühlte und nun zu einer ebenso starken Erz-Nemesis mit dem Namen „Sicherheit“ herangewachsen ist. (Ja, es gibt in der Tat mehr als eine Nemesis und einen Erzfeind bei der Accessibility). Und glauben Sie mir, die beiden stehen ewig im Widerspruch zueinander.

Ich behaupte, dass Accessibility wichtiger als Sicherheit ist, denn pendelt sich die Accessibility bei Null ein, bedeutet dies, dass man überhaupt kein Produkt mehr hat. Bewegt sich aber die Sicherheit gen Null, erhält man noch ein einigermaßen erfolgreiches Produkt, wie beispielsweise das Playstation Netzwerk.

Falls Sie es noch nicht bemerkt haben sollten: Ich könnte ein ganzes Buch zu diesem Thema schreiben, ein ziemlich dickbändiges, gefüllt mit unterhaltsamen Anekdoten über Ameisen und Gummihammer in Unternehmen, für die ich gearbeitet habe. Leider werde ich diese Schimpftirade nie veröffentlichen lassen. Und Sie werden sie somit nie lesen können, es sei denn, ich fange an, einzupacken.

Die eine letzte Sache, die Google nicht gut macht, sind Plattformen. Für Plattformen fehlt uns das Wissen und das Handwerkzeug. Einige von Ihnen würden das hinbekommen, Sie sind aber in der Minderheit. Im Verlaufe der letzten sechs Jahre ist mir das schmerzlich bewusst geworden.
Ich hatte eigentlich gehofft, dass der von Microsoft, Amazon und zuletzt von Facebook ausgehende Wettbewerbsdruck uns gemeinsam wachrütteln und zu der Entwicklung universeller Services treiben würde. Allerdings nicht in einer unüberlegten Ad-hoc Aktion, sondern in einer vergleichbaren Weise wie es Amazon gemacht hat: alles auf einmal, handfest, ohne Schummelei, mit der sofortigen Einstufung der Services als oberste Priorität.

Leider hat es sich anders entwickelt und wir sprechen von der zehnten, elften, möglicherweise sogar nur der 15. Priorität. Auf jeden Fall ist die Bedeutung, die wir diesem Thema geben, ziemlich gering. Es gibt zwar ein paar Teams, die diese Idee ziemlich ernst nehmen, die meisten Teams denken aber entweder überhaupt nicht darüber nach, und wenn, dann nur ein geringer Anteil von ihnen in sehr geringem Maße.

Es bedarf schon einer ziemlichen Anstrengung, die meisten Teams dazu zu bewegen, auch nur einen halbherzigen, kurz-bündigen Service anzubieten, um programmatischen Access zu ihren Daten und Berechnungen herzustellen. Die Mehrheit von ihnen ist der Meinung, die Arbeit beschränke sich lediglich auf die Herstellung von Produkten. Offenbar ist ihnen nicht bewusst, dass ein halbherziger, kurz-bündiger Service ein ziemlich miserabler Service ist. Hier kann ich nur empfehlen, einen Blick auf den Auszug der Lernprozess-Liste Amazons zu werfen. Da werden Sie feststellen, dass da nichts „von der Stange“ ist. „Kurz und bündig“ ist an für sich nichts Schlechtes, metaphorisch gesprochen entspricht dies aber nur dem Wert einzelner Fahrzeugteile, wenn Sie eigentlich ein ganzes Auto benötigen.

Ein Produkt ohne Plattform ist völlig nutzlos, oder präziser formuliert: Ein Produkt, das über keine Plattform verfügt, wird immer ersetzt werden durch ein äquivalentes Produkt, das mit einer Plattform ausgestattet ist.

Google+ ist ein Musterbeispiel eines Unternehmens, das die Signifikanz von Plattformen absolut verkannt hat. Das Nichterkennen dieser Bedeutung zieht sich von der höchsten Hierarchieebene der Geschäftsführung (hallo Larry, Sergey, Eric, Vic, wie geht´s Euch?) bis zur untersten Unternehmensebene der Arbeiter (hallo Ihr!). Wir haben es alle nicht kapiert. Die goldene Regel der Plattformen lautet: “Essen Sie Ihr eigenes Hundefutter”. Die Google+ Plattform ist eine erbärmliche “Nachlese”. Bei der Markteinführung setzten wir überhaupt keine API ein. Nach meiner letzten Überprüfung hatten wir nur einen mickrigen API Call. Eine der Team-Mitarbeiterinnen kam herein und erzählte mir davon, als sie gerade bei der Markteinführung waren. Daraufhin fragte ich: „Handelt es sich um die Stalker API?“ Ihre Antwort war ein ziemlich mürrisches „Ja“. Ich dachte, ich hätte einen Scherz gemacht. Aber nein, tatsächlich zielt der einzige API Call, den wir anbieten, darauf ab, den Datenstrom einer anderen Person zu ermitteln. Also ist der Scherz auf meine Kosten gegangen.

Die “Hundefutter-Regel” ist Microsoft seit mindestens zwanzig Jahren bekannt. Es ist Teil seiner Unternehmenskultur seit nunmehr einer ganzen Generation. Die Regel ist ganz einfach zu verstehen: Sie können Ihren Entwicklern nicht einfaches Hundefutter vorsetzen, während Sie sich selbst hochwertigeres Essen für Menschen einverleiben. Das zu machen hieße, sich selbst des langfristigen Plattform-Wertes zu berauben, um einen kurzlebigen Erfolg zu erhaschen. Bei Plattformen ist eine langfristige Planung und Investition gefragt.

Bei Google+ handelt es sich um eine spontane Reflexreaktion, um eine Erforschung im Kurzzeit-Denken, ausgerichtet an der inkorrekten Vorstellung, dass Facebooks Erfolg darauf beruhe, ein geniales Produkt erfunden zu haben. Das ist aber nicht der Grund, weshalb sie so erfolgreich sind. Facebooks Erfolg begründet sich darauf, dass sie eine komplette Produktpalette aufgebaut haben, indem sie anderen Leuten gestatteten, ihre Arbeit zu machen. Das macht Facebook so einmalig. Es gibt Menschen, die verbringen ihre gesamte Zeit damit, Mafiakriege auszutragen. Andere wiederum verbringen ihre gesamte Zeit bei Farmville.

Es gibt hundert oder sogar tausend unterschiedliche, zeitaufwändige Beschäftigungsformen mit hohem Qualitätsanspruch. Da ist für jeden etwas dabei.

Unser Google+ Team hat den Anschlussmarkt für Dienstleistungen analysiert und dabei festgestellt: „Es wäre eine gute Idee, unser Angebotsspektrum um Computerspiele zu erweitern. Lasst uns jemanden rekrutieren, der diese Spiele für uns konzipiert“. Verstehen Sie jetzt, wie unglaublich falsch dieser Gedankengang ist, vor allem aus heutiger Sicht? Das Problem ist, dass wir versuchen, zu prognostizieren, was die Leute wollen und es ihnen dann zur Verfügung stellen.

So geht das einfach nicht. Dieser Ansatz ist unrealistisch und absolut nicht verlässlich. Es hat nur ein paare wenige, hoch-kalibrige Menschen in der gesamten Welt der Computer-Geschichte gegeben, die in der Lage waren, eine zuverlässige Prognose zu erstellen. Steve Jobs war einer von ihnen. Leider haben wir keinen Steve Jobs bei uns. Das können wir nun einmal nicht ändern.

Larry Tesler mag Bezos überzeugt haben, dass er kein Steve Jobs ist. Bezos hat jedoch erkannt, dass es nicht zwingend eines Steve Jobs bedarf, um Konsumenten mit den richtigen Produkten zu versorgen: Anwenderschnittstellen und Unternehmensabläufe als Workflows, mit denen die Benutzer gut und gerne arbeiten. Das einzige was er tun musste, war externe Entwickler damit zu beauftragen. Alles andere würde dann automatisch passieren.

Ich entschuldige mich bei all denjenigen dafür, die meine Ausführungen zu diesem Thema als ganz offensichtlich und auf der Hand liegend betrachten. Es ist in der Tat unglaublich evident. Und trotzdem unternehmen wir nichts dagegen. Wir schaffen weder Plattformen noch die richtige Accessibility. Beides sind integrale Bestandteile: Plattformen lösen das Problem der Accessibility, denn nur über die Plattform ist die Accessibility möglich.

Microsoft hat das verstanden. Und Sie wissen genauso wie ich, wie erstaunlich das ist, da sie sonst ja eigentlich nichts so richtig hinbekommen. Für sie sind Plattformen eine rein zufällige Begleiterscheinung und Folge einer Geschäftstätigkeit, die sich bereits in der Anfangszeit mit der Bereitstellung von Plattformen befasste. So konnten sie in diesem Bereich bereits mehr als 30 Jahre Erfahrung sammeln.

Und wenn Sie auf msdn.com gehen und dort einige Zeit browsen, werden Sie überwältigt sein. Die Plattform ist gigantisch groß. Dort gibt es Abertausende von API Calls. Die Plattform ist absolut riesig, eigentlich zu riesig für den Otto-Normalverbraucher. Aber zumindest sind sie offenkundig sehr engagiert.

Amazon hat es auch kapiert. Amazons AWS (aws.amazon.com) ist einfach unglaublich.
Schauen Sie es sich einmal an und klicken Sie sich dort einmal durch. Es ist einfach nur peinlich, dass wir so etwas bei uns nicht hinbekommen haben.

Auch Apple hat es hinbekommen, natürlich! Sie haben hier ein paar grundlegende, nicht-öffentliche Entscheidungen getroffen, insbesondere bei ihrer mobilen Plattform. Aber sie verstehen viel von Accessibility, der Bedeutung der Entwicklungsarbeit Dritter und – sie essen ihr Hundefutter. Und wissen Sie was? Sie machen ein ziemlich gutes Hundefutter! Ihre APIs sind schon seit ewiger Zeit deutlich makelloser und professioneller als die Microsofts.

Facebook hat es auch verstanden. Das macht mir echte Sorgen und hat mich letztendlich dazu motiviert, all diese Dinge niederzuschreiben. Ich hasse bloggen. Plussing – d.h. eine massive Schimpftirade in Google+ loszulassen, ist mir auch zuwider. Obwohl Sie wissen, dass dies ein furchtbarer Ort dafür ist, machen Sie es trotzdem. Denn letztendlich möchten Sie wirklich, dass Google erfolgreich ist. Ich möchte das auf jeden Fall!
Fakt ist, dass Facebook mich haben möchte, und es wäre ziemlich leicht, einfach zu gehen. Google ist aber für mich wie eine Heimat. Daher bestehe ich auf diese kleine “Familien-Einmischung”, auch wenn es etwas unangenehm sein mag.

Nachdem Sie die Plattform-Angebote von Microsoft und Amazon und ich befürchte auch die von Facebook bestaunt haben (Letzteres habe ich mir verkniffen, um nicht ganz in Depressionen zu verfallen), schauen Sie sich doch bitte developers.google.com an und browsen dort ein wenig. Sie werden schnell den gewaltigen Unterschied wahrnehmen, oder? Das entspricht in etwa der Leistung, die Ihr Neffe aus der 5. Klasse hervorbrächte, müsste er in einer Hausarbeit demonstrieren, was ein großes, mächtiges Plattformunternehmen herstellen könnte, wenn es dafür lediglich auf eine Ressource in Form eines einzigen Fünf-Klässlers zurückgreifen müsste.

Verstehen Sie mich hier bitte nicht falsch – es ist eine Tatsache, dass das Entwicklungsteam regelrecht kämpfen musste, um eine ähnliche mickrige Ressource von extern zur Verfügung gestellt zu bekommen. Trotz aller Widrigkeiten schaffen sie es, Plattformen herzustellen. Dabei unternehmen sie fast heldenhafte Anstrengungen, denn sie sind mit einem Umfeld konfrontiert, das im besten Falle indifferent und im schlimmsten Falle offenkundig feindselig und ablehnend gegenüber Plattformen eingestellt ist.

Ich beschreibe hier nur in aller Offenheit, wie developers.google.com für Aussenstehende erscheinen muss. Es ist einfach kindisch. Wo um Himmels willen befinden sich hier die APIs der Maps? Einige der Dinge dort sind Labor-Projekte. Und alle APIs, die ich angeklickt habe, waren ziemlich dürftig. Es handelt sich hier offenbar um Hundefutter, aber kein gutes, aus organischem Anbau. Verglichen mit unseren internen APIs sind das im besten Falle “Schnauzen” und “Pferdehufe”.

Verstehen Sie mich auch bitte nicht falsch, was Google+ angeht. Sie sind bei Weitem nicht die einzigen Angreifer. Das ist eine Sache der Unternehmenskultur. Wir tragen derzeit einen internen Kampf aus. Dabei nimmt die “Pro-Plattform-Fraktion” als Underdog Minderheit gegenüber den allmächtigen, selbstbewussten und kapitalkräftigen Herstellern mehr oder weniger die Verliererposition ein.

Alle Teams, die erfolgreich die Vorstellung verinnerlicht haben, dass es von Grund auf extern zu programmierbare Plattformen geben sollte, gehören zu den Underdogs. – Und schon denkt man an Maps and Docs. Ich weiß auch, dass GMail Avancen in dieser Richtung startet. Es ist aber schwer für sie, eine Finanzierung dafür zu bekommen, da dies nicht Teil unserer Kultur ist. Die Finanzierung Maestros ist ziemlich schwach, setzt man sie in Relation zu der riesigen Microsoft Office Programmierplattform: Es ist wie ein flauschiges Kaninchen im Vergleich zu einem Tyrannosaurus rex. Das Docs Team ist sich bewusst, dass sie erst dann mit Office konkurrieren können, wenn sie mit seinen Scriptsprach-Einrichtungen mithalten können. Dazu fehlt ihnen aber die Unterstützung durch entsprechende Ressourcen. Ich gehe davon aus, dass sich die Lage noch nicht geändert hat, da Apps Script zurzeit nur in Spreadsheet funktioniert. Außerdem verfügt das Team noch nicht einmal über Keyboard Shortcuts als Teil ihrer API. Das Docs Team scheint wirklich ziemlich unbeliebt und allein gelassen zu sein.

Das Ironische dabei ist, dass Wave einmal eine tolle Plattform war, mag sie in Frieden ruhen. Aber eine Plattform zu gestalten bedeutet nicht, sofort und automatisch Erfolg zu haben. Eine Plattform braucht einen Killer App. Facebook – das heißt, der Bestandsservice, der dort mit Facebook Walls und Friends etc. angeboten wird, ist der Killer App der Facebook Plattform. Und es ist ein großer Fehler, zu glauben, dass das Facebook App ohne die Facebook Plattform auch nur annähernd so erfolgreich wäre.

Sie wissen, dass die Leute immer sagen, Google sei arrogant? Als „Googler“ ärgert mich diese Bemerkung genauso wie Sie. Im Großen und Ganzen sind wir nicht arrogant.

Wir sind fast zu 99 Prozent frei von Arroganz. Ich habe diesen Beitrag begonnen – wenn Sie in Ihrer tiefsten Erinnerung graben – indem ich Google als ein Unternehmen beschrieb, das alles richtig machen würde. Fakt ist, wir sind einfach nur bester Absichten. Und wenn uns jemand den Vorwurf macht, wir seien arrogant, liegt es zumeist an folgenden Gründen: Entweder ist der Kritiker ein Job-Aspirant, der unser Rekrutierungsverfahren nicht bestanden hat, oder jemand, der Probleme mit unserer Unternehmenspolitik hat, oder irgendetwas in dieser Richtung. Sie leiten daraus Arroganz ab, weil sie sich dadurch besser fühlen.

Wenn wir die Einstellung vertreten, das perfekte Produkt konzipieren zu können, das alle Kunden gleichermaßen zufrieden stellt – und glauben Sie mir bitte, so etwas höre ich sehr oft – dann sind wir einfach nur dumm. Aus solch einer Einstellung ließe sich wirklich Arroganz oder Naivität ableiten. Letztlich würde das auch keinen Unterschied machen, es ist schierer Wahnwitz. Es gibt KEIN perfektes Produkt, das wirklich alle Nutzer zufrieden stellt.

Die Folge ist, wir stellen einen Browser ein, mit dem Sie die Default-Schriftgröße nicht festlegen können. Und schon begehen wir wieder einen Affront gegenüber der Accessibility. Jetzt, wo ich älter werde, scheine ich auch mit Blindheit geschlagen zu sein. Es ist wirklich wahr. Mein ganzes Leben bin ich schon kurzsichtig – und wenn Sie erst einmal die 40 erreicht haben, sind Sie meist nicht mehr in der Lage, Dinge aus der Nähe zu betrachten. Folglich wird das Thema der Font/Schrift-Auswahl zu einer Entscheidung auf Leben und Tod: Es kann sie regelrecht aus dem Produkt hinauskatapultieren und ausgrenzen. In dieser Hinsicht ist das Chrome Team völlig arrogant: sie wollen unbedingt ein Zero-Konfigurationsprodukt entwickeln und riskieren dabei gerne eine dicke Lippe. Wenn Sie dann blind, taub oder in irgendeiner anderen Form gehandicapt sind, bleibt Ihnen wohl nichts anderes übrig, als für den Rest Ihres Lebens bei jedem einzelnen Page Visit die Ctrl-+ Taste zu bedienen.

Leider verhält sich nicht nur das Chrome Team so, sondern eigentlich alle. Das Problem liegt darin, dass wir durch und durch ein Produkt-Unternehmen sind. Wir haben ein erfolgreiches Produkt mit weitreichender Popularität und Breitenwirkung geschaffen – ich spreche hier von unserer Suchfunktion. Dieser gigantische Erfolg hat aber auch Nachteile mit sich gebracht.

Amazon war auch ein Produkt-Unternehmen. Folglich bedurfte es einer Out-of-Band-Kraft, um Bezos von der Notwendigkeit einer Plattform zu überzeugen. Diese Kraft entstand aus Amazon´s allmählich “verdampfenden” Gewinnspannen. Bezos stand mit dem Rücken zur Wand und musste sich überlegen, wie er da raus kommen kann. Er hatte lediglich ein Grüppchen Ingenieure und all diese vielen Computer… wenn sich die nur zu Geld machen ließen … Jetzt werden Sie verstehen, wie er im Nachhinein zu AWS kam.

Microsoft hat von Anfang an eine Plattform gehabt und verfügt daher über einen großen Erfahrungsschatz.

Facebook hingegen beunruhigt mich. Ich bin zwar kein Experte, aber ziemlich sicher, dass Facebook auch einmal als Produkt anfing und damit einen ziemlich lang anhaltenden Erfolg hingelegt hat. Ich bin mir allerdings nicht absolut sicher, wie das Unternehmen den Übergang zu einer Plattform hinbekommen hat. Facebook muss offenbar schon seit relativ langer Zeit eine Plattform sein, auf jeden Fall bevor sich solche Dinge wie Mafiakriege entwickeln konnten.

Vielleicht haben sie sich uns einfach nur angeschaut und sich dabei gefragt: „Wie schaffen wir es, Google zu übertrumpfen? Was fehlt bei ihnen, das wir bei uns aufbauen können?“

Wir stehen vor einer ziemlich großen Herausforderung und einem echten Problem. Um dieses lösen zu können und wieder „auf Vordermann“ zu kommen, müssten wir unsere Unternehmenskultur signifikant reformieren.

Wir kreieren keine Service-orientierte Plattformen für den internen Gebrauch. Genauso wenig konzipieren wir externe. Das bedeutet, dass sich diese Art ”Unvermögen” fast endemisch durch das ganze Unternehmen zieht: d.h. die Produktmanager bekommen es nicht hin, die Ingenieure nicht, die Produktteams nicht, eigentlich bekommt es niemand hin. Selbst wenn es ein einzelner schaffen sollte, vielleicht sogar Sie, würde das absolut keinen Unterschied machen. Die Situation würde sich erst dann ändern, wenn wir endlich anfangen, sie als überlebenswichtige Angelegenheit zu behandeln, bei der der Einsatz jedes Einzelnen zählt. Wir können nicht einfach weiter Produkte auf den Markt bringen und dann so tun, als ob wir sie später in magisch schöne, ausbaufähige Plattformen umwandeln. Das haben wir versucht und es hat nicht funktioniert.

Die goldene Regel der Plattformen: „Essen Sie Ihr eigenes Hundefutter” kann auch umformuliert werden als: „Beginnen Sie mit der Herstellung einer Plattform und nutzen Sie sie dann später einfach für alles.“ Darauf erst später aufzusatteln und es dann festzuzurren geht einfach nicht. Auf jeden Fall wäre das ziemlich schwer. Dazu können Sie jeden befragen, der schon einmal bei der Plattformierung von MS Office oder auch Amazon mitgewirkt hat. Wenn Sie die Plattformierung erst später durchführen, bedeutet das zehn Mal soviel Arbeit als wenn Sie es von Anfang an richtig machen. Dabei können Sie es sich nicht leisten zu schummeln. Es gibt keine geheimen Hintertüren für interne Apps, um so einen speziellen und vorrangigen Access zu bekommen. Hierbei gibt es keine Ausnahmeregelung. Es gilt, die schwierigen Probleme an vorderster Front zu lösen.

Ich will damit nicht sagen, dass es zu spät für uns ist. Tatsache ist aber, je länger wir warten, desto stärker nähern wir uns dem “zu spät sein”.

Ganz ehrlich, ich weiß nicht, wie ich diesen Beitrag schließen soll. Ich habe so ziemlich alles gesagt, was ich mir für heute vorgenommen hatte zu sagen. Dieser Beitrag ist seit sechs Jahren in der Mache. Es tut mir Leid, falls ich mit dem Thema nicht besonders sanft umgegangen bin. Ebenso entschuldige ich mich dafür, falls ich irgendein Produkt, Team oder eine Einzelperson fälschlich dargestellt haben sollte. Ich entschuldige mich auch dafür, falls wir doch viel an Plattform-Arbeit geleistet haben sollten, und nur „rein zufällig“ niemand, weder ich selbst noch alle anderen, mit denen ich jemals darüber gesprochen habe, davon gehört hat. Sorry.

Wir müssen jetzt endlich damit beginnen, alte Fehler auszubügeln und alles richtig zu machen. Ende der Übersetzung.