Welcome to ovogel.de

Featured

Architecture is my passion. Since my early days as a software developer, I have been appreciating the great value a good architecture brings to any system be it a single IT system, a system of IT systems or an overall enterprise.

One of the important things I have learned during my carrer is that any system has an architecture. Some have planned and others have accidental architectures. Depending on the criticality of the system, bad architectures can have severe impacts on the overall value a system can deliver. The key is to balance all architectural forces in order to establish a fit for purpose architecture, which is not overengineered, addresses the current needs while at the same time is open to embrace future changes.

Nowadays I work on various engagements as an IT and Enterprise Architect, defining, implementing, and governing architectures of different kinds ranging from IT solution to overall enterprise architectures. In addition, I am an active author, presenter, and lecturer about architecture conveying the value of architecture and contributing to the further enhancement of this discipline. Some of the things I have been doing around this subject, can be found on this web site. Enjoy exploring!

Feel free to follow me or get in touch with me via following channels:
LinkedIn, Xing, Twitter

Architektonisches Denken in der Praxis

Abstrakt

  • Architektur beeinflusst Stabilität, Flexibilität und Erweiterbarkeit des Entwurfs, des Programmcodes und der Softwaretests.
  • Zielführende Architekturen machen Systeme anschaulich, verstehbar und reduzieren Komplexität.
  • Eingebettet in einen Softwareentwicklungsprozess wird Architektur „gelebt“ und führt zu Motivation aller Beteiligten .
  •  „Architektonisches Denken“ durchdringt alle Aktivitäten bei der Erstellung von Software und verbessert die Qualität.
  • Um moderne Software-Infrastrukturen wie J2EE oder .NET richtig verstehen und anwenden zu können ist „Architektonisches Denken“ erforderlich.

Einleitung

Der erfolgreiche Entwurf von Software-Architekturen ist aufgrund der inhärenten Komplexität von Software-Systemen kein leichtes Unterfangen. Software-Architekturen müssen heutzutage übliche nicht-funktionale Anforderungen wie Verteilbarkeit, Verfügbarkeit, hohe Integrierbarkeit etc. würdigen und darüber hinaus eine Basis zur Realisierung funktionaler Anforderungen bieten. Somit stehen sie also vor der Herausforderung, unterschiedlichste, architektonische Einflussfaktoren, wie funktionale, qualitative und operationale Aspekte zu berücksichtigen und für die konkrete Problemstellung ausreichend zu balancieren. Um diese Aufgabe zielgerichtet und systematisch zu verfolgen, bedarf es eines architektonischen Vorgehensmodells. Im Rahmen dieses Modells liegt das Hauptaugenmerk auf dem kognitiven Prozess, dem sogenannten architektonischen Denken, zur Definition einer Architektur. Architektur beinhaltet alle Festlegungen und Vereinbarungen, die zwar durch die fachlichen Anforderungen angestossen worden sind, sie aber nicht direkt umsetzen. Eine Architektur macht Komplexität handhabbar. Sie behandelt nur die wesentlichen Teile eines Systems und ermöglicht so, es in 5 Minuten während einer Aufzugfahrt zu erklären.

Blendwerk

Sehr häufig kann man beobachten, daß in Projekten der Begriff „Architektur“ missbraucht wird. Anstelle einer Architektur tritt eine Marketing-Architektur11, die einem Manager (dem „Architekten“) als Verkaufsvehikel dient. Solche Pseudo-Architekturen enthalten keinen nennenswerten technischen „Nährwert“, d.h. sie bringen dem System keine technischen Vorteile und werden darüber hinaus von den Entwicklern auch nicht beachtet. Diese Art von Architekturen manifestieren sich meist in Form von Präsentationsfolien mit Diagrammen, die kaum eine der untengenannten technischen Informationen beinhalten.

Definition

