Wandel des Mindsets in der Softwareentwicklung – Warum und sollte man mitgehen?

[Software-Schamanin]

 

Hallo zusammen,

ich bin sehr interessiert an der Entwicklung der Softwarearchitektur und der damit verbundenen Entscheidungsprozesse in Unternehmen. Insbesondere fasziniert mich der Übergang von traditionellen Core-basierten, monolithischen Architekturen zu modernen, modularen Architekturen wie Microservices.

Mich würde besonders die Meinung der lang erfahrenen Softwarearchitekten interessieren. Die vielleicht auch vor 10 - 15 Jahren Software geplant haben. 

Einige Punkte, die ich gerne diskutieren möchte:

Historischer Kontext: Warum waren früher Core-basierte, monolithische Architekturen der Standard? Welche technologischen und geschäftlichen Faktoren haben diesen Ansatz beeinflusst?

Wandel zu Modularität: Was waren die treibenden Kräfte hinter der Bewegung hin zu modularen und Microservices-Architekturen? Wie haben sich Geschäftsanforderungen und technologische Fortschritte darauf ausgewirkt?

Erfahrungen und Herausforderungen: Welche Erfahrungen habt ihr beim Übergang in euren Projekten und Organisationen gemacht? Welche Herausforderungen und Vorteile ergaben sich aus diesem Wandel?

Notwendigkeit des Wandels für Unternehmen: Muss man als Firma den Weg zur Microservice-Architektur mitgehen, um konkurrenzfähig zu bleiben? Oder gibt es Fälle, in denen traditionelle Ansätze noch sinnvoll sind?

Ähnlichkeiten in Firmenarchitekturen: Ich finde es interessant, dass viele Firmen ähnliche "alte" Architekturen haben, die alle in eine ähnliche Richtung transformiert werden sollen. Was sind eure Gedanken dazu?

Zukunft der Softwareentwicklung: Wie seht ihr die Zukunft der Softwarearchitektur? Welche Trends oder Entwicklungen haltet ihr für besonders wichtig?

Ich freue mich auf einen regen Austausch von Gedanken, Erfahrungen und Meinungen zu diesem spannenden Thema. Eure Einsichten sind wertvoll, um ein umfassenderes Bild der Evolution in der Softwareentwicklung zu erhalten.

Vielen Dank für eure Beiträge!

 

[Chris-Info]

Die Frage ist irgendwie komisch.
Modularisierung und Microservices sind ja kein Mindset, genau so wenig wie eine Bogenbrücke ein Mindset oder "Trend" ist. Es ist einfach nur eine Form der Architektur. Man sucht die Architektur aus, die dann für das jeweilige Projekt und die Anforderungen am besten passt.

Und ja Microservices kamen erst später, weil Monolithen quasi die Ausgangssituation waren, da man in der Anfangszeit der Softwareentwicklung garnicht die Möglichkeiten hatte Dinge zu modularisieren bzw. das von der Programmiersprachen, den Entwicklertools etc. garnicht so richtig unterstützt wurde. Heute haben wir da deutlich mehr Spielraum und sollten den, wie schon gesagt, auch einfach ausschöpfen um die Lösung auf das Problem anzupassen.

[Rabber]

Ein wesentlicher Grund, warum microservices und -frontends heute so modern sind, ist für mich die Fähigkeit, unterschiedliche Quellen und Systeme über einen Standard zu vereinen. REST und HTTP spricht heute nahezu alles und jeder. Das ist eine große Stärke. Gerade in den gewachsenen Landschaften der IT.

das war früher anders. Da hatte jede Plattform und jede Technologie eigene Schnittstellen, sodass Kompatibilität nicht so einfach herzustellen war. Häufig auch gar nicht nötig und erst recht nicht gewünscht. Da war ein CSV-Import der Gipfel der Interoperabilität.

Heute investiert sogar Microsoft groß in Open Source. Früher undenkbar. Da hat sich was getan, in der IT-Welt.

—

übrigens haben beide Ansätze ihre vor und Nachteile. Modern ist nicht immer besser.

Die Komplexität moderner Architekturen ist häufig um einiges höher als die klassischer Varianten. Performance, Fehlerbehandlung und Wartbarkeit leiden auch, wenn alles über hundert Schichten und Systeme verteilt läuft.

