Liebe Leserin, lieber Leser,

bei allem Fortschritt in der IT ist es leider immer noch so, dass große Systeme nicht mit kleinem Aufwand zu erreichen sind. Und doch hat sich viel verändert. Wer heute ein großes System haben will, bekommt nicht mehr den einen alleskönnenden Monolith, sondern viele kleine Teile. Diese können für sich genommen nur wenig, vielleicht sogar nur eine einzige Sache. Aber zusammen können sie alles, was der Monolith kann – und noch viel mehr. Modularisierung war in der IT schon immer vorhanden, aber der Grad, in dem das heute passiert, ist noch immer neu. Getrieben sind die Projekte aktuell in fast allen Branchen von der digitalen Transformation und dem stetigen Zuwachs von Services und Lösungen in der Cloud. Und da liegt dann auch das Problem: Hatte man früher ein Ziel, ein Pflichtenheft, ein System, eine Sprache, ein Werkzeugset und ein Team, stehen einem heutzutage sofort ganz viele zur Verfügung. Es arbeiten immer gleich mehrere Teams aus unterschiedlichen Abteilungen in unterschiedlichen Programmiersprachen und nach agilen Methoden nebeneinander zusammen. Das verändert die Kommunikation und verlangt ein anderes strategisches Denken bei allen Beteiligten. In der Folge verlangt es auch ein anderes strategisches Design im Gesamtsystem und in jedem seiner Teile. Die Modularität des gewünschten Systems und die Modularität der Entwicklung bedingen sich.

Strategisch und taktisch zum Ziel

In dieser Ausgabe des Windows Developer finden Sie – ganz passend – viele kleine Artikel, die Denkanstöße für größere Lösungen geben. Angefangen bei den Tipps von Lukas Steurer zur Visualisierung am Flipchart (S. 18), die wichtig sein kann, um mehr Übersicht in der Planung zu bekommen. Denn bei vielen benötigten Modulen sind viele Absprachen die Folge, und die sollten in den Ergebnissen so klar wir möglich sein. Wie man dann „strategisches Design“ zur Grundlage seiner großen Businessanwendung macht, zeigt Manfred Steyer in seinem Artikel am Beispiel von Angular (S. 36). Wer dann die Teile seiner Anwendung miteinander verbinden will, kommt schnell dazu, sich Gedanken über Microservices zu machen. Wie man das sinnvoll gestalten kann, erklärt Marco Schulz in seinem Artikel „Slice down the Monlith“ (S. 66). Will man die Microservices mit .NET und Docker zur Verfügung stellen, dann findet man im Artikel von Dr. Felix Nendzig grundlegende Konzepte dafür (S. 60). Um über diese Menge von einzelnen Modulen den Überblick zu behalten, hat Patrick Schnell ein Tool zur zentralen Überwachung von Anwendungen erstellt (S. 86). Und wer es auf die Spitze treiben will, kann seine Fachabteilungen mit dem Einsatz von Low-Code-Plattformen in die Lage versetzen, gleich selbst eigene Anwendungen zu erstellen (S. 72).

Sie merken es schon, einfacher wird es nicht. Die Menge der zur Verfügung stehenden Lösungen wird immer größer. Ich empfehle Ihnen daher für den Einstieg die Kolumne Stropek as a Service „Information Overload – erweiterte Anforderungen an Softwareentwickler“ (S. 26) und wünsche Ihnen viel Erfolg.

Mirko Schrempp, Redakteur