Im Web findet man zahlreiche (92!) Definitionen. Offensichtlich gibt es durchaus Schwierigkeiten, dieses Thema exakt abzugrenzen. Nicht umstritten und in unserem Zusammenhang wichtig legt eine Software-Architektur (Architektur) fest:

  • Aus welchen logische und physikalischen Bausteinen (Schichten, Komponenten, Subsysteme, Schlüsselklassen etc.) ein System aufgebaut wird
  • Wie diese Bausteine in Beziehung stehen und miteinander kommunizieren
  • Welche Verantwortlichkeiten die Bausteine dabei haben
  • Welche Schnittstellen die Bausteine besitzen
  • Wie die Bausteine gruppiert bzw. geschichtet sind
  • Nach welchen Festlegungen und Kriterien ein System in Bausteine aufgeteilt wird

Eine tragfähige Architektur bürgt für:

  • Einfache Fehlerbeseitigung: Durch Kohäsion und schwache Kopplung können Fehlerbehebungen weitgehend lokal erfolgen
  • Gute Änderbarkeit und Wartbarkeit: Es werden keine unnötige und zu frühe Festlegungen getroffen, die die realen Wandlungen des System verkomplizieren
  • Geringen Testaufwand: Die Möglichkeiten von automatisierten, wiederholbaren Tests werden von Anfang an berücksichtigt

Schichtverwerfungen

Architektur ist das Fundament für die Anforderungen an ein Software-System (System). Investitionen in solche Systeme rechnen sich langfristig wirtschaftlich, wenn sie auf stabilen und zweckdienlichen Architekturen aufgebaut werden. Es gilt, fundamentale (bis hin zu „tödlichen“) Risiken konstruktiv zu umgehen.

Die Anforderungen, die vom Kunden bzw. Nutzer des Systems formuliert werden, sind architektonisch betrachtet unstrukturiert. Wenn nun diese vorliegenden funktionalen Anforderungen direkt in einen detailierten Entwurf gegossen und implementiert werden, besteht das Risiko, ein monolithisches („Stovepipe“) System zu kommen. Einem solchen System liegt eine Architektur zugrunde, die einem „Big Ball of Mud“  entspricht und die den qualitativen Anforderungen auf Dauer nicht gerecht wird. Zu einer anderen schwer bis gar nicht zu handhabenden Entwicklung kann es kommen, wenn im Projektverlauf neue fachliche oder technische Anforderungen bekannt werden, denen die Architektur nicht gewachsen ist. Solche fundamentalen Risiken können unabsehbar große Aufwände bis hin zur kompletten Neuentwicklung notwendig machen oder das ganze Projekt in Frage stellen.

Adhoc-Architektur

Die Strukturierung, welche durch eine Architektur erreicht wird, ist sowohl statisch wie auch dynamisch und erlaubt es je nach aktueller Entwicklungsphase verschiedene Sichten (logisch, physikalisch etc.) auf die Architektur eines Systems einzunehmen. Verschiedene Sichten sind notwendig weil Architekturen ganz unterschiedliche Aspekte eines Systems beinhalten und für bestimmte Arbeitsschritte nur bestimmte dieser Aspekte relevant sind und es unhandlich wäre immer sämtliche dieser Aspekte gleichzeitig vor Augen haben zu müssen.

Mit dem Reference Model for Open Distributed Processing (RM-ODP) gibt es einen internationalen Standard in Form eines generischen Referenzmodells, daß beschreibt, was Architektur ist. Dieses Model definiert unter anderem die notwendigen Sichten einer Architektur. Eine Ausprägung von RM-ODP, die sich bewährt hat, ist die sog. 4+1 Sicht10 aus dem Rational Unified process (RUP) . Es gibt keine Reihenfolge, in der die Sichten entstehen. Die Sichten werden weitgehend parallel entwickelt.

4-1-Sicht

