Follow my new blog

Dienstag, 6. September 2011

Softwareevolution in Vielfalt

In einem früheren Posting habe ich über Rahmenbedingungen für die Evolution von Software nachgedacht. Den dort genannten möchte ich nun noch eine hinzufügen: die Vielfalt.

Ich glaube, dass Evolution eines Ganzen schwieriger ist, als die Evolution von Vielem, das eine Summe hat.

Das Leben auf der Erde ist nicht ein Organismus (auch wenn es die Gaia-Hypothese gibt), sondern es besteht aus unzähligen. Und es evolviert in jedem einzelnen.

Genauso ist ein Betriebssystem wie Unix oder Windows nicht “ein Ding”, sondern besteht aus Hunderten oder gar Tausenden kleinen “Dingen”, die erst in Summe das ergeben, was wir mit dem Namen “Unix” oder “Windows” betiteln.

Mein iPhone ist einerseits ein “Ding”, eine Hard-/Softwareplattform. Andererseits ist es etwas, das sich entwickelt. Die Summe einer wachsenden Zahl von Teilen, den Apps. Mein iPhone evolviert sozusagen; es passt sich meinen Bedürfnissen ständig an. Das ist ganz einfach möglich, weil es nicht monolithisch ein “Ding” ist wie mein vorheriges Handy. Die Evolvierbarkeit steckt in der Möglichkeit zur Vielfalt.

Ich kann meine Schreib-Anforderungen iterativ immer besser erfüllen, weil ich meine Schreib-Apps getrennt von den Diagramm-Apps und die wiederum getrennt von den Musik-Apps “weiterentwickeln” kann. Ich kann mit “Notizen” beginnen, zu “Nebulous” weitergehen, auf “Pen & Paper” umsatteln und schließlich bei bei “Simplenote” enden.

Die Erfüllung anderer Anforderungen, ist von dieser Weiterentwicklung nicht betroffen. Ich kann auch jederzeit meinen Fokus wechseln. Mal möchte ich beim Schreiben vorankommen, mal möchte ich die Fotonachbearbeitung verbessern.

Diese Offenheit zur Evolution eines Ganzen durch feingranulare Evolution einer Vielfalt von Summanden, halte ich für eine Voraussetzung für evolutionären Erfolg. Unix hat es in Software vorgemacht, der PC hat es in Hardware nachgemacht, das Web hat dieses Prinzip ins Extreme getrieben, das iPhone setzt wieder darauf.

Voraussetzung für eine derartige Evolution der Vielfalt ist eine Plattform. Bei Unix war es der Kernel, würde ich sagen, beim PC der Bus mit seinen Slots für die Erweiterungskarten, beim Web TCP+DNS+HTTP+HTML, beim iPhone Hardware+iOS+AppStore.

Und was bedeutet das für Ihre Anwendung?

Wenn der Kunde kommt und sagt, er wolle “eine Anwendung”, dann nehmen Sie das “eine” nicht so genau. Ihr Kunde will einen Anforderungsberg abgetragen bekommen. Klar. Aber letztlich ist ihm egal, ob das mit 1 Anwendung (lies: EXE) geschieht, solange es praktikabel und nachhaltig geschieht.

Denken Sie also nicht reflexhaft an 1 großes Fenster für die GUI, in dem sich irgendwie alles abspielt. Denn das zwingt den Code in schnell in 1 großen Kasten, in dem er leicht verklebt.

Stattdessen überlegen Sie, wie Sie die Lösung als Summe einer Vielfalt von Apps beschreiben können. Ja, ich meine App in der Linie von iPhone oder iPad Apps. Das sind kleine, sehr fokussierte Programme. Sie dienen einem überschaubaren Zweck. Ihre Usability ist zu dessen Erfüllung maximiert.

Deshalb sehen die Apps auch alle sehr unterschiedlich aus. Eine Foto-App ist ganz anders als ein Spiel und das unterscheidet sich von der Mindmap-App. Das nehmen wir ihnen nicht übel, sondern begrüßen es. Auch, dass wir auf dem iPhone nur jeweils 1 App zur Zeit sehen, stört uns meist nicht. Im Gegenteil: so fokussieren wir uns.

Ich glaube, dass wir diesen Ansatz auf unsere “Geschäftsanwendungen” übertragen sollten. Wir sollten sie zerschlagen in eine Vielfalt von Apps. Und jede dieser Apps kann separat evolvieren.

Beispiel Faktura. Landläufig würde ein Softwarehaus für die Anforderungen, die hinter dem Begriff stehen, eine Anwendung bauen. Eine EXE, die auf allen Desktops im Büro installiert wird. (Und vielleicht noch ein SQL Server auf einem Server-Rechner.) Alle Funktionen würden über ein Hauptfenster erreicht und liefen im Faktura-Prozess ab.

