Baukunst vs. Softwareschmiede

Was ist Architektur?

Adam Bien

„Architecture should be as simple as possible, but not simpler.“
Frei nach Albert Einstein

Architekturen strukturieren Anwendungen: Wie auch das Prinzip „Divide And Conquer“
helfen Architekturen bei der Komplexitätsbewältigung und senken so die Kosten
für die Pflege und manchmal auch für die Entwicklung von Anwendungen. Und doch
ist diese Struktur in der Praxis nicht von Dauer, denn der Feind Nr. 1 jeder Architektur ist
der Compiler. Arbeitet man in Java, hat man noch Glück: Im Bytecode bleibt die Struktur
der Software nahezu unverändert enthalten. Aber schon bei der nächsten Optimierung,
z.B. durch den HotSpot-Compiler, geht diese Struktur unwiederbringlich verloren. Aus
den eleganten Ideen, Strukturen und Mustern entsteht lediglich Maschinencode.

Paradoxerweise wirken sich gute Architekturen mit ihren Indirektionen, Kapselungen
und Entkoppelungen negativ auf die Wartbarkeit des Maschinencodes aus. Und ein „Urzeitentwickler“ könnte mit dem auf diese Weise entstandenen Maschinencode nur
wenig anfangen. Denn für ihn wären die vielen sinnlosen Prozessorzyklen, welche aus
den Architektur- oder Designpatterns entstanden sind, kaum fassbar. Dennoch spielt
dieses Verfahren in der Praxis kaum noch eine Rolle: Immer weniger „Urzeitentwickler“
sind in der Lage, die Maschinenprogrammierung von modernen Prozessoren direkt
durchzuführen. Die Wartbarkeit des Maschinencodes wird daher in der Regel zu einem
völlig irrelevanten Argument.

Enterprise Architekturen

von Adam Bien


Dieser Onlineartikel ist ein Auszug aus dem Buch „Enterprise Architekturen. Leitfaden für eine effiziente Software-Entwicklung“ von Adam Bien, das bei entwickler.press erschienen ist. Sie können das Buch im Onlineshop von entwickler.press erwerben.

entwickler-press.de

Auch C-Entwickler mussten anfänglich ziemlich lange „kämpfen“, bis die höchst ineffiziente,
viel zu abstrakte C-Sprache die direkte Assemblerprogrammierung abgelöst hat.
Das gleiche Problem beschäftigte die C++-Entwickler: Objekte? Würde das nicht unnötigen
Mehraufwand bedeuten? Ließe sich das Gleiche nicht mit der funktionalen Programmierung
erreichen, die zudem den Vorteil einer deutlich höheren Performance und
eines wesentlich geringeren Ressourcenverbrauchs hätte? Ähnlich turbulent verlief auch
die Einführung von Java und .NET: Bei diesen Sprachen werden sogar die echten CPUs
gekapselt und die Anwendungen für eine nicht-existierende Hardware kompiliert. Und
diese virtuelle Maschine interpretiert zunächst den künstlichen Maschinencode und
führt erst anschließend echten Maschinencode aus. In Anbetracht dieser Tatsache hätte
jeder pflichtbewusste „Urzeitentwickler“ wahrscheinlich sofort seinen Job gekündigt …

Aus Maschinensicht sind Unternehmensarchitekturen noch deutlich ineffizienter: Denn
diese beschreiben die Strukturierung von Anwendungen, welche bereits in der virtuellen
Hardware ablaufen. Aus Sicht der Maschine (CPU) handelt es sich daher bei höheren
Sprachen und insbesondere bei Architekturen um eine unfassbare Verschwendung von
Ressourcen. Da aber Hardware immer weniger kostet, nimmt man diese Laufzeitnachteile gerne in Kauf. Schließlich wird kreative Software immer noch von Menschen
gebaut. Mit der steigenden Komplexität von Anwendungen nimmt die Strukturierung
von Software an Bedeutung zu. Nur wenige Entwickler sind in der Lage, Maschinencode
zu schreiben. Man findet schon mehr Assemblerentwickler, etwas mehr C-Entwickler,
vielmehr Java/.NET-Entwickler. Nun stellt sich die Frage, wie viel Struktur bei der Verwendung
von modernen Programmiersprachen noch notwendig ist – nach jedem Kompiler
bzw. Optimierungsvorgang wird die schöne Struktur sowieso in eine Bitfolge von 0
und 1 umgewandelt …

Warum über Architekturen nachdenken?

