Buy - don’t Build!
Im Herbst musste ich – ganz überraschend – feststellen, dass unsere IT mit immer mehr Leuten immer weniger geschafft bekam. In manche Probleme muss man vielleicht selber machen, auch wenn man sehenden Auges hineinläuft.
Also steht eine grosse Entschlackung an. Wir machen nur noch selber was a) andere nicht können oder b) andere nur deutlich teuerer und/oder schlechter als wir können.
Das läuft den Geek instinkten sehr zuwieder. Ist der Service, den man da Zukauft nicht überteuert? Wie ist der Integrationsaufwand? Hat man so was nicht schneller Selbstprogrammiert, als es dauert, die Dokumentation des Dienstes zu lesen und deren APIs zu debuggen? Wird man nicht unnötig abhängig von dem Dienstleister, wenn es mal nicht so läuft, wie gedacht?
Die Antwort ist in den meisten Fällen: Nein! Denn bei den Diensten die man zukauft kauft man ja nicht nur die Entwicklung, sondern auch die Dokumentation, den Serverbetrieb, den Speicherplatz, die Backups und den Support. Wenn man das alles Selber machen will, verschlingt das in Summe doch erhebliche Personal-Ressourcen. Und Personal ist in vielerlei Hinsicht teuer: Mehr Leute kosten mehr Gehalt, das ist offensichtlich, aber eigentlich gar nciht so interessant. Mehr (gute) Leute zu finden ist sehr teuer. Mehr Büros sind sehr teuer. Mehr Accouns, Server, Rechner, Lizenzen, Switchports, Backups, Viren, Konfigurationen, Schreibtische, Parkplätze, Plätze auf der Weihnachtsfeier, Sitze im Besprechungsraum, Gradrobenhaken, Klos, Urlaube, Geburtstage, Krankentage, Befindlichkeiten, Liebeskummer, Personalgespräche, Lohnpfändungen und Personalfluktuation bedeuten alle erheblichen Aufwand. Aber am schlimmsten ist: mehr Leute bedeuten mehr Managment, mehr Kommunikationsverluste, mehr Missverständnisse und alles in allem viel mehr Energie, die in Dinge investiert werden müssen, die nicht dem Kunden nutzen.
Neben allen finanziellen Betrachtungen, bedeutet das vor allem: mit mehr Leuten verbringt man weniger Zeit damit, das zu tun, was das Unternehmen eigentlich tun soll.
Als ist es vielleicht nicht so gut, die IT-Abteilung stetig wachsen zu lassen.
Da man in den letzten Jahren immer mehr Aufgaben zukaufen kann, gibt es einige Beispiele von hochfokussierten Unternehmen, bei denen eine Hand voll Leute, sehr vielen Kunden ein sehr gutes Produkt anbieten. 37signals, github und besonders Plenty of Fish sind ein paar Beispiele für diesen Ansatz.
Ein weiterer Punkt ist, das man sich mit den unzulänglichkeiten von zugekauften Projekten viel besser abfinden kann. Bei selbstgeschriebenen Projekten, hat man immer im Kopf, dass man “dass mal ordenlich machen” und dieses oder jenes Feature noch zufügen muss “wenn mal Zeit ist”.
Mit Basecamp haben wir seit Jahren Erfahrung mit gehosteten Applikationen. Vor geraumer Zeit sind wir auch von unserer eigenen Asterisk Lösung auf eine fremd gewartete VoIP Telefonanlage umgestiegen. Also: Weg mit dem, was weg kann!
Erster Schritt war die Nutzung von Shopify für einige Sparten-Webshops. Plötzlich musste das eCommerce Team nicht mehr warten, bis die Programmierer aus dem Quark kamen und die Programmierer hatten nicht dauernd Feature Wünsche aus der eCommerce Ecke am Bein. Unterdessen importiert ein kleines Skript die Shopify Aufträge in unserer eigenes Fullfillment Backend.
Sehr gut lief auch der Wechsel von selbstgehosteten Zimbra-Mailserver zu Google Apps. Bei Zimbra hat sich nach der Übernahme durch Yahoo recht wenig getan und wir wollten zum einen mehr Features, zum anderen ist Backup und Betireb von der sehr grossen Hardware, auf der Zimbra lief schon eine Sache für sich. Ausserdem bereitete das Thema Spamfilter erhebliche Mühe. Dauernd sollten wir nach irgendwelchen abhanden gekommenden Mails verhanden. Das hat jetzt ein Ende. “Fragen Sie doch mal bei Google”.
Unser eigenes Subversion / Trac Setup war fürchterlich langsam. Wir sind von Subversion, auf GIT gewechselt, was sozusagen jede Entwicklermaschine zum Backup-Server macht. Die Server-Dienstleistung kaufen wir bei Github ein.
Das macht es uns auch einfacher, unsere Open-Source software zu veröffentlichen. Git macht Branching sehr viel einfacher und GitHub hat ein riesiges Ökosystem aus Tools und APIs. Das war der ausschlaggebende Grund nicht (Mercurial und BitBucket zu nutzen).
Gleichzeitig kann http://github.com/search unsere Gonzui Programmcodesuche ersetzen.
FogBUGZ mit seinen blöden PHP binary only Modulen hatten wir schon im Frühjahr abgeschafft und durch eine Kombination aus jutda-helpdesk und Trac ersetzt. Das war aber mehr recht als schlecht. Trac war langsam und Jutda Helpdesk war nicht grade, was man ein “polished Product” nennt.
Jetzt nutzen wir Tender für den internen Support und für die interne Dokumentation.
Für das Bug-Tracking udn die Software-Entwicklung nutzen wir Lighthouse. Das ist sehr schön mit GitHub und Tender zu integrieren.
Die Hoffnung bei der Trennung von Support und Entwicklung ist auch, dass wir nicht immer durch Alltagswehwechen (”druckt nicht”) vom eigentlichen Entwickeln abgehalten werden.
Unsere interne reviewboard installation ersetzen wir durch how’s my code? Beide Applikationen machen nicht genau das gleiche, aber how’s my code ist schön mit Github integriert und macht viel mehr Spass zu benutzen.
Diverse kleine Applikationen haben wir durch das Wufoo Formularsystem abgelöst.
Diverse Fehler Melde- und Sammelskripte ersetzen wir durch Hoptoad.
Spezialisierte Hardware, wie unseren selbstgebauten Terminals zum Einsatz auf Gabelstaplern, inklusive selbstentwickelter (Lua) Software, ersetzen wir stück für Stück durch standartproduckte, z.B. iPod Touch mit Webapplikation.
Unsere LDAP basierte Login-Infrastruktur wersetzen wir durch Single-Sign-On mit Google Apps. (Z.B. so.)
Unser externes Wiki wandert zu GitHub.
Bei den Servern verschieben wir diverse komplexe Speicher-System zu Amazon S3. Anstatt eine CouchDB mit 50 GB zu managen, lagern wir einen Teil der Daten bei Amazon und haben nur noch 45 MB in der CouchDB zu verarbeiten – für die Replikation und Backups eine unschätzbare Erleichterung. Auch Backups können bei Amazon S3 bequem untergebracht werden.
Statt Serverüberwachung mit Nagios, lassen wir das durch Pingdom erledigen.
Auch bei den Servern kaufen wir mehr zu. Klassisch hatten wir immer Kopfschmerzen mit dem Betrieb von PHP-Webservern. Nun mieten wir per Infrastructure as a Service einfach einen vorkonfigurierten server mit LAMP-Stack und installieren darauf nur noch die eigentlichen Applikationen, die wir nutzen wollen.
Die Administration der Server selbst kann mit Anbietern wie Rightscale & Co voll automatisiert werden.
All das sollte uns von sehr vielen kleinen Baustellen entlasten und dazu führen, das wir uns im Support ganz darauf konzentrieren können, unseren internen Nutzern weiterzuhelfen und den effizienten Betrieb des Warenwirtschaftssystems sicherzustellen. In der Entwicklung können wir uns darauf fokussieren, Lösungen zu erarbeiten, die das Unternehmen nach vorne bringen und nicht ständig das Rad neu zu erfinden, nur weil uns der Farbton der am Markt erhältlichen Räder nicht passt.