Jede Änderung würde dann notwendig die eine Codebasis betreffen. Unschöne Kopplungen würden bei aller Mühe immer wieder entstehen. Die Evolvierbarkeit würde schnell sinken. (Ja, dagegen kann man sich mit Prinzipien und Praktiken stemmen, doch die grundlegend monolithische Sicht auf die Anforderungen macht es schwer für sie zu greifen.)

Wie anders würde die Entwicklung verlaufen können, wenn das Projekt mit evolvierender Vielfalt angegangen würde. Dann gäbe es eine App für die Rechnungslegung, eine App für die Stammdatenpflege, eine App für den Zahlungseingang, eine App für das Mahnwesen und eine App für den Chef. Vielleicht auch noch eine App für den Import und Export. Oder noch eine App für die Gestaltung unterschiedlicher Rechnungsvorlagen.

Es gäbe nicht mehr eine große Codebasis. Es gäbe ja nicht mehr eine Anwendung, sondern viele, ein Anwendungssystem. Die könnten Codeteile gemeinsam verwenden. Aber sie wären grundsätzlich sehr deutlich getrennt. Änderungen würden dann nicht mehr zu ungewollten Kopplungen in der Codebasis führen, da sie meist nur eine App zur Zeit beträfen. An manchen Apps würde mehr geschraubt als an anderen. Apps, die später in Angriff genommen würden, könnten intern anders aufgebaut sein, als frühere Apps, weil man schon aus Fehlern gelernt hat. Überhaupt müssten Entscheidungen nicht immer für “alles” getroffen werden; keine Notwendigkeit für 1 allumfassende Datenbank, 1 allumfassendes Datenmodell, 1 alle glücklich machende Persistenztechnologie, 1 GUI-Technologie usw.

Eine App könnte ihre Daten in SQL Server speichern, die andere in MongoDb. Die eine App könnte noch mit einer WinForms-Benutzerschnittstelle versehen sein, die andere WPF benutzen. Und wenn in einer App die Unwartbarkeit erreicht sein sollte, dann könnte die ganz unabhängig von allen anderen neu gemacht werden.

Ich kann nur Vorteile in einer solchen Vielfalt erkennen. Sie eröffnet Chancen, ohne einzugrenzen.

Es gibt lediglich eine Hürde: die in unseren Köpfen. Wir müssen Anwendungen so denken wollen. Technisch spricht nichts dagegen, sondern alles dafür. Auch sollten uns die genannten Präzedenzfälle ermutigen. Wir alle lieben Plattformen, die wir stückweise erweitern, die wir evolvieren können. Warum also nicht die Vorteile feingranularer Vielfalt für unsere eigenen Projekte nutzen?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat...

PS: Einige Leser werden nun denken, ich würde damit vorschlagen, dass eine GUI-Shell oder ein Basisframework wichtig seien. Ohne etwas Gemeinsames unter allen Apps oder über allen Apps sei solche Vielfalt nicht zu machen. Nichts könnte mir jedoch ferner liegen. Anwendungsevolution durch eine Vielfalt an Apps hat keine Voraussetzung; nichts muss erstmal eingerichtet werden. Jede App kann unabhängig von anderen jederzeit begonnen werden. Das Betriebssystem als Plattform reicht.

PPS: Das Ganze nicht als Monolith zu sehen, sondern als Summe von vielen Teilen, sollte sich natürlich durch alle Ebenen einer Software ziehen. Die ganze Anwendung besteht aus unabhängig evolvierbaren Apps. Jede App besteht aus unabhängig evolvierbaren Bausteinen. Und diese Bausteine wiederum sind unabhängig evolvierbar. Apps sind mithin Ausdruck der Selbstähnlichkeit von Software.

13 Kommentare:

bjomahler hat gesagt…

Interessante Ideen - insbesondere weil ich gestern erst wieder über eine solche technische Umsetzung gegrübelt habe ;) - und zwar bei einer Webanwendung bei der jedes kleine Modul quasi eine App in der Landschaft der Unternehmensanwendung wäre.

Problem hierbei ist für mich, dass ich hier ein trade of zwischen Unabhängigkeit und Evolvierbarkeit auf der einen Seite und KISS, sowie übergreifendes Nutzen von gleichen Domänen auf der anderen Seite habe.

Selbst wenn man letzteres in den Griff bekommt mit einer Global-Domain-Object-Collection App... die Einfachheit einer monolitischen Webanwendung im Aufbau steht dem gigantischen nervigen Overhead bei Plugin Mechanismen wie z.B. OSGI gegenüber... ich finde die aktuellen Möglichkeiten solch wirklich gut unabhängig und lose gekoppelten Module erstellen zu können alle zu aufgebläht, mies dokumentiert und zu schwierig, als dass sie meinen KISS Ansprüchen genügen würden.

