Nach vielen inhaltlichen Folgen zum Umgang mit Requirements greifen wir diesmal ein ganz anderes Thema auf: Wie sollten Architekt(inn)en mit Requirements-Spezialisten zusammenarbeiten?

In zehn Folgen haben wir Ihnen in dieser Kolumne REQ4ARCS nahegebracht – das, was Architekt*innen über Requirements wissen sollten, wenn sie erfolgreiche Systeme oder Produkte bauen und deployen wollen. In dieser (vorläufig letzten) Folge zeigen wir Ihnen im Überblick nochmals die wichtigsten Themen in Kurzform. Als Ausgangspunkt nutzen wir die sechs Hauptaufgaben aus arc42, die Sie in Ihrer Architektenrolle bearbeiten sollen (Abb. 1) und konzentrieren uns im Folgenden auf das Thema „Anforderungen und Randbedingungen klären“.

In einer der letzten Folgen haben wir bereits über beispielhafte Spezifikationen geschrieben. Diesmal möchten wir konkreter auf die Möglichkeiten der Ausführbarkeit solcher Spezifikationen eingehen. Dazu werden wir einen Ausflug in die großartigen Möglichkeiten von Behavior-driven Development unternehmen.

In der letzten Folge hatten wir das Thema „Qualität“ top-down erklärt und Ihnen dazu das generische Qualitätsmodell von ISO 25010 vorgestellt – zur Erinnerung finden Sie in Abbildung 1 nochmal die obere Ebene der Qualitätseigenschaften zusammengefasst – das komplette Modell geht noch eine Stufe tiefer und umfasst insgesamt gut 45 solcher Eigenschaften. Das ergibt eine ziemlich breite Themenvielfalt rund um „Qualität“, ist aber als Grundlage für konkrete Architektur- oder Implementierungsentscheidungen viel zu abstrakt: Wir benötigen mehr Details, wir müssen genauer wissen und beschreiben, was Stakeholder denn nun wirklich von unseren Systemen erwarten oder benötigen. Abstrakte Begriffe wie „Performance“ genügen dazu nämlich nicht.

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.