Suche
Architektur | Nutzen von Softwarearchitektur

Architektur sollte man vermeiden

Niklas Schlimm
©Shutterstock/alphaspirit

Ganz auf Softwarearchitektur zu verzichten, kann zum Problem werden. Das liegt daran, dass die Auswirkungen von „schlechter Architektur“ beträchtlich sein können. Es ist trotzdem immer wieder notwendig, über den Stellenwert von Architekturarbeit zu diskutieren. Und das ist auch nachvollziehbar, denn im echten Leben verdichten sich beim Architekten alle Probleme der Softwareentwicklung. Immer wenn was richtig schief geht, dann ist es auf die Softwarearchitektur zurückzuführen. Meistens sind erfahrene Architekten auch noch die mit Abstand teuersten Berater am Markt. Also lohnt es sich, das Geld in die Hand zu nehmen? Die kurze Antwort lautet: ja, aber man sollte es vermeiden.

Die Frage, ob Architektur wirklich wichtig ist, kann man auf unterschiedliche Art und Weise beantworten. Ich stelle im Folgenden vier unterschiedliche Argumentationslinien vor. Zunächst erfolgt eine kurze Betrachtung, wie sich Softwareentwicklung über die Jahre verändert hat. Das vermittelt ein gutes Gefühl dafür, ob und wann Softwarearchitektur wirklich wichtig ist. Auf Basis einer Fallstudie wird danach beschrieben, welche Ursachen und Folgen Architekturprobleme haben können. Dann drehen wir den Spieß um, denn Softwarearchitektur ist nicht nur eine gute Strategie zur Problemvermeidung. Es wird beschrieben, wie durch den Einsatz von Frameworks konkrete betriebswirtschaftliche Potenziale entstehen. Zuletzt beschreibe ich, warum Architektur für die Wettbewerbsfähigkeit des Unternehmens von zentraler Bedeutung ist.

Architektur eines Softwaresystems

In der Literatur gibt es viele Definitionen zum Begriff Architektur eines Softwaresystems. In [1] wird Architektur wie folgt definiert: „The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.” Diese Definition ist nur teilweise zufriedenstellend. Sie weist auf den Strukturaspekt von Architektur hin, sowie darauf, dass die Strukturelemente in Beziehung stehen. Es geht hier um das Ergebnis von Architekturarbeit. Wenig intuitiv ist jedoch der dargestellte Hinweis auf die „extern sichtbaren Eigenschaften“. Es ist schwierig, bei einem imaginären Produkt wie Software von extern sichtbaren Eigenschaften zu sprechen. Alles, was einem Laien dazu einfällt, ist allenfalls die Benutzeroberfläche. Des Weiteren fehlt der Bezug zur Umgebung, zu den Stakeholdern, die ja die wichtigen architekturrelevanten Anforderungen an die Architektur definieren. Deswegen wird folgende Definition aus [2] ergänzt: „The architecture of a system constitutes what is essential about that system considered in relation to its environment.” Über diese Definition wird der wichtige Aspekt ergänzt, dass es sich bei Architektur immer um die wirklich essenziellen Systemaspekte handelt. Ob was essenziell ist, ergibt sich aus der Beziehung zur Umwelt. Zum Beispiel daraus, welche Erwartungen die wichtigsten Stakeholder haben. Dieser Aspekt wird auch in [3] betont, wenn es heißt: „Software Architecture = { Elements, Form, Rationale }.“ Architektur entsteht immer aus einem bestimmten Grund („Rationale“). Diese Gründe sind idealerweise die Anforderungen des Kunden.

Wie sich Softwareentwicklung verändert hat

Das Verstehen einer Technik setzt eine Gewisse Grundkenntnis über das Werden des Zu-Verstehenden voraus. Im Laufe der Zeit haben sich die Problemstellungen in der Softwareentwicklung seit Beginn der 50er Jahre erheblich verändert. Ein Grundverständnis über diese Entwicklung hilft dabei, wirklich fundiert die Notwendigkeit von Softwarearchitektur für den eigenen Kontext zu beurteilen.

Produktfamilien

Dem Thema Produktfamilien [4] kommt im Kontext von Softwarearchitektur ein besonderer Stellenwert zu. Eine Produktfamilie ist – vereinfacht ausgedrückt – eine Menge von Programmen, die gemeinsame Eigenschaften haben. in den 60ern hatte man erst einmal eine Produktversion fertiggestellt. Danach wurde von dieser aus das zweite „Mitglied der Familie“ entwickelt, zum Beispiel dasselbe Betriebssystem für eine andere CPU-Architektur. Das Vorgehen erzeugte hohen Änderungsaufwand von einer Version zur nächsten. Man erkannte, dass es sich auszahlt, gemeinsame Eigenschaften der Familie erst zu erkennen, bevor man ein Programm ganz fertigstellt. Denn auf diese Weise können zuerst die gemeinsamen Entwurfsentscheidungen getroffen werden. Später können dann von einem gemeinsamen Programmstand aus unterschiedliche Versionen von ausführbaren Systemen erstellt werden.

Ein typisches Beispiel einer Produktfamilie ist ein Betriebssystem, das für unterschiedliche CPU-Architekturen entwickelt wird. Hier trifft man typischerweise sofort die Entscheidung, das die systemnahen Anweisungen in eine „untere Schicht“ gekapselt werden. Auf dieser Schicht bauen dann die höheren benutzernahen Schichten und Dienste auf. Unterschiedliche CPU-Architekturen führen dann Idealerweise nur zu neuen Versionen, die sich höchstens in den maschinennahen Schichten unterscheiden. Die benutzernahen Schichten der Familie sind jedoch die gleichen in allen Versionen. Solche abstrakten Entscheidungen kommen dem, was wir heute unter einer Architekturentscheidung verstehen, sehr nahe. Denn auch hier müssen wir gemeinsame Eigenschaften (von Modulen, Klassen, Anwendungen) erkennen und darauf aufbauend bestimmte Entwurfsentscheidungen früh treffen. Diese Entscheidungen haben dann für das gesamte System bindenden Charakter und deren Rückabwicklung verursacht extrem hohe Kosten.

Zusammenfassend würde ich aus der historischen Betrachtung [5] [6] [7] folgende Aspekte auflisten, die die Bedeutung von Softwarearchitektur begründeten bzw. erhöhten:

  • Software wurde im Laufe der Zeit viel größer, das erforderte immer mehr Abstraktion, um das gesamte System noch zu verstehen.
  • Aufgrund der Größe musste die Arbeit auf mehrere Entwickler aufgeteilt und Software in Files und Module zerlegt werden.
  • Die Verteilung von Software auf mehrere Systeme erfordert die Integration eben dieser Systeme zur Durchführung der Aufgabensynthese.
  • Die an der Erstellung von Software beteiligten Personen vertreten unterschiedliche Interessen.
  • Die Auswahl an Lösungsalternativen ist durch das Internet und Open-Source-Software deutlich größer geworden.
  • Die offenen Architekturen aus der Open-Source-Gemeinde sind eine gute Alternative gegenüber den vorgefertigten Architekturen der etablierten Anbieter.
  • Software sollte für Produktfamilien entwickelt werden, das heißt auf verschiedenen Endgeräten ausführbar sein. Parallel stieg diese Heterogenität der Endgeräte.

Diese Faktoren haben dazu geführt, dass Softwarebau heutzutage besonders komplex ist. Die Komplexität ergibt sich einerseits durch die schiere Größe der Software bzw. des zu lösenden Problems und andererseits durch die Auswahlmenge an Alternativen und Einflussfaktoren bei Architekturentscheidungen. Softwarearchitektur ist eine junge Disziplin, die diese Komplexität reduzieren soll.

Fallstudie: Ursachen und Auswirkungen von Architekturproblemen

Softwaresysteme sind groß und komplex. Kein Wunder also, dass bei der Entwicklung Probleme auftreten. Welche das auf Architekturebene sind, verdeutlicht folgende Fallstudie. Ein internationaler Automobilkonzern baut ein neues Produktsystem, um Autos an weltweit verteilten Standorten zu entwickeln. Mit dem Kunden werden folgende nicht funktionale Anforderungen besprochen:

  1. Das neue System soll bei 90 Prozent der Benutzertransaktionen eine Antwortzeit von unter zwei Sekunden haben.
  2. Das System soll es ermöglichen, innerhalb von vier Wochen neue Produktkonfigurationen einzuführen.
  3. Das System soll über diverse Endgeräte zugänglich sein, die gegenwärtig und in absehbarer Zukunft am Markt erhältlich sind.
  4. Bestehende PL/1-Geschäftslogik auf dem Großrechner soll möglichst wiederverwendet werden.
  5. Ein hoher Funktionsumfang des Systems zum festgelegten Einführungstermin ist wichtiger als eine hohe Ressourceneffizienz.

Abb. 1: Architektur eines Produktsystems in der Automobilbranche

Die konzeptuelle Architektur ist in Abbildung 1 dargestellt. Beim Entwurf wurde berücksichtigt, dass das System besonders gut änderbar sein muss. Das System wurde dazu „regelbasiert“ entworfen. Auf diese Weise können Ingenieure eigenständig umfangreiche Funktionsanpassungen über einen Regeldefinitionsrechner vornehmen. Um eine große Anzahl unterschiedlicher Endgeräte zu unterstützen, hatte der Kunde sich für eine konventionelle Weboberfläche entschieden. Durch die gewählte Technologie wird ein Web Application Server als Middleware zwischen Endbenutzerclient und Großrechner notwendig. Es wird sich für einen Java EE Server entschieden. Java ist eine weit entwickelte Sprache und offene Plattform mit sehr großer Verbreitung, hohem Funktionsumfang und die Programme sind auf unterschiedlichsten Computersystemen ausführbar.

Herausfordernd sind nun die Performanzanforderungen sowie die Wiederverwendung bestehender Geschäftslogik in PL/1. Zur Wiederverwendung der Geschäftslogik bestehen grundsätzlich zwei Alternativen:

  1. Die neue Geschäftslogik für das Bestandssystem wird in Java entwickelt und es erfolgt eine Anbindung der bestehenden PL/1-Programme.
  2. Es werden auch die neuen Programmteile in PL/1 auf dem Großrechner entwickelt.

Wenn die neuen Programmteile in Java entwickelt werden würden, befürchtet man viele Fernzugriffe pro Benutzertransaktion auf den Großrechner. Um die Anforderungen an die Antwortzeiten zu erfüllen, soll die Wartezeit durch Netzwerkkommunikation jedoch minimiert werden. Es wird sich daher für PL/1 auf dem Großrechner entschieden. Des Weiteren wird der Großrechner auch als Laufzeitumgebung für die Regelmaschine bestimmt. In Summe entsteht so die geringste Wartezeit zwischen den fachlich eng verzahnten Komponenten.

Das Ergebnis der Überlegungen ist eine klassische Drei-Schichten-Architektur bestehend aus HTML-basierter Oberfläche im Browser, Oberflächenlogik in Java auf dem JEE Application Server und der Geschäftslogik in PL/1 auf dem Großrechner als Backend-System. Das System erfüllt in Produktion alle oben aufgeführten Anforderungen. Es gibt aber trotzdem einige Probleme, deren Ausmaß leider erst nach Produktionseinführung erkannt wird.