Architektonisches Denken ist komplex. Psychologische Untersuchungen belegen, dass Menschen 7+-2 Informationseinheiten gleichzeitig verarbeiten können. Ausgedrückt in Informationseinheiten übersteigen i.d.R. alle Aspekte einer Software-Architektur diese Kennzahl um ein Vielfaches. Zur Reduktion der gleichzeitig zu betrachtenden Aspekte hat sich die Konzentration auf unterschiedliche Sichten und die iterative Elaboration der Software-Architektur bewährt. Die Verwendung unterschiedlicher Sichten erlaubt es dem Architekten, sich zu einer Zeit auf eine Problemstellung zu konzentrieren. In ihrer Gesamtheit ergeben die Sichten ein komplementäres Bild des zu realisierenden Software-Systems. Das iterative Vorgehen ermöglicht wiederum die einzelnen Sichten über die Zeit zu verfeinern und gemachte Erfahrungen einfließen zu lassen. Architektonisches Denken kann wie folgt illustriert werden:

Architektonisches Denken

„Der Architektur-Prozess“

Architektur steuert fundamentale Design-Entscheidungen und prägt damit den Rahmen für die jeweils darauffolgenden Iterationen.

Direkt nach der Initiierung des Software-Projekts wirkt das Architektonische Denken auf alle Disziplinien der Softwareentwicklung ein. Bereits beim Ermitteln der fachlichen und qualitativen Anforderungen werden kritische Punkte und technische Risiken herausgearbeitet und die Machbarkeit frühzeitig durch Prototypen (evolutionäres Prototyping), welche die Architektur implementieren, validiert.

durch Prototypen überprüft. In der ersten Iteration entsteht eine grundlegende Architektur. Hierbei fliessen also die architekturprägenden Aspekte in die Architektur-Konzeption ein und führen zu einem Architekturvorschlag mit evolutionärem Charakter. Die fachlichen Anforderungen werden meist in der Form von Anwendungsfällen beschrieben und im Rahmen von Anforderungsanalyse-Workshops identifiziert. Die Herausforderung an den Architekten besteht nun darin, aus der Vielzahl der Anwendungsfälle, die architektonisch relevanten auszuwählen und beim Entwurf der Architektur zu berücksichtigen. Die gewählten Anwendungsfälle sollten Logik auf jeder Architekturschicht bedingen, so dass eine möglichst hohe Durchgängigkeit erreicht wird. Hierdurch wird sichergestellt, dass das Zusammenspiel der unterschiedlichen Schichten der Architektur gewürdigt und möglichst früh reflektiert wird. Schon bald kann die klassische Programmierung Ihre Arbeit aufnehmen. Da die Softwareentwickler vom Architektonischen Denken geprägt sind, werden dabei auftauchende Fragen vor dem Hintergrund der Gesamtarchitektur untersucht und Lösungen gefunden, die die Architektur des gesamten Systems ergänzen und verfeinern 817. Auf diese Weise werden die im Laufe des Projekts sich zunehmend konkretisierenden fachlichlichen Anforderungen zerlegt und in eine systemweite Struktur überführt (siehe <Abbildung „Architektonische Systemsicht“>).

Der dabei treibende architektonische Denkprozess wird mehrfach durchlaufen. Architektonisches Denken verläuft also zwangsläufig in iterativen Bahnen. Nun stellt sich jedoch die Frage, wann dieser Prozess abgeschlossen ist? Der Architektur-Entwurf sollte solange fortgesetzt werden bis die Architektur in einem Zustand ist, die dem Projekt hilft, den nächsten Schritt z.B. den nächsten Anwendungsfall zu implementieren. Diese unter dem Begriff Sufficient-To-Purpose bekannte Best Practice wird hauptsächlich von agilen Entwicklungsmethoden propagiert und hat sich nach unserem Ermessen sehr bewährt. Dieses Prinzip sollte über die einzelnen Iterationen hinweg solange angewandt werden, bis sich die Architektur genügend stabilisiert hat, um die Anforderungen zu tragen. Mit zunehmender Erfahrung wird der Prozess intuitiv ablaufen. Um diesen Zustand zu erreichen, muss man offen sein für Neues und erkannt haben, dass man nie auslernen wird.

Architekonisches Denken umfasst jedoch auch die Würdigung organisatorische Aspekte.