Im Gegensatz zum Bauwesen lassen sich Anwendungen oft schneller ohne die Berücksichtigung
von Architekturen entwickeln. Man muss nur motivierte Entwickler engagieren:
Entwickler, die noch Spaß an der Entwicklung von Software haben, werden sich
bald und ohne unnötige Formalismen selbst organisieren, effiziente Teams bilden, und
sich erstaunlich schnell in das Projekt und die Technologie einarbeiten. Bei komplexen
Aufgaben werden mehrere Entwickler an einem PC zusammenarbeiten – das ganze Vorgehen
wird sehr agil.
Die Entwicklungskosten lassen sich noch weiter (aber nicht mehr so drastisch) senken,
wenn Sie folgende Punkte berücksichtigen:

  • Nicht nachdenken – loshacken!
  • Die Anzahl der Subsysteme, Komponenten, Packages und Klassen minimieren.
  • Auf Objekte verzichten – statische Methoden bevorzugen.
  • Systematische Fehlerbehebung kostet Zeit und somit auch Geld – „catch throwable“
    funktioniert ebenfalls zuverlässig. Auch muss man nicht soviel schreiben.
  • Die Dokumentation auf keinen Fall selbst verfassen (ist nicht mehr zeitgemäß), dafür
    gibt es auch interessante Reverse-Engineering UML-Tools.
  • Copy & Paste bevorzugen – bevor man über andere Arten der Wiederverwendung zu
    lange nachdenken muss
  • Unnötig ist die Trennung von Zuständigkeiten bzw. der Fachlichkeit von der Technik- ohne Trennung funktioniert’s auch gut!
  • Sämtliche Muster, Vorgehensweisen und Idiome auf jeden Fall ignorieren – das Lesen
    von Büchern, Whitepapers und Artikeln dauert einfach zu lange. Diese Zeit geht dem
    Projekt unwiederbringlich verloren.

Die hier genannten „Verbesserungsvorschläge“ wurden tatsächlich in nicht so offensichtlicher
Form in Projekten befolgt – zumindest hat der Quellcode danach ausgesehen.
Nichtsdestotrotz kann diese Art Software zu entwickeln mit viel Glück auch sehr günstig
sein. Aber im Gegenzug fallen die Folgekosten für die Produktionseinführung, den laufenden
Betrieb und die Wartung deutlich dramatischer aus. Dennoch wird die Unternehmung
aus der Sicht des Projektleiters als erfolgreich abgeschlossen beurteilt werden.
Auch wenn das Projekt bereits einige Monate später auf Grund von hohen Wartungskosten
beendet wird… Dies ist im Übrigen ein „Trend“ der letzten Jahre: Die meisten Projekte gehen ohne Probleme in die Produktion. Interessant ist nur, ob sie auch die ersten Erweiterungen und Korrekturen überstehen.

Baukunst vs. Softwareschmiede

Die Entwicklung von Software wird oft mit der Herstellung von Produkten aus anderen
Industriesparten verglichen. Jedoch zeichnet sich Software durch andere Eigenschaften
aus, die sich nicht so ohne weiteres mit anderen (Kauf-)Produkten vergleichen lassen:
Denn hierbei handelt es sich um ein virtuelles, veränderbares Produkt. Im Gegensatz
dazu sind Gebäude erheblich konkreter und bei weitem nicht so erweiterbar wie Software.
Auch sind die Wartungskosten eines Hauses deutlich günstiger im Vergleich zu
der Anfangsinvestition. In der Softwareentwicklung übersteigen hingegen die Wartungs-
und Betriebskosten wesentlich die Aufwände für die Entwicklung. Dennoch findet
man immer wieder diese Art Vergleich: Software-Architekturen werden mit eher
konkreten Gebäudearchitekturen oder CAD-Entwürfen gleichgesetzt und Manager
wundern sich folglich, warum Software nach der Installation so teuer ist bzw. sich die
Folgekosten so schlecht planen lassen.

Auch gibt es einen großen Unterschied zwischen einem typischen Bauherrn und einer
Fachabteilung – Bauherrn wissen oft ganz genau, was sie wollen – und Sie wissen auch
ganz genau, dass nachträgliche Änderungen viel Geld kosten. Dies fließt vom Anfang an
in die Kalkulation mit ein: Man entscheidet sich zwischen einem Fertig- und einem „Individual“-
Haus. Und weiß, dass die Umsetzung von Änderungen, Erweiterungen und
Sonderwünschen bei Fertighäusern letztendlich deutlich teurer zu Buche schlagen als bei
einem Individualhaus. Dieses Bewusstsein fehlt oft (noch) bei dem Software-Auftraggebern:
Spezifikationen und Pflichtenhefte verlieren oft schon während der Entstehungszeit
ihre Gültigkeit. Und um dieses Problem zu umgehen, werden die Anforderungen so
schwammig formuliert, dass die Entwickler/Architekten sämtliche Freiheiten genießen,
aber dadurch auch keine vertragliche Sicherheit haben. Dieser Effekt lässt sich noch verstärken
durch möglichst umfangreiche, oder am besten noch generierte Spezifikationen.

