© Excellent backgrounds/Shutterstock.com
Eine Replik auf Wolfgang Pleus’ Artikelserie „Sustainable Service Design“

Nachhaltig - oder nur langlebig?


Wolfgang Pleus kritisiert in seiner Artikelserie „Sustainable Service Design“ (Java Magazin 2.2015 und 3.2015), dass Nachhaltigkeit in der Softwarebranche bisher zu wenig Beachtung geschenkt werde. Ich möchte dem einen grundlegend anderen Ansatz entgegenstellen: Statt der Servicekontrakte könnte auf universelle Schnittstellen gesetzt werden, um Wiederverwendbarkeit zu erreichen. Lange etablierte Designprinzipien können dabei helfen, Software schon in der Konzeption besser auf den Nutzen für Auftraggeber und Endanwender zuzuschneiden. Statt sich auf Langlebigkeit und strikte Vorgaben zu fixieren, schlage ich vor, den Austausch zwischen Entwicklern und Stakeholdern in den Mittelpunkt zu stellen und eine Umgebung zu schaffen, in der alle Beteiligten ihr kreatives Potenzial ausschöpfen können. Denn Langlebigkeit alleine bringt keine Nachhaltigkeit, wenn der Nutzen fehlt.

Pleus bemängelt, dass wir das Rad ständig neu erfinden, indem wir Software nach einigen Jahren wegwerfen und neu implementieren. Da beispielsweise Banken und Versicherungen seinen Beobachtungen zufolge ohnehin über lange Zeiträume gleichbleibende Datenstrukturen und Geschäftslogik verwenden, schlägt er einen Ansatz vor, den er „nachhaltiges Servicedesign“ nennt: Services sollen abstrakt und technologieneutral beschrieben werden, um kurzlebige Technologietrends zu überdauern. Konkrete Implementierungen werden dann durch technologiespezifische Bindings umgesetzt.

Doch würden nicht auch Banken und Versicherungen von mehr Flexibilität in der Softwareentwicklung profitieren? Mit Wolfgang Pleus’ „nachhaltigem Servicedesign“ zumindest nicht. Wie im Folgenden anhand eines kurzen Praxisbeispiels gezeigt wird, suggeriert der Name zwar Leichtgewichtigkeit und Effizienz, in der Praxis bewirkt der Ansatz aber letztendlich das Gegenteil. Services müssen zunächst abstrakt beschrieben und dann durch konkrete Bindings implementiert werden. Um sich „zukünftig in möglichst vielen fachlichen und technischen Kontexten verwenden“ zu lassen, erfordern sie für jeden neuen technischen Kontext ein neues Binding. Auch hier wird also häufiger mal das Rad neu erfunden, allerdings mit noch mehr Aufwand.

Aus unveränderter Geschäftslogik und gleichbleibenden Datenstrukturen folgert Pleus, Unternehmen würden davon profitieren, ihre Services in Form von langlebigen und technologieunabhängigen Servicebeschreibungen zu definieren. Was aber, wenn die Langlebigkeit von Geschäftslogik und Datenstrukturen eher auf schwergewichtige IT-Systeme und veränderungsfeindliche Organisationsstrukturen zurückzuführen ist? Dann gibt Wolfgang Pleus’ Auffassung zwar eine richtige Beobachtung wieder, nicht aber die tatsächlichen Bedürfnisse der Fachabteilungen und Kunden. Die Langlebigkeit weiter zu manifestieren wäre dann nicht im wirtschaftlichen Interesse des Unternehmens.

Gehen wir einmal davon aus, dass auch Unternehmen in eher konservativen Branchen von mehr Flexibilität profitieren würden. Banken könnten zum Beispiel mehr Kunden erreichen, wenn sie es schaffen würden, neue Produkte schneller auf den Markt zu bringen. Onlineangebote und mobile Apps können auf Basis von regelmäßigem Nutzerfeedback kontinuierlich verbessert werden. Dazu ist jedoch die Organisation der Entwicklung in kurzen Releasezyklen erforderlich, Nutzungsdaten müssen ausgewertet und in der Konzeptentwicklung miteinbezogen werden. In der Praxis scheitern viele Unternehmen jedoch bereits daran, ihre mobile Software an die häufigen Versionssprünge von iOS und Android anzupassen.

Doch wollen wir nicht lieber den Markt gestalten, statt ihm hinterherzulaufen? Was ambitioniert klingt, ist manchmal schon durch etwas mehr Fokus und ein früher veröffentlichtes Feature möglich. Um dahin zu kommen, sollten wir aber bei den Anforderungs- und Entwicklungsprozessen ansetzen, statt Services langfristig festzuschreiben. Indem wir Kundennutzen und Kundenzufriedenheit an erste Stelle setzen, können wir die Wünsche und Bedürfnisse unserer Endnutzer besser verstehen und zielgerichtet nur das entwickeln, was wirklich benötigt wird. So erhöhen wir die Effizienz der Softwareentwicklung, steigern den Wert unserer Produkte und erreichen Nachhaltigkeit durch Ressourcenschonung.

Praxistest: Nachhaltiges Servicedesign und REST Binding

Auch auf der technischen Detailebene stellt sich die Frage, ob Wolfgang Pleus’ Vorgehen am richtigen Punkt ansetzt. Sehen wir uns das anhand eines einfachen Beispiels an. Um keine fachlichen Assoziationen zu wecken, begeben wir uns in eine unschuldige Domäne und setzen ein API zur Verwaltung von Hundewelpen (angelehnt an [1]) um. Unser Hundewelpen-API in Version 1.0 könnte so aussehen:

getAllDogs, foodNeeded, getLocation, getDog, save­Dog, replaceSittingDogsWithRunningDogs, health­Check etc.

Wolfgang Pl...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang