Ich will heute die Zeit nutzten und einen kurzen Beitrag über meine Gedanken zu „Microservices“ schreiben.

In meiner Beratung und bei den Kunden, die ich begleite, spielen die Strategie und die wechselnden Anforderungen an digitale Lösungen häufig eine sehr große Rolle. Gerade weil das Thema aber meistens diese gesamte Firma betrifft, werden Ideen auch während des Projektes entwickelt und sorgen dafür, dass Projekte schnell schwer zu managen sind. Es gibt nun immer die verschiedenen Ansichten – so gibt es immer eine Ansicht des Auftraggebers und der Agentur, die Anforderungen umsetztet. Gerade, und besonders in Festpreisprojekten, wird dann die zu Beginn noch so harmonische Stimmung gegen Ende eines Projektes doch immer angespannter. Zumeist können Anforderungen noch zu gut dokumentiert und festgeschrieben sein: Sie ändern sich! Erwartungen, gefühlte Erwartungen und zumeist das Bild einer perfekten Lösung werden währen des Projektes verändert.
Um das klar zu sagen: Das ist auch gut so! Denn ich als Berater oder auch der Dienstleister in seiner Rolle als „Umsetzer“ wollen ja, dass Kunde lernt, dass ein Portal, eine digitale Lösung – wie auch immer diese aussieht – immer der erste Schritt und der Beginn einer langen Zusammenarbeit ist. 

Die Zeit verändert sich – Lösung und notwendige Funktionen auch!

Wie geht man nun aber damit um, dass währen der nicht all zu langen Projektphase diese Wünsche sich ändern und damit der Scope ab dem der Kunde zufrieden ist? Jeder Key Accounter würde jetzt sagen: CR’s! Das birgt immer die Gefahr, dass der politisch und nur gefühlte Scope nicht wirklich erweitert wird. Der Kunde läuft in die Gefahr, „nie fertig“ zu werden – die Agentur in Verdacht, zu viele Kosten zu verursachen.

Ich empfinde die Lösung – zugegeben nur, wenn Projekte starten – über den Gedanken der Microservices sehr angenehm.

Ich will nicht zu sehr an dieser Stelle heute auf die Technik eingehen – aber grundsätzlich bin ich ein extremer Freund von „kapselbaren“, kleinen Lösungen, die miteinander gut harmonisieren.
Große Lösungen – die bestimmt perfekt funktkionieren – aber unglaubliches Know-How bei allen Beteiligten benötigen, halte ich für eine Bremse, um Speed aufzunehmen. Die Abhängigkeiten innerhalb der Softwarelösungen sind riesig – einzelnen Komponenten können nie einzeln für sich Ihre Funktion beweisen.

Anders ist es bei dem Gedanken der Microservices! So werbe ich seit Jahren dafür, dass man einzelne Funktionen (in Scrum Projekten würde man EPICs sagen) als geschlossene, unabhängige, geclusterte Anforderungen betrachtet – die notfalls ohne Sinn aber mit Ergebnis funktionieren würden, ohne dass die vollständige Lösung bereits funktioniert. Microservices verlangen ein hohes Verständnis für das Business und stellen besonders an den Architekten von Projekten hohe Anforderungen. Der Architekt wechselt in seiner Rolle als „technischer Architekt“ in die Rolle des Business Architekten. Er sollte näher beim Business sein, als das er beim Entwickler ist. Damit wächst die Verantwortung des gesamten Entwicklungsteams und sorgt dafür, dass diese in einzelnen Fragmenten arbeiten können und Lösung produzieren, die wie ein Puzzle später zusammenpassen müssen. Ein Verständnis bis ins kleinste Detail der Business Prozess ist für den Architekten somit absolut notwendig.

Aber sind wir ehrlich: In fast allen Projekten kommt irgendwann der Punkt, in dem man sich fragt, wer noch den Überblick über den gesamten Businessprozess hat. Ist diese Rolle dann nicht beim Architekten – selbst wenn nur auf Zeit – wird es kein erfolgreiches Projekt geben! Alle Projekte, die erfolgreich waren, sind Projekte, die genau wussten, welche Prozesse an welcher Stelle gebraucht werden und welche abhängig sind. Unternehmen, die erfolgreich digitale Projekte umgesetzt haben, hatten Prozessschaubilder. Setzt man den Gedanken von Microservices auch in der Steuerung der Projekte konsequent um, so wird Ihr Projekt ein Erfolg.

WordPress Cookie Hinweis von Real Cookie Banner