Softwarearchitekturen lassen sich eben nicht mit Architekturen von anderen Bereichen
vergleichen. Auch die Motivation für eine Softwarearchitektur ist eine andere. Während
man einen Bauleiter bereits für den Bau von Gebäuden benötigt, stört ein Softwarearchitekt
eher die Entwicklung. Gute, d.h. motivierte Entwickler kommen auch ohne abstrakte
Architekturen und die oft technologieneutralen Präsentationen oder Entwürfe
eines Architekten aus. Softwarearchitekturen und somit auch -architekten werden primär
für die Minimierung der Gesamtkosten und nicht für die Beschleunigung der Entwicklung
benötigt. Somit leben die Architekten gefährlich, zumindest in einem ständigen
Konflikt mit dem Projektleiter. Projektleiter sind vorwiegend an der Einhaltung der
Termine und somit der Verkürzung der Entwicklungsphase, die Architekten dagegen
auch an der Wartbarkeit der Anwendung interessiert.

Der Hauptunterschied zwischen den Architekten der Bau- und Softwarebranche ist jedoch
offensichtlich: Während ein Architekt aus der Baubranche tatsächlich ein virtuelles, und
manchmal ein eher konkretes Modell des Gebäudes erstellt und dem Kunden präsentiert,
ist der Softwarearchitekt nur am Rande an den Äußerlichkeiten der Anwendung interessiert– für ihn zählen vielmehr die inneren Werte. Somit ist die Arbeit eines Softwarearchitekten
für den Auftraggeber bzw. Kunden schwer greifbar und somit auch oft verdächtig.

Architektur
Die meisten Definitionen in der Fachliteratur bezeichnen mit „Architektur“ zunächst die
innere Struktur eines Systems. Dabei geht es insbesondere um das Zusammenspiel von
internen Modulen. Sowohl die Struktur als auch das Zusammenspiel solcher Module
und die Schnittstellen sind im Zusammenhang mit dem Architekturbegriff von Bedeutung– und so könnte man die Erläuterung folgendermaßen formulieren: „Unter Architektur
versteht man die Regeln für das Zusammenspiel von zusammengehörigen (kohäsiven)
Einheiten in einem gegebenen Kontext.“
Wartbare Software

„Wartbare Software“ – was ist mit diesem Begriff eigentlich gemeint? Diese Frage lässt
sich schnell beantworten: Software ist dann wartbar, wenn der Aufwand für die Pflege
und Weiterentwicklung möglichst gering ist. Daran schließt sich eine weitere interessante
Frage an: Lässt sich Wartbarkeit messen? Die Antwort: Eine direkte Messung ist
kaum möglich, vielmehr kann man aus anderen messbaren Einheiten auf die Qualität
der Software schließen. Denn aus dem Grad der Koppelung, Schichtung und Einhaltung
der Namenskonventionen lässt sich indirekt die Wartbarkeit ableiten. Soweit die Theorie.
Die Praxis gestaltet sich dann oft schwieriger, als man denkt. Ein Beispiel: Beim
Review einer Web-Anwendung im Rahmen einer automatisierten Qualitätskontrolle hat
es sich herausgestellt, dass die Koppelung zwischen den Modulen sehr gering ist – worauf
man kurzfristig sogar stolz war. Nach einem „manuellen“ Review der Module kam
eine andere Tatsache ans Licht – bedingt dadurch, dass die Software von C-Programmierern
entwickelt wurde: Es waren nur wenige, aber dafür mächtige, monolithische
Klassen vorhanden, die nur wenig miteinander kommunizierten. Folglich waren die
Kohäsion sehr hoch, die Koppelung sehr lose und die Software letztlich unwartbar.

In der Praxis lässt sich die Wartbarkeit auch mit anderen, einfacheren Indikatoren bestimmen:
nach dem Aufwand, der für die Einarbeitung von neuen Entwicklern erforderlich
ist. Je klarer, ordentlicher, durchgängiger und offensichtlicher die Struktur der Software,
desto weniger Zeit benötigt ein Entwickler, bis er einen eigenen produktiven
Einsatz leisten kann. Anwendungen werden von der „Entwicklung“ oft an den Betreiberübergeben. Somit wird Software von unterschiedlichen Personenkreisen entwickelt und
gepflegt. Insbesondere in diesem Fall zahlen sich Mehraufwände für die Strukturierung
und mögliche Refactorings ziemlich schnell aus.

Dipl.-Inf. Adam Bien arbeitet als freiberuflicher Berater und Dozent im Enterprise-Java-Bereich. Seine praktische Erfahrung stammt aus seiner Mitarbeit an vielen Java- und J2EE-Projekten, bei denen er als Enterprise-Architekt und Softwareentwickler tätig ist.
Geschrieben von
Adam Bien
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.