Es gibt durchaus noch Szenarien, wo die klassische, monolithische Anwendung im Vorteil ist. wird gerne verdrängt.

[Software-Schamanin]

vor 2 Stunden schrieb Chris-Info:

Die Frage ist irgendwie komisch.
Modularisierung und Microservices sind ja kein Mindset, genau so wenig wie eine Bogenbrücke ein Mindset oder "Trend" ist. Es ist einfach nur eine Form der Architektur. Man sucht die Architektur aus, die dann für das jeweilige Projekt und die Anforderungen am besten passt.

Und ja Microservices kamen erst später, weil Monolithen quasi die Ausgangssituation waren, da man in der Anfangszeit der Softwareentwicklung garnicht die Möglichkeiten hatte Dinge zu modularisieren bzw. das von der Programmiersprachen, den Entwicklertools etc. garnicht so richtig unterstützt wurde. Heute haben wir da deutlich mehr Spielraum und sollten den, wie schon gesagt, auch einfach ausschöpfen um die Lösung auf das Problem anzupassen.

 

Ist die Microservices-Architektur nicht eher aus dem agilen Mindset heraus entstanden? Es ist ja nicht so, dass jemand sich einfach hingesetzt hat und entschieden hat, 'Jetzt machen wir Microservices'. Vielmehr ist es ein Muster oder Pattern, das über die Jahre hinweg gereift ist. 

Im Kontext der agilen Entwicklung, die schnelle Anpassungsfähigkeit und kontinuierliche Verbesserung betont, haben sich Microservices als eine natürliche Evolution herausgebildet. Sie ermöglichen Teams, unabhängig und iterativ an verschiedenen Teilen einer Anwendung zu arbeiten, was wiederum gut zu den Prinzipien des agilen Managements passt.

Ein wichtiger Aspekt dabei ist auch die Entwicklung einer neuen Fehlerkultur. Durch die Aufteilung in kleinere, unabhängige Services wird das Risiko eines vollständigen Systemausfalls verringert, und Fehler können schneller isoliert und behoben werden. Dies fördert eine Kultur, in der Fehler als Gelegenheit für Lernen und Verbesserung gesehen werden, anstatt als Katastrophen.

Zudem ist die Einführung von Microservices oft mit einer Umstrukturierung der Organisation verbunden. Teams werden kleiner und autonomer, Entscheidungsprozesse werden dezentralisiert und es gibt einen stärkeren Fokus auf interdisziplinäre Zusammenarbeit. Diese organisatorischen Veränderungen sind entscheidend, um die Vorteile von Microservices voll ausschöpfen zu können.

 

[0x00]

Modularität und Microservices ist nicht das selbe. Modularität gab es schon früher - das ist einer der grundlegenden Prinzipien guter Softwarearchitektur, man kann ja auch eine monolithische Applikation sehr modular aufbauen.

Der große Benefit von Microservices ist eigentlich nur das separate Deployment - den Rest kann man auch ohne Microservices bekommen. Wenn man nicht separat deployen will, dann benötigt man auch keine Microservices. Und Deployments sowie das assoziierte Tooling sahen halt vor 10 bis 15 Jahren ganz anders aus.

Meiner Meinung nach sollte man schon auf gute Modularität und sinnvolle Kopplung achten - alles in Microservices zu splitten, nur weil das Hip ist, ist allerdings nicht der Weg. Ganz im Gegenteil, ich würde sogar eher in die andere Richtung lehnen: Wenn es keinen Grund gibt, wieso etwas ein Microservice werden sollte (e.g. es wird kein separates Deployment benötigt, Lastverteilung ist vorhersehbar und gleichmäßig), dann sollte man auch nicht zum Microservice greifen. Microservices und verteilte Systeme bringen auch eine Menge zusätzliche Komplexität mit sich (z.B. Garantien in verteilten Systemen, Debugging und Error Tracing über mehrere Services) und auch Monolithen haben ihre Daseinsberechtigung - auch heute noch.

Wer meint Modularität, sinnvolle Kopplung und angemessene Abstraktion nur durch Microservices erreichen zu können, der sollte wirklich noch einmal zu den Basics zurückkehren.

