Microservices, ReactJS und Co: Warum attraktive Software-Architekturen und moderne Technologien wirklich wichtig sind


01.06.2016 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

"Sie erhalten die volle Unterstützung Ihrer Mitarbeiter nur, wenn Sie ihre persönlichen Ziele und Bedürfnisse berücksichtigen"

Ich möchte in diesem Beitrag auf eine Situation eingehen, die man in Software-Projekten, in denen ein IT-Dienstleister Software für einen Kunden entwickelt, immer wieder anfindet und die regelmäßig zu Konflikten führt. Dabei möchte ich insbesondere darstellen, welche Gefahren aber auch gleichzeitig Chancen sich für IT-Dienstleister und Kunden in der Zukunft ergeben.

Die zwei vielleicht unterschiedlichsten Gruppen auf der Welt

Vereinfacht dargestellt, finden wir in Software-Projekten häufig zwei grundsätzlich unterschiedliche Gruppen. Die erste Gruppe ist die eher betriebswirtschaftlich orientierte, die insbesondere das Budget und den zeitlichen Rahmen des Projektes im Fokus hat. In dieser Gruppe finden sich in erster Linie das Management des IT-Dienstleisters, die Projektleitung sowie der Kunde. Wie genau die gewünschte Software umgesetzt wird, d.h. deren Architektur und eingesetzte Technologien werden von dieser Gruppe in erster Linie durch das Budget und den Projektkontext bestimmt. Die zweite Gruppe ist die technisch orientierte. Hier finden wir insbesondere Architekten und Entwickler, d.h. diejenigen, die für die Umsetzung der Software zuständig sind und eine hohe Affinität für technische Aspekte mitbringen. Für diese Gruppe stehen im Rahmen der Umsetzung der Software die Architektur und die eingesetzten Technologien im Vordergrund.

 

 

Wen interessiert eigentlich was

Was passiert nun häufig in Projekten? Die erste, d.h. die betriebswirtschaftlich orientierte Gruppe ist weniger daran interessiert, wie die Software im Detail umgesetzt wird. Jedoch gibt sie durch das Budget und den Projektkontext den Rahmen vor, in dem sich die zweite, d.h. die technisch-orientierte Gruppe bewegen darf. Der Rahmen kann dabei unterschiedlich groß sein. So gibt es Projekte, in denen Programmiersprache, Frameworks etc. vollständig von Architekten und Entwicklern ausgewählt werden dürfen. Es gibt aber genauso Projekte, in denen diese Aspekte fest vorgeschrieben sind. Architekten und Entwickler müssen anschließend mit dieser Situation arbeiten und persönliche Präferenzen hinten anstellen. Ähnlich verhält es sich mit der Architektur der Software: Die erste Gruppe ist weniger an der konkreten Umsetzung interessiert, gibt durch das Budget jedoch vor, wieviel Zeit in eine adäquate Architektur investiert werden darf, während die zweite Gruppe häufig ein großes Interesse an einem sauberen Entwurf und kontinuierlicher Weiterentwicklung der Architektur hat, auch wenn dies ggf. einen höheren Aufwand mit sich bringt.

 

 

 

Um diesen Konflikt zu verdeutlichen, muss man sich anschauen, welche der beteiligten Gruppen welche Sicht auf die Software hat: Die erste Gruppe betrachtet die Software von außen. Hier werden der Funktionsumfang, das User Interface und das verbrauchte Budget wahrgenommen.

Die zweite Gruppe hingegen betrachtet weniger das Außen. Durch die tägliche Arbeit an der Implementierung ist auch der Blick auf das Innenleben und die Architektur gerichtet.

Die Bedürfnisse des anderen verstehen

Um den Konflikt zwischen den Gruppen zu beheben, ist es wichtig, die jeweils andere Gruppe und ihre Bedürfnisse zu verstehen. Für die erste Gruppe gilt es daher, sich zu verdeutlichen, dass das Empfinden der zweiten Gruppe bzgl. dem Innenleben identisch zum Empfinden der ersten Gruppe für das äußere Erscheinungsbild ist. Häufig wird diese Emotion, die mit dem Innenleben, d.h. der Attraktivität der Architektur verbunden wird, als weniger relevant abgewertet. Jedoch hat sie für die zweite Gruppe exakt denselben Stellenwert wie ein attraktives User Interface für die erste Gruppe!

Dies bedeutet im Wesentlichen, dass man sich fragen muss: Wieso darf sich die erste Gruppe an einem unattraktiven User Interface stören, jedoch die zweite Gruppe nicht an unattraktiven Architekturen und Technologien? Es ist dasselbe Empfinden, jedoch nur ein anderes Artefakt. Es muss somit stets klar sein: Das negative Empfinden, das die erste Gruppe mit einem unattraktiven User Interface verbindet, ist genauso unangenehm wie das Empfinden, das die zweite Gruppe mit unattraktiven Architekturen oder Technologien verbindet.

