In den vergangenen drei Folgen haben Sie erfahren, wie Sie systematisch mit funktionalen Anforderungen umgehen können. Sie wissen jetzt, wie Sie die richtigen fachlichen Prozesse mitsamt den dafür notwendigen fachlichen Daten ermitteln und kommunizieren, Sie kennen User Stories, Abläufe und Features. Ihre Anwendung kann jetzt (beispielsweise) Kinokarten verkaufen. Aber da war doch noch was: Die Zahlungen der Kinokarten sollen gegen unbefugte Zugriffe geschützt und vor allen Dingen nicht-abstreitbar erfolgen (Stichwort: IT-Sicherheit). Außerdem muss der gesamte Bezahlvorgang in weniger als dreißig Sekunden abgeschlossen sein (Stichworte: Performance) und natürlich niemals ausfallen (Stichwort: Zuverlässigkeit). Diesen schwierigen Themen wenden wir uns in den nächsten Folgen zu – den Qualitätsanforderungen.

In den letzten Folgen haben wir Ihnen Optionen für die Darstellung und Klärung funktionaler Anforderungen aufgezeigt. Eingestiegen sind wir über Geschäftsprozesse und haben anschließend die Granularität in kleinen Schritten bis zu User Stories verfeinert [1]. In der letzten Folge haben Sie dann einige Aspekte des Knowledge Crunchings aus dem Domain-driven Design kennengelernt, insbesondere Event Storming und die Ubiquitous Language [2]. Nun stellen wir Ihnen noch eine dritte Perspektive für funktionale Anforderungen vor, nämlich Beispiele.

In der vorigen Folge haben Sie gesehen, wie wir Überblick über die wesentlichen funktionalen Anforderungen bekommen können – nämlich indem wir von groben Zielen ausgehend die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse und Ende-zu-Ende-Abläufe (Use Cases oder User Stories) untersuchen. In dieser Folge möchten wir das Thema Domain-driven Design (DDD) aufgreifen und auf dessen Ansätze in puncto „Requirements“ eingehen.

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.