[allesweg]

vor 8 Stunden schrieb Mickey0501:

Durch die Aufteilung in kleinere, unabhängige Services wird das Risiko eines vollständigen Systemausfalls verringert

Nur weil der Prozess statt von einem Monolithen abhängig ist, sondern jetzt von vielen Teilchen soll das Risiko sinken?

Es können ggf noch Einzelschritte ausgeführt werden, jedoch sobald auch nur ein Kettenglied bricht, kann der Prozess nicht mehr vollständig durchlaufen werden!

Falls das Monitoring nicht ausgereift ist, kann ein Fehler in Service5 erst bei Service8 bemerkt werden. Oder aber aufgrund verteilter Zuständigkeiten kommt es durch Meldewegs-Verlusten zu Verzögerungen in der Behebung, ... oderoderoder.

Wenn ein Monolith ausfällt, erfahren das die Zuständigen üblicherweise binnen Sekunden - durch den Aufschrei der Anwender.

Modularisierung oder Microservices als Alleinzweck ist unsinnig!

Und: selbst am alten, monolithischen Mainframe kann man Modularisierung mit separatem Deployment leben!

vor 7 Stunden schrieb 0x00:

Wer meint Modularität, sinnvolle Kopplung und angemessene Abstraktion nur durch Microservices erreichen zu können, der sollte wirklich noch einmal zu den Basics zurückkehren.

^THIS!

[Tratos]

Früher als noch mit wenig Speicherplatz und geringen Grafischen Mitteln gearbeitet wurde waren die Produkte oft besser durchdacht und Programmiert.

Heutige Anwendungen haben zwar ein schönes GUI aber durch unterschiedliche Projektbeteiligte, entsprechende Biliotheken die zugekauft wurden, oder von Drittanbietern bereitgestellt werden kommen eine menge mögliche Fehlerquellen zu stande. Ebenso läuft die Software oft nur eine begrenzte Zeit ohne weiteren Support, so ein DOS Spiel bekommst du heute noch im Emulator zum laufen, der benötigt nicht irgendein Framework.

 

[TooMuchCoffeeMan]

Ich frag' jetzt mal ganz ketzerisch. Ist das eine Bachelor-/Master-Arbeit?

[Maniska]

vor 24 Minuten schrieb TooMuchCoffeeMan:

Ich frag' jetzt mal ganz ketzerisch. Ist das eine Bachelor-/Master-Arbeit?

Oder eine Hausaufgabe/Hausarbeit. Die Fragen klingen irgendwie zu sehr nach Lehrer

vor 58 Minuten schrieb Tratos:

Früher als noch mit wenig Speicherplatz und geringen Grafischen Mitteln gearbeitet wurde waren die Produkte oft besser durchdacht und Programmiert.

Weil sie oft gar keine andere Wahl hatten. Eine Software musste mit den zum damaligen Zeitpunkt vorhandenen Ressourcen laufen, da war nichts mit "hey Kunde, rüste mal deinen Rechner auf, dann läufts auch anständig", und sie musste fertig und funktionstüchtig sein, es gab kein Internetz für die Patchverteilung. Und selbst wenn, das Verteilen und Einspielen wäre deutlich aufwändiger gewesen, das hätte man als Softwarebude nicht allzu oft machen können.

[allesweg]

Je öfter ich die drei Beiträge lese, desto theoretischer und praxisferner klingen sie.

Für mich existiert kein kausaler Zusammenhang zwischen agil, Microservices und Unternehmensorganisation.

Welcher Studiengang ist das?

[Software-Schamanin]

Danke für Ihr Feedback. Ich beschäftige mich nun seit über 10 Jahren mit der Softwarearchitektur in unterschiedlichen Firmen und habe in den letzten 2 - 3 Jahren festgestellt, dass ein agiles Mindset bei Entwicklern wesentlich dazu beiträgt, eine Microservices-Architektur erfolgreich zu gestalten. Aus meiner Erfahrung wird es oft problematisch, wenn man versucht, Microservices mit einer traditionelleren, wasserfallartigen Herangehensweise umzusetzen. 

