Sent from Hauptstadt!

ein Blog für den geneigten Leser

Wir sind nicht Facebook, Google oder Amazon!

Tags: ,

Kategorie Software Engineering | Keine Kommentare »

Im Vorspann der Simpsons gab es immer die Szene, in der Bart als Strafe die Tafel im Klassenzimmer mit einer Benimmregel vollschreiben muss. CTOs und IT Führungskräften würde ich gerne genau diese Strafe aufbrummen mit dem Satz: „Wir sind nicht Facebook, Google oder Amazon“!

Zeit für eine Polemik…

Die großen IT Konzerne haben eine Vielzahl sehr fortgeschrittener Technologien im Einsatz, um ihre digitalen Angebote zu betreiben. In diversen Vorträgen, Blogs und Videos kann man von ihren Erfolgsgeschichten lernen und sie stellen auch diverse Werkzeuge gerne als OpenSource zur Verfügung.

Typisches Beispiel: die Code Änderung eines Entwicklers wird automatisch über mehrere Stufen bis auf Produktion ausgerollt. Dementsprechend ändert sich die Seite oder die Webapp mehrmals täglich.

Ein anderes Beispiel ist der Chaos Monkey von Netflix. Dieser Dienst stoppt mehrmals täglich zufällig einzelne Komponenten der Netflix Infrastruktur, um sicher zu stellen, dass die einzelnen Komponenten mit Ausfällen umgehen können und das Angebot für den Nutzer nicht beeinträchtigt wird.

Diese ganzen Technologien sind alle beeindruckend und haben zur Weiterentwicklung des Fachs massiv beigetragen! Entsprechende Erfolgsgeschichten gehören zu jeder guten Konferenz und es gibt unzählige Beratungsfirmen, die gerne bei der Einführung der Technologien und Prozesse behilflich sind.

Auch für Entwickler ist es schön, wenigstens die Techniken von Facebook & Co. zu adaptieren, wenn man schon nicht den Traumjob (?) bei einem dieser Vorreiter abbekommen hat.

Leider wird viel zu selten hinterfragt, ob es überhaupt einen echten Nutzen für den Benutzer eines digitalen Angebots hat, wenn die Anwendung sich in täglichen homöopathischen Dosen weiterentwickelt?! Völlig ignoriert werden auch die Kosten für Aufbau und Pflege der dazu notwendigen Infrastruktur und Werkzeuge, denn darüber schweigen sich die Vorträge auch gerne aus. Ich bin mir aber ziemlich sicher, dass sich bei den großen IT Konzernen mehrere tausend Ingenieure um die Infrastruktur kümmern und nein, mit 3 Leuten geht das nicht.

Anstatt die Übernahme des Idealbilds unreflektiert zu fordern, bin ich, entsprechend meiner Selbstbeschreibung, für ein pragmatischeres Vorgehen. Zwei Beispiele:

  • Bei den meisten Geschäftsanwendungen sind periodische Releases aus Nutzersicht wesentlich besser, als ständige kleine Änderungen. Benutzer möchten etwa vorab über Neuerungen informiert werden und das Schulungsmaterial (Doku, What’s new!, Video Tutorials) sollte beim Release bereitstehen. Geschäftsnutzer möchten auch nicht als Versuchskaninchen missbraucht werden und ständig nicht durchdachte halbgare Features testen. Warum also in den Aufbau einer vollautomatisierten Release Pipeline in einer heterogenen und von Legacy Apps durchseuchten IT Landschaft investieren, wenn es am Ende niemanden nutzt?
  • Und warum musste ich gleich nochmal die seit Jahren auf einem einzigen Server völlig stabil laufende Business Applikation in einen Container packen, damit ich sie mittels eines Kubernetes Cluster in die Cloud verschieben konnte? Wem nutzt das nochmal?

Natürlich verstehe ich die CTOs und IT Entscheider dieser Welt, die ihre Organisation in die Zukunft stoßen und sich mit modernen Technologien schmücken wollen. Agile Transformation, Employer Branding, you name it!

Leider werden sie damit aber ihrer Verantwortung nicht gerecht, denn eigentlich sollten sie die begrenzten betrieblichen Mittel möglichst gewinnbringend für Kunde und Zukunft der eigenen Organisation einsetzen. Und dies bedeutet in vielen Fällen anzuerkennen, dass die eigene Organisation nicht Facebook, Google oder Amazon ist!

Schreiben sie ein Kommentar