Monat: März 2015

„Das neue System muss aber das Gleiche können … !“

Wir alle haben sie schon gehört, die einfachste Anforderung der Welt:

"Das neue System muss aber das Gleiche können wie das alte!"

Diese Anforderung hört sich zunächst plausibel an. Sie tritt fast immer auf, wenn Unternehmen aus folgenden Gründen ein Softwaresystem modernisieren oder erneuern müssen:

  • „Wir machen jetzt SOA!“
    Ein neues vielversprechendes Architekturparadigma soll verfolgt werden
  • „Finger weg! Keiner weiß was passiert, wenn wir das anfassen!“
    Niemand traut sich mehr, bestimmte Teile des Systems überhaupt noch zu ändern
  • „Das zahlt uns doch kein Kunde!“
    Eine unzureichende Wartbarkeit macht Änderungen viel zu teuer
  • „Wir gehen jetzt in die Cloud!“
    Ein neues Geschäftsmodell soll verfolgt werden
  • „Silverlight ist tot!“
    Eine bisher eingesetzte Technologie wird abgekündigt
  • „So wie bei Apple!“
    Das User Interface soll moderner werden
  • „Unser Vertrieb braucht jetzt auch Apps!“
    Neue Interaktionsgeräte sollen genutzt werden

In allen diesen Fällen scheint es zunächst plausibel, dass das modernisierte oder erneuerte Softwaresystem das Gleiche können soll wie das alte. Schließlich ändern sich nicht die Features, sondern nur die Architektur (die ersten fünf Fälle) oder die User Experience (die letzten vier Fälle).

Schauen wir uns die Fälle also genauer an:

Die Architektur soll sich ändern: Das Softwaresystem ist offensichtlich schon älter! Das heißt, dass seit dem Zeitpunkt der ursprünglichen Konzeption schon einiges an Zeit vergangen ist. In dieser Zeit wurden viele Ergänzungen und Änderungen umgesetzt. Jede dieser Ergänzungen und Änderungen wurde mit Rücksicht auf den jeweiligen Zustand des Systems oder die Situation des Unternehmens durchgeführt:

  • „Das haben wir auf die Schnelle mal reingebaut!“
  • „Das sollte eigentlich nie so lange drin bleiben!“
  • „Das benutzt schon seit Jahren keiner mehr, aber die Entfernung ist zu riskant!“
  • „Wir mussten damals auf vorhandene Features Rücksicht nehmen: Hätten wir die Freiheit gehabt, hätten wir es ganz anders gemacht!“

Offensichtlich wurden in der Lebenszeit des Systems (oft aus guten Gründen) viele Kompromisse eingegangen, die sich im heutigen System widerspiegeln. Diese Kompromisslösungen wollte eigentlich niemand haben und somit ist auch das System nicht so, wie man es eigentlich haben wollte. Wird das System jetzt massiv modernisiert oder gar erneuert (wie es für eine Architekturänderung nötig ist), dann ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte.

Diagramm - Anforderungen im Lebenszyklus eines Softwaresystems

Anforderungen im Lebenszyklus eines Softwaresystems

Die User Experience soll sich ändern: Hier geht es gerade darum, das System anders zu benutzen als zuvor.

  • „Es soll einfacher zu benutzen sein!“
  • „Es soll nicht mehr so kompliziert sein!“
  • „Wir benutzen nur 15% der Features!“
  • „Es sieht noch aus wie in den 80ern!“
  • „Auf meinem iPad geht alles einfacher!“

Der Wunsch nach veränderter Benutzung führt immer dazu, dass sowohl Interaktionsdesign als auch visuelles Design massiv überarbeitet werden müssen. Deshalb ist es offensichtlich, dass das neue System gerade nicht das Gleiche machen soll wie das alte. Eine massive Überarbeitung des Interaktionsdesigns oder der Einsatz einer neuen Client-Plattform (z.B. Mobile statt Desktop) führt so gut wie immer auch zu einer Anpassung der darunterliegenden Architektur und damit zu noch mehr Aufwand.

Sowohl für die Veränderung der Architektur als auch der User Experience stellen wir somit fest:

  • Die Veränderungen führen zu massivem Aufwand!
  • Das neue System soll gerade nicht das Gleiche machen wie das alte!

