Prozesswissen effizient verarbeiten
Microservices schätzt man bei Fuchs mittlerweile als stabiles Fundament, um Eigenentwicklungen mit Standardsoftware in Systemlandschaften zu integrieren. "Bei Einführung neuer Software gibt es künftig immer eine Alternative mehr. Wir setzen Microservices verstärkt in Bereichen ein, wo wir mit Standardsoftware einen zu hohen Customizing-Bedarf erwarten", erläuter Alexander Fuchs. Agile Softwareentwicklung helfe, benötigtes Prozesswissen möglichst effizient zu erarbeiten und in lauffähige Software zu überführen. Es sei freilich nicht ausgeschlossen, dass einzelne Microservices später durch Standardsoftware abgelöst würden.
- Knackpunkte in agilen Entwicklungsteams
Seit die Verfasser des "Agilen Manifests" im Jahr 2001 den klassischen Phasenmodellen wie Wasserfall und V-Modell den Kampf angesagt haben, erlebt die Softwareentwicklung eine tief greifende Veränderung. Mittlerweile ist Agilität fast zu einem Hype-Begriff geworden. Darüber gerät gelegentlich aus dem Blick, was die Methode tatsächlich leisten kann und an welchen Stellen das ursprüngliche Dokument von 2001 aufgrund von Projekterfahrungen aus mehr als einer Dekade präzisiert werden sollte. - Crossfunktionale Teams aus Spezialisten und Generalisten bilden
- Teamübergreifende Governance sichern
- Verantwortungsvolles und pro-aktives Handeln der agilen Teammitglieder
- Ständige Kommunikation innerhalb und zwischen Sprint-Teams
- An agiler Community aktiv teilnehmen und auf Best Practices setzen
- Verständigung über technisches Rahmenwerk (Architektur) herstellen
- Bereitstellung von Testdaten und Ausführung von Integrationstests sichern
- Dokumentation im Hinblick auf Compliance nicht vernachlässigen
Komplexität einer verteilten Systemlandschaft
Bei allen positiven Erfahrungen: Es gibt durchaus Faktoren, die Microservices als Architekturmodell zu einer Herausforderung machen, wie sich in der Praxis beweist. "Man halst sich die Komplexität einer verteilten Systemlandschaft auf mit der Konsequenz, Konsistenz und Transaktionssicherheit herstellen zu müssen", räumt Alexander Fuchs ein. Infrastrukturlösungen in Form von Loadbalancing- und Monitoring-Werkzeugen existieren zwar am Markt. Die erforderlichen Skills freilich mussten am Teutoburger Wald seinerzeit aufgebaut werden. "Die Leute müssen im Team skalierbare, robuste SW entwickeln können, die hohen architektonischen Qualitätsansprüchen gerecht wird", so Fuchs. Außerdem sei die Fähigkeit zur Kommunikation mit den Fachbereichen gefordert. Kurzum: "Man muss sich als Microservices-Entwickler im agilen Umfeld wohlfühlen."
Zudem: Bei aller Agilität des Vorgehens ist gute Planung besonders im Microservices-Umfeld wichtig, insbesondere hinsichtlich der Architektur. Der Microservices-Ansatz birgt nämlich das Risiko, "fachliche Domänen nicht richtig zu zerlegen, also irrtümlich Dinge zu trennen die zusammengehören und damit vermeidbare Schnittstellenkomplexität zu erzeugen", warnt Fuchs und rät, im Zweifelsfall prophylaktisch Funktionalitäten zunächst zusammenzuhalten und Sie erst später bei Bedarf zu zerlegen.
Microservices sind nicht SOA
Aus seinen Alltagserfahrungen im IT-Management leitet Alexander Fuchs als Wirtschaftsinformatiker auch theoretische Überlegungen ab, die sich auf die Trennschärfe der Begriffe Microservices und SOA (serviceorientierte Architektur) beziehen. Auf den ersten Blick ähneln sich die Ideen: In beiden Fällen handelt es sich um eine Architektur, die aus wiederverwendbaren und in unterschiedlichen Kontexten konfigurierbaren Services, beziehungsweise Funktionsmodulen, zusammengesetzt ist.
Im Video: Microservices als Architekturmuster
(Quelle: video2brain, Trainer: Christopher Janietz)
Viele SOA-Implementierungen haben jedoch einen zentralistischen Ansatz, erläutert Fuchs den Unterschied. SOA sei ein Konstrukt mit einem mächtigen Integrationswerkzeug, einer intelligenten Middleware, etwa einem ESB (Enterprise Service Bus). Der könne zwar unterschiedliche Komponenten "fest miteinander verdrahten" und sei in dieser Hinsicht flexibel. Weil er aber große Teile der Prozesslogik selbst enthalte, mache er sich unverzichtbar. "Das Ding in der Mitte wird man nie wieder los" warnt Fuchs. Das Ziel, Anwendungen voneinander zu entkoppeln, gerate in Gefahr, wenn der zentrale ESB sie mithilfe von Engines für Business-Prozesse und -Regeln sowie durch Routing, Mapping etc. miteinander verklebe. Bei Microservices dagegen stecke die Logik in den Endpunkten, weshalb sie als "Methode zur Komplexitätsbehandlung" weitaus besser geeignet seien.
Eine Systemlandschaft ganz aus Microservices kann sich der CIO - zumindest gegenwärtig - nicht vorstellen; dazu müssten alle Softwarehersteller ihre Anwendungen einzeln als umsetzungsfähige ("deploybare") Apps anbieten. Fuchs ruft damit nach einer umfassenden App-Economy, wie sie ja auch tatsächlich bereits prognostiziert wird. (fm)
- 7 Fragen zur SOA-Effizienz
Das Potenzial für die Automatisierung der Geschäftsprozesse, das in einer Service-orientierten Architektur steckt, bleibt oft ungenutzt. Wenn das so ist, ändert auch eine Modernisierung nichts daran. - 1. Ist die SOA kompatibel mit Geschäftsmodell und IT-Landschaft?
Zunächst wird man vorbehaltlos rekapitulieren müssen, ob die ursprüngliche Entscheidung für SOA vor dem Hintergrund der aktuellen Bedingungen eigentlich noch die richtige ist. War der Bedarf für wiederverwendbare IT-Services so groß wie erwartet? Ist die Systemlandschaft tatsächlich so heterogen, dass sie eines ESB bedarf? Von entscheidender Bedeutung ist auch, ob sich in den fachlichen Prozessen die Servicequalität verbessern lässt, wie das SOA-Konzept es verspricht. - 2. Verwirklicht die SOA konsequent eine Architekturentscheidung?
Schon der Name Service-oriented Architecture zeigt an, dass es um eine IT-Architektur und eine grundsätzliche Entscheidungen in IT-Fragen geht. Nötig sind deshalb klare Vorgaben, für welche Einsatzgebiete der ESB beziehungsweise eine Orchestrierung in BPEL und BPMN (Business Process Model and Notation) zu verwenden sind. - 3. Werden die Potenziale zur Effizienzsteigerung genutzt?
Eine IT-Architektur ist kein Selbstzweck. Die bloße Möglichkeit, flexible IT-Services aufsetzen zu können, rechtfertigt die Investitionen nicht. Nur wenn die Service-orientierte Architektur hilft, die Effizienz im Unternehmen zu steigern, zahlt sich der Aufwand aus. - 4. Behindert eventuelles Silodenken den effizienten SOA-Einsatz?
Die Kopplung einzelner Systeme zu übergreifenden Prozessketten ist eher eine organisatorische Herausforderung als ein IT-Poblem. SOA-Potenziale lassen sich oft nur ausschöpfen, wenn vorher eine Silo-übergreifende Prozessoptimierung stattgefunden hat. - 5. Liefern die Services aussagekräftige Kennzahlen?
Bei der Orchestrierung und in den Services sind standardisierte Messpunkte zu setzen, die sich für die Auswertung durch ein Business-Activity-Monitoring eignen. Zudem liefern diese Messpunkte die Grundlagen für die KPI-Überwachung (Key Performance Indicators) sowie die kontinuierliche Prozessoptimierung. - 6. Funktioniert die IT-Governance?
Als strategische Entscheidung bestimmt SOA, wie Prozesse in der IT abgebildet werden. Deshalb hängt sie eng mit der IT-Governance zusammen. Wenn es keine gibt oder die vorhandene nicht funktioniert, ist das häufig ein Grund für das Versanden von SOA-Projekten. - 7. Welche SOA-Infrastruktur passt in das Unternehmen?
Erst nachdem die bisherigen SOA-Initiativen hinterfragt wurden, stellt sich die Frage nach einer Migration oder Modernisierung. Auch hier gilt: Die Komponenten müssen zur Strategie des Unternehmens und der dort vorherrschenden IT-Systemlandschaft passen.