Continuous Delivery – Nur etwas für Web 2.0 Firmen?

Auf den ersten Blick möchte man meinen, dass Continuous Delivery etwas für Web 2.0 Firmen ist. Dort liegt es ja auf der Hand, dass man schnell und häufig Software liefern möchte, da es oft ein Wettrennen um das neueste und hippste Feature gibt und Kunden sich sehr schnell neu orientieren können. Auch klar ist, das Web 2.0 Firmen es sich nicht leisten können, Ihre Plattformen länger vom Netz zu nehmen, da Ihr Geschäftsmodell von der Präsenz per se abhängt und daher Zero Downtime Deployment als eine Ausprägung von Continuous Delivery sehr wichtig ist. Soweit so gut.

These: Continuous Delivery ist für fast alle Unternehmenstypen eine wettbewerbsrelevante Fähigkeit.

Betrachten wir zum Zwecke der Herleitung zunächst einge Trends in Volkswirtschaften des 21. Jahrhunderts:

• Kürzere Produktzyklen – In vielen Branchen verkürzen sich die Produktzyklen drastisch. Paradebeispiel sind dabei für jedermann wahrnehmbar mobile elektronische Geräte.
• Optimierte Geschäftsprozesse – Verdrängung findet unter anderen in reiferen Märkten auch durch bessere Geschäftsprozesse statt. Ein Gutes Beispiel ist Amazon bezogen auf den Versandhandel.
• Abhängigkeit von IT -Durch die immer tiefere Durchdringung des Geschäfts mit IT, um effektiver und automatisierter zu sein, ist die Abhängigkeit von funktionierender und robuster IT deutlich gestiegen.
• Globaler Wettbewerb – Die Globalisierung wird für die vorgenannten Trends zum „Brandbeschleuniger“, da jedes Unternehmen mit den Besten global konkurrieren muss.

Und nun ein Blick auf Continuous Delivery:

Auf den ersten Blick bedeutet Continuous Delivery die Automatisierung des Lieferprozesses der Software in alle relvanten Umgebungen inkl. Produktionsumgebung. Auf den zweiten Blick erfordert diese Automatisierung (damit ich mich das auch traue) einen sehr hohen Reifegrad einer Vielzahl von Disziplinen, wie Architektur (gute Modularisierung), Testautomatisierung (Unit-, Itegrations-, Akzeptanz- und Performancetests), Software Craftmanship (Clean Code, etc.), Requirement Engineering (Abnahmekriterien als Teil des Requirements, Schnitt der Requirements), Entwicklungsprozesse, etc. Continuous Delivery ist also ein fundamentaler Qualitätstreiber für den gesamten Entwicklungsprozess.

Selbst wenn es nicht das Ziel ist schnell und häufig zu liefern, erreicht man so doch deutliche Verbesserung, was Produktivität, Qualität und Passgenauigkeit der Software angeht.

Und nun der „Merge“:

Um IT als Untersützung bzgl. der oben genannten globalen Trends erfolgreich zu betreiben, benötigen wir Qualität, Produktivität und oft auch eine höhere Geschwindigkeit. Alles Faktoren, die sich durch die Umsetzung von Continuous Delivery auch in klassischen Unternehmen verbessern.

Was meint Ihr?

Thomas