Es kommt zu einem sehr hohen CPU-Verbrauch, wodurch der Betrieb der anderen Anwendungen auf dem Großrechner gefährdet wird. Es ist sehr kostspielig, die CPU-Ressourcen auf dem Großrechner zu erhöhen. Der Zukauf von CPU und Speicher soll das Problem also alleine nicht lösen. Bei der Regelmaschine handelt es sich um generierten Programmcode in ANSI C. Dieser kann daher auch für eine günstige dezentrale Windows-Plattform kompiliert und dorthin ausgelagert werden. Die neu entwickelten PL/1-Programme müssen auf dem Großrechner verbleiben und unter hohem Aufwand optimiert werden. Die Auswirkungen dieser Maßnahmen sind:

  1. Durch die Softwareverteilung entsteht jetzt mehr Netzwerkkommunikation und dies führt zu dauerhaft höheren Antwortzeiten.
  2. Für Hardwarezukauf sowie für die Performanceoptimierung muss der Kunde noch mal einen sechsstelligen Betrag aufwenden.
  3. Das System wird auf Dauer zu einer geringeren „Verarbeitungsgeschwindigkeit“ im Fachbereich führen. Die geplante Prozessoptimierung kann nur teilweise erreicht werden.

Das zeigt, dass etwas Essenzielles schief gelaufen war. Aber was? Alle formulierten Anforderungen wurden korrekt erfüllt. Daher müsste man dies bezüglich von einem Erfolg sprechen, das System arbeitet wie spezifiziert. Leider wurden die bestehenden Anforderungen an den Ressourcenverbrauch jedoch nicht formuliert. Dadurch hat das Team beim Entwurf des Systems maßgeblich auf Antwortzeiten, Wiederverwendung und Änderbarkeit des Programms geachtet. Bei der Auswahl der Lösungen sind ebenfalls Fehler unterlaufen. Gut änderbare Programme, wie regelbasierte Systeme, stehen grundsätzlich unter dem Verdacht, nicht besonders ressourceneffizient zu sein. Daher hätte dafür möglicherweise eine günstigere Plattform von vornherein als Lösungsalternative betrachtet werden müssen. Auf dieser hätte man den hohen Ressourcenverbrauch wahrscheinlich durch Zukauf von Hardware verkraften können. Unter diesen Umständen hätten die neuen Programmteile möglicherweise doch komplett in Java gebaut werden können. Denn dann hätte die neue Geschäftslogik und die Regelmaschine zusammen im JEE Application Server lokal deployt werden können. Auf diese Weise hätte man Hardwarekosten sparen können und die Antwortzeiten hätten sich verbessert.

Die Fallstudie hat (stark vereinfacht) in den Entscheidungsprozess auf Architekturebene eingeführt, und hat verdeutlicht, wie sich Architekturentscheidungen auf den Projekterfolg auswirken. Es geht um Entscheidungen über essenzielle Eigenschaften des Systems. Wenn diese Entscheidungen falsch getroffen werden, kommt es zu schwerwiegenden Auswirkungen. Das liegt daran, dass die Korrektur- und Folgekosten falsch getroffener Architekturentscheidungen hoch sind. Gleichzeitig werden die Entscheidungen auf Basis unvollständiger Informationen getroffen. Daher sind sie mit einer hohen Unsicherheit versehen. In der Fallstudie wurde der zu erwartende CPU-Verbrauch zum Beispiel nicht in die Entwurfsentscheidungen miteinbezogen.

Es ist unmöglich, jedes Problem während der Entwicklung oder nach der Produktionseinführung vorherzusehen. Das bedeutet ferner, dass nicht alle Entwurfsentscheidungen auch als architrekturrelevant eingestuft und wirklich bewusst getroffen werden. In der Fallstudie ist man aufgrund der gewählten Programmiersprache PL/1 erstmal an den Großrechner gebunden. Als man spät erkannt hat, dass die Anwendung sehr CPU-intensiv ist, wurde das zum Problem. Die Aufrüstung der Hardware ist nämlich mit dauerhaften Folgekosten verbunden, da auf CPU-Verbrauchsbasis abgerechnet wird. Solche „Sackgassenszenarien“ vorherzusehen kostet Zeit und erfordert viel Erfahrung im Bereich Architektur. Alle möglichen Szenarien vorherzusagen ist unmöglich. Das ist das Dilemma, in dem wir alle stecken und der Hauptgrund, warum man Architektur vermeiden sollte. Aber darauf gehe ich später noch mal ein.