Unsere Erfahrungen zeigen, dass organisatorischen Aspekten häufig viel zu wenig Bedeutung bei der Entwicklung einer Architektur zuteil wird. Dies führt leider oft dazu, dass eine Architektur, obwohl sie funktionale, qualitative und operationale Aspekte entsprechend würdigt, nicht tragfähig ist. Woran liegt das? Melvin Conway formulierte die These, dass Software Architektur vielmehr durch organisatorische Einflüsse als durch technologische Einflüsse geprägt ist. Dieses als Conways Gesetz bekannte Phänomen möchten wir im folgenden näher untersuchen.

Zu den organisatorischen Aspekten zählt als wichtigster Bestandteil das eingesetzte Vorgehensmodell. Ein Architekt ist Mitglied der Organisation und wird in seinem Handeln durch organisatorische Aspekte beeinflusst. Architektonisches Denken ist somit eng verzahnt mit dem eingesetzten Software-Entwicklungsprozess resp. der verwendeten Projekt-Management-Methodik. Ein streng sequentiell ausgelegtes Vorgehensmodell, das keine Iterationen zulässt und die Korrektheit einer Architektur nach dem Abschluss der Konzeptionsphase erwartet, wird in den allermeisten Fällen scheitern, da es nicht möglich ist, alle Gegebenheiten von vorneherein zu berücksichtigen. Trotzdem starten heutzutage noch immer viele Projekte mit einem sequentiellen Vorgehensmodell. In späten Phasen wie Integrations- oder Akzeptanz-Test treten dann häufig Architekturschwächen zutage, die zu massiven Änderungen führen. Das Ruder ist in diesem Fall meist nur durch höchste Anstrengungen des Projektteams herumzureissen. Deshalb ist ein iteratives, inkrementelles Vorgehen zu favorisieren, das es ermöglicht, früh gegenzusteuern und im Projektverlauf gemachte Erfahrungen in der Architektur zu reflektieren. Architektonisches Denken impliziert Lernen. Das hierdurch erlangte Wissen sollte bereits in das laufende und nicht erst in ein Nachfolge-Projekt einfliessen können. Iterative, inkrementelle Vorgehensmodelle erlauben dies. Hierdurch wird auch deutlich, warum eine Software-Architektur als evolutionäres Konstrukt betrachtet werden sollte. Software Architektur lebt über den gesamten Projektverlauf hinweg und entwickelt sich iterativ bis sie sich soweit stabilisiert hat, dass sie die an sie gestellten Anforderungen erfüllt.

Um eine überzeugende und sinnvolle Softwarearchitektur im Projekt zu realisieren, sind alle Beteiligten gefragt. Ein abgestimmtes Vorgehen mit klar umrissenen Aufgaben und Kompetenzen kann das Gegeneinander im Projekt verhindern und trägt erheblich zum gemeinsamen Erfolg bei. Deshalb werden wir im Folgenden die Rollen der im Architekturprozess beteiligten unter die Lupe nehmen.

Rollen im Architekturprozess

Unternehmens- und Projektkultur legen fest, wie Menschen innerhalb einer Organisation miteinander umgehen und welche Erwartungen die Organisation an sie stellt. Je nach Kultur wird ein Architekt motiviert sein, bei der Umsetzung der konzipierten Architektur selbst Hand anzulegen oder die eigentliche Handarbeit seinen Team-Mitgliedern überlassen. Eine aktive Mitarbeit durch den Architekten trägt jedoch signifikant zum Projekterfolg bei, da die Realisierbarkeit architektonische Ideen sofort deutlich wird. Durch die direkte Kommunikation erhöht sich die Wahrscheinlichkeit, dass die Projektmitglieder die Architektur verstehen und mittragen. Die Akzeptanz des Architekten durch die Entwickler wird gesteigert, soziale Barrieren werden abbaut. Direkte Kommunikation, Abbau sozialer Hemmnisse und die Schaffung eines konstruktiven, partizipativen Arbeitsklimas sind wichtige soziologische Faktoren, die den Erfolg einer Architektur beeinflussen. Eine weitere Möglichkeit dies zu gewährleisten, ist die Architektenrolle auf ein Team zu verteilen und somit Architektur als Teamleistung und nicht als Leistung eines einzelnen zu betrachten. Im Idealfall sollte von jedem Subteam (z.B. Client-, Server- und Backend-Team) eine Person im Architektenteam partizipieren. Dies stellt sicher, dass die Architektur auch in die Subteams hineingetragen wird und deren Erfahrungen wiederum in die Architektur einfliessen. Der Erfahrungsschatz des Architekturteams wird hierdurch erhöht und der Umgang mit der inhärenten Komplexität von Software reduziert.