In meiner Praxis habe ich beobachtet, dass Teams, die agil arbeiten und denken, besser in der Lage sind, die Flexibilität und Unabhängigkeit, die Microservices bieten, zu nutzen. Sie können schneller auf Veränderungen reagieren, iterativ arbeiten und sind offener für kontinuierliche Verbesserungen. 
Auf der anderen Seite habe ich gesehen, dass Teams, die einer strikteren, wasserfallartigen Methodik (oder pseudo Agilität) folgen, oft Schwierigkeiten haben, die dynamische Natur von Microservices zu handhaben. Dort wird eher dazu geneigt zentrale Funktionen wegzukapseln und eine gemeinsame Basis zu verwenden. Was immer dazu führt, dass man die Vorteile nicht optimal nutzen kann. 

Wenn man versucht eine neue komplexe Architektur einzuführen geht dies meist nur, wenn man auch das Team oder die Leute mitnimmt. Nicht nur technologisch sondern auch methodisch.

 

[allesweg]

Ich habe beobachtet, dass in echt-agilen Teams der Altersdurchschnitt deutlich geringer ist und auf jungen Architekturen gearbeitet wird. Andererseits arbeiten Wasserfall-Teams üblicherweise auf historisch gewachsenen Architekturen, welche vor vielen Jahren bis Jahrzehnten - oft von den heute noch aktiven Mitarbeitern selbst - entworfen wurden.

vor 12 Minuten schrieb Mickey0501:

die Flexibilität und Unabhängigkeit, die Microservices bieten

Darauf, dass einige hier Microservices nicht als zwingende Voraussetzung für Flexibilität sehen gehst du gar nicht ein,

vor 13 Minuten schrieb Mickey0501:

dass ein agiles Mindset bei Entwicklern wesentlich dazu beiträgt, eine Microservices-Architektur erfolgreich zu gestalten

In welcher Richtung willst du hier einen Kkausalzusammenhang konstruieren?

[Software-Schamanin]

 

vor 39 Minuten schrieb allesweg:

Ich habe beobachtet, dass in echt-agilen Teams der Altersdurchschnitt deutlich geringer ist und auf jungen Architekturen gearbeitet wird. Andererseits arbeiten Wasserfall-Teams üblicherweise auf historisch gewachsenen Architekturen, welche vor vielen Jahren bis Jahrzehnten - oft von den heute noch aktiven Mitarbeitern selbst - entworfen wurden.

 

Leider mischen sich die beiden Welten heutzutage immer mehr:

In verschiedenen Teams sehe ich regelmäßig die Spannung zwischen traditionellen und agilen Arbeitsweisen. Oft müssen 'alte' und 'neue' Ansätze zusammengebracht werden, insbesondere wenn sich die Welt der Softwareentwicklung weiterentwickelt und neue Technologien in bestehende Systeme integriert werden müssen. 

Diese Herausforderung wird noch verstärkt, wenn junge Entwickler, die mit agilen Methoden vertraut sind, in Teams kommen, die traditionell arbeiten. Sie sehen oft die bestehende Software als veraltet an und möchten sie durch neuere Ansätze ersetzen. Als Architekt steht man dann vor der Aufgabe, beide Welten zu vereinen und alle Beteiligten auf diese Reise mitzunehmen.

 

vor 39 Minuten schrieb allesweg:

In welcher Richtung willst du hier einen Kkausalzusammenhang konstruieren?

 

Im agilen Kontext ist eine experimentierfreudige Haltung erforderlich. Man probiert Dinge aus und wenn sie nicht funktionieren, versucht man es erneut, idealerweise mit lose gekoppelten Systemen. Das erlaubt es, bei Bedarf einen Service zu verwerfen und neu zu beginnen. Genau da merkt man die Vorteile der Microservice-Architektur.

Im Gegensatz dazu erfordert das Wasserfallmodell viel Vorplanung und ausgiebige Entscheidungsfindung, was bei zentralen Komponenten sinnvoll sein kann. Meist erfordert dieses Vorgehen auch eine erfahrene "Elite" die dazu Berufen ist die Entscheidungen zu treffen und den Core-Teil zu entwickeln. Die anderen Entwickler können diesen dann "sturr" nutzen und können mit deren Hilfe alles umsetzen. Einarbeiten und experimentieren mit neuen Technologien entfällt. Das erfordert schon ein Umdenken. Meist hört man setze wie: Das muss ausführlich geplant werden, Ich brauche genaue Vorgaben usw. 

 

 

 

Bearbeitet 6. Februar von Mickey0501

[MiaMuh]

Irgendwie klingt das hier für mich zu viel nach Wischiwaschi und nicht nach wen mit Berufserfahrung oder?

Es ist immer schön von den verschiedenen Arbeitsmodellen zu reden. Die kann man auch in jedem Buch nachlesen. Die Vor- und Nachteile.

[Datawrapper]

Nennt mich blöd, aber ich verstehe den Sinn dieses Threads nicht so ganz. Alles was ich hier lese, kann ich so in Büchern nachlesen. Das sind die absoluten Basics der Softwareentwicklung. Also worüber reden wir jetzt hier?

[allesweg]

Geht es dir jetzt um agil vs. Wasserfall? Oder um Monolith vs. Microservices? Oder Modularisierung?

Oder Onboarding neuer Mitarbeiter, welche an bestehenden Unternehmensstrukturen rütteln wollen?

[Chris-Info]

Irgendwie sind wir hier im Uncanny Valley der Gesprächsführung...

Den interessantesten Gedanken finde ich eigentlich dass Modularisierung ja auch in Monolithen schon lange möglich ist. Was mich wiederum zu der These bringt zu fragen, ab wann wird aus einem Modul egtl. ein Microservice. Wenn man es mal rein von der Funktionalität her betrachtet ist der Übergang ja sehr fließend. Die Entscheidung aus einem Modul einen Microservice zu machen scheint mir dann doch eher beeinflusst durch technische Anforderungen wie z.B. man will etwas "Cloud Native" bei AWS/AZure etc aufsetzen oder das Modul soll auch Funktionalitäten für Externe Systeme/Systeme von Drittanbietern (Salesforce, SAP whatever) haben und es macht darum Sinn das Modul als eigenständigen Service aufzusetzen.

Etc. etc

[Software-Schamanin]

vor 8 Minuten schrieb MiaMuh:

Irgendwie klingt das hier für mich zu viel nach Wischiwaschi und nicht nach wen mit Berufserfahrung oder?

Es ist immer schön von den verschiedenen Arbeitsmodellen zu reden. Die kann man auch in jedem Buch nachlesen. Die Vor- und Nachteile.

Da hast du soweit recht. Die Vor- und Nachteile werden in diversen Büchern erläutert. Auch, warum klassische Modelle nicht mehr zeitgemäß sind usw. 

Ich kann in jedem Buch nachlesen, wie agil entwickelt wird und ich kann mir ein Experten suchen der mir das Vorgehen bei bringt. 

Ich gehe aber die Reise nicht alleine. Ich muss diverse Menschen mit unterschiedlichen Erfahrungen und Ansichten mitnehmen. Das man besten so, dass am Ende das bestmögliche Ergebnis rauskommt. Das geht am besten, wenn man diese kennt und versteht. Für die agile Welt ist das tatsächlich sehr einfach. Aber für die Beurteilung der "alten" Welt fällt es mir tatsächlich manchmal etwas schwer, da ich dort nur die "Endphase" mitbekommen habe

[allesweg]

vor 8 Minuten schrieb Mickey0501:

Ich gehe aber die Reise nicht alleine. Ich muss diverse Menschen mit unterschiedlichen Erfahrungen und Ansichten mitnehmen.

In welcher Rolle sollst du bei deinem Arbeitgeber die Führung bei diesem Kulturwandel übernehmen?

[Software-Schamanin]

vor 8 Minuten schrieb allesweg:

Geht es dir jetzt um agil vs. Wasserfall? Oder um Monolith vs. Microservices? Oder Modularisierung?

Oder Onboarding neuer Mitarbeiter, welche an bestehenden Unternehmensstrukturen rütteln wollen?

Mir geht es ein bisschen darum zu verstehen, wie sich das Bild oder die Arbeitsweise des Softwareentwicklers im laufe der Zeit gewandelt hat und wie das unsere Architektur beeinflusst. 

Als noch regelmäßig die "alte" Modelle verwendet wurden, gab es ja auch in Unternehmen noch hierachischere Strukturen und im Gegensatz zu unserer agilen Welt wurde weniger auf Eigenverantwortung gesetzt. 

Meine Theorie war, dass sich genau diese unterschiedlichen Denkweisen auch in der Architektur wiederspiegeln und es den "alten Entwickler" deshalb auch schwerer fällt die neuen Ansätze zielführend einzusetzen. Zum Beispiel:

- die Idee von autarken Teams ohne detaillierte Architekturplanung  
- dass man mit einem MVP startet, der noch nicht hundertprozentig perfekt ist, um erstmal zu prüfen, ob das ganze von der Zielgruppe angenommen wird
- Das Prinzip lieber schnell und oft neue Versionen bereitzustellen

Es geht mir auch um das Onboarding neuer Mitarbeiter, die diese Sichtweise ins Unternehmen bringen. Denn um am Markt mitzuhalten wird meiner Meinung nach diese Sichtweise dringend benötigt. Ansonsten ist die Konkurrenz immer schneller mit innovativen Ideen

 

[0x00]

vor 10 Minuten schrieb Chris-Info:

Den interessantesten Gedanken finde ich eigentlich dass Modularisierung ja auch in Monolithen schon lange möglich ist. Was mich wiederum zu der These bringt zu fragen, ab wann wird aus einem Modul egtl. ein Microservice. 

Meiner Meinung nach durch ein separates Deployment. Ich kann modularen Code bauen, alles wichtige hinter APIs verstecken (was man sowieso machen sollte), den Code so schreiben, dass er Lastpeaks in verschiedenen Regionen handlen kann und dennoch alles auf einer Maschine laufen lassen.

Aber sobald ich ein separates Deployment auf andere Hosts habe, wird ein Modul zu einem Microservice. Ich habe auf einmal eine echte Unabhängigkeit mit allen Vor- und Nachteilen und - sollte ich es davor nicht gehabt haben - auch ein verteiltes System.

[allesweg]

Jetzt bringst du noch TimeToMarket mit rein?

Früher war der klassische Softwareentwickler für die Implementierung der Vorgabe verantwortlich, der Anforderungsmanager für die Qualität der Anforderungen, der Projektleiter für die Termin- und Kapazitätsplanung, der Anayst für die Anforderungserstellung, ...

Welche dieser dezidierten Personen-Rollen-Zuordnungen gibt es in einem echt-agilen Umfeld noch? Welche Freigabeschleifen bremsen zwischen Idee und potentiell produktiv einsetzbarem Artefakt?

Wenn man insel-agil werden will, gibt es immense Reibungsverluste zu klassisch planenden Einheiten, alleine aufgrund der Planungszeiträume.

Daran scheitern viele "Agilitäts-Einführungen" und man endet in Scrumbut und CargoCult.

Aber das schweift in eine Philosophie-Diskussion aus, welche den Rahmen eines Forenbeitrags sprengt. Das ist etwas für Changemanagement-Workshops!

[allesweg]

vor 6 Minuten schrieb 0x00:

Aber sobald ich ein separates Deployment auf andere Hosts habe, wird ein Modul zu einem Microservice.

ich bin so böse und erweitere: ein Modul mit genau einem Zweck, welches von verschiedenen anderen Systemen unabhängig voneinander aufgerufen werden kann.

[Software-Schamanin]

vor 3 Minuten schrieb allesweg:

In welcher Rolle sollst du bei deinem Arbeitgeber die Führung bei diesem Kulturwandel übernehmen?

Leider auch in der Rolle als Architekt. Die meisten Teams bestehen aus den Mischformen. Und beim Designen und Strukturieren von Software hilft es, wenn das Team die Entscheidungen mitträgt und man nicht einfach von oben vorgibt, dass etwas so gemacht wird. 

Das gleiche gilt übrigens auch für die Art wie ich entwickle. Aber die Aufgabe liegt dann meist hauptverantwortlich woanders. 

 

[allesweg]

vor 1 Minute schrieb Mickey0501:

Und beim Designen und Strukturieren von Software hilft es, wenn das Team die Entscheidungen mitträgt und man nicht einfach von oben vorgibt, dass etwas so gemacht wird. 

Solange man objektiv begründen kann, was man vorgibt, tragen Teams die Entscheidung üblicherweise mit?