Full Application Lifecycle ManagementCustom Software DevelopmentMid-Sized Business

Was „Full Lifecycle“ wirklich bedeutet, wenn wir es sagen

Jeder Anbieter verspricht Full Lifecycle. Was der Begriff tatsächlich verspricht, sind die Lücken: die fünf Momente, in denen die Verantwortung normalerweise den Besitzer wechselt. Zwei Systeme, die wir heute betreiben, eines seit drei und eines seit fast zehn Jahren, zeigen, wie es aussieht, wenn dasselbe Team auf beiden Seiten jeder Übergabe sitzt.

Foto: Google Gemini · AI-generated

„Full Lifecycle“ steht auf der Website jedes Anbieters, auch auf unserer. Es klingt vollständig. Es bedeutet fast nichts, solange niemand es ausbuchstabiert.

Hier ist, was es bedeutet, wenn wir es sagen, an zwei Systemen, die wir heute betreiben.

Das Versprechen gilt den Lücken

Ein Softwareprojekt hat fünf Momente, in denen die Verantwortung normalerweise den Besitzer wechselt. Die Spezifikation geht an die Entwickler. Der Code geht an die Tester. Der getestete Build geht an die, die die Server betreiben. Das gestartete System geht an den Support. Und Jahre später geht das laufende System an die, die die nächste Version bauen.

Jede Übergabe ist eine Lücke. In jeder geht etwas verloren: eine Entscheidung, die niemand aufgeschrieben hat, eine Konfiguration, die nur im Kopf einer Person existiert, ein Fehler, den jede Seite der anderen zuordnet. Wenn sich vier Dienstleister ein Projekt teilen, gehören die Lücken dem Kunden. Dort wohnen die Verzögerungen, die Schuldzuweisungen und die überraschenden Rechnungen.

Full Lifecycle heißt: Die Lücken gehören uns. Nicht, weil ein Vertrag alles abdeckt, sondern weil dasselbe Team auf beiden Seiten jeder Übergabe sitzt. Die Leute, die das Datenmodell geschrieben haben, bauen die Pipeline. Die Leute, die die Pipeline gebaut haben, gehen ans Telefon, wenn sie ausfällt.

Wie das bei einem Einkaufsportal aussah

Ein Maschinenbauer in Deutschland, 100 bis 150 Mitarbeitende, steuerte ein Lieferantennetzwerk über mehrere Länder per E-Mail, Tabellen und manuellen Einträgen in Sage 100. Wir haben ein Einkaufsportal als Erweiterung dieses ERP gebaut. Lieferanten bestätigen Aufträge und melden Lieferungen selbst. Das Einkaufsteam sieht jeden offenen Auftrag live. Die Daten fließen zurück nach Sage 100, ohne dass jemand abtippt.

Sehen Sie sich an, was „full“ abgedeckt hat. Wir haben die Daten modelliert. Wir haben das Portal gebaut. Wir haben den Release-Weg eingerichtet, mit Entwicklung, QA, Test und Live als getrennten Umgebungen, damit jede Änderung denselben abgesicherten Weg in die Produktion geht. Wir betreiben es auf der Infrastruktur des Unternehmens, weil das deren Aufstellung ist, nicht unsere. Und der Prüfpfad über jeden Auftrag und jede Änderung ist da, weil Finanzen und Compliance danach fragen würden, nicht weil ihn später jemand angeschraubt hat.

Nichts davon wurde an ein anderes Unternehmen übergeben. Wenn in dieser Kette etwas ausfällt, gibt es eine Nummer, die man anruft.

Wie es nach zehn Jahren aussieht

Ein Medizintechnikunternehmen brauchte einen Onlinekatalog mit mehr als 10.000 Produkten. Plugin-basierte Shop-Plattformen tun sich in dieser Größe schwer, also haben wir ein eigenes Framework gebaut, mit eigener Inhalts- und Produktdatenverwaltung.

Das ist fast zehn Jahre her. Die Plattform ist seitdem in Produktion, mit über 99 Prozent Verfügbarkeit, und hat nur selten Updates gebraucht. Das ist der Teil von „Full Lifecycle“, den niemand auf eine Folie schreibt: das Hosting, die Serverwartung, die Sprach- und Bibliotheksupgrades, die Zertifikatsverlängerungen, der Server, der irgendwann ersetzt werden muss. All das ist bei uns geblieben. Der Kunde hat nie ein Ticket bei einem Hosting-Anbieter geöffnet und gehört, der Fehler liege in der Anwendung, oder umgekehrt.

Was es nicht bedeutet

Es bedeutet keine Abhängigkeit. Dokumentation, Zugang zu den Umgebungen und der Quellcode gehören dem Kunden, und eine saubere Übergabe ist jederzeit möglich.

Es bedeutet nicht am günstigsten. Ein verantwortlicher Partner kostet mehr als das jeweils niedrigste Angebot für jedes einzelne Teil. Das lohnt sich nur, wenn die Lücken sonst bei Ihnen lägen.

Und es ist nicht immer das richtige Modell. Ein Unternehmen mit eigenem Entwicklungsteam ist meist mit einem festen Team oder Time & Materials besser bedient, und das sagen wir auch.

Drei Fragen, die zeigen, ob ein Anbieter es ernst meint

Wer hat Bereitschaft, wenn der Server um zwei Uhr nachts ausfällt, und ist das dasselbe Unternehmen, das den Code geschrieben hat?

Wer bezahlt das Framework-Upgrade, das niemand bestellt hat und alle brauchen?

Können Sie die Pipeline sehen, die eine Änderung vom Laptop eines Entwicklers in die Produktion trägt, und gehört sie dem Anbieter?

Zeigen die Antworten auf drei verschiedene Unternehmen, gehören die Lücken Ihnen. Lesen Sie, wie unsere Full-Lifecycle-Engagements ablaufen, oder sprechen Sie mit uns darüber, welches Modell zu Ihrer Situation passt.