Wenn es darum geht, eine entwickelte Software auszuliefern, gibt es zwei Extreme: Eine Lieferung der kompletten (virtuellen) Appliance, am besten versiegelt, und eine Lieferung von nackten Komponenten mit Handbuch. Die Realität ist irgendwo dazwischen: Die Appliance ist sicherlich ein für Hersteller und Support attraktiv, verbietet sich aber oft durch Probleme bei der Integration in bestehende Infrastruktur, und nackte Komponenten sind nicht unbedingt das, was Kunden kaufen wollen.
Hierzu eine Anmerkung: Der Lieferumfang eines Produktes sollte immer so strikt wie möglich definiert sein, also nur die absolut notwendigen Bestandteile umfassen. Beispiel: Wenn ich eine Web-Applikation liefere, dann enthält mein Lieferpaket im Idealfall nur die unvermeidlichen Bestandteile meine-webapp.war und Handbuch-für-meine-webapp.pdf, in dem steht, auf welcher Plattform meine-webapp.war deployed werden kann.
Warum? Weil man für alles, was man liefert, verantwortlich ist. Im schlimmsten Falle also für jeden Programmfehler im verwendeten Tomcat, sofern man sich erweichen ließ und einen Tomcat ins Lieferarchiv gepackt hat. In diesem Falle muß man also regelmäßig Updates der ursprünglichen Lieferung schicken, die alle getestet werden müssen -- und obwohl die eigene Kreation sich möglicherweise schon lange nicht mehr geändert hat, entsteht hier ein regelmäßiger Aufwand. Ist man mit den Verträgen ungeschickt, sind womöglich Probleme mit der Gewährleistung nicht ausgeschlossen. Schön, das ist ein Schreckensszenario, welches so schnell nicht eintreten sollte, aber es bleibt ein potentielles Problem.
Das hat auch eine Auswirkung auf die Softwareentwicklung: Der Verzicht auf das "Anpassen" (aka "customizing") der Plattform vereinfachen Deployment und Betrieb und erlaubt, die Plattform "out-of-the-box" zu verwenden. Damit entfällt ein wichtiger Grund, die Plattform mitzuliefern, den Lieferumfang deutlich strafft.
Keine Kommentare:
Kommentar veröffentlichen