Software Architektur ist von zentraler Bedeutung und kann einfach erklärt werden. Ein Vergleich mit der Überbauung einer Siedlung ermöglicht Parallelen zur Software Architektur. Auch als technischer Laie können Sie die richtigen Fragen stellen und verstehen die groben Zusammenhänge.
Ein Blick in die Überbauung einer Siedlung
Als konkretes Beispiel betrachten wir die Überbauung einer neuen Siedlung mit Einfamilienhäusern (EFH) auf der grünen Wiese. Der Käufer kann zwischen 3 Varianten wählen:
- 5 Zimmer EFH mit Flachdach, ohne Garage
- 5 Zimmer EFH mit Giebeldach und Garage
- 5 Zimmer EFH mit Giebeldach, Garage und Solaranlage für die Stromerzeugung
Als Architekt stellt sich die Frage, ob diese 3 Varianten fix geplant werden oder ob ein Modulbaukasten besser wäre:
- Auswahl Anzahl Zimmer (5 oder 6.5)
- Mit / ohne Garage
- Flachdach oder Giebeldach
- Mit / ohne Solaranlage
Vergleich der beiden Varianten:
| 3 fixe Varianten | Modulbaukasten |
| Einfacher | komplexer |
| Schneller realisiert (falls keine Zusatzwünsche) | Mehr Aufwand zu Beginn (= teurer) |
| Nicht flexibel: Neue Anforderungen führen zu neuen Varianten | Einfacher erweiterbar, z.B. Anzahl Nasszellen wählbar
Mehr Varianten |
| Gefahr von zu vielen Varianten im Laufe der Zeit | Gefahr von zu vielen (kleinen) Modulen, die Übersicht geht verloren |
Der Architekt muss entscheiden, welche Flexibilität nötig ist resp. welche Rahmenbedingungen gegeben sind:
- Soll der Kunde kaufen, was vordefiniert ist (Auswahl aus genau 3 Varianten)
- Wie viele EFH sollen insgesamt gebaut resp. verkauft werden
- Wann muss das erste EFH verkauft sein, wie lange darf es max. dauern, bis alle EFH verkauft sind
- Wie viel darf ein EFH kosten: Ein Konkurrenzvergleich liefert wichtige Informationen
Die Zukunft kann niemand voraussagen. Die Wahl der richtigen / besseren Variante ist immer verbunden mit einer subjektiven Einschätzung der Zukunft.
Von den Bauwerken zur Software Architektur
Als Vergleich wird die Entwicklung einer Buchhaltungs-Software herangezogen. Die Siedlung entspricht der Buchhaltungs-Software, das EFH einem Kunden (privat oder geschäftlich).
Es gibt wieder 3 Varianten:
- Light: Einfache Buchhaltung, nicht mandantenfähig, ohne MWSt, keine Schnittstellen zu anderen Systemen
- Simple: Doppelte Buchhaltung, mandantenfähig, mit MWSt, keine Schnittstellen zu anderen Systemen
- Advanced: Doppelte Buchhaltung, mandantenfähig, mit MWSt, Schnittstellen zu anderen Systemen
Als Modulbaukasten gibt es folgende Konfigurationsmöglichkeiten:
- Einfache oder doppelte Buchhaltung
- Mit / ohne MWSt
- Mandantenfähig
- Schnittstellen (z.B. Export von Buchungen im csv-Format)
Marketing / Verkauf müssen folgende Fragen beantworten:
- Wie lange darf es max. dauern, bis eine erste Variante verkauft werden kann und wie hoch dürfen die Entwicklungskosten dafür sein
- Welche Variante ist es: Light oder Simple? Die komplizierteste Variante wird selten als Erste umgesetzt.
- Wann müssen die anderen Varianten bereit sein und wie hoch dürfen die Entwicklungskosten dafür sein
- Sind weitere Varianten denkbar: Doppelte Buchhaltung, nicht mandantenfähig, ohne MWSt
Danach muss die Technik entscheiden, ob die fixen Varianten oder der Modulbaukasten umgesetzt werden.
Wechsel der Architektur
Ein Wechsel der Architektur ist kostspielig. Die Architektur der Software widerspiegelt sich in der Grundstruktur der Anwendung:
- Eingesetzte Tools und Technologien
- Struktur der Kernfunktionalitäten (Module, Ablauf, Daten)
- Definition der Schnittstellen
Bei einem Wechsel müssen nicht alle Punkte betroffen sein. Jeder einzelne Punkt für sich alleine betrachtet kann mit Aufwand verbunden sein.
Technisch ist ein Wechsel machbar. Je später der Wechsel erfolgt desto teurer wird es. Sind z.B. schon Lizenzen für das Buchhaltungsprogramm verkauft worden, muss der technische Support sichergestellt werden. Diese Kunden sind nicht bereit, für eine neue Version, die keine neuen Funktionen beinhaltet, Geld zu bezahlen. Eine Migration dieser Kunden auf die neue Architektur kostet auf jeden Fall Zeit (und somit auch Geld).
Ein paar Tipps
- Im Zweifelsfall einfach als kompliziert: Eine einfache Architektur ist übersichtlicher und leichter verständlich.
- Nicht zu sehr in die Zukunft schauen: Es ist besser, nicht alle Eventualitäten von Anfang an zu berücksichtigen. Meist kommt es anders als zu Beginn gedacht. Was nicht von Anfang an gebraucht wird aber schon realisiert ist, kostet mehr und macht die Architektur komplizierter.
- Sind die Module beim Modulbaukasten zu klein, besteht die Gefahr, dass die Architektur zu kompliziert ist. Jedes Modul hat Schnittstellen und kommuniziert mit den anderen Modulen. Je mehr Module es gibt, desto komplexer wird es. Vor lauter Bäumen sehen Sie den Wald nicht mehr. In diesem Fall können mehrere Module zu einem einzigen zusammengefasst werden.
Fazit
- Parallelen zum Bauwesen erlauben, die Grundzüge einer Software Architektur besser zu verstehen und die richtigen Fragen als Laie zu stellen.
- Es ist besser, mit einer (zu) einfachen Architektur zu starten und diese zu verfeinern als mit einer (zu) komplizierten.
- Ein Wechsel der Architektur ist immer mit (hohen) Kosten verbunden und sollte vermieden werden.
