Out of the Box – Produktkartons

Die Älteren unter uns werden sich noch erinnern: Früher kaufte man Software im Laden in einem Karton. In dem befanden sich dann Disketten (siehe [1]), später CDs mit der zu installierenden Software. Heute wird kommerzielle Software in der Regel in Online Shops erworben, und heruntergeladen. Die Anbieter sichern sich mit Lizenzschlüsseln gegen eine unerwünschte Verbreitung ab. Nur Computerspiele, insbesondere solche für Konsolen, werden heute noch in nennenswertem Umfang in Schachteln verkauft.

Doch die Schachteln leben weiter: Auf einer Vielzahl von Webseiten finden sich virtuelle Produktkartons. Als Beispiel zeigt Abbildung 1 die Homepage von Apache ActiveMQ [2]. Als Open Source Middleware ist es ein besonders interessanter Vertreter, da man diese Software gar nicht käuflich erwerben kann, und sie als Software-Infrastruktur-Komponente für Außenstehende auch schwer zu begreifen ist (es gibt nichts zu klicken). Durch den Karton bekommt die Lösung trotzdem etwas Gegenständliches, sie erscheint fassbarer.

Abb. 1: Produktkarton auf der Homepage von Apache ActiveMQ

Wozu benötigen wir in der Softwareentwicklung etwas zum Anfassen? Das machen wir doch sonst auch nicht! Projektteams brauchen ein gemeinsames Ziel, eine Vision. Was entwickeln wir eigentlich? Was ist die Idee des Systems? Wem nützt es? Wie unterscheidet es sich von Produkten der Mitbewerber? Ich habe reichlich Projekte erlebt, wo einzelne Entwickler diese Fragen nicht, oder nur unklar beantworten konnten. Sie kannten ihren begrenzten Bereich, hatten aber keinen Blick für das große Ganze. Das kann frustrierend wirken, und verhindernd häufig auch innovative Lösungsideen. Es ist eine Ihrer Aufgaben als Softwarearchitekt, die Idee des Systems im Team zu verankern.

ActiveMQ macht es mit seiner Homepage vor. Gleich neben der Kiste entdecken Sie kurz und knapp umrissen, was die Software eigentlich leistet. Die Kartonmetapher funktioniert dabei in mehrerer Hinsicht. Ein echter Produktkarton ist nicht nur hübsch anzusehen (er soll im Regal Aufmerksamkeit erregen; der Interessent soll zu genau diesem Produkt greifen und nicht zu dem der Konkurrenz). Nimmt man ihn in die Hand, findet man die wichtigsten Fakten aufgedruckt: Leistungsmerkmale, Systemvoraussetzungen, besondere Features. Der Produktkarton hilft daher auch bei der Priorisierung von Anforderungen. Was es auf den Karton schafft, hat höchste, alles andere mittlere oder geringe Priorität. Da der Platz dort begrenzt ist, muss sein Inhalt verändert werden, wenn sich die Inhalte in den hohen Prioritäten verändern. Etwas altes muss weichen, damit ein neues hochpriorisiertes Feature auf dem Karton Platz findet. Ist die Systemidee in dieser Form fixiert, können Sie über die auch Monate beobachten, ob Ihr Projekt seine ursprünglichen Ziele überhaupt noch verfolgt.

Ein entsprechendes Arbeitsergebnis sollte jedes Projekt erstellen, zumindest textuell (Ziel: maximal eine DIN A4-Seite, 5-20 Sätze). Manche Teams bannen die Inhalte sogar auf einen echten Karton, und stellen ihn gut sichtbar im Projektzimmer auf. Für neue Teammitglieder haben Sie dann sofort etwas griffiges in der Hand, um sie auf das gemeinsame Ziel einzuschwören.

In weniger bastelfreudigen und vor allem in verteilten Teams ist das Platzieren auf der Startseite des Projektwikis ein guter Plan. Bei ActiveMQ z.B. wird die Systemidee auch nach außen getragen („Mission Statement“); sie dient nicht zuletzt auch dem (Projekt-) Marketing und dem Rekrutieren neuer Entwickler. Unterhalb der Kartongraphik finden Sie auf der Startseite die beeindruckende Featureliste. Man merkt: Diese Software erfüllt die Entwickler mit Stolz. Die Systemidee (repräsentiert durch den Produktkarton) ist eine interessante Ergänzung zum Systemkontext [3]. Während letzterer sich darauf konzentriert, in welcher Umgebung das System eingebunden ist, mit welchen Nutzern und Fremdsystemen es interagiert – kurz abgrenzt, was draußen ist, erlaubt die Systemidee einen ersten Blick in das System. Sie hilft wie der Systemkontext dabei, den Umfang abzustecken. Deshalb sollten beide Arbeitsergebnisse sehr früh im Projektverlauf entstehen.

Man kann darüber streiten, ob es tatsächlich Ihre Aufgabe als Softwarearchitekt ist, die Systemidee zu formulieren, oder ob das nicht eher im Verantwortungsbereich eines Product Owners steht. Für mich steht aber außer Frage, dass es ein entsprechendes Arbeitsergebnis in jedem Projekt geben sollte. Und wenn Sie sich bei dieser für das Team identitätsstiftenden Maßnahme eines virtuellen Produktkartons bedienen wollen, um Ihre Projektseite damit zu zieren: Nur zu! Anleitungen zu dem Thema finden Sie zu Genüge im Netz (z.B. [4]). Wichtiger ist allerdings der beschreibende Text auf den Seiten der Kiste: Was steckt drin?

Links & Literatur

[1] Deutsches Museum, https://www.deutsches-museum.de
[2] Apache ActiveMQ, http://activemq.apache.org
[3] S. Zörner, „Kombiniere – der Systemkontext“, Java Magazin 11.2008
[4] „How to Create Your Own Product Mockup Box in Photoshop”, www.photoshoptutorials.ws

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Out of the Box – Produktkartons”, Java Magazin, 07/2009, 2 Seiten, S. 90
(mit freundlicher Genehmigung)