Problembeschreibung
Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.
Dieser Architekturstil erlaubt es, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implement und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.
Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.
Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.
Projektbeschreibung
Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.
Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert werden. In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Je nach Teilnehmerzahl wird/werden einer oder mehrere Services der Projektbörse sowie prototypisch entwickelt. Dazu werden Mocks eines oder mehrere Umsysteme (wie etwa ILIAS oder HOPS) erstellt.
Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu validieren und offene Fragen zu identifizieren.
Beitrag des Projektpartners Capgemini
Projektpartner ist Capgemini (Axel Burghof, Senior Delivery Architect). Capgemini entwickelt für den Einsatz in Kundenprojekten die Devon-Plattform, eine Best-of-Breed-Sammlung von Technologien und Good Practices. Die Zielstellung von Devon ist durchaus vergleichbar mit dem Ziel des Architektur-Blueprints für den Campus. Daher kann Devon als Anregung, Vergleichsmaßstab und Grundlage für das Projekt genutzt werden. Capgemini kann wiederum die Ergebnisse des Projekts in die Devon-Entwicklung zurückfließen lassen. Daher wird Axel Burghof die Entwicklung eng begleiten.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen
- Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
- Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Interesse an professioneller Software-Entwicklung
- Interesse an der Softwarearchitektur
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
Capgemini, Niederlassung Köln
