Das iSAQB-Modul zu den technischen Aspekten serviceorientierter Architekturen (SOA-T) ist eines der Advanced-Level-Lehrplanmodule, mit denen Teilnehmer an lehrplankonformen Schulungen Credit-Points in den Bereichen technische und methodische Kompetenz erwerben können. Dieser Artikel beschreibt die Inhalte einer solchen Schulung und deren Nutzen für den Projektalltag näher.
Motivation
Viele IT-Anwendungslandschaften in Unternehmen und Organisationen haben die Tendenz, sich im Laufe der Zeit weitgehend ungeplant und unkoordiniert zu entwickeln. Sei es durch Zeitdruck, Budgetfragen oder manchmal auch schlicht fehlendes Architekturbewusstsein: Die isolierte Betrachtung von Anwendungen führt auf die Dauer fast zwangsläufig zur Bildung von Applikationssilos mit den damit verbundenen Problemen wie etwa der mangelhaften Unterstützung fachdomänenübergreifender Prozesse oder der semantischen Inkonsistenz zentraler fachlicher Konzepte bzw. Entitäten. Entsteht nun durch zusätzliche Anforderungen der Fachseite auch noch Integrationsbedarf zwischen diesen Silos, ist das Chaos komplett. Das Fehlen einer übergreifenden Strategie führt hier schnell zu einem Wildwuchs an Ad-Hoc-Integrationsschnittstellen verschiedenster Couleur, der nur noch schwer zu überblicken ist. Die Konsequenzen einer solchen Entwicklung sind oft gravierend. Mangelnde Flexibilität bei der Automatisierung von Geschäftsprozessen, hohe zeitliche und monetäre Aufwände für die Umsetzung neuer fachlicher Anforderungen sowie Effizienzverluste durch Doppelarbeit sind nur einige Beispiele für die Herausforderungen, vor denen viele Unternehmen stehen.
Schon seit langer Zeit liefert hier die Idee der serviceorientierten Architektur (SOA) einen Lösungsansatz, um Struktur und Ordnung in Anwendungslandschaften zu bringen und – vor allem – sicherzustellen, dass diese auch bei der kontinuierlichen Weiterentwicklung erhalten und verbessert wird. Leider unterlag aber auch diese Idee in den letzten Jahren dem offenbar unvermeidlichen IT-Hype-Cycle: nach anfänglicher Euphorie und massiven Investitionen der Early-Adopter in das Thema kam die Zeit der Ernüchterung, die sich vor allem in zahlreichen gescheiterten SOA-Vorhaben niedergeschlagen hat. Neben technischen Problemen, die in der Anfangszeit vor allem durch die Unreife der relevanten Standards bedingt waren, wurde meist ein wichtiger Aspekt massiv unterschätzt: SOA ist im ursprünglichen Sinne ein Ansatz, der eine fundamentale Transformation der Anwendungslandschaft bedingt – und damit auch Auswirkungen bis in die Organisation des Unternehmens hinein hat.
Nachdem das Thema SOA also in den letzten Jahren dadurch bedingt ein wenig in den Hintergrund getreten ist, erlebt es in jüngerer Zeit geradezu eine Renaissance. Grund dafür ist sicherlich nicht zuletzt auch die zunehmende Verbreitung agiler Methoden der Softwareentwicklung und damit der Wunsch, die Entwicklung kleinteiliger zu gestalten und sich vom klassischen Anwendungsmonolithen zu entfernen.
Vor diesem Hintergrund war es naheliegend, das Curriculum der Advanced-Level-Ausbildung des CPSA-A um dieses – eigentlich für jeden professionellen Softwarearchitekten wichtige – Thema zu erweitern.
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 möchten. Dementsprechend wird die Kenntnis von Grundbegriffen und -prinzipien der Softwarearchitektur (wie sie etwa die Foundation-Level-Ausbildung vermittelt) vorausgesetzt. Darauf aufbauend beschäftigt sich der erste Block des Lehrplans mit den Grundlagen von SOA und vor allem dem Service als zentralem Konzept einer jeden serviceorientierten Architektur und den Eigenschaften, die ihn gegenüber anderen Artefakten wie Komponenten oder Klassen auszeichnen. Ein wichtiger Aspekt dabei ist die konsequente Unterscheidung zwischen dem Geschäftsservice auf der einen Seite und dem technischen Service als dessen konkreter Umsetzung in laufender Software auf der anderen Seite. Während der Geschäftsservice als abstraktes Konstrukt rein fachlich motiviert ist und damit die Grundlage für die Abstimmung zwischen IT und Fachseite darstellt (auf Neudeutsch: „Business/IT-Alignment“), ist der technische Service das, was für uns als Softwarearchitekten meist von primärem Interesse ist. Dennoch sind beide wie zwei Seiten der gleichen Medaille: der eine kann ohne den anderen nicht.
Nach dieser noch eher theoretischen Betrachtung des Themas befasst sich der folgende Block des Lehrplans mit den technischen Konzepten, die bei der konkreten Umsetzung einer SOA zu berücksichtigen sind. War noch vor wenigen Jahren SOA technisch fast immer auch gleichbedeutend mit „klassischen“ Web Services, so gewinnen zunehmend REST-Services und damit die Hoffnung auf einen leichtgewichtigeren Weg zur technischen Realisierung einer SOA an Bedeutung. Obwohl es sich hier oberflächlich betrachtet lediglich um zwei alternative technische Ansätze handelt, hat die Entscheidung für den einen oder anderen durchaus weitreichende Konsequenzen bezüglich der Kommunikations- und Interaktionsmuster zwischen Serviceprovidern und ihren Nutzern sowie der Möglichkeiten zur Komposition und Orchestrierung von Services. Außerdem sind auch die Konzepte zur Behandlung querschnittlicher Aspekte in einer SOA, wie beispielsweise Sicherheit oder Transaktionen, abhängig vom gewählten Ansatz unterschiedlich. Softwarearchitekten in die Lage zu versetzen, diese Konsequenzen zu verstehen und abwägen zu können, ist daher eines der zentralen Ziele der Ausbildung.
In der täglichen Projektpraxis stehen uns heute leistungsfähige und mächtige Frameworks zur Verfügung, welche die Komplexität der zugrundeliegenden Technologie einer SOA weitgehend verbergen und diese damit auch für weniger erfahrene Softwareentwickler effizient nutzbar machen. Dennoch ist es für Architekten aus unserer Sicht essenziell, zumindest die Grundlagen der wichtigsten Protokolle und Standards zu kennen – spätestens im Fehlerfall, wenn das Framework doch einmal nicht das tut, was es soll, erweist sich dieses Wissen als sehr hilfreich. Web Services (basierend auf Standards wie SOAP und WSDL) und ihrem komplexen Ökosystem von darauf aufbauenden und ergänzenden Standards sowie den aktuellen Alternativen aus der REST-Welt ist daher ein eigener Block gewidmet. Ziel ist es hier nicht, jeden Softwarearchitekten zum Low-level-Protokollexperten zu machen, sondern ein Grundverständnis dafür zu vermitteln, was letztendlich „über den Draht geht“.
Die Königsdisziplin in einer SOA ist – und das zeigen uns neben unserer langjährigen Projektpraxis auch die Erfahrungen aus den Schulungen – das technische Servicedesign. Bereits an einfachen Beispielen zeigt sich schnell die Vielzahl der denkbaren Entwurfsalternativen, zwischen denen der Architekt seine Entscheidung treffen muss. Aber wie und nach welchen Kriterien? Gibt es ein „richtig“ und ein „falsch“ oder ein „gut“ und ein „schlecht“? Der Schlüssel zur Beantwortung dieser Frage liegt, neben Praxiserfahrung und dem Lernen aus in der Vergangenheit gemachten Fehlern, in einem guten Repertoire an typischen Patterns (und Anti-Patterns) – und natürlich, wie bei allen Architekturfragen, auch einem guten Teil Kreativität und gesundem Menschenverstand. In diesem Sinne ist dieser Block des Lehrplans erfahrungsgemäß auch derjenige, der die lebhaftesten Diskussionen anregt und damit auch den Erfahrungs- und Meinungsaustausch zwischen den Teilnehmern fördert. Wie auch immer der Weg zum konkreten Servicedesign aussieht: es ist unwahrscheinlich, dass der erste Wurf auf alle Anforderungen 100%ig passt, geschweige denn, auf alle Anforderungen der Zukunft vorbereitet ist. Es ist daher extrem wichtig, dass Prozesse zur kontinuierlichen Weiterentwicklung über den gesamten Lebenszyklus eines Services existieren (und gelebt werden). Anhand beispielhafter Service-Lifecycle-Prozesse lernen die Teilnehmer, worauf es dabei ankommt und gewinnen eine Vorstellung davon, wie ein solcher Prozess als Teil der SOA-Governance innerhalb ihrer eigenen Organisation gegebenenfalls aussehen könnte.
Wie aber baut man nun Anwendungen auf Basis von Services? Wodurch unterscheidet sich das Entwicklungsvorgehen und was bedeutet das für die Rolle des Softwarearchitekten? Auch diesen Fragen widmet der Lehrplan einen separaten Block. Neben grundlegenden Fragen wie der Aufteilung von Geschäftslogik und der Datenhoheit können sich, je nach Ausgangssituation, Auswirkungen bis hin zur Teamstruktur der Entwicklungsteams ergeben. Der Architekt steht hier vor der Herausforderung, dafür zu sorgen, dass aus vielen beweglichen Teilen am Ende ein funktionierendes System wird – keine leichte Aufgabe!
Ergänzt werden die einzelnen inhaltlichen Blöcke des SOA-T-Moduls jeweils durch die Vorstellung von entsprechenden Standardwerkzeugen und -infrastrukturkomponenten (z.B. Service-Repositories und -Registries, ESBs oder Werkzeugen zum Service-Management) und ihrer typischen Funktionen.
Zur zusätzlichen Illustration und Vertiefung der Inhalte dient immer mindestens ein konkretes Fallbeispiel. Abhängig von Teilnehmerkreis und Schulungsanbieter kann dies ein vorbereitetes Beispielszenario sein oder aber auch ein reales Szenario z.B. aus einem aktuellen Projekt der Teilnehmer. Im Idealfall besteht sogar die Möglichkeit, verschiedene Ansätze einer SOA im Vergleich zu betrachten – eine Lernerfahrung, die sich für uns in unserer Schulungspraxis als sehr wertvoll erwiesen hat.
Relevanz für die Projektpraxis
Die deutliche Mehrheit der großen und mittelständischen Unternehmen hat sich heute das Thema SOA mehr oder weniger groß auf die Fahnen geschrieben. Abhängig vom SOA-Reifegrad der jeweiligen Organisation finden sich bereits etablierte, funktionierende Strukturen oder es ist echte Pionierarbeit zu leisten (oder irgendetwas dazwischen). In jedem Fall aber bedeutet das für einen Softwarearchitekten in einem solchen Umfeld, dass er mit seiner Erfahrung und Expertise einen wesentlichen Erfolgsfaktor darstellt. Nur Lösungen, die in den durch die jeweilige SOA-Strategie abgesteckten Rahmen passen und sowohl die fachlichen als auch die technischen Randbedingungen erfüllen, werden langfristig nachhaltig wirtschaftlich sein können. Hier die richtigen Entscheidungen zu treffen, ist eine schwierige und wichtige Aufgabe.
Aber auch in der vermeintlich so modernen Welt der Internet-Startups bedient man sich eifrig der guten und richtigen Erkenntnisse und Ideen aus der Vergangenheit. Letztendlich gelten auch für den derzeit heiß (und durchaus auch kontrovers) diskutierten IT-Trend namens „Microservices“ im Kern immer noch die gleichen Prinzipien wie in der „klassischen“ SOA. Neu und anders ist hier eher die Art und Weise, wie solche Services betrieben und genutzt werden. An die Stelle des herkömmlichen Applikationsservers treten heute zunehmend leichtgewichtige und massiv virtualisierte Ablaufumgebungen, die ein schnelles und häufiges Deployment in die Produktionsumgebung ermöglichen und damit eines des wesentlichen Versprechen von SOA – die schnelle und flexible Reaktion auf sich ändernde fachliche Anforderungen – optimal einlösen.
Fazit
Egal, ob Architekt in einem Großkonzern mit globaler SOA-Strategie oder Lead Engineer in einem Startup-Unternehmen mit hohen Anforderungen an Flexibilität und Skalierbarkeit: SOA ist heute für praktisch alle Softwarearchitekten ein Thema – auch, wenn es ihnen vielleicht manchmal gar nicht bewusst ist, weil es einfach nicht so genannt wird.
Letztlich hilft das vermittelte Wissen den Teilnehmern – unabhängig von ihrem Hintergrund – dabei, in ihrem Projektalltag als Architekt die richtigen Entscheidungen zu treffen und so das Potenzial einer SOA möglichst gut auszuschöpfen: höhere Flexibilität in den Geschäftsprozessen, schnellere Umsetzung neuer Anforderungen und reibungslosere Kommunikation zwischen Fachseite und IT.