Die Gefahren

Wenn man sich nun die Marktsituation anschaut, dann müssen wir folgendes bedenken: Findet ein Kunde eine Software seitens User Interface oder Funktionsumfang unattraktiv, sucht er sich ggf. einen neuen Dienstleister. Für Architekten und Entwickler gilt mittlerweile eine sehr ähnliche Situation: Wir leben heute in einer Zeit, in der sich die Talente in der IT den Arbeitgeber aussuchen können. Dies bedeutet, dass sich auch Architekten und Entwickler im Falle unattraktiver Architekturen oder veralteter Technologien nach neuen Arbeitgebern umsehen werden.

Dies kann in einem verheerenden Kreislauf enden: Durch den Wegfall von Talenten finden auch weniger innovative Architekturen und Technologien Anwendung, selbst wenn es das Projekt zulassen würde. D.h. es wird in Projekten zunehmend mit veralteten Technologien gearbeitet und auch die Qualität der Ergebnisse sinkt. Dies führt wiederholt dazu, dass der Dienstleister weniger attraktiv für neue Talente ist.

Worauf IT-Dienstleister achten müssen

Was heißt das nun für IT-Dienstleister? IT-Dienstleister müssen sich im Klaren darüber sein, dass durch Budgetlimitierungen herbeigeführte unattraktive Architekturen oder durch den Kunden vorgegebene veraltete Technologien heutzutage mehr als je zuvor eine Gefahr für das eigene Unternehmen darstellen. Architekten und Entwickler suchen nach dem, was auch jeder Anwender von seiner Software bzgl. des User Interface erwartet: Attraktivität, Schönheit etc. Die Welt hat sich diesbezüglich in den letzten Jahren weitergedreht. Wer die Talente in seinem Unternehmen aufnehmen möchte, muss Freiräume schaffen, damit sich Architekten und Entwickler entfalten können.

Wesentlich ist hierbei: Am Ende profitiert auch der Kunde hiervon!

  • Der Dienstleister beschäftigt die Talente des Marktes, d.h. auch im Projekt sind entsprechend qualifizierte Architekten und Entwickler beschäftigt.
  • Es gibt weniger Mitarbeiterfluktuation beim IT-Dienstleister und somit im Projekt des Kunden.
  • Wer sich frei entfalten kann, arbeitet mit Leidenschaft. Der Kunde erhält somit Mitarbeiter, die über den Tellerrand hinaus- und im Interesse des Kunden denken. Der Kunde erhält mehr als nur Dienst nach Vorschrift.
  • Neue Technologien bieten ggf. auch fachlich neue Möglichkeiten (IT enables Business).

Für die erste Gruppe bedeutet dies, sich immer bewusst zu machen, welchen Stellenwert die zweite Gruppe hat und welche Bedürfnisse sie treiben. Wenn wieder einmal diskutiert wird, ob Microservices, ReactJS oder ein anderes Framework eingesetzt werden soll, geht es nicht nur um den fachlichen Mehrwert, der für die Software entsteht. Es geht vielmehr um die Motivation und um die Leidenschaft, die entsteht, wenn Architekten und Entwickler die Möglichkeiten haben, sich mit diesen Themen zu beschäftigen. Für den IT-Dienstleister heißt es somit, wachsam zu sein, um derartige Gefahren frühzeitig zu erkennen. Werden solche Gefahren erkannt, so sollte bewusst darüber nachgedacht werden, diese dem Kunden transparent zu machen, so dass gemeinsam an einem Weg gearbeitet werden kann, der die Bedürfnisse aller Beteiligten berücksichtigt.

Ergänzung: Ich habe in diesem Artikel bewusst den Fokus darauf gesetzt, dass die erste Gruppe die Technologieaffinität der zweiten Gruppe und somit deren persönliche Bedürfnisse nachvollziehen können muss, um die Relevanz dieses Sachverhalts hervorzuheben. Selbstverständlich sollte dieses Verständnis stets auf Gegenseitigkeit beruhen. D.h. auch die zweite Gruppe sollte sich im Klaren darüber sein, dass es gewisse Rahmenbedingungen (Budget etc.) gibt, die seitens der ersten Gruppe nicht frei gewählt werden können. Es gilt daher wie so häufig einen gesunden Kompromiss zwischen den Bedürfnissen beider Gruppen zu finden.

Acknowledgements: Danke an meinen Kollegen Dr. Andreas Baumann für die spannenden Diskussionen zu diesem Thema. Wir haben die Ergebnisse auch im Rahmen des Architekturworkshops der iteratec am 28. Oktober 2015 als Streitgespräch präsentiert.

 

 

Diesen Artikel bewerten
 
 
 
 
 
 
 
0 Bewertungen (0 %)
Bewerten
 
 
 
 
 
 
1
5
0
 

Artikel im Warenkorb:

0