In der vorigen Folge haben wir uns Scope angesehen. Der saubere Start hat also geklappt. Wir haben uns auf Ziele, Stakeholder und Scope geeinigt. Jetzt wollen wir die Anforderungen verstehen und klären – und zwar sowohl die funktionalen Anforderungen als auch Qualitätsanforderungen und Randbedingungen.

In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor Sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

In der zweiten Folge unserer Kolumne stellen wir Ihnen drei Zutaten vor, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten. Wir nennen das zusammenfassend einen „Clean Start“ für Ihr Projekt oder Ihre Produktentwicklung. Für den Fall, dass das nicht klappt, kennen Sie ja Ihr Schicksal: Dann müssen Sie diese Teile der Analysearbeit auch noch selbst in die Hand nehmen.

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des „Knigge für Softwarearchitekten“ hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben [1], geht es in dieser neuen Kolumne um ein Dilemma. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für ihre Arbeit. Dabei finden Entwicklungsteams für praktisch jedes Problem eine vernünftige Lösung – sofern sie wissen, wo genau das Problem liegt [2].

Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen gehen vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Ändern und erweitern unter Zeitdruck – das ist traurige Normalität für viele Softwerker. Ständig zwingen uns widrige Umstände oder dunkle Mächte dazu, mit zu wenigen Informationen oder zu wenig Zeit neue Features oder auch notwendige Änderungen suboptimal umzusetzen. Wir möchten gerne besser arbeiten, aber nur selten geben uns die dunklen Mächte die Chance dazu.

Der Flexibilisator implementiert seine Komponenten oder Systeme am liebsten so: generisch, möglichst auf viele zukünftige Gegebenheiten vorbereitet, universell einsetzbar und grenzenlos flexibel in alle Richtungen. Er findet den ultimativen Kick, wenn er über den beschränkten Spezialfall der aktuellen User Story hinaus quasi ein zeitloses Denkmal der Flexibilität erschaffen kann. Kennen Sie das auch, diesen Drang nach Verallgemeinerung, den tiefen Wunsch, etwas Großes zu schaffen? Wir möchten in dieser Folge zuerst etwas über mögliche Arten der Flexibilität von Software klarstellen, auf einige Vor- und Nachteile davon eingehen und anschließend kräftiges Bashing auf Flexibilisatoren betreiben.

Immer wieder jammern Kunden, dass Systeme schlecht seien und die IT die Anforderungen überhaupt nicht erfüllt habe. Entwicklungsteams verteidigen sich damit, dass ihnen niemand gesagt hat, was das Produkt wirklich können soll. Sie schieben die Schuld auf schlechte Anforderungen. Hätte man diese Wünsche rechtzeitig und klar geäußert, dann wäre die Lösung auch skalierbar, erweiterbar, performant und sicher. Fachbereiche oder Marketingabteilungen kontern: Es war doch klar, dass wir nach dem europäischen auch den asiatischen Markt erobern wollen. Selbstverständlich muss das Produkt leicht an neue Gesetze, Standards und Normen adaptiert werden können. Warum hätten wir das explizit sagen sollen?

Seit 2014 hören wir in IT-Diskussionen immer wieder das Stichwort „Bimodale IT“, oder auch „IT der zwei Geschwindigkeiten“. Ein wenig Englisch möchten wir Ihnen diesmal zumuten, damit Sie die volle Schönheit der Erklärung bimodaler IT direkt von den Erfindern, der Gartner Group, lesen können: „Bimodal is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed“.

In den letzten Jahren tauchten zahlreiche Artikel und Blogbeiträge auf, die unserer Meinung nach eine gefährlich Botschaft verbreiten: Wir sind agil und brauchen daher keine Architekten! Wir wollen dagegenhalten: mit dem Agilitekten.

Remote is the new local: Waren, Maschinen, Fabriken, Lieferanten, Kunden, Menschen und Bots koordinieren automatisch Entwicklung, Lieferung, Produktion, Bestellung und Abwicklung von Produkten und Dienstleistungen. Hinter dem globalen – und nichtssagendem – Stichwort Industrie 4.0 verbirgt sich die nächste Evolutionsstufe unserer ohnehin schon ziemlich elektronifiziert-vernetzten Gesellschaft: die postindustrielle Revolution. Fabriken erhalten jetzt neben der physischen Dimension eine zusätzliche; nämlich die komplette Interorganisationsvernetzung.

Willkommen zu einer neuen Staffel unseres „Knigge für Softwarearchitekten“. In den bisherigen Staffeln, die zwischen 2012 und 2014 im Java Magazin erschienen sind und inzwischen auch als Buch vorliegen, hatten wir Ihnen vielerlei gute und schlechte Verhaltensmuster von Softwarearchitekten vorgestellt. Nun geht’s ganz im Trend von Industrie 4.0 innovativ weiter: Wir beleuchten allerlei neue Themen, mit denen sich unserer Ansicht nach Softwarearchitekten und -entwickler jenseits von React, Angular, Spring Boot und JShell noch beschäftigen sollten.

Wenn Sie wieder einmal böse sind, dass Ihre Textverarbeitung crasht, denken Sie einmal daran, dass das harmlos ist im Vergleich zu einem Ausfall des Avionic-Systems von Flugzeugen, dem Airbag Ihres Autos, einem Herzschrittmacher oder dem Regelsystem zur Produktionsüberwachung bei der Herstellung hochgiftiger Chemikalien.

Ein ganz normaler Tag: Morgens frage ich mich, welche Katastrophe mich heute erwartet. Ich bin einiges gewohnt, aber die letzten Monate wurde es immer schlimmer: Früher gab es nur Fehler im Test oder Schwierigkeiten bei der Entwicklung. Jetzt kommen auch noch Laufzeitfehler dazu, die den Betrieb im Rechenzentrum stören und unsere Endkunden massiv irritieren. Als hätte sich die dunkle Macht gegen uns verschworen – dabei haben wir doch nur ganz normale Anforderungen. Aber sicherlich das schlechteste Softwaresystem der Welt …

Diese Folge unserer Kolumne skizziert mögliche Reaktionen, die Sie bei Reviews (auch genannt Bewertung, Analyse oder Audits) von Softwaresystemen erleben können. Wir beschäftigen uns mit Gegnern und verschiedenen Stufen der Ablehnung.

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design (Literatur dazu siehe hier, hier und hier). Dieses sieht vor, die Konzepte der Domäne, d. h. die Entities, die verarbeitet werden und die Services, die fachlich gebraucht werden, zuerst zu modellieren und dann möglichst unverändert eins zu eins im Sourcecode zu verankern. Das klingt einfach und fast selbstverständlich. Je stärker die Codestruktur mit der realen Welt übereinstimmt, desto leichter sind die Wartbarkeit und die Erweiterbarkeit der Software.

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

Nach einigen Typen wie dem Fahnder und dem Schmutzfink, die sich mehr oder weniger professionell mit Sourcecode auseinander gesetzt haben, diskutieren wir in dieser Folge ein anderes Problem bei der Wartung existierender Systeme: Man hat Ihnen viel Code übertragen, den Sie aufrechterhalten und weiterentwickeln müssen, zu dem aber keine geeignete Dokumentation vorhanden ist. So geht es Beate, die mit Ihrem Team gerade 840 000 Zeilen C++ geerbt hat – und die nächsten Wünsche der Kunden stehen schon an.

Diese Folge unserer Kolumne handelt von Schmutzfinken, einer Spezies, die so alt ist wie das Programmieren selbst. Sie besitzen einen überaus starken Überlebenswillen und lassen sich auch durch Technologiewechsel nicht aus ihrem Konzept bringen. Im Gegenteil: Mit jeder neuen Technologie, Programmiersprache oder Framework entdecken Schmutzfinken neue und kreative Möglichkeiten, ihrer Passion zu frönen.

Zum Umbauen und Ändern von Software gehört nach unserer Erfahrung auch die Suche nach Fehlern – daher erwarten Sie diesmal Tipps zum zielgerichteten Debuggen.