Ralf Westphal - One Man Think Tank hat gesagt…

@bjomahler: Aber ich spreche doch gar nicht von Plugins. Die mögen auch mal angebracht sein, um innerhalb einer App Features zu entkoppeln. Mir ging es jedoch um echt getrennte Apps, also z.B. verschiedene ASP.NET Anwendungen. Das halte ich für sehr KISS-konform.

Ole hat gesagt…

Ich habe mal einen Artikel auf DZone mit aehnlicher Stossrichtung (allerdings eingeschraenkt auf Webapps) veroeffentlicht:
Extremely Decoupled Architecture for Web Applications (EDAWA); Part 1: Vertical Decoupling


Ist teilweise etwas expliziter. Allerdings gibt es auch eine uebergreifende "Klammer", damit es fuer den User wie eine Anwendung aussieht.
Ist halt oft eine Forderung von Kundenseite.
Liesse sich aber leicht durch die Bookmarklist des Browsers ersetzen.

Andreas Schädler hat gesagt…

Hmmm… tönt für den Entwickler wirklich toll, aber wie ist es für den Anwender?

Da ich kein iPhone oder was Ähnliches habe kenn ich mich mit dem Umgang mit Apps nicht so aus, denke aber jetzt an eine Erfahrung zurück.

Als ich meine aktuelle Stelle antrat gab es eine Anwendung, welche aus mehr als 10 Access-Programmen bestand. Eben für jeden bereich eine Eigene. Auch ein damaliges VB6 Programm wurde nicht erweitert sondern mit ca 8 Access-Programmen ausgebaut. Auch hier nach Funktion wie Bestellungen, Zahlungen usw. getrennt. Die Benutzer hatten den Desktop voller Links und mussten so ihre „Apps“ ständig zusammensuchen. Später wurden diese Funktionen in einer einzigen Access-Anwendung zusammengefasst, was für die Benutzer eine enorme Erleichterung darstellte und die Produktivität erhöte.

Können Apps untereinander verlinkt werden? Ich stelle mir vor, ich bin in einer Lieferschein-App und stelle fest, dass die Adresse nicht korrekt ist. Jetzt muss ich also die Adress-App öffnen, die Adresse suchen, mutieren und dann wieder in die Lieferschein-App wechseln. Bei einer „Integration“ kann ich einfach aus dem Lieferschein heraus die Adresse mutieren was doch viel bequemer ist.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anderas: Wenn Apps falsch geschnitten sind, ist das natürlich schlecht. Und wenn man die Anwendungsfälle nicht genau analysiert, ist das auch doof. Beides widerspricht dem Ansatz der Apps aber nicht.

1. Wer sagt, dass die Erfassung von Lieferadressen eine eigene App sein muss? Vielleicht ist das schlicht zu simpel gedacht: "Lieferadresse = 'Dateneinheit' = App".

2. Wer sagt, dass Lieferadressen nicht in mehreren Apps nachgeschlagen (oder gar geändert) werden dürfen? Ich greife auf dem iPhone ja auch mit mehreren Apps auf dieselben Daten zu. Das muss auch nicht in allen Apps in gleicher Weise geschehen; vielleicht in einer nur Nachschlagen, in einer anderen rudimentär ändern, in einer weiteren komplett ändern.

Apps sind vertikale Schnitte. Die gehen nicht unbedingt entlang von Daten (also Daten nur hier oder dort; dieselben Daten können hier und dort im Zugriff sein).

Andreas Schädler hat gesagt…

@Ralf: Danke, jetzt verstehe ich besser.

bjomahler hat gesagt…

@Ralph: Hmm - okay - hast recht ;) - da war ich noch zu sehr in meiner eigenen Problemdomäne, um zu erkennen, dass du über was ganz anderes sprichst.

Statt also einer monolithischen Anwendung, die alles erschlägt, sollen wir jetzt mehrere Anwendungen schreiben, die jeweils den Teilaspekt realisiert, für den sie gedacht ist. Das ist natürlich maximale Entkopplung.

An sich ja ganz nett.. aber meist bedingen sich doch gerade diese Anwendungen untereinander. Beispielproblem - alle Anwendungen sollen einem CI unterliegen und wenn sich dieses ändert, sollen alle Anwendungen automatisch mitgeändert werden... bei einer vollständigen Entkopplung in einzelne Anwendungen muss ich also dann alle neu deployen, wenn so etwas eintritt (könnte man jetzt mit static resources kommen, aber das war auch nur als Beispiel gedacht).

Einzel Apps sind schön und gut - aber in bestimmten Fällen ist eine einheitliche, konsistente und trotzdem maximal entkoppelte Anwendung aus meiner Sicht interessanter...

