Obwohl agile Prinzipien mittlerweile in der Softwareentwicklung weit verbreitet sind, werden viele IoT-Projekte nach wie vor auf traditionelle (zunehmend veraltete) Weise umgesetzt. Die Folge: Nicht wenige IoT-Projekte dauern viel länger als geplant oder scheitern völlig.

Eine Herausforderung für Entwicklungsteams in IoT-Projekten besteht darin, ein breites Spektrum an Fähigkeiten in Bereichen wie Hardware, Netzwerke, Sicherheit, Cloud-Plattformen, Analytik, künstliche Intelligenz und Schnittstellen (API) abzudecken. Diese Fähigkeiten sind in den meisten Organisationen traditionell sehr siloartig verteilt. Der Austausch und die Zusammenarbeit zwischen “Zuständigkeitssilos” funktioniert in vielen Fällen eingeschränkt bis gar nicht. Es fehlt eine gemeinsame Vision.

In IoT-Projekten müssen Entwicklungsteams jedoch integriert auf ein gemeinsames Ziel hinarbeiten. Dies ist einer der Hauptgründe, warum die traditionelle IoT-Entwicklung nach der Wasserfallmethode an ihre Grenzen stößt. Das beginnt schon bei der Projektsteuerung: Ein IoT-Projekt, das mit Methoden und Werkzeugen des klassischen Projektmanagements, wie GANTT-Charts geplant und gesteuert wird, läuft früher oder später aus dem Ruder und endet im Extremfall im Chaos. Das zeigt unsere Erfahrung.

Teams im IoT Development: Agile Zusammenarbeit statt Zuständigkeitssilos

“Projekte, die agil umgesetzt wurden, weisen eine Erfolgsquote von 64 Prozent auf, verglichen mit 49 Prozent bei Projekten, die mit traditionellen Methoden umgesetzt wurden” – Boris Shiklo, CTO bei ScienceSoft.

Agile Software-Entwicklung konzentriert sich auf Wertschöpfung statt Umsetzung einzelner Funktionen. Entlang von Wertschöpfungskette werden kleine funktionierende Teile der Software in Iterationen erstellt, statt auf ein komplettes Produkt (als Summe von Funktionen) hinzuarbeiten. Das hat in der Software-Entwicklung den großen Vorteil, dass Nutzer während der Entwicklungsphase Feedback geben und Anforderungen ändern können, ohne das gesamte Projekt in Gefahr zu bringen. 

In IoT-Projekten ist dies besonders wichtig, da hier die fachlichen Anforderungen und das Zusammenwirken verschiedener Disziplinen und Zuständigkeitsbereiche in der Regel deutlich komplexer ist als in “normalen” Software-Projekten.

“IoT-Projekte sind nur dann erfolgreich, wenn alle Beteiligten an einer gemeinsamen Vision arbeiten. Ein Denken in Zuständigkeitssilos führt nicht zum Ziel.” – Igor Pshul, Solution Architect.

Agiles Manifest (2001) – Ausschnitt

• Funktionierende Software ist wichtiger als umfassende Dokumentation
• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

In IoT-Projekten, in denen Teams aus verschiedenen Bereichen der Architektur – Frontend, Middleware und Hardware – integriert zusammenarbeiten müssen, kommt es besonders auf eine reibungslose Interaktion zwischen Individuen an – Kommunikation ist ein erfolgskritischer Faktor. Um optimalen Austausch zu gewährleisten, braucht es zum einen die Bereitschaft im Team, einer gemeinsamen Vision zu folgen und zum anderen ein Projektmanagement, das die Zusammenarbeit über Zuständigkeitsgrenzen hinweg etabliert.

Die Rolle des Projektmanagers in agilen IoT-Projekten

Der Erfolg von IoT-Projekten steht und fällt mit der Interaktion zwischen Entwicklern aus verschiedenen Bereichen der IoT-Architektur. Damit verändert sich auch die Rolle des Projektmanagements – weg von Aufgaben und Timelines hin zum Menschen. “People-Management” statt “Projekt-Management”.

Ziel des Projektmanagements in IoT-Projekten ist es, Entwickler in jeder Situation zu befähigen, wechselnde Rollen in agilen Teams zu übernehmen. “Projektmanager” – egal ob “Product Owner” oder “Scrum Master” – müssen in der Lage sein, Rollen und Kompetenzen in den Teams dynamisch zu steuern und die Rahmenbedingungen dafür schaffen, dass die Interaktion zwischen Entwicklern und den Teams jederzeit reibungsfrei funktioniert. 