Die einfachste Anforderung der Welt ist somit unsinnig und führt immer zu stark unterschätztem (und auch unnötigem) Aufwand für die Rekonstruktion aller alten Anforderungen, da diese natürlich nie konsistent und vollständig dokumentiert sind. Dennoch hören wir diese Anforderung immer wieder. Und warum? Weil sie so einfach zu formulieren ist, und zwar von jedem, egal wie gut er das System kennt.

Trotzdem hat diese Anforderung auch einen wahren Kern. Natürlich muss man für eine Modernisierung oder Erneuerung viele der alten Anforderungen wieder rekonstruieren und berücksichtigen, aber eben nicht pauschal alle.

Verlgeich Nikon D100 Spiegelreflex-Kleinbildkamera und der Nikon D100 Spieglereflex-Digitalkamera (Front und Rückansicht)

Den signifikanten Einfluss, den ein Technologiewechsel sowohl auf die Architektur eines Systems, als auch auf die User Experience hat, zeigt das Evolutionsbeispiel der Nikon F100 Spiegelreflex-Kleinbildkamera zur Nikon D100 Spiegelreflex-Digitalkamera. Eine neue Technologie eröffnet oft auch neue Möglichkeiten (hier z.B. die Vorschaufunktion am eingebauten Monitor) und macht bisherige Funktionen überflüssig (hier z.B. das Zurückspulen eines Films).

Die Kunst liegt nun genau darin, die Unterscheidung zu treffen, welche Anforderungen vom alten System noch gebraucht werden und welche nicht. Der Ansatz, um auf die zukünftigen Anforderungen zu kommen, besteht gerade nicht darin, zunächst alle alten Anforderungen genau zu erheben und dann die irrelevanten wieder zu streichen. Stattdessen empfehlen wir, die Hauptanforderungen konstruktiv aus der intendierten Benutzung abzuleiten und nicht aus den Features des alten Systems. Dies ist die neue Grundlage für die zukünftige Architektur des Systems. Auf diesem stabilen Fundament kann dann das neue System aufgebaut werden. Bei bestätigtem Bedarf können Detailfeatures aus dem alten System konsistent ergänzt werden.

Wenn schon, dann gleich richtig!

Wir haben gezeigt, dass die Modernisierung oder Erneuerung eines Systems für eine Verbesserung der Architektur und der User Experience IMMER zu hohem Aufwand führt und das neue System NIE das Gleiche machen soll wie das alte. Wer also diesen hohen Aufwand auf sich nimmt, sollte bei einer Modernisierung oder Erneuerung NIE versuchen, die gleichen Anforderungen wie vorher umzusetzen. Offensichtlich, oder?

On Tour: SATURN 2015 in Baltimore, USA

Von 27. – 30.04.2015 bin ich bei der SATURN in Baltimore. Ich werde dort einen gemeinsamen Vortrag mit meiner Kollegin Susanne Braun und Ralf Carbon von John Deere halten.

Never again offline?!? Experiences on the outstanding role of data in a large-scale mobile app ecosystem

Abstract: Data is key in information systems. Nevertheless, explicit design of data is often neglected in architecture design because of the focus on components, decisions, or technology selection. We want to change this and put data in the center of the story.

We will share our experiences from an innovation and development project of John Deere and Fraunhofer IESE. We developed a mobile app ecosystem with several apps and its own cloud backend. During the course of the project, we learned that we had to pay more and more attention to the role of data due to its impact on the quality attributes performance, scalability, user experience, and security.

Our entertaining story starts with data on a single mobile device that spreads over multiple apps, users, devices, companies, tenants in our cloud backend, even data exchanged with agricultural machines. We report on security aspects, multi-tenancy, offline capability and synchronization, internationalization, and the different treatment of master data, job planning data, and high-frequency near-real-time data for the localization of vehicles in the field. All this is presented with a strong focus on data, elaborating step by step the challenges and our decisions in the system design.

Our audience will learn about many recurring architectural challenges and solution patterns around data in mobile app ecosystems, they will learn how recent patterns like Command Query Responsibility Segregation (CQRS) and many others helped us, and they will learn how technologically innovative today’s farming practices are.

SATURN Programm

© 2017 mibinu

Theme von Anders NorenNach oben ↑