[ header = Potenziale durch frameworkbasierte Produktfamilien ]

Potenziale durch frameworkbasierte Produktfamilien

Zuvor haben wir Softwarearchitektur sozusagen als Zwangsdisziplin vorgestellt, die man machen muss, weil es sonst erhebliche Probleme gibt. Jetzt drehen wir den Spieß einmal um und sagen: es gibt betriebswirtschaftliche Vorteile durch Softwarearchitektur! Als konkretes Beispiel gehe ich im Folgenden auf den Aufbau von Produktfamilien auf Basis zentral entwickelter Frameworks ein.

Viele Unternehmen betreiben mehr als fünfzig verschiedene Java-EE-Anwendungen. Für solche Szenarien ist es sehr ratsam, die einzelnen Geschäftsanwendungen auf einem zentral entwickelten Framework aufzubauen. Alle Anwendungen sind auf diese Weise Mitglied einer Produktfamilie, sie ähneln sich also in weiten Teilen. Abbildung 2 zeigt ein praxisnahes Architekturbeispiel für eine Produktfamilie Java-basierter Geschäftsanwendungen. Jede Geschäftsanwendung arbeitet auf Basis unterschiedlicher Frameworks. Die Nutzung von Java EE und Spring in einer Anwendung wird besonders von den jeweiligen Religionsvertretern kontrovers diskutiert. Sie ergibt sich jedoch ganz natürlich aufgrund der Evolution, der nicht funktionalen Anforderungen sowie der organisatorischen Gegebenheiten in großen Unternehmen. Das hauseigene Framework bietet Funktionen, die keiner der Standards unterstützt. Durch den Frameworkeinsatz können viele Basisdienste zentral an einer Stelle implementiert werden.

Abb. 2: Produktfamilie auf Basis von Java-Frameworks

Abbildung 3 zeigt wichtige Basisdienste, die in einer konkreten Kundensituation umgesetzt werden sollten. Diese Themen sollten dann für alle Mitglieder der Familie am besten einmal gelöst werden. Durch den Einsatz von Produktfamilien wurde vermieden, dass die Themen immer wieder neu entwickelt werden. Stattdessen werden sie einmal im Framework bereitgestellt. Ein neues Mitglied einer Produktfamilie ergibt sich nun durch die Portierung einer Geschäftsanwendung auf eine neue Plattform (Standardsystem-Produktfamilie). Oder es wird auf derselben Plattform eine neue Geschäftsanwendung mit dem Framework entwickelt (Standardplattform-Produktfamilie). Durch die Gründung einer solchen Produktfamilie entsteht ein ganz entscheidender wirtschaftlicher Vorteil, der nur erzielt werden kann, wenn die Softwarearchitektur entsprechend entworfen und im Unternehmen durchgesetzt wurde.

. 3: Technische Basisdienste einer konkreten Produktfamilie

Die hohe Governance durch die Gründung von Produktfamilien hat weitere nennenswerte Vorteile, die nicht unbedingt direkt „auf der Hand“ liegen. Betrachten wir zum Beispiel die Automatisierung des Deployment-Verfahrens. Hier stellen sich die Gesamtkosten für die Automatisierung KG als Funktion über den Kosten der Automatisierungsmaßnahme KE und der Anzahl unterschiedlicher Anwendungen n dar: KG = KE * n. Anwendungen sind unterschiedlich, wenn sie verschiedene Deployment-Spezifikationen aufweisen. Durch ein einheitliches Framework ist die Konfiguration für eine Zielumgebung immer gleich. Das bedeutet: n = 1. So sind die Automatisierungskosten sehr gering und es kann ausgehend vom Kundenauftrag an die IT bis zum Release in die Test- oder Produktionsumgebung eine umfangreiche Automatisierung stattfinden.