“Jetzt ist es ein extremer Teamsport […] wir haben viel mehr Releases, aber die Prototypen sind kleiner und es gibt viel mehr Komponenten.” – Harel Kodesh, ehem. CTO bei GE Software.

Gemeinsame Vision & vertikale Orientierung im Team

In Zeiten, in denen sich Technologien und Anforderungen an Software-Systeme immer schneller ändern, verändern sich auch Architekturen – weg von einzelnen Funktionen (horizontal) in Monolithen hin zu Wertschöpfungsketten (vertikal) in modularen Systemen. Dementsprechend muss sich auch die Organisation von Teams in IoT-Projekten vertikal ausrichten. Statt spezialisierte Teams für die Entwicklung einzelner Funktionen werden cross-funktionale Teams gebildet, die die Features einer Wertschöpfungskette umsetzen. 

Die Herausforderung für Projektmanager besteht vor allem in Unternehmen, die klassisch “horizontal ticken”, darin, eine vertikale Orientierung im Team (und im Produkt) zu etablieren. Dazu braucht es eine agile Kultur und eine gemeinsame Vision für das Produkt und den Weg zum Ergebnis. Fehlen diese Kultur und Vision im Team (oder auch nur bei einzelnen Entwicklern) dann ist Reibung vorprogrammiert und das Risiko zu scheitern extrem hoch.

Kommunikationsblockaden überwinden

In einem idealtypischen IoT-Projekt arbeiten Entwickler aus allen Bereichen der System-Architektur in agilen Teams zusammen. In der Praxis können jedoch besonders in internationalen Projekten unterschiedliche Sprachen, Zeitzonen, Kulturen und Arbeitsweisen die Zusammenarbeit und den Austausch erschweren, im Extremfall sogar unmöglich machen. Hier muss das Projektmanagement gegebenenfalls Brücken bauen. 

Oft braucht es kreative Workarounds, um Kommunikationsblockaden zwischen Teams aufzulösen. Dazu ein Beispiel aus unserer Praxis: Läuft die Zusammenarbeit zwischen den Bereichen Software (Frontend, Middleware) und Hardware (Firmware) nicht optimal – etwa, weil verschiedene Sprachen, Kulturen, Zeitzonen o.ä. aufeinander treffen – dann muss das Projektmanagement gegebenenfalls gemeinsam mit dem Software-Team Wege finden, auch ohne Zugang zur Hardware zu entwickeln. Eine Lösung wäre beispielsweise, die Hardware mithilfe eines digitalen Zwillings zu simulieren.

Beispiel: Digitaler Zwilling hilft, Kommunikationsblockaden zu neutralisieren

Zudem müssen Entwickler aus dem Software-Team in der Lage sein, die Hardware zu simulieren. Hier ist echte Full-Stack-Entwicklung gefragt, die über den Kompetenzbereich der “normalen” Software-Entwicklung hinausgeht. Deshalb stehen wir bei voltage IT für holistisches Full Stack Development statt Entwicklung in Zuständigkeits- und Kompetenzinseln.

Unsere Vision: 100% holistische Entwicklung in autonomen Teams

Software-Entwicklung ist Team-Sport, keine Einzeldisziplin. IoT-Projekte sind dann erfolgreich, wenn es gelingt, Kompetenzen innerhalb und zwischen den beteiligten Teams zu steuern, Stärken zu kombinieren und Zuständigkeiten zu bündeln. Ziel ist es, Teams zusammenzustellen, die Probleme autonom lösen können. Die Herausforderung für Project Owner besteht darin, die optimale Balance zwischen Steuerung und Autonomie zu finden. 

Bei voltage IT folgen wir diesen Prinzipien:

• Verantwortlichkeiten & Zuständigkeiten folgen Zielen, nicht den Rollen im Team
  Agile Software-Entwicklung orientiert sich an Wertschöpfung statt an Funktionen. Verantwortlichkeiten & Zuständigkeiten im Team werden so verteilt, dass die Features einer Wertschöpfungskette schnell und effizient umgesetzt werden können. Dazu müssen gegebenenfalls klassische Rollen und Zuständigkeiten aufgebrochen werden. An die Stelle von spezialisierten Teams treten cross-funktionale Teams, in denen notwendige Kompetenzen bestmöglich kombiniert werden.

