Lösungsdesign · Schritt 03 · Wie wir arbeiten
Strategie & Architektur legt fest, wie ein System strukturiert sein sollte. Das Lösungsdesign bestimmt genau, was gebaut wird — die spezifischen Workflows, Schnittstellen, Datenverträge und Fehlerverhalten, die eine technische Richtung in etwas verwandeln, das ein Team tatsächlich umsetzen kann.
Diese Phase beginnt nicht mit einer Implementierung. Sie beginnt mit einer Spezifikation, die anhand von Belegen getestet wurde, bevor eine einzige Zeile Produktionscode geschrieben wird.
Nicht diese Frage
"Was sollen wir bauen?"
Stattdessen diese Frage
"Verhält sich dieses konkrete Design unter den Bedingungen, denen es tatsächlich ausgesetzt sein wird, so wie wir es erwarten — und können wir das beweisen, bevor wir Engineering-Ressourcen zum Bau einsetzen?"
Design · Prototyp · Test · Messen · Spezifizieren
Warum Design der Architektur folgt
Die Referenzarchitektur aus der vorherigen Phase definiert Schichten, Technologieentscheidungen und bereichsübergreifende Belange. Sie legt noch nicht fest, wie ein konkreter Workflow sich verhalten soll, wenn eine Anfrage mehrdeutig ist, oder was passiert, wenn eine Integration fehlerhafte Daten zurückliefert. Solution Design schließt diese Lücke — ohne es bleibt "architecture" ein Diagramm, kein System.
Referenzarchitektur → Lösungsspezifikation
Warum sorgfältiges Design wichtig ist
Barry Boehms Forschung zur Wirtschaftlichkeit der Softwareentwicklung — erstmals 1976 veröffentlicht und in seinem 1981 erschienenen Buch Software Engineering Economics erweitert — ergab, dass die Kosten zur Behebung eines Fehlers erheblich steigen, je später er entdeckt wird.
~1×
Kosten zur Behebung eines während der Designphase entdeckten Fehlers.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Kosten zur Behebung desselben Fehlers nach Produktionsfreigabe, abhängig vom Projektumfang.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Diese Erkenntnis wurde seither überprüft. Boehm und Basilis eigene Überarbeitung von 2001 ergab, dass die Kurve für kleinere, schnell iterierende Teams mit ausgeprägtem Testen und Continuous Delivery deutlich flacher ist. Der Multiplikator ist nicht universell, und wir behandeln ihn auch nicht als solchen.
Die Richtung dieser Erkenntnis wurde jedoch nicht widerlegt: Einen Designfehler zu finden, bevor er implementiert wird, ist günstiger als ihn danach zu entdecken. Deshalb betrachtet OpenQCore Prototyping und Testing als Teil des Designs selbst — nicht als Phase, die erst beginnt, wenn die Entwicklung bereits begonnen hat.
Von der Architektur zur Spezifikation
Jede architektonische Entscheidung aus der vorherigen Phase wird in konkrete Spezifikationen zerlegt.
Die genaue Reihenfolge von Schritten, Entscheidungspunkten, Ausnahmen und Übergaben, die eine Lösung unterstützen muss — verankert im während der Discovery erstellten Current-State Workflow Model, nicht in einem neu erdachten Idealprozess.
Was jeder Benutzer, jedes System oder jeder Agent tatsächlich sieht, sendet und empfängt — Bildschirme, Konversationsflüsse, API-Verträge und die Felder, die in jedem Schritt relevant sind.
Die genaue Struktur, Validierungsregeln, Versionierungsstrategie und Verantwortlichkeit der Daten, die zwischen Komponenten übertragen werden.
Was das System unter normalen Bedingungen, in Randfällen und bei Fehlerbedingungen tut — und ausdrücklich nicht tut.
Ausgabe
Lösungsspezifikation (Entwurf)
Workflow- und Interaktionsdesign
Eine konversationelle Schnittstelle, die auf einen defekten Workflow aufgesetzt ist, behebt den Workflow nicht — sie verdeckt ihn, bis die zugrunde liegende Einschränkung an anderer Stelle wieder auftritt.
Solution Design beginnt mit den während der Discovery gesammelten Workflow-Evidenzen und stellt vor einer Interface-Frage eine strukturelle Frage: Welche Schritte in diesem Prozess sollten automatisiert werden, welche sollten menschlich bleiben, und wo genau erfolgt die Verantwortungsübergabe zwischen ihnen? Wir kartieren das explizit, sodass Human-in-the-Loop-Punkte eine bewusste Designentscheidung sind — kein Zufall dessen, wozu die Technologie gerade fähig war.
Explizite Kontrollpunkte, bei denen menschliche Überprüfung, Beurteilung oder Autorisierung durch das Design erforderlich sind — nicht durch Unterlassen.
Präzise definierte Grenzen dessen, was ein System ohne menschliche Freigabe entscheiden oder ausführen darf.
Vorgesehene Wege für Fälle, die außerhalb der normalen Handhabung liegen — keine stillen Fehler oder vordefinierten Fallbacks.
Prototyping & Experimentieren
OpenQCore betrachtet frühe Designphasen so, wie die Designwissenschaft ein Artefakt der Informationssysteme betrachtet: als etwas, das speziell so gebaut wurde, dass es gegen ein reales Problem evaluiert werden kann, und nicht bloß seiner Eleganz wegen bewundert wird. Dieser Ansatz — formalisiert in der einflussreichen Arbeit von Hevner et al., "Design Science in Information Systems Research" (MIS Quarterly, 2004) — behandelt das Artefakt und seine Bewertung als untrennbar. Wir wenden dieselbe hypothesengesteuerte Argumentation an, die während der Entdeckungsphase verwendet wird, nun auf der Design-Ebene.
Eine konkrete, falsifizierbare Designentscheidung — keine vage Vorgabe.
Eine funktionsfähige Darstellung, die ausreicht, um die Entscheidung zu testen — nicht unbedingt produktionsreif.
Echte oder realistisch repräsentative Eingaben, nicht idealisierte Beispiele, die so ausgewählt wurden, dass sie erfolgreich sind.
Vergleich mit der Baseline und den während der Entdeckungsphase festgelegten Erfolgskriterien — nicht ein subjektiver Eindruck von Qualität.
Das Design wird beibehalten, modifiziert oder verworfen basierend auf den Testergebnissen — nicht basierend darauf, wie viel Arbeit bereits hineingesteckt wurde.
Das Ziel eines Prototyps ist nicht zu zeigen, dass ein Design funktionieren kann. Es geht darum festzustellen, ob es unter den Bedingungen, denen das fertige System tatsächlich ausgesetzt sein wird, zuverlässig funktioniert.
Daten- & Schnittstellenspezifikation
Integrationsfehler entstehen selten aus einer einzigen offensichtlich falschen Entscheidung. Sie resultieren eher aus Mehrdeutigkeit — ein Feld, von dem angenommen wurde, dass es immer vorhanden ist, ein Fehlerfall, den niemand dokumentiert hat, eine Versionsinkompatibilität, für die niemand geplant hat.
Dies ist bewusst unspektakuläre Arbeit. Es ist zugleich die Arbeit, die darüber entscheidet, ob ein System, das in einer Demo gut funktioniert, auch in Produktion, nach sechs Integrationen und achtzehn Monaten, weiterhin gut funktioniert.
Für Ausfälle entwerfen, nicht nur für Erfolg
Die meisten Designfehler sind keine Fehler des „Happy Path“. Sie betreffen das, was passiert, wenn etwas schiefgeht — ein vorgelagertes System läuft ins Timeout, ein Dokument lässt sich nicht sauber extrahieren, ein Modell ist unsicher, ein Benutzer verhält sich unerwartet. OpenQCore entwirft diese Bedingungen bewusst, statt sie erst in der Produktion zu entdecken.
Was das System tut, wenn die Zuverlässigkeit einer Ausgabe gering ist — einschließlich ob und wie es dies kommuniziert.
Welche Funktionen verfügbar bleiben, wenn eine Abhängigkeit ausfällt, statt eines vollständigen Systemausfalls.
Die konkreten Bedingungen, unter denen ein Fall an einen Menschen übergeben wird, und welchen Kontext diese Übergabe mit sich bringt.
Wie sich das System bei fehlerhaften Eingaben, unerwarteten Abläufen oder versuchtem Missbrauch verhält — nicht nur bei wohlgeformten Anfragen.
Ein System, dem nie die Frage ‚Was passiert, wenn das fehlschlägt?‘ gestellt wurde, ist nicht wirklich entworfen worden. Es wurde nur demonstriert.
Validierungskriterien vor der Implementierung definiert
Im Einklang mit dem im Discovery etablierten Prinzip — dass Erfolg vor der Implementierung definiert sein muss — erstellt das Solution Design explizite, schriftliche Akzeptanzkriterien und einen Testplan, bevor die produktive Entwicklung beginnt.
Was die Lösung korrekt tun muss, in testbaren Begriffen formuliert.
Im Einklang mit anerkannten Qualitätsmerkmalen von Software — einschließlich Leistungsfähigkeit, Zuverlässigkeit, Benutzbarkeit, Sicherheit und Wartbarkeit, wie sie im Software-Produktqualitätsmodell ISO/IEC 25010 organisiert sind — als messbare Ziele formuliert statt als allgemeine Absichtserklärungen.
Die spezifischen Szenarien, Datensätze und Bedingungen, anhand derer die Lösung bewertet wird, bevor sie als bereit für die produktive Umsetzung gilt.
Das Gate der Designüberprüfung
Diese Praxis hat Präzedenz: Michael Fagans formale Methode zur Design- und Code-Inspektion, eingeführt bei IBM 1976, zeigte, dass strukturierte, kriteriumsbasierte Reviews Fehler früher und zuverlässiger finden als informelle Freigaben. OpenQCore wendet dasselbe Prinzip auf das Solution Design an.
Die Spezifikation ist ausreichend präzise, der Prototyp erfüllte seine Bewertungskriterien, und die Entwicklung kann beginnen.
Die Grundrichtung ist sinnvoll, aber konkrete Elemente müssen aufgrund der Testergebnisse überarbeitet werden.
Die Designarbeit zeigte eine Einschränkung, die die Architektur nicht berücksichtigt hatte — die angemessene Reaktion besteht in der Überarbeitung der Architektur, nicht darin, das Design um die Einschränkung herum anzupassen.
Bei der Designarbeit wurde ein Risiko festgestellt — technisch, betrieblich, sicherheitsrelevant oder ethisch — das eine Entscheidung auf höherer Ebene als der Autorität des Designteams erfordert, bevor fortgefahren werden kann.
Ein Design-Gate, das immer Ja sagt, ist kein Gate.
Was das Lösungsdesign liefert
Je nach Umfang der Zusammenarbeit liefert diese Phase:
Arbeitsabläufe, Schnittstellen, Datenverträge und Verhalten in ausreichendem Detail, um darauf zu bauen, ohne die zugrundeliegende Absicht neu ableiten zu müssen.
Visuelle Darstellungen des Prozessflusses, einschließlich expliziter Mensch-in-der-Schleife-Punkte.
Schemata, Validierungsregeln und Versionsstrategie für jede Schnittstelle zwischen Komponenten.
Was getestet wurde, gegen welche Referenz und welche Schlussfolgerungen die Ergebnisse stützen oder ausschließen.
Dokumentierte Ausfallbedingungen und die jeweils entworfene Systemreaktion.
Die spezifischen, messbaren Bedingungen, die die implementierte Lösung vor der Bereitstellung erfüllen muss.
Vom Design zur Entwicklung & Integration
Das Lösungsdesign liefert eine getestete, validierte Spezifikation — kein fertiges System. Die nächste Phase verwandelt diese Spezifikation in funktionierende Software, die in die Systeme integriert ist, mit denen sie zusammenarbeiten muss.
Lösungsspezifikation → Prototyp-Evaluierung → Abnahmekriterien → Entwicklung & Integration
Schritt 04
Die spezifizierte Lösung anhand definierter Abnahmekriterien umsetzen — nicht anhand von Annahmen.
Forschungs- & methodische Referenzen
Boehm, B. — Software Engineering Economics (1981); Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
Quelle der oben genannten Erkenntnisse zum Kostenanstieg bei Änderungen, einschließlich der späteren Überarbeitung, die für kleinere, schnell iterierende Teams eine flachere Kurve zeigt.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in der Informationssystemforschung", MIS Quarterly (2004)
Grundlegender Rahmen, der das Artefakt eines Informationssystems und dessen Evaluation als untrennbar behandelt — die Grundlage für den oben beschriebenen Prototyp–Test–Verfeinerungszyklus.
Fagan, M. — "Design- und Code-Inspektionen zur Reduzierung von Fehlern in der Programmentwicklung", IBM Systems Journal (1976)
Ursprung der strukturierten, kriterienbasierten Design-Review als formale Ingenieurpraxis, auf die im oben genannten Design Review Gate verwiesen wird.
ISO/IEC 25010:2011 — Systeme und Software: Qualitätsanforderungen und Bewertung (SQuaRE) — Modelle für System- und Softwarequalität
Quelle der in den oben genannten Akzeptanzkriterien referenzierten nicht-funktionalen Qualitätsmerkmale.
