Fragmentierung und Plattformstrategie

Oft denkt man im Hinblick auf den Kundennutzen daran, neue Features zu liefern, und ist darauf aus, die Featurewünsche möglichst agil und auf Kundenzuruf zu implementieren.

Dabei wird nur zu gerne vergessen, daß der Produkterfolg auf unterster Ebene des Entwicklungszyklus vordefiniert wird. Dort bestimmen die Produktarchitektur zusammen mit der Strategie, mit der die Anforderungen umgesetzt werden, was Kunden später langfristig überhaupt nutzen können.

Michael Degusta hat für seinen Artikel →Android Orphans: Visualizing a Sad History of Support eine sehr interessante Grafik zusammengestellt, die sehr gut zeigt, welche Vorteile eine Plattformstrategie in der Softwareentwicklung bringt, bzw welche Nachteile eine zu große Fragmentierung hat.

Fragmentierung

Degusta zeigt in seiner Grafik (siehe unten) die Updatehistorie aller Smartphones, die in einem bestimmten Zeitraum in den USA verkauft worden sind.

Man kann sehr gut erkennen, daß die Geräte von Apple regelmäßig auf den neuesten Softwarestand gebracht werden. Vielen Geräte, die das Android-Betriebssystem verwenden, werden demgegenüber nicht mit der neuesten Softwareversion versorgt, und veralten so nach und nach.

Wenn Updates stattfinden, finden sie häufig erst mit einer großen zeitlichen Verzögerung statt, oder die Weiterentwicklung wird gleich ganz eingestellt.

Konsequenzen der Fragmentierung

In seinem Artikel zeigt Degusta einige Konsequenzen auf, so zum Beispiel die Konsequenz, daß nur sehr wenige Android Kunden überhaupt die neue Version des Betriebssystems nutzen werden, das derzeit so euphorisch diskutiert wird (Ice Cream Sandwich).

Er erwähnt aber auch einige Nachteile, wie zum Beispiel, daß es Entwicklern schwer gemacht wird, zu entwickeln, oder, daß die Sicherheitsrisiken zunehmen.

Zunächst aber zu der Frage, woher die Fragmentierung kommt.

Falsche Strategie kann zur Fragmentierung führen

Die Fragmentierung kommt, wenn man nicht aufpasst, leicht zustande. Zum Beispiel, wenn man aus extern gegebenen Gründen dazu gezwungen wird, mehrere Releases zu unterhalten und zu pflegen, fällt es zusehends schwerer, die Anforderungen gleichmäßig in jedem Release zu implementieren. Am Ende sieht die Situation dann ähnlich aus wie bei dem Android Betriebssystem.

Fragmentierung kann aber auch entstehen, wenn man „zu“ agil entwickelt. So bauen viele Smartphonehersteller eigene Erweiterungen in das Betriebssystem ein, um den Kunden eine einzigartige Funktionalität bieten zu können. Spätestens beim nächsten Update des Betriebssystems müssen diese Erweiterungen angepasst werden, was im günstigen Fall zu einer Zeitverzögerung führt, und im Extremfall dazu, daß die Neuerungen nicht übernommen werden, und das Telefon veraltet.

Aus meiner Erfahrung führen aber auch kommerzielle Entscheidungen zu einer solchen Fragmentierung. Apple liefert zum Beispiel die Updates kostenfrei (oder zu geringen Kosten) an alle Kunden aus. Andere Firmen lassen sich die Gelegenheit nicht entgehen, und verlangen viel Geld für eine neue Softwareversion. Im Zweifel machen Kunden den Upgrade dann eher nicht, und schon sind die Kunden über die Releases verteilt.

Ich empfehle Ihnen, die Entscheidung wohlinformiert zu machen. Auf der einen Seite stehen die Umsätze, die sie mit den kostenpflichtigen Upgrades machen. Auf der anderen Seite hat Fragmentierung auch eigene Kosten, die man nicht unterschätzen sollte.