bei den Apps auf einem nPhone würde ich mir manchmal auch mehr Zusammenarbeit und ineinanderintegration wünschen.

Ralf Westphal - One Man Think Tank hat gesagt…

@bjomahler: Warum sollte sich Einheitlichkeit nicht so leicht herstellen lassen, nur weil Fenster/Masken in zwei ganz unterschiedlichen Projekten definiert sind? In Web Projekten können sie ja gemeinsame CSS Dateien referenzieren.

Außerdem ist ja gerade die Einheitlichkeit ein Problem. Was hat Vorrang: CI oder Usability. Die CI darf nicht im Wege stehen.

Nein, da sehe ich kein fundamentales Problem. Dem Kunden muss man nur klar machen, um was es geht. Wie teuer darf CI werden, wenn die Evolvierbarkeit leidet?

Auf so allgemeinem Niveau lässt sich aber kaum drüber reden.

Dass iPhone Apps gelegentlich besser zusammenarbeiten könnten, stimmt. Aber da ist es ja auch extrem mit der Trennung derjenigen, die sie entwickeln. Wenn die Apps aus einer Hand kommen, dann ist das leichter.

Am Ende bleibt es dann nicht bei Apps, die einfach jede für sich Durchstiche darstellen, sondern eine Anwendung wird durch eine Matrix an Services realisiert. Quasi eine SOA Matrix. Auch das sollte man denken können.

Unknown hat gesagt…

@Ralf:
Diese Idee, mit den vielen fokussierten Apps, gefällt mir auch.

Wenn ich mir das Szenario überlege:
Man hat einen Viewer für bestimmte Daten. Dessen Interface ist absolut optimiert für diese Aufgabe. Nun möchte der User die Daten gerne bearbeiten. Da könnte in dem Viewer ein Button hinterlegt sein. Beim Klick darauf, wird die Anwendung "Editor" gestartet.
Für den User könnte es so wirken, als wäre alles aus einem Guss.

In der Konfiguration könnte es sogar möglich sein, den Pfad zur *.exe des Editors zu verändern. Dadurch könnten sogar völlig unterschiedliche Editoren genutzt werden. Der Nutzer könnte also den Editor nutzen, der ihm am besten gefällt.

So ähnlich wird es ja heute schon getan. Da gibt es Bildverwaltungsprogramme. Sie selber bieten kaum Möglichkeiten, ein Bild zu bearbeiten. Sie bieten aber die Möglichkeit, das Bild z.B. mit Photoshop oder Gimp zu bearbeiten.

Ein ähnliches Konzept sehe ich z.B. auch sehr stark bei den Google-Diensten. Das Nutzerkonto bildet die zentrale Datenbasis. Aber die Dienste selbst haben quasi nix miteinander zu tun. Sie greifen lediglich auf die gemeinsamen Daten zu.
Das ist aus Entwickler-Perspektive sicher vorteilhaft. Aus User-Sicht wirkt das manchmal aber eben sehr chaotisch und willkürlich, weil manch ein Dienst noch alte Technologien nutzt, während ein anderer Dienst voll modern ist.

Thomas hat gesagt…

Eine Sache macht mir bei deinem Ansatz Sorgen:

Du hattest gesagt, dass verschiedene Apps auf dieselben Daten zugreifen könnten (Apps als vertikale Schnitte). Gerade hier ergibt sich ja wieder eine Abhängigkeit. Falls auch die Datenstrukturen evolvierbar sein sollen, sind somit alle Apps betroffen und müssten angepasst werden.

Wie kann man dieses Problem lösen?

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Klar, Apps können auf dieselben Daten zugreifen. Müssen sie aber nicht. Du entscheidest.

Apps, die auf demselben (persistenten) Datenmodell basieren, liegen im selben Bounded Context (BC).

Wenn dieselben Daten in verschiedenen BC benutzt werden sollen - das ist völlig ok -, dann muss zwischen den BC repliziert werden.

Anonym hat gesagt…

Hi Ralf,

würde Dir ja gerne einen Kaffee spendieren, doch Paypal ist nach dem Erpressungsversuch von Rossmann für mich gestorben, die Kombination aus unendlicher Arroganz gepaart mit einer ebensolch großen Dummheit (zusammen: Amerikaner) geht gar nicht.

Nun zum Wesentlichen: Wie immer ein lesenswerter Gedanke - leider habe ich noch keine Möglichkeit gefunden, Mainframe-basierte Betonköpfe sanft zu knacken :-)

Viele Grüße

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@Christian: Dann spendierst du mir mal nen Kaffee irgendwo, wo wir uns live sehen.

Betonköpfe knackt das Leben irgendwann. Besser, du bist dann aber nicht mit in der Presse :-)