Software-Schamanin

Soweit korrekt. Wenn ich Software direkt an den Kunden ausliefere passt das auch. Aber mit dem Trend der agilen Entwicklung gehen auch viele Firmen immer mehr den Weg SaaS anstatt direkte Deploys beim Kunden anzubieten. Natürlich auch mit allen kaufmännischen Konsequenzen. Die Frage ist kann ich in der Branche noch Bestand haben, wenn ich den Weg nicht mit gehe? Vielleicht ist meine Qualität bei dem Produkt, dass ich ausliefere durch längere Releasezyklen eine Bessere. Aber die neuen Features werden von der Konkurrenz schneller geliefert, da sie durch Cloud-Infrastruktur und dem Verwenden von zielgerichteter Technoligen viel schneller liefern können. Auch die Leute, die sich mit neuen Technologien auskennen, fallen nicht vom Himmel. Das wissen kommt ja daher, dass man es in einzelnen Projekten mal ausprobiert hat. Eigentlich ist es fast die Regel, dass man im Zuge eines Projektes auch Erfahrungen mit neuen Technologien sammelt. Zudem ist es ja auch meist ein Team, dass diese Erfahrungen sammelt und keine Einzelperson. Das heißt nicht, dass ich alles blind einsetze, aber ich sollte schon den Mut und die Fähigkeit haben an der entscheiden Stelle zu wissen, was ich Einsetzen kann um schneller ans Ziel zukommen.

Wenn ich bereits in der Cloud bin dann ist das durchaus üblich genau das zu machen. Ich schaue welche Technologie mir hilft mein Problem zu lösen. Wenn mir meine relationale Datenbank mehr Probleme als nutzen bringt, versuche es mal für die Teilproblem eine dokumentenorientierte zu nehmen. Durch die lose Kopplung betrifft das ja nur einen Teil des Systems. Das Systeme immer mehr komplett in der Cloud gehostet werden ist auch nicht unüblich um genau diese Flexibilität zu haben.

okay die gab es auch. Aber wenn ich eine Datenbank brauche kann ich mir ein Clouddienst suchen und die mal eben hochfahren. Habe ein gesichertes System, dass ich jeder Zeit nutzen kann. Das ging natürlich früher nicht. Bietet natürlich auch potenzial zu schauen, ob für mein konkretes Problem eine andere Datenbank vielleicht besser geeignet ist als meine jetzige

Bei den jüngeren Entwicklern, die die agile Denkweise mitnehmen ist das meist kein Problem. Schwierig wird es für mich immer bei den "älteren" Die älteren Entwickler, die gewohnt sind, dass sie Konzepte bekommen usw. sind meist sehr irritiert, dass sie eigenverantwortlicher arbeiten müssen oder Entscheidungen vielleicht sehr spät und dynamischer getroffen werden. Wenn die Software agil ist, dann kann man auch nur schwer im Vorfeld planen. Oder man hat Entwickler die selbst anfangen alles bis ins kleinste Detail zu planen anstatt erstmal den MVP umzusetzen. Da sie es aber auch so gewohnt sind an jede Funktionalität zu denken. Meine Vermutung ist, dass das daher kommt, dass Software früher viel langsamer releaset wurde und alles perfekt laufen musste. Während es heute in bestimmten Bereichen "egal" ist, wenn es noch nicht hundertprozentig läuft. Dann wird es halt angepasst und neu deployed. Dafür konnte man schonmal sehen, wie das Feature von den Kunden/Zielgruppe angenommen wird.

Wenn man sich mit dem Thema ausseinander setzt bin ich allerdings auch schnell bei Conway: Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations. Ja das Systeme per Webservice kommunizieren ist keine neue Technologie. Was neu ist, ist dass ich durch Clouddienste Bibliotheken usw. viel schneller bin diese bereitzustellen. Wenn man sich mit dem Thema auseinander setzt, wird immer betont, dass die Teams autark strukturiert sein müssen um autarke Systeme zu erstellen. Wenn ich zum Beispiel ein Frontend- und ein Backendteam mache, habe ich auch zwei Services. Diese sind aber nicht autark und erschweren nur die Kommunikation und die Abhängigkeiten. Oder der klassiker den man häufig findet. Ich habe einen Service/Team der den Zugriff auf meine zentrale Datenbank verantwortet. Für jedes neue Feature muss immer dieser Service angepasst werden. Und das ist meist der Punkt wo man dann sagt Microservices sind blöd weil man in einer Service-Hölle endet.

Jetzt würde ich tatsächlich sagen, dass das realitätsfern ist. Die meisten Firmen haben genau diesen Prozess nicht durchgemacht sondern entweder aus der Laune eines motivierten Mitarbeiters oder aufgrund von Befehl von oben genau das eingeführt. Andere sind nun agil also müssen wir das jetzt auch machen. Gleiches gilt auch für die Architektur andere machen Microservices also müssen wir die jetzt auch machen. Mag sein, dass das wirklich sehr stark abstrahiert ist. Aber für mich sind das Probleme und Fragestellungen mit denen ich mich täglich ausseinander setzen muss. Könnte evtl. an der Wahl der Firmen liegen. Agile Transformation laut Lehrbuch findet man leider selten so dass es immer die Mischwelten sind mit denen man klar kommen muss.

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.

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

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

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. 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.

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.

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.

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!

Hallo zusammen, als Mitleser in diesem Thread möchte ich mich gerne an dieses Thema anhängen. Auch ich bin sehr daran interessiert, mehr über bewährte Methoden zur Förderung von Auszubildenden im Bereich Fachinformatik Anwendungsentwicklung zu erfahren. Besonders wertvoll wären Erfahrungen von anderen Ausbildern oder Auszubildenden. Ich habe einige spezifische Fragen, die mir auf dem Herzen liegen: Verlauf der Ausbildung: Programmierkenntnisse: Wie habt ihr das Programmieren gelernt? Gab es besondere Übungsaufgaben oder Projekte, die euch besonders geholfen haben? Selbstständiges Lernen: Welche Techniken oder Ressourcen könnt ihr empfehlen, um die Azubis zum selbstständigen Lernen anzuleiten? Lehrplaninhalte außerhalb des Programmierens: Wie wurden Themen vermittelt, die nicht direkt mit Programmieren zusammenhängen, wie z.B. unterschiedliche Vorgehensmodelle? Eigene Projekte während der Ausbildung: Wurden neben dem Abschlussprojekt weitere eigene Projekte durchgeführt? Wie war eure Erfahrung damit? Abschlussprüfung: Dokumentation: Als Ausbilder möchte ich meine Azubis beim Erstellen guter Dokumentationen unterstützen. Welche Kriterien sind hierbei wichtig? Maßnahmen in Ausbildungsbetrieben: Welche speziellen Aktivitäten oder Maßnahmen habt ihr in euren Betrieben umgesetzt, um die Ausbildung zu unterstützen? Bei uns gibt es z.B. regelmäßige Präsentationen durch die Azubis. Vorbereitung auf das Fachgespräch: Welche Methoden oder Übungen haben sich als effektiv erwiesen, um die Azubis auf das Fachgespräch vorzubereiten? Ich freue mich auf einen regen Austausch und bin gespannt auf eure Erfahrungen und Ratschläge. P.s: Ich hoffe das passt noch zum Thema, ansonsten würde ich einen neuen Thread aufmachen

Hi, auch ich suche Abschluss- und Zwischenprüfungen mit Lösungen für Fi im Bereich SI und AE. maike.kobiolka@gmail.com Vielen Dank Maike