Kosten der Fragmentierung

Einige Kosten hat Degusta bereits erwähnt. Doch gibt es noch mehr verborgene Aufwendungen. Ich will hier nur ganz wenige Aspekte nennen, da die hohen Kosten auf der Hand liegen sollten.

Denken Sie zum Beispiel an die Kosten der Qualität i.w.S. So wird es einer Firma, die eine Releasepolitik wie Apple verfolgt, leichter fallen die Software zu testen, als dies eine Firma kann, die unterschiedliche Releases unterstützen muss (z.B. HTC oder Motorola).

Weiterhin ist die Komplexität nicht zu unterschätzen, die eine fragmentierte Lösung besitzt. Im Fall Apple müssen alle Projektbeteiligten (Entwicklung, Produktmanagement, …) die Lösung kennen, die sie optimieren können und pflegen müssen. Im Android-Fall muß weitaus mehr Versionen kennen, und unterhalten. Während man sich im ersten Fall voll auf die Optimierung konzentrieren kann, muß man im zweiten Fall viel Aufwand in den Abgleich stecken.

Daß auch die Kunden große Nachteile haben (was auch dazu führen kann, daß die Kunden unzufrieden werden), liegt auf der Hand. Schliesslich arbeiten viele dieser Kunden mit alten Funktionen, und es fehlen ihnen die neuen Features, die es erst in höheren Releases gibt.

Gegenmaßnahmen

Wenn die Fragmentierung gewollt ist, muß man sich keine weiteren Gedanken machen. Oft kommt Fragmentierung aber auch zufällig zustande. Hier sollte man mit Verbesserungen ansetzen. Hierzu einige Ideen:

• Der Arbeit an der Architektur einen großen Raum geben: Oft kommen releasespezifische Besonderheiten dadurch zustande, daß es zu aufwendig ist, ein Feature in alle Releases einzubauen. Die Schwierigkeiten wiederum ergeben sich oft daraus, daß die Produktarchitektur nicht durchdacht ist, und zu hohem Änderungsaufwand führt.
• Engen Terminen eine Absage erteilen: Viele Softwareprojekte stehen unter Zeitdruck. Aber, je höher der Druck, desto höher die Wahrscheinlichkeit, daß man sich auf einzelne Versionen kümmert. Oft kommt der Zeitdruck durch schlechte Planung zustande. Hier sollte man nachjustieren.
• Die Kosten richtig berechnen: Viele Manager unterschätzen den Aufwand der durch Fragmentierung entsteht,und treffen so falsche Releaseentscheidungen. Es ist daher sinnvoll, an den Methoden zu arbeiten, und sicherzustellen, daß die Transparenz entsteht, und, daß die Entscheidungen auf der richtigen Ebene gefällt werden.
• Synchonisierungspunkte vorsehen: Um zu verhindern, daß Versionen auseinanderlaufen, sollte man regelmäßig Synchronisierungsphasen vorsehen, die nur dazu dienen, die Versionen technisch anzugleichen.
• Test Driven Development implementieren: Mit dieser Methode entwickelt man zuerst den Testfall, und dann das Produktivcoding. Der Vorteil hierbei ist, daß man so über Testfälle verfügt, die man verwenden kann, wenn man die Software umbauen will. Ohne Testfälle wird es schnell ein riskantes Vorhaben, wenn man eine Funktionalität umbauen möchte.

Weiterführende Informationen

… im Internet

In den folgenden Artikeln im Internet finden Sie weiterführende Informationen zum heutigen Thema:

• →Android Orphans: Visualizing a Sad History of Support  (Degusta)

… auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Living Specification und Qualität der Software
• →Focussing is about saying No 

Kontakt

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Montag, November 7th, 2011 at 8:41 pm. It is filed under Allgemein, Innovation, Thema des Tages and tagged with Agile Development, Anforderungen, Development, Rapid Prototype, Softwareentwicklung. You can follow any responses to this entry through the RSS 2.0 feed.