• Full-Stack-Entwicklung und -Kompetenzen im Team, nicht in Einzelpersonen
  Sind Kompetenzen gleichmäßig auf möglichst viele Projektbeteiligte verteilt, lassen sich einfacher und flexibler agile Teams bilden, die in der Lage sind, autonom zu entwickeln. Zudem sinkt durch die Verteilung von Kompetenzen das Projektrisiko durch Ausfall einzelner Entwickler (“Bus Factor”).  

• Agile Methoden wie z.B. Pair Programming stärken die Autonomie
  Autonome Teams sind in der Lage, aus sich selbst heraus auf neue Anforderungen im Projekt zu reagieren und Lösungen zu finden. Zudem können autonome Teams mithilfe von agilen Arbeitsmethoden und Tools fortlaufend die Qualität der Entwicklung sichern. Bei voltage IT setzen wir auf “Pair Programming”, bei dem Entwickler paarweise zusammenarbeiten, simultan entwickeln und Qualität prüfen. 

Fazit: Agile Entwicklung ist perfekt für IoT-Projekte

So wie Anwendungen im IoT dezentral organisiert sind, muss auch die Software-Entwicklung dezentral organisiert sein. An die Stelle des klassischen Projektmanagements nach dem Wasserfall-Prinzip tritt Agile Leadership. Cross-funktionale Teams arbeiten autonom und holistisch entlang von Wertschöpfungsketten, statt fremdbestimmt und engmaschig funktionale Anforderungen abzuarbeiten. Das ist bei voltage IT nicht nur Vision und Anspruch, sondern erfolgreiche Realität in komplexen IoT-Projekten.

Leseempfehlungen

• How Much Autonomy Should Teams get from Their Agile Leader? (scrum.org)

• Allen Holub über Software-Handwerk und agile Prinzipien (Video)

Wir unterstützen Sie

Seit vielen Jahren kämpfen wir dafür, dass Unternehmen die richtigen IT-Entscheidungen treffen und Software-Systeme bekommen, von denen sie nachhaltig profitieren und die sie selbst beherrschen können. Unser Credo: Vernünftige Lösungen jenseits von Technologie-Hype.

“Quick & Dirty” in der Software-Entwicklung spart kurzfristig Zeit, kann aber langfristig mehr schaden als nützen. Hier ist ein Umdenken in Richtung “vernünftige” Software-Entwicklung gefragt. Erfahren Sie hier, worauf es dabei ankommt.

Software, die schnell aber handwerklich schlecht entwickelt wird, verursacht weltweit immensen Schaden – der größte Teil davon durch Software-Ausfälle im Betrieb. Studien zufolge lagen die Kosten von Ausfällen infolge schlechter Softwarequalität in den USA im Jahr 2020 bei 1,56 Billionen US-Dollar. Das ist 10-mal teurer, als Fehler in der Entwicklung zu vermeiden bzw. zu beheben, bevor die Software in Betrieb genommen wird.

Wenn Software weiterentwickelt wird und wächst, neigt ihre Architektur dazu, komplex zu werden. Das macht die Wartung der Software schwierig und fehleranfällig. Sind Design, Architektur und Quellcode zudem von vornherein schlecht angelegt, kann früher oder später jede noch so kleine Anpassung für Product Owner und Entwickler zum Alptraum werden. 

Die Herausforderung für Entwickler ist, Fehler im Programmiercode zu vermeiden bzw. so früh wie möglich zu erkennen, sodass sie relativ kostengünstig zu beheben sind. Dazu müssen Software-Handwerk und Qualitätsmanagement ab der ersten Zeile Code eng ineinandergreifen. Denn bereits in Zeile 1 wird die Basis für qualitätvolle und nachhaltige Software gelegt. 

Vernünftige Software-Entwicklung zielt darauf ab, Geschwindigkeit und Qualität bestmöglich zu vereinbaren. Der Schlüssel liegt in gutem Software-Design, das nicht “quick & dirty” sondern nachhaltig entwickelt werden sollte.

Grundwerte unseres Software-Handwerks (Software Craftsmanship)