Der Startschuss des Softwarearchitekten

Nach der Präsentation des Softwarearchitekten sprach der Projektleiter aus, was alle dachten: Dieses Mal machen wir alles richtig – und zwar von Anfang an.

Der qualifizierte Softwarearchitekt für das neue Projekt hat in einer engagierten und professionellen Darstellung die Grundsätze der neuen Software vorgestellt. Die Präsentation war perfekt inszeniert, die Argumentationskette unwiderlegbar, die Grafiken überzeugend – das Projekt musste ein Erfolg werden.

Präsentation versus Realität

Die architektonischen Grundsatzentscheidungen für die Softwarestrukturen, Schichten und Module liegen in einer beachtenswerten Dokumentation vor. Die Umsetzung kann beginnen. Schon nach wenigen Monaten sind die Farben der Präsentation verblasst. Die programmierte Realität und die dokumentierte Planung des Softwarearchitekten stammen scheinbar aus verschiedenen Projekten …

Programmierer versus Architekt

Was ist mit den Vorgaben der SW-Architekten passiert?

Ein Prototyp für die Diskrepanz zwischen Theorie und Praxis: die Entscheidungen über die künftige Softwarearchitektur und ihre Dokumentation fallen in die Planungsphase und die hat noch wenig mit der Praxis zu tun. Erst die Realität während der Konstruktionsphase zeigt, ob die festgelegten Richtlinien zur Softwarearchitketur praxistauglich sind oder nicht.

In der Konstruktionsphase sind die Erfahrungen der Entwickler gefragt. Es geht nun darum, die Fachanforderungen unter Berücksichtigung der architektonischen Rahmenbedingungen umzusetzen. Erfahrende Programmierer bekommen schnell zu spüren, wenn die Vorgaben der Architektur zu restriktiv sind und das Leben schwer machen. Und welche Anforderungen sich nur mit aufwändigen Verrenkungen hätten lösen lassen. So wird ein Prozess initiiert, der die Praxis immer weiter von den ursprünglichen Annahmen entfernt. Dabei spielen folgende Punkte eine Rolle :

  • Pragmatismus bei der Programmierung
  • Spätere Änderungen in den Fachanforderungen
  • evtl. mangelndes Verständnis oder gar Missachtung der Architektur.

Persönliche Komponenten tragen dazu bei, dass das ursprüngliche Konzept häufig nicht realisiert wird. So haben sich viele Entwickler auf Ihre persönlichen Standards eingeschworen. Eventuell spielen auch Aversionen und Grenzziehungen zwischen Softwareentwicklern und Architekten hier eine Rolle. Last but not least: auch Softwareentwickler sind Künster und lassen sich in ihrer Freiheit nicht gern eingeschränken.

Aufgaben und Kompetenzen eines Architekten

Bereits in der Planungsphase des Projekts müssen die Entwicklungs- und Dokumentationswerkzeuge festgelegt werden. Ebenfalls von tragender Bedeutung sind die grundsätzlichen technischen Standards und eine rudimentäre, aber tragfeste. Zu diesem Zeitpunkt sind bereits die Systemgrenzen klar und es wird festgelegt, wie mit Fremdsystemen kommuniziert wird.

Diese Entscheidungen des Architekten (bzw. der Entwicklungsmannschaft, die die Architektenrolle übernommen hat), haben in jeder Hinsicht weitreichende Konsequenzen. Und damit sind diese Kompetenzen mit einer besonderen Verantwortung verbunden. Um die Aufgaben souverän ausfüllen zu können, muss der Softwarearchitekt über Projekterfahrung und technisches KnowHow auf hohem Niveau verfügen.