Zusammenfassend lässt sich festhalten, dass Softwarearchitektur gezielt zur Realisierung betriebswirtschaftlicher Potenziale eingesetzt werden kann. Denn durch Produktfamilien werden Erstellungs- und Wartungskosten von Software deutlich reduziert. Das wird ermöglicht, indem die Implementierung von Basisdiensten an zentraler Stelle erfolgt, anstatt in jeder einzelnen Fachanwendung.

Geschäft und Architektur beeinflussen sich gegenseitig

Jetzt spannen wir den Bogen zum Schluss noch etwas weiter. „Strategische“ Architekturentscheidungen sind solche, die sich nicht nur auf eine Anwendung, sondern auf das gesamte Unternehmen beziehen. Sie überdauern viele Jahre, weil deren Rückabwicklung erhebliche Kosten mit sich bringen würde. PL/1 auf dem Großrechner wurde z. B. vor vierzig Jahren in viele Unternehmen eingeführt und diese Unternehmen haben heute 15 Millionen Zeilen PL/1-Code im Bestand. Eine einfache Migration in moderne Java-Umgebungen ist aus wirtschaftlichen Gründen unmöglich. Andererseits drängt der Markt die Unternehmen dazu, modernere Technologien zu verwenden. Die jüngeren Kollegen wollen nicht mit „verstaubten“ Technologien des letzten Jahrhunderts arbeiten. Im Ergebnis müssen moderne Systeme nun mit dem Bestand an Geschäftslogik in Altsystemen integriert werden. Wir finden heute mehr oder weniger heterogene Systemlandschaften vor.

Die Geschäftsprozesse des Fachbereichs sind mit der Systemlandschaft des Unternehmens eng verzahnt. Aktivitäten werden vollautomatisiert ausgeführt, oder es wird eine Benutzeroberfläche bereitgestellt, um teilautomatisierte Tätigkeiten im Rahmen einer Mensch-Maschine-Kommunikation abzuwickeln. Mensch und Maschine sind beide Aufgabenträger (Hardware) im Geschäftsprozess. Das menschliche Gehirn und die entwickelte Software enthalten die Programme zur kooperativen Aufgabendurchführung. Unternehmen entwickeln neue Produkte und optimieren Geschäftsprozesse, um dem Kostendruck mit immer höherer Produktivität zu begegnen. Solche Veränderungen haben direkte Auswirkungen auf alle Aufgabenträger. Während sich das menschliche Gehirn verhältnismäßig schnell autonom umstellen kann, bedeutet die Änderung der Software hohen Aufwand. Dieser muss nun bei der Entscheidungsfindung mit berücksichtigt werden. Wir sind, wie man so schön sagt, normalerweise nicht mehr „auf der grünen Wiese“, wenn wir neue IT Projekte planen und umsetzen.

Es bestehen also Abhängigkeiten zwischen Geschäftsprozessen des Fachbereichs und komplexer Systemlandschaft. Deswegen nehmen einmal getroffene Architekturentscheidungen erheblichen Einfluss auf die Fähigkeit eines Unternehmens, auf geänderte Geschäftsstrategien und Wettbewerbsbedingungen zu reagieren. Sie bestimmen maßgeblich das Kosten-Nutzen-Verhältnis von zukünftigen Initiativen und zeigen Grenzen bezüglich der Machbarkeit von Produkt- und Prozessinnovationen auf (Abb. 4). Damit wirken sich Architekturentscheidungen nicht nur auf den Projekterfolg aus, sie betreffen unter Umständen den Erfolg des gesamten Unternehmens. Dieser Gedankengang führt das Thema Architektur auf eine Ebene von strategischer Bedeutung für den langfristigen Erfolg des Unternehmens.

Abb. 4: Wechselwirkungen zwischen Softwarearchitektur und Geschäft

Architektur vermeiden ist sinnvoll

Nachdem was ich bisher zusammengetragen habe, machen der Titel des Artikels und diese Aussage vielleicht keinen Sinn. Doch in den letzten Kapiteln sollte auch folgender zentraler Aspekt klar geworden sein: Architekturentscheidungen werden unter Unsicherheit getroffen und sind nur schlecht wieder rückgängig zu machen. Gleichzeitig nehmen sie erheblichen Einfluss auf den Erfolg des Projekts oder des Unternehmens. Wir haben auch gelernt, dass Architekturentscheidungen besonders komplex sind. Es wäre unter all diesen Umständen ungünstig, besonders viele solcher Entscheidungen treffen zu müssen. Eine mögliche Lösung ist, Architekturentscheidungen zu vermeiden.

Aber wie soll das gehen? Martin Fowler hat in seinem Artikel „Who needs an Architect?“ [8] angemerkt: „I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs. “ Wenn man seine Entscheidungen problemlos ändern kann, dann ist es auf einmal weniger wichtig, sie richtig zu treffen. Daraus folgt, dass Softwareentwürfe modifizierbar sein sollten. Hiermit ist nicht gemeint, dass sie abstrakt sein sollen, sodass niemand mehr den Code versteht. Vielmehr geht es darum, an Stellen, an denen Änderungen schon absehbar sind, auch Änderungen einzuplanen. Der Einsatz von JDBC als Abstraktionsebene zwischen Geschäftslogik und Datenbank macht zum Beispiel das Datenbanksystem weitgehend frei austauschbar. Der Einsatz von Web Services ermöglicht es, ganz verschiedene Technologien an der Benutzeroberfläche zu unterstützen. IOC Container ermöglichen es, ein objektorientiertes System ganz unterschiedlich zu konfigurieren und flexibel auf geänderte Bedürfnisse anzupassen. Das alles sind Beispiele, wie eigentlich essenzielle Eigenschaften eines Systems auf Dauer änderbar bleiben. An der Stelle darf nicht verschwiegen werden, dass solcher Luxus natürlich auch etwas kostet: CPU-Ressourcen.

Ein weiteres probates Mittel, Architekturentscheidungen zu vermeiden, ist, wenn man sich auf geschlossene Baukastenarchitekturen der großen Anbieter reduziert. Von Microsoft, IBM oder Oracle kann man das komplette Programm einkaufen und das wird auch funktionieren. Allerdings hat man so nur Auswahlentscheidungen reduziert. Die liegen nun im Bauchladen des Anbieters vor. Übrig bleibt immer noch der Bau der Anwendungen, die fachliche Architektur des Systems. Dieses muss zerlegt werden, damit mehrere Programmierer daran arbeiten können. Bei dieser Alternative entscheidet sich der Kunde bewusst, einen Teil der Architekturentscheidungen abzugeben und deren Lösung einzukaufen. Daraus ergeben sich manchmal unerwünschte Abhängigkeiten zum Lieferanten und es kann auch im Vergleich zu offenen Architekturen ziemlich teuer werden.

Aus der XP-Gemeinde kommt die kontrovers diskutierte Forderung kein, „Big Design Up Front“ zu machen. Darunter wird eine zu lange Analysephase ohne Kodierung verstanden. Die Betonung liegt hier auf dem „Big“ und nicht auf dem „Up Front“. Das Problem einer langen Analysephase ohne Programmierung liegt darin, dass es unmöglich ist, alle Probleme vorherzusehen, die sich während der Entwicklung ergeben. Außerdem ändern sich die Anforderungen laufend. Also direkt losprogrammieren? Das geht leider auch nicht, denn leider müssen einige essenzielle Eigenschaften des Systems entschieden werden, bevor programmiert wird: die Programmiersprache, die Laufzeitumgebung, wenigstens ein paar fachliche Anwendungsfälle und einiges mehr. Die modernen Vorgehensweisen zur Architekturentwicklung versuchen deswegen die goldene Mitte zu finden und schlagen vor, ein „Skeletal System“ [1] zu entwickeln oder „Experimente“ [9] durchzuführen, um Unsicherheiten zu reduzieren. In Feature-driven Development wird erst ein Gesamtmodell des Systems erstellt [10]. Die Zeitspanne zwischen dem Projektstart und dem Beginn der Programmiertätigkeit wird in allen Fällen kurz gehalten. Denn im Rahmen der Programmiertätigkeit können Unsicherheiten reduziert werden, bevor man eine endgültige Entscheidung trifft.

Zuletzt möchte ich noch auf eine vielleicht triviale Erkenntnis hinweisen, die man nicht oft genug wiederholen kann: ein System sollte unbedingt in Anlehnung an seine konkreten Anforderungen entwickelt werden. Systeme, deren tatsächliche Lebenszeit kurz ist, müssen nicht wartbar sein. Onlineanwendungen brauchen in der Regel nicht dieselbe Performance wie Batch-Anwendungen. Systeme, die nicht portiert werden sollen, müssen natürlich nicht plattformunabhängig sein. Es ist sehr ratsam, sich die Anforderungen an die Architektur des Systems genau zu betrachten, um jegliches „Over-Engineering“ tunlichst zu vermeiden. Auch dadurch wird die Anzahl von Architekturentscheidungen erheblich reduziert. In dem die Menge relevanter Architekturtreiber auf ein Minimum herabgesetzt wird.

Fazit

Durch Softwarearchitektur soll Komplexität reduziert werden. Das funktioniert, indem Informationen verständlich aufbereitet und Auswahlentscheidungen methodisch fundiert getroffen werden. Es lassen sich durch Architekturarbeit Folge- und Korrekturkosten im Rahmen der Neuentwicklung und Wartung minimieren. Durch gezielten Einsatz von Architektur, zum Beispiel durch Produktfamilien, lassen sich auch konkrete Einsparpotenziale realisieren. Gut getroffene Architekturentscheidungen erhöhen zudem die Flexibilität eines Unternehmens, auf geänderte Umweltbedingungen zu reagieren. Aus diesen Gründen ist Architektur notwendig und definitiv wichtig.

Problematisch stellt sich dar, dass Architekturentscheidungen in der Regel auf Basis unsicherer Information getroffen werden müssen. Sie betreffen gleichzeitig essenzielle Eigenschaften des Systems. Dadurch können sie später schlecht rückgängig gemacht werden. Eine Lösung dieses Problems liegt darin, den Entwurf des Systems so zu gestalten, dass es an den essenziellen Stellen veränderbar bleibt. Dadurch wird die Irreversibilität so mancher Entscheidung aufgehoben. Die Eigenschaften, die zuvor essenziell und daher architekturrelevant waren, sind es jetzt nicht mehr. Es geht sprichwörtlich darum, sich möglichst viele Türen offen zu halten, falls eine Veränderung ansteht. Architektur vermeiden bedeutet Irreversibilität aufheben. Sehr hilfreich ist es auch, wenn man ein System entlang seiner Anforderungen baut, also nur die Architekturtreiber berücksichtigt, die tatsächlich relevant sind. Unsicherheiten können durch frühe Programmierung reduziert werden. Wem das alles immer noch zu kompliziert ist, der geht einfach einkaufen bei einem der großen Anbieter von geschlossenen Baukastenarchitekturen. Das ist aber nicht so spannend, und entspricht auch so gar nicht unserem „Freigeist“: Java ist nun mal eine offene Architektur, ein schöner bunter Blumenstrauß. Mischkultur und keine Monokultur.

Aufmacherbild: sketch of an architect von Shutterstock / Urheberrecht: alphaspirit

Geschrieben von
Niklas Schlimm
Niklas Schlimm
Niklas Schlimm ist Leiter des Architekturteams der Provinzial Rheinland Versicherung AG. Er arbeitet als Architekt seit fünfzehn Jahren in EDV-Projekten im Java-Umfeld, meist mit Großrechneranbindung. In diesen Jahren war er in unterschiedlichen Beratungshäusern und Versicherungsunternehmen tätig. Die Provinzial Rheinland gehört zu den führenden deutschen Versicherungsunternehmen und ist Marktführer in ihrem Geschäftsgebiet.
Kommentare

Schreibe einen Kommentar

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