• Qualität: Software soll nicht nur funktionieren, sondern auch gut gemacht sein
• Mehrwert: Wir reagieren nicht nur auf Veränderungen, sondern schaffen stetig Mehrwerte
• Team: Nicht Individuen schaffen gute Ergebnisse, sondern eine Gemeinschaft von Fachleuten
• Kooperation: Produktive Partnerschaften statt nur Zusammenarbeit mit Kunden

Quelle: manifesto.softwarecraftsmanship.org

Komplexe Software schnell und auf höchstem Qualitätsniveau entwickeln

Software Code wird heutzutage dank fortgeschrittener Tools und Methoden schneller als je zuvor veröffentlicht. Dadurch können Unternehmen neue Funktionen in immer kürzerer Zeit entwickeln. Gleichzeitig wächst auch die Komplexität der Funktionen, die früher sehr viel mehr Zeit für Entwicklung und Testing beansprucht hat als heute. Diese erfreuliche Entwicklung hat jedoch Grenzen, wenn die Qualität der Software unter Zeitdruck und Komplexität leidet. 

Die Herausforderung: Je schneller Unternehmen neue Funktionen entwickeln, desto schwieriger ist es, die Qualität und Zuverlässigkeit von Software sicherzustellen. Durch sehr kurze Testzeiten wächst das Risiko, dass mehr Fehler unentdeckt bleiben und ihren Weg in die Produktion finden. Je nach Häufigkeit und Umfang von Anpassungen akkumulieren diese Fehler und lassen Software-Design und -Architektur über kurz oder lang erodieren bzw. verrotten. Die Kosten für das Finden und Beheben von Fehlern in erodierenden Systemen steigen mit jeder Anpassung.

Kosten eines Fehlers im Software-Entwicklungsprozess

Kritische Software-Fehler im laufenden Betrieb zu finden und zu beheben ist 10-mal teurer, als diese zu finden und zu beheben, bevor die Software in Betrieb genommen wird. Es lohnt sich also zu Beginn in die Vermeidung von Fehlern durch sauberes Design zu investieren, statt unter Zeit- und Erfolgsdruck “quick & dirty” zu entwickeln.

Quelle: altexsoft.com

Die Kehrseite von “quick & dirty”

Software-Erosion, -Zerfall oder -Verrottung bezeichnet die schleichende Verschlechterung einer Software infolge schlechter Planung und/ oder Umsetzung. Indizien für Software-Erosion sind u.a. die Akkumulation von Programmfehlern, erschwerte Anpassbarkeit, Rückgang der Performanz, sowie Inkompatibilitäten mit neuen und zukünftigen Software-Umgebungen. Die Software bekommt mittelfristig einen “Code-Smell”, bei dem der Quellcode zwar noch funktioniert, aber schlecht strukturiert ist. Die Software wird nach und nach zu einem Altsystem und damit funktional und wirtschaftlich unbrauchbar.

Symptome für verrottendes Software-Design

1. Starrheit: das System lässt sich nur schwer und mit viel Aufwand ändern
2. Fragilität: kleine Änderungen haben unvorhersehbare Konsequenzen im System
3. Unbeweglichkeit: einzelne Komponenten lassen sich nur schwer isolieren
4. Viskosität: die Architektur der Software lässt sich bei Eingriffen schwer erhalten
5. Unnötige Komplexität: die Software enthält Infrastruktur ohne direkten Nutzen
6. Unnötige Wiederholungen: Architektur enthält Code-Strukturen, die sich wiederholen
7. Undurchsichtigkeit: Quellcode ist schwer zu lesen und zu verstehen

Quelle: in Anlehnung an Robert C. Martin

Nachhaltige Software-Entwicklung statt “quick & dirty”

Die Qualität von Software steht und fällt langfristig mit einem guten Software-Design und einer sauberen Umsetzung des Software-Codes. Die Weiche für Qualität wird bereits im Design gestellt, denn der Plan für eine Computersoftware ist so wichtig wie der Plan für ein Haus, sonst entsteht Chaos. Das Software-Design definiert, was in der Umsetzung in Form von Software-Code gebaut werden soll. Beide – Design und Code – erfordern höchstes handwerkliches Niveau.

Die Rolle von gutem Software-Design