Damit die architektonischen Festlegungen für ein Projekt konstruktiv umgesetzt werden, muss das gesamte Team diese Festlegungen verstanden und sein Einverständnis dazu gegeben haben. Das ist die entscheidende Voraussetzung für eine erfolgreiche Umsetzung der architektonischen Vorgaben. Und sie ist nur dann zu realisieren, wenn beide Gruppen, Architekten und Entwickler, zu konstruktiver Kommunikation fähig sind. Hier ist die soziale Kompetenz und Überzeugungsfähigkeit des Softwarearchitekten ausschlaggebend.

Neben diesen Aufgaben, die bereits vor der Konstruktionsphase erfolgen können, muss der Architekt während der gesamten Projektlaufzeit „am Ball bleiben“. Der wichtigste Punkt dabei ist das Herstellen einer gemeinsamen Qualitätsvorstellung. Der Erhalt einer hohen Qualität kann durch die Architektur befördert und aufrecht erhalten werden.

Der Architekt muss bei den Projektbeteiligten das Vertrauen aufbauen, dass die Architektur den sich ändernden Kundenvorstellungen und technischen Anforderungen während der Projektdauer gewachsen sein wird. Dieser Punkt betrifft hauptsächlich die Kommunikation mit den Programmierern.

Künstler unter sich: das Verhältnis zwischen Architekt und Programmierer

Architekten und Programmierer verbindet im Projekt ein besonderes Verhältnis. Beide beschäftigen sich mit dem lauffähigen System und beide sind technisch orientiert.

Dadurch besteht die Gefahr, dass sie in Kompetenzstreitigkeiten geraten. Gute Entwickler haben oft den Anspruch, Architekturen festzulegen, indem sie Frameworks bauen, die ihrerseits Festlegungen treffen, Designentscheidungen nahelegen oder gar erzwingen. Entwickler können so die Kompetenz des Architekten untergraben.

Entwickler müssen die Ideen des Architekten verstanden und verinnerlicht haben, sie müssen dahinter stehen und überzeugt sein, dass die Architekturfestlegungen sie nicht gängeln, sondern die Arbeit erleichtern. Entwickler müssen die Architektur beflügeln, sie sozusagen beweisen. Deswegen ist das Vertrauen, das Entwickler der Architektur entgegenbringen, vielleicht der wichtigste Wert, den ein Architekt schaffen kann.

Come together: Architekten und Programmierer gestalten ihr Projekt

Um ein Projekt zum Erfolg zu führen, muss die dauerhafte Kommunikation zwischen Architekten und Entwicklern im Zentrum stehen. Die beiden Gruppen müssen sich gegenseitig befruchten. Beide müssen und können profitieren.

Die Softwarearchitektur muss während der gesamten Projektlaufzeit Wandel und Anpassung zulassen. Der Architekt und das Softwareentwicklungsteam begleiten diesen Prozess. Architektur ist ausdauerndes, langwieriges Arbeiten an den Fachspezifikationen über die ganze Projektlaufzeit hinweg. Die Dokumentation (über die Grundsatzentscheidungen hinaus) entsteht bzw. wächst im Verlauf des Projekts mit.

Die Festlegung einiger Grundstrukturen, ohne sie dabei auf Dauer fest zu zementieren, bietet gerade für die Entwicklerteams Vorteile. Kennt der Architekt die realen Umstände und die Vorstellungswelt der Entwickler bzw. gehört er selbst dazu, so kann er dabei leichter Überzeugungsarbeit leisten.

Technologische Aspekte

Regelwerk

Es gibt eine Reihe von altbekannten fundamentalen Prinzipien89 (Best-Practises) um gute Software zu erstellen. Die Einhaltung dieser Prinzipien ist Grundvoraussetzung um eine brauchbare Architektur zu erhalten, welche auch die nicht-funktionalen Anforderungen umsetzt. Die wesentlichen Grundprinzipien sind hier dargestellt:

Softwareentwicklungs-Prinzipien

Architekturansätze

Bevor sich der Architekt für eine bestimmte Architektur entscheidet, sollte er einen klaren Überblick der wichtigsten Systemeigenschaften (Kernaufgabe, Art der Benutzung, Systembenutzer etc.) haben8.

Es gibt verschiedene Architekturansätze für unterschiedliche Systemeigenschaften.
Architektur-Ansaetze
Darüber hinaus gibt es eine Reihe von weiteren Ansätzen6 spezifisch für verteilt und parallel laufende Systeme. Diese Architekturansätze liegen als Architektur-Patterns76 vor und können dem Architekten die Arbeit erleichtern, indem sie helfen, eine tragfähige und für die vorliegenden Systemeigenschaften passende Architektur zu finden. Weil diese Patterns auf bewährten Konzepten beruhen und die o.g. Softwareentwicklungs-Prinzipien implizieren, mindern sie das Risiko, in eine Sackgasse zu geraten. Jeder dieser Ansätze deckt jedoch nur einen bestimmten Aspekt einer Architektur ab, d.h. eine Architektur wird auf eine ganze Reihe solcher Ansätze basieren.

Schicht um Schicht

Einer der wichtigsten und gebräuchlichsten Architekturansätze ist die Strukturierung eines Systems in Schichten. Die Partitionierung eines Systems ausschliesslich in wichtige Klassen, Substeme und Komponenten ist unzureichend weil es dann immer noch zu viele Abhängigkeiten, Unklarheit über Verantwortlichkeiten und eine zu komplexe Verwendung gibt. Mit dem Architekturansatz der Schichtenbildung kommt eine Partitionierung auf einer höheren Abstraktionsebene zum Tragen. Dabei ist zu beachten, daß jede Schicht eine bestimmte Verantwortlichkeit haben sollte und Bausteine des Systems enthält, die eine hohe Kohäsion in Bezug auf die Verantwortlichkeit der Schicht haben.

Man unterscheidet strenge Schichtung und lose Schichtung4. Erstere besagt, daß eine Schicht nur mit der unmittelbar nachfolgenden Schicht interagieren kann (horizontale Schichtung). In einer losen Schichtung (vertikale Schichtung) kann eine Schicht potentiell mit allen anderen Schichten interagieren. Eine solche Schichtung ist sinnvoll für Basisfunktionalität. Weiter ist zu entscheiden, ob die Interna einer Schicht anderen Schichten zugänglich sein soll (White-Box Layering) oder nicht (Black-Box Layering)4.

3-Schichten-Architektur

In der folgenden Abbildung sind Varianten der klassischen (Client-Server) 3-Schichten-Architekturen dargestellt.
3-Schichten-Architektur
In Systemen, die auf so einer Architektur basieren, findet man häufig sog. Fat-Clients vor, die neben der Präsentationslogik noch Teile der Business-Logik enthalten.

N-Schichten-Architekturen

In modernen (stark verteilten) Systemen kann es n Schichten geben:
N-Schichten-Architektur
Systeme, deren Architekturen derartig geschichtet sind, warten mit sog. Thin-Clients (z.B. Web-Browser) auf, die ausschliesslich für die Präsentation verantwortlich sind.

Qualitative Aspekte umfassen nicht-funktionale Anforderungen, wie Verteilbarkeit, Verfügbarkeit, Nebenläufigkeit, Effizienz und immer häufiger Integrierbarkeit resp. Offenheit. Diese Aspekte müssen von Anfang an in die Architektur einfließen. Eine nicht auf konkurrierende Zugriffe ausgelegte Architektur ist nur mit sehr großem Aufwand, wenn überhaupt, auf Nebenläufigkeit zu adaptieren. Ähnlich verhält es sich auch mit der Verteilbarkeit. Zur Erreichung der qualitativen Anforderungen kann der Software Architekt auf Best Practices, architektonische Patterns und Architektur-Blueprints (J2EE, .NET etc.) zurückgreifen. Aufgrund der einzusetzenden Plattform werden oftmals bereits Blueprints vorgegeben und qualitative Aspekte, wie Verteilbarkeit und Verfügbarkeit, implizit unterstützt. Es ist jedoch falsch zu denken, dass moderne Application Server den Architekten davon befreien, nichtfunktionale Anforderungen bei der Konzeption zu berücksichtigen. Application Server bieten zwar sehr viele Dienste, die Architektur muss jedoch darauf abgestimmt sein. Die reine Konzentration auf das Geschäftsproblem ist somit ein Trugschluss und zum Scheitern verurteilt.

