Das iSAQB-Modul zu Webarchitekturen (WEB) ist eines der Advanced-Level-Lehrplanmodule, mit dem Teilnehmer an lehrplankonformen Schulungen Credit-Points im Bereich technische Kompetenz erwerben können. In diesem Artikel beschreiben wir die Inhalte einer solchen Schulung und deren Nutzen für den Projektalltag näher.
Motivation
Noch vor einigen Jahren wurden die wirklich großen Systeme nicht für das Web gebaut, sondern für die Verwendung innerhalb von Unternehmen, und es war durchaus kontrovers, Enterprise-Anwendungen mit Weboberflächen ausstatten zu wollen. Anders gesagt: Als Architekt beschäftigte man sich im Wesentlichen mit betrieblichen Informationssystemen, denn innerhalb des Unternehmens gab es kaum Webtechnologien.
Heute sind bei so gut wie jeder neueren Architektur diverse Komponenten aus dem Webarchitekturumfeld enthalten. Ob RESTful-Backend-Services, webbasierte Frontends oder das Reduzieren von HTTP zum Basisprotokoll für die Kommunikation mit anderen Systemen: Die Flut an teilweise altbewährten, teilweise neuen Technologien und Konzepten aus diesem Bereich scheint endlos.
Während eine detaillierte Kenntnis jedes Aspekts der Webtechnologie ein geradezu aussichtsloses Unterfangen wäre, ist es doch essenziell, diese richtig einordnen zu können. Voraussetzung dafür ist ein solides Verständnis der Basistechnologien, wie HTTP, HTML, JavaScript und CSS, vor allem aber auch der eigentlichen Intentionen, die hinter diesen Standards stecken. Es ist entscheidend zu wissen, wofür sich der Webstack hervorragend eignet und was sich damit nur schwer realisieren lässt. Wenige Dinge sind so frustrierend wie eine Webanwendung, die langsam, unergonomisch, schlecht skalierbar, nicht barrierefrei und unansehnlich ist; besonders dann, wenn man erkennen kann, dass dies durch einen geeigneteren Ansatz vermeidbar gewesen wäre.
Anders gesagt: Als Architekt für Informationssysteme kommt man heute kaum noch daran vorbei, sich mit Webanwendungen oder Web Services zu beschäftigen. Deshalb haben wir mitgeholfen, das Thema Web als eines der ersten rein technischen Module im Advanced Level der CPSA-Ausbildung zu etablieren. In diesem Artikel stellen wir die zentralen Inhalte der Ausbildung vor und gehen auf ihre Relevanz für den Projektalltag ein.
Zentrale Inhalte
Die Ausbildung richtet sich (wie alle Advanced-Level-Module) nicht an Einsteiger, sondern an erfahrene Architekten, die bestehende Kenntnisse vertiefen und eventuelle Lücken schließen wollen. Dennoch sieht der Lehrplan die Vermittlung eines gemeinsamen Verständnisses über die Grundlagen vor, indem die wesentlichen Interaktionsmuster, die Rollen der unterschiedlichen Standard- und Individualkomponenten sowie die relevanten Standards im Überblick vorgestellt werden. Außerdem geht es um konkrete Protokolle und Standards, insbesondere HTTP bzw. HTTPS, URIs, HTML, CSS usw., und deren spezifikations- und architekturkonforme Verwendung. Wie so oft steckt der Teufel im Detail und eine Auseinandersetzung mit den Mechanismen ist nicht nur für die Beherrschung von effizientem Caching im Web absolut unumgänglich.
Wie bei vielen anderen Technologiestacks gibt es im Webumfeld nicht nur eine einzige „richtige“ Art und Weise, die vielen verschiedenen Möglichkeiten auszuprägen. Daher ist ein zentrales Thema der Ausbildung die Vermittlung unterschiedlicher Architekturstile im Web. So gibt es zum Beispiel mit REST-konformen oder statusbehafteten Backends verschiedene Ausprägungen auf der Serverseite, und gleiches gilt für unterschiedlichste Arten von Frontend-Architekturen, wo es von JavaScript-agnostischen Frontends über Resource-oriented Client Architecture (ROCA) bis hin zu Single-Page Applications diverse Spielarten gibt. Dabei werden diese Vorgehensweisen nicht einfach nur inhaltlich vorgestellt, sondern auch deren Vor- und Nachteile für unterschiedliche Einsatzbereiche diskutiert. Gerade die Frage nach dem richtigen Ansatz für die Frontend-Entwicklung („Wie viel JavaScript darf’s denn sein?“) ist dabei ein Thema, das im Moment für heftige Kontroversen sorgt.
Nach der Entscheidung für einen konkreten Architekturstil ist die Auswahl und der sinnvolle Einsatz konkreter Technologien und Infrastrukturkomponenten der nächste wichtige Themenblock: Hier stehen „native“ Bestandteile eines Webarchitekturentwurfs im Mittelpunkt, also Load Balancer, Webserver oder Proxy-Caches und weniger Applikationsserver, die auch in anderen Architekturen zum Einsatz kommen.
Ein weiterer Block des Lehrplans, der konkrete Entwurf von Softwarearchitekturen für Websysteme, beschäftigt sich mit den wichtigen intern und extern sichtbaren Entscheidungen: der Wahl geeigneter Persistenz- und Skalierungsansätze, der Datenablage in hochverteiltem Umfeld und den dabei eintretenden Limitierungen für die Gewährleistung von Konsistenz und transaktionale Verarbeitung. Der Lehrplan für das Modul ordnet auch die Wahl der geeigneten Mechanismen für die Realisierung von internationalisierten und barrierefreien Benutzerschnittstellen diesem Bereich zu.
Nicht funktionale Aspekte, allen voran Sicherheit, Skalierbarkeit und Verfügbarkeit als Qualitätsziele spielen im Architektenalltag ebenso eine wichtige Rolle und werden daher explizit im Lehrplan behandelt. Schließlich sind, wie auch im Foundation Level, konkrete Beispielarchitekturen Bestandteil der Ausbildung, an denen das Gelernte praktisch demonstriert werden soll. Konform zum Grundmodell des CPSA Curriculums gibt der Lehrplan Inhalte und deren Gewichtung zueinander vor, nicht jedoch einen konkreten Ablauf. Die Mindestdauer einer lehrplankonformen Schulung beträgt drei Tage, aber es steht dem Schulungsanbieter frei, eine längere Dauer zu wählen.
Relevanz für die Projektpraxis
Das vermittelte Wissen bewahrt Teilnehmer davor, sich im Projektalltag mit falschen Entscheidungen die Möglichkeiten des Webs zu verbauen. Häufig nähert man sich dem Thema allerdings über die Implementierung, nicht über die Konzepte. Vielleicht kennen Sie die Situation: Es wird eine Evaluation gestartet und ein Proof of Concept entwickelt, mit dem geklärt werden soll, ob AngularJS oder doch vielleicht JSF, Spring MVC oder GWT die richtige Technologie für die Zukunft sind – und dabei wird übersehen, dass es sich um Werkzeuge aus völlig unterschiedlichen Kategorien handelt. Der Wunsch nach einem Framework, das sich um die lästigen Details kümmert und Best Practices in bereits fertig kodierter Form enthält, ist zwar nachvollziehbar, verlagert aber die Komplexität, die Webtechnologien nun einmal haben, oft nur auf das Framework. Darüber hinaus gibt diese Entscheidung auch vor, welche Features des Webs man später verwenden kann und welche nicht: Ist das System skalierbar? Sind seine Ressourcen verlinkbar? Tendiert die Architektur zu Monolithenbildung?
Eine Schulung, die sich am Lehrplan orientiert, ordnet die vielen Bausteine, die insgesamt im Umfeld von Webarchitekturen existieren, in ein großes Ganzes ein. Für die Teilnehmer wird damit klar (oder klarer), welche Entscheidungen grundsätzlicher Art zu treffen sind, bevor in dem so entstehenden Rahmen konkrete Implementierungswerkzeuge ausgewählt werden und festgelegt wird, wie mit diesen umgegangen werden soll. So treffen viele Frameworks beispielsweise über den Umfang von serverseitigem Status keine Aussagen. Diese Entscheidung sollte aber nicht der Tagesform verschiedener Entwickler überlassen werden, da sie beispielsweise für die Skalierbarkeit und Benutzbarkeit des Systems essenziell ist.
Auch der Schnitt der Entwicklungsteams spielt eine entscheidende Rolle. Nach Conway’s Law spiegeln sich die Kommunikationsstrukturen innerhalb der Organisation, die die Software entwickelt, in der Architektur wider. So findet man auch in den meisten Unternehmen Backend- (von Backend-Teams gebaut) und Frontend-Systeme (mit einem entsprechenden Frontend-Team dahinter). Organisatorisch mag dies durch Unternehmenstraditionen oder Kommunikationsschwierigkeiten zwischen den Teams (mit meist sehr unterschiedlichen Hintergründen) begründbar sein. Betrachtet man das Ganze aber mit etwas Abstand, wirkt es recht ineffizient. So ist eine Änderung eines Systems, die rein auf das Frontend oder das Backend begrenzt ist, äußerst unwahrscheinlich. Viel wahrscheinlicher ist, dass die meisten Änderungen beide Teile betreffen werden und mit viel Synchronisationsaufwand organisiert werden müssen. Ein Architekt sollte sich also der Reichweite des Architektur- oder eben des Teamzuschnitts bewusst sein und sicherstellen, dass sich ein Großteil möglicher Änderungen oder neuer Features nur auf ein System auswirken. Die Architektur muss für den Normalfall ermöglichen, dass die Teams unabhängig voneinander arbeiten können. Dies setzt aber ein fundiertes Abwägen aller für Websysteme wichtigen Punkte voraus. Schließlich sollte sich ein Architekt auch noch der besonderen Bedeutung von Infrastrukturkomponenten bewusst sein. Besonders bei Anwendungen mit hohen Anforderungen an die Skalierbarkeit spielen diese oft eine zentrale Rolle. So ist zum Beispiel durch Einsatz geeigneten Cachings mithilfe eines Reverse-Proxy-Caches auf der Serverseite oft eine dramatische Steigerung von Durchsatz und Performance erzielbar. Dies setzt jedoch voraus, dass die Anwendungskomponenten auch so entwickelt werden, dass sie von den Caching-Möglichkeiten profitieren können. Die Infrastruktur ist damit kein Detail, das von Entwicklern ignoriert werden kann, sondern ein ganz entscheidender Aspekt, der in enger Kooperation zwischen Betrieb und Entwicklung geklärt werden muss.
Architekten verfügen oft über sehr umfangreiche Backend-, aber nur wenig Frontend-Erfahrung, und wenn, dann eher in Technologien, die für klassische Cliententwicklung zum Einsatz kommen. Der Bereich der Web-Frontends ist allerdings enorm umfangreich und bietet viele verschiedene Architekturalternativen, sowohl was seine interne Gestaltung angeht, als auch seine Beziehung zum Backend: Schließlich handelt es sich bei jedem HTTP-Request, den der Browser zum Server schickt, um eine klassische Interaktion in einem verteilten System, die mit derselben Sorgfalt behandelt werden sollte wie ein Aufruf zwischen zwei Backend-Komponenten. CSS und JavaScript, als die zentralen Technologien im Web-Frontend, verfügen mittlerweile über eigene Welten von Komponenten wie Präprozessoren, Frameworks, Metaframeworks und anderen Tools. Die Fülle und der Umfang der hier entstandenen und aktuell entstehenden Technologien brauchen den Vergleich mit den Backend-bezogenen Technologien nicht scheuen. Ignoriert man als Architekt diese Welten, so rächt sich dies entweder in unwartbaren Frontends oder in verschenkten Möglichkeiten der Frontend-Gestaltung (sehr wahrscheinlich sogar in beidem).
Fazit
Eine Webanwendung mit der ihr eigenen Anwendungsarchitektur bettet sich als Teil in das Gesamtsystem Web ein, dessen Komponenten insgesamt ebenfalls einem Architekturentwurf folgen. Was für eine klassische Client/Server- oder 3-Tier-Anwendung eine passende Architektur ist, muss dabei nicht in das Webszenario passen. Auf der anderen Seite unterliegt nicht jede Anwendung, die heute als Webanwendung realisiert wird, denselben Anforderungen wie das globale Web als Ganzes. Die Schulungen zum Webmodul des iSAQB vermittelt Architekten, wie sie die projektspezifischen Aspekte mit dem, was im Web „passt“, möglichst gut in Einklang bringen – und sich an den Stellen gegebenenfalls darüber hinwegsetzen, an denen dies kontraproduktiv wäre.