Gutes Design kostet zwar Zeit und Mühe, zahlt sich aber aus, weil es die Weiterentwicklung der Software in Zukunft erleichtert. Schlechtes Design spart kurzfristig Zeit und Aufwand, verursacht aber technische Schulden, die die Produktivität der Software-Entwicklung später bremsen.

Quelle: martinfowler.com

Gutes versus schlechtes Software-Design

Quelle: in Anlehnung an geeksforgeeks.org

Die Rolle von gutem Software-Code

Die Qualität und Struktur des Quellcodes entscheidet wesentlich darüber, ob sich eine Software wirtschaftlich weiterentwickeln lässt oder nicht. Wird Software-Code etwa zu Beginn der Entwicklung unter Zeitdruck schnell und “schmutzig” entwickelt, schleichen sich Fehler ein, die man später im Projekt teuer bezahlt. Anders als bei “Clean Code”, der einfach und strukturiert geschrieben ist, wachsen die Kosten für Anpassungen von “schmutzigem” Code über die Zeit.

Quelle: geeksforgeeks.org

“Dirty and Fast Code” hat nur der Entwickler im Griff, der diesen geschrieben hat und selbst dieser tut sich nach einiger Zeit und tausenden von Zeilen irgendwann schwer damit, seinen eigenen Code zu verstehen. Und was passiert, wenn dieser Entwickler ausfällt, etwa durch Krankheit, Urlaub oder, weil er zu einem anderen Arbeitgeber wechselt? Dann kann es zur Katastrophe kommen – der sogenannte “Bus-Faktor” beschreibt dieses Risiko.

Exkurs: Der „Bus-Faktor“ beziffert die Mindestanzahl von Entwicklern im Team, die plötzlich aus einem Projekt verschwinden müssen, damit ein Projekt wegen Mangel an Code-Wissen zum Stillstand kommt. Wenn sich nur ein Entwickler mit dem Code auskennt, ist das Risiko extrem hoch, dass ein Projekt zum Stillstand kommt, sollte dieser Entwickler ausfallen. Es empfiehlt sich daher, Code-Wissen immer im Team zu verteilen.Sobald andere Entwickler an fremdem Code arbeiten sollen, wächst der Aufwand immens, da diese zunächst die individuelle Struktur verstehen müssen, bevor sie diese anpassen können. Und selbst dann, lassen sich die Risiken von Eingriffen nur schwer abschätzen, da verborgene Beziehungen im System nicht einfach zu erkennen sind. “Clean Code” dagegen macht es Entwicklern, die den Code nicht selbst geschrieben haben, sehr viel leichter, Strukturen zu verstehen und diese mit minimalem Risiko weiterzuentwickeln.

„Clean Code ist einfach und direkt. Clean Code liest sich wie eine gut geschriebene Prosa. Clean Code verschleiert nie die Absicht des Designers, sondern ist voller klarer Abstraktionen und geradliniger Kontrolllinien.“ – Grady Booch (Autor von Object-Oriented Analysis and Design with Applications)

Leseempfehlung zur Bedeutung der Architektur für die Nachhaltigkeit von Software:
Software-Architektur für KMU: Microservices vs Monolith – Welches ist die beste Lösung? 

Agile Softwareentwicklung nach handwerklichen Prinzipien

Software-Entwicklung nach dem Quick-and-dirty-Prinzip verursacht immense Folgekosten und lässt Product Owner in Unternehmen schlecht schlafen. Deshalb folgen wir bei voltage IT in der Softwareentwicklung den Prinzipien des “Software Craftsmanship”, die nachhaltige Qualität konsequent über kurzfristige Erfolge stellt. 

Nachhaltiges Software-Design und sauberer Code spielen in unseren Projekten eine zentrale Rolle. Für die Umsetzung nutzen wir agile Methoden und Werkzeuge:

• TDD (Test Driven Development): Die Funktionalität jedes Software Features wird über mindestens einen automatisierten Test überwacht. Dies schafft Sicherheit und Vertrauen bei Code-Änderungen und ermöglicht schnelle Entwicklungszyklen ohne manuelle Testdurchläufe.
• Pair Programming/ Continuous Code Review: Während ein Entwickler den Code schreibt, liefert ein anderer laufend Feedback und macht Verbesserungsvorschläge. Dadurch entsteht bereits während der Arbeit ein qualitativ besserer Code und spart nachträgliche Code Reviews.
• Refactoring: Gut gemachte Software muss intensiv und kontinuierlich refaktorisiert werden, um gut gemacht zu bleiben. Beim Refactoring wird die interne Struktur eines bestehenden Code angepasst ohne das externe Verhalten zu ändern.
• Continuous Delivery: Code wird in sehr kurzen Zyklen angepasst, sodass Änderungen jederzeit für das gesamte Team nachprüfbar bleiben. Damit lassen sich große, verborgenen Softwarefehler in der Produktion vermeiden und kleinere Defekte blitzschnell beheben.