Die einzusetzende Plattform ist ein Bestandteil der operationalen Aspekte. Beispiele hierfür sind J2EE, CORBA und .NET. Sobald man sich für eine Technologie entschieden hat, sind auf dieser Technologie basierende Produkte wie Application Server oder ORBs zu evaluieren. Darüber hinaus muss die Architektur hier Punkte, wie Deployment, Netzwerktopologie, Anschluss an System-Management-Infrastruktur und Wartungsprozesse behandeln.

Zu guter Letzt: doch noch Bilder

Als Dokumentation einer Architektur sollte es grafische Darstellungen und zugehörige textuelle Beschreibungen geben. Als grafische Notation ist UML zu empfehlen weil UML alle notwendigen Notationselemente enthält um eine Architektur darzustellen und es sich hier um einen weitverbreiteten Standard handelt. UML-Diagramme, die sich üblicherweise auf Objekte und Klassen beziehen können ganz pragmatisch auch für die Darstellung von Subsystemen, Schichten etc. verwendet werden.

Fazit

Architektur ist einer der entscheidenten Faktoren für Software-Qualität. Den hohen Anforderungen heutzutage kann nur solche Software gerecht werden, die auf einer explizit geplanten und in den Entwiclungsprozess integrierten Architektur beruht. Eine solche Architektur muß neben technologischen unbedingt auch organisatorische und soziale Faktoren berücksichtigen.

Literatur und Webadressen

  1. Andreas Elting und Walter Huber; Sanierungsfall – Rettung von gescheiterten IT-Projekten; iX3/2003. S. 92

  2. Architekturdefinitionen: www.sei.cmu.edu/architecture/definitions.html

  3. Brian Foote e.a.; Big Ball of Mud; www.laputan.org/mud/mud.html 1999

  4. Colin Atkinson e.a.; Component-based Product Line Engineering with UML; Addison-Wesley 2002

  5. Craig Larman; Applying UML and Patterns; Prentice Hall 2002

  6. Douglas Schmidt e.a.; Pattern-Oriented Software Architecture – Patterns for Concurrent and Networked Objects; Wiley 2000

  7. Frank Buschmann e.a.; Pattern-Oriented Software Architecture – A System of Patterns; Wiley 1996

  8. Gernot Starke; Effektive Software-Architekturen; Addison-Wesley 2002

  9. Peter Herzum und Oliver Sims; Business Component Factory; Wiley 2000

  10. Philippe Kruchten; The Rational Unified Process – An Introduction; Addison-Wesley 2000

  11. Raphael Malveau e.a.; Architect Bootcamp; Prentice Hall 2001

  12. S. Ambler; Agile Enterprise Architecture: Beyond Enterprise Data Modeling; http://www.agiledata.org 2002

  13. Alister Cockburn; Agile Software Development; Addison-Wesley 2002

  14. G. Miller; The Magical Number Seven, Plus Or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review vol. 63(2), S. 86 1956

  15. M. Conway; http://www.elsewhere.org/jargon/html/entry/Conway’s-Law.html 1968

  16. J. Coplien; A Development Process Generative Pattern Language, Architect Also Implements, http://www.bell-labs.com/user/cope/Patterns/Process/section16.html 1995

  17. Kent Beck; Extreme Programming Explained. Embrace Change; Addison-Wesley 2000

  18. William J. Brown a.e.; Anti Patterns – Refactoring Software Architectures and Projects in Crisis