Ein Wort zum Schluss: In vielen Bereichen unseres Lebens konnten handwerkliche Tätigkeiten durch Fließband und Automatisierung rationalisiert werden, was in vielen Fällen aus ökonomischer Sicht seine Berechtigung hat. Unsere langjährige Erfahrung zeigt, dass Fließbandarbeit in der Softwareentwicklung an Grenzen stößt und mittelfristig eher schadet als nützt. Gute Software braucht nach wie vor gutes Handwerk, und das wird so bleiben.

Leseempfehlungen

• Refactoring – Kurze Einführung von Martin Fowler (refactoring.com)
• DesignStaminaHypothesis – Lohnt sich der Aufwand, Software gut zu gestalten? (martinfowler.com)
• Cost of Poor Software Quality in den USA: 2020 Report (it-cisq.org)

Wir unterstützen Sie

Seit vielen Jahren kämpfen wir dafür, dass Unternehmen die richtigen IT-Entscheidungen treffen und Software-Systeme bekommen, von denen sie nachhaltig profitieren und die sie selbst beherrschen können. Unser Credo: Vernünftige Lösungen jenseits von Technologie-Hype.

Microservices sind seit Jahren hype, aber nicht immer die beste Lösung. Was vor allem kleine und mittlere Unternehmen mit knappen Ressourcen oft übersehen: Microservice-Architekturen sind trotz aller Vorteile im laufenden Betrieb echte Ressourcenfresser. Erfahren Sie hier mehr über (oft totgesagte) Alternativen.

Um Missverständnissen vorzubeugen: Microservice-Architekturen sind für KMU nicht per se ungeeignet; sie haben jedoch einige Tücken, die man bedenken sollte. Um die Flexibilität, die Microservices ohne Zweifel bieten, voll auszuschöpfen müssen Unternehmen in der Lage sein, dezentrale Entwicklung und Pflege in ihrer IT-Organisation abzubilden. Das ist oft eine große Herausforderung.

“Unternehmen, die nicht über ausgereifte Teams für die Software-Entwicklung und -pflege verfügen, sollten kritisch hinterfragen, ob sie sich Microservices wirklich leisten können.” – Igor Pshul, Solution Architect

Monolithische Architekturen werden oft als überkommenes Gegenmodell zu Microservices dargestellt. Sie sind jedoch nicht so schlecht wie ihr Ruf, vorausgesetzt sie werden handwerklich auf einem hohen Qualitätsniveau umgesetzt. In (oft ideologisch geführten) Debatten um Software-Architekturen werden die Vorteile von Monolithischen Architekturen nicht selten ignoriert.

Welcher Architekturstil im Einzelfall der richtige ist entscheidet sich nicht daran, was gerade technologisch en vogue ist. Entscheidend ist vielmehr, welcher Ansatz für ein Unternehmen realisierbar ist und sich besser eignet, Geschäftsziele zu erreichen. Deshalb unterstützen wir bei voltage IT unsere Kunden objektiv und mit klarem Blick auf den langfristigen Erfolg.

Die Herausforderung, vor dem jedes Unternehmen früher oder später steht: durch Erosion ihrer Architektur werden Software-Systeme nach und nach fehleranfälliger und ineffizienter. Schon kleinste Anpassungen können schließlich mit viel Angst und Schmerz verbunden sein. Wir wollen im Folgenden Hinweise geben, wie Sie mit der richtigen Architektur vorbeugen können.

Microservice-Architektur: Eigenschaften, Anforderungen, Pro & Contra

Microservices stehen für einen Architekturstil von Software-Anwendungen, die aus kleinen Dienste (Microservices) bestehen. Jeder einzelne Service wird in einem eigenen Prozess ausgeführt und kommuniziert über Schnittstellen (HTTP, REST API) mit anderen Services oder Systemen im Unternehmen. 

Services werden um Geschäftsfunktionen herum organisiert, weitestgehend dezentral verwaltet und können unabhängig voneinander und voll automatisiert bereitgestellt werden (automated deployment). Dabei können Microservices in verschiedenen Programmiersprachen entwickelt sein und unterschiedliche Technologien für die Datenspeicherung verwenden. Die Umsetzung erfolgt mithilfe von Containern, die mit Kybernetes orchestriert (bereitgestellt, skaliert und verwaltet) werden.

Herausforderungen:

• Ressourcen: Verschiedene Teams für Pflege und Entwicklung nötig
• Kommunikation: Steuerung unabhängiger Deployment-Einheiten
• Performance: Latenzzeiten im Zusammenspiel von Services und Systemen
• Infrastruktur: Redundanzen durch unabhängige Deployment-Prozesse
• Sicherheit: Jede API ist potenzieller Angriffspunkt für Cyberkriminalität
• Architektur: Dezentrale Service-Struktur erhalten (“Monolithisierung” vermeiden)

Fazit: Microservice-Architekturen sind per se flexibel in der Anpassung und Weiterentwicklung. Dafür müssen jedoch verteilte Teams bereitgestellt und koordiniert werden. Bei stark verteilten Systemen entwickeln Unternehmen einen Overhead für die Verwaltung und Kommunikation.

Monolithische Architektur: Eigenschaften, Anforderungen, Pro & Contra

Anders als verteilte Systeme auf Basis von Microservices verbinden Monolithische Software-Architekturen ihre funktionalen Elemente in einem einzigen homogenen Gebilde. Die Komponenten des Systems werden gemeinsam bereitgestellt (Deployment) und in einem gemeinsamen Prozess betrieben. Sie lassen sich dementsprechend nur als Ganzes skalieren.

Die Vorteile Monolithischer Architekturen entsprechen größtenteils den Nachteilen von Microservice-Architekturen und umgekehrt. 

Modulare Monolithen: Das Beste aus beiden Welten kombinieren

Was in der oft ideologisch geführten Debatte um Software-Architekturen nicht selten untergeht: Microservices und Monolithen schließen sich nicht gegenseitig aus. Das Optimum liegt wie so oft irgendwo in der Mitte. Smarte Programmierer vereinen das Beste aus beiden Welten und schaffen Systeme, die sich nicht dogmatisch an Architekturstilen orientieren. Entscheidend ist der Business Value, der aus der intelligenten Kombination verschiedener Ansätze resultiert.

Quelle: Simon Brown @ codingthearchitecture.com

Wir bei voltage IT verfolgen besonders für kleine und mittlere Unternehmen mit knappen Ressourcen eine strukturierte Software-Entwicklung, die monolithisch startet, jedoch bei Bedarf jederzeit die Vorteile von Microservices nutzen kann. Sinnvoll ist beispielsweise, im Monolithen eine klare vertikale Trennung nach Funktionalitäten vorzunehmen und nach höchsten Qualitätsstandards zu entwickeln: Domain Driven Design, Test Driven Development, Clean Code, um die Erosionen und die enge Kopplung der einzelnen Module zu vermeiden und für jedes Modul die Möglichkeit zur Extraktion zu einem Microservice zu erhalten.

Wir nennen das “vernünftiges” Software-Engineering – “vernünftig”, weil wir uns nicht vom Microservice-Hype leiten lassen, sondern strategisch die Basis für Systeme legen, die die tatsächlichen Anforderungen in den Mittelpunkt stellen und von Unternehmen bzw. deren Dienstleistern langfristig selbst gepflegt und flexibel weiterentwickelt werden können. 

Leseempfehlungen

• Microservices – schöne Einführung von James Lewis (martinfowler.com)
• MonolithFirst – Argumente für den Start mit Monolithen (martinfowler.com)
• Don’t start with a monolith – Wann sich  Monolithen nicht eignen (martinfowler.com)
• Distributed big balls of mud – Über verteilte Architekturen (codingthearchitecture.com)

Wir unterstützen Sie

Seit vielen Jahren kämpfen wir dafür, dass Unternehmen die richtigen IT-Entscheidungen treffen und Software-Systeme bekommen, von denen sie nachhaltig profitieren und die sie selbst beherrschen können. Unser Credo: Vernünftige Lösungen jenseits von Technologie-Hype.