Individuelle Software wird in der Regel produziert, um Geschäftsprozesse im Unternehmen besser zu unterstützen als es mit Standardsoftware “von der Stange” möglich ist. Nutzer arbeiten effizienter und machen weniger Fehler, weil unternehmensspezifische Abläufe und besondere Fähigkeiten in der Software abgebildet werden. Individuelle Software kann einem Unternehmen einen entscheidenden Vorteil in einem umkämpften Marktsegment verschaffen.

Individuelle Software hat eine ganze Reihe von interessierten Parteien: Nutzer, die Fachabteilung als Auftraggeber und die Geschäftsführung, um nur die wichtigsten zu nennen. Nutzer wollen wissen, was die Software leistet, wo die Grenzen sind. Die Fachabteilung muss abschätzen können, wie sie die Software erweitern kann, passend zur Strategie der Geschäftsführung. Interessierte Parteien wollen aus unterschiedlichen Gründen wissen, was die Software leistet. Dabei geht es nicht darum, die Komponenten der Software zu identifizieren oder die Datenflüsse zu kennen, sondern um die Fähigkeiten der Software, normalerweise aus Nutzersicht.

Betrachten wir ein sehr einfaches Beispiel. Nehmen wir an, wir haben eine Anwendung, mit dem der Kundenstamm einer Vertriebsorganisation verwaltet wird. Aus Nutzersicht gibt es einen sehr großen Unterschied zwischen der Eingabe eines neuen Kunden und einer Änderung an einem Bestandskunden. Im ersten Fall müssen die Angaben eines neuen Kunden geprüft werden. Der neue Kunde ist noch unbekannt und muss objektiv anhand anderer Informationsquellen kritisch beurteilt werden, z.B. durch eine Bonitätsprüfung. Alle diese Prüfungen passieren aber außerhalb der Software, durch Recherche im Internet, durch E-Mail-Verkehr oder persönliche Gespräche.

Im zweiten Fall wird ein Bestandskunde aufgrund von Feedback des Kunden selbst verändert, z.B. neue Firmenanschrift oder neue Ansprechpartner. Diese Angaben werden in der Regel schnell geprüft, eingegeben und gespeichert, weil sie aus einer vertrauenswürdigen Quelle stammen.

Aus Sicht der Entwicklung unterscheiden sich die Lösungen nicht großartig. In beiden Fällen werden die gleichen Komponenten der Software und die gleiche Datenstrukturen verwendet.

Halten wir also fest: Interessierte Parteien wollen etwas über die Fähigkeiten einer Software wissen, nicht über die technische Lösung. In den phasenorientierten Entwicklungsprojekten nutzten wir viele Jahre Fachkonzepte. Die Analyse der Anforderungen der Auftraggeber führte zu einem Gesamtbild mit Anwendungsfällen und Geschäftsregeln. Viel Aufwand steckte auch in der Lösungsfindung. Die Lösung wurde von Personen entworfen, die in der Regel nicht die Entwickler waren. Für einen Auftraggeber war das Fachkonzept die letzte Chance, Änderungen und Wünsche einzubringen. Nach Auftragserteilung war das Fachkonzept bindend für Auftraggeber und Auftragnehmer. Änderung erforderten einen oft anstrengenden Änderungsprozess. Sinnvolle Änderungen kamen daher häufig so spät, dass viel Zeit in die falsche Richtung investiert wurde. Agile Entwicklungsprozesse haben vieles verändert. Fachfeinkonzepte haben einen schlechten Ruf bei agilen Teams. Sie möchten die Anforderungen am liebsten im Dialog mit den interessierten Parteien, allen voran Nutzer, erarbeiten, damit sie schrittweise die richtige Lösung dazu finden.

Die Bausteine der Systembeschreibung von CARDS+ verfolgen einige der Ziele der Fachkonzeption. Der Baustein Topic gibt einen Überblick über die für die Software relevanten Geschäftsprozesse. Im Baustein Topic steckt auch die Abgrenzung des Auftrages. Mit den Bausteinen Epic und Case werden aus den Anforderungen die notwendigen Fähigkeiten abgeleitet (Case) und sinnvoll gruppiert (Epic). Die Bausteine Topic und Epic sind in der Sprache der interessierten Parteien geschrieben und enthalten keinen Hinweis auf die technische Lösung. Auch aus dem einfachen Grund, weil sie zum Zeitpunkt der Erstellung der beiden Bausteine noch gar nicht bekannt ist. Der Baustein Case ist zweigeteilt. Im Abschnitt Ausgangslage wird die Fähigkeit der Software ganz konkret beschrieben, aus Nutzersicht bei dialogorientierten Systemen, prozessorientiert bei automatisierter Datenverarbeitung. Der Abschnitt Lösung bleibt jedoch solange leer, bis Essenzschritte durch das Feedback der Entwickler ergänzt werden können. Die Essenzschritte zeigen dabei in stark vereinfachter Art und Weise, welche Komponenten und Datenstrukturen der Software für die Realisierung dieser einen Fähigkeit des Systems zuständig sind und wie sich der Datenfluss in diesem konkreten Fall gestaltet. Der Abschnitt Lösung enthält jedoch keine Details der Implementierung. Die Essenzschritte im Baustein Case bestehen im Grunde nur aus Verlinkungen zu den Bausteinen Service, Event, Entity und Layout, gegebenenfalls ergänzt um einen kurzen Hinweis, welche Geschäftsregel oder welcher Algorithmus in dem vorliegenden Case eine wesentliche Rolle spielt.

Diese unterschiedliche Sichtweise ist einer der zentralen Vorteile von CARDS+. Es ist leicht nachvollziehbar, dass mit den Bausteinen der Systemstruktur eine Software angemessen beschrieben werden kann. Vergleichbare Konzepte verfolgen übrigens auch ARC42 oder das Domain-Driven-Design. Mit den Bausteinen ServiceEventEntity und Layout geben wir den Komponenten der Software eindeutige Namen und entwickeln und festigen so die gemeinsame Sprache der Entwicklung. Datenstrukturen, Geschäftsregeln, Algorithmen oder Statusautomaten werden ausschließlich in den Bausteinen der Systemstruktur beschrieben, dort, wo sie tatsächlich auch implementiert wurden.  Damit wird wichtiges Wissen der Entwickler auch für die interessierten Parteien im Wiki sichtbar – inklusive der Kommentarfunktion für Feedback.

Rufen wir uns das Beispiel der Verwaltung des Kundenstamms einer Vertriebsorganisation in Erinnerung. Nehmen wir an, die Vertriebsorganisation nutzt für die Prüfung einer ganz bestimmten Kategorie von Kunden einen öffentlich verfügbaren Online-Dienst. Diese Prüfung soll nicht nur einmal, bei der Erstellung des Kunden gemacht werden, sondern regelmäßig wiederholt werden. Die Prüfung ist außerdem automatisierbar. Der Auftraggeber formuliert eine entsprechende Anforderung, die in diesem Fall in zwei neue Fähigkeiten des Systems münden: Kunde mit automatischer Prüfung neu anlegen ist der erste Case, Kunde automatisch prüfen ist der zweite Case. Der bestehend Case zum Pflegen eines Bestandskunden ermöglicht zusätzlich die Angabe, ob der Kunden automatisch geprüft werden kann. Aus Sicht der Entwickler wird die bereits existierende Komponente der Software erweitert und die gleiche Datenstruktur wie bisher verwendet, erweitert um ein einziges Attribut, das anzeigt, ob eine automatische Prüfung bei diesem Kunden möglich ist.

Entwickler und vor allem Tester lernen durch den Baustein Case die Sprache der Nutzer. Ein Case sichert damit wichtiges Wissen der Nutzer. Ein neuer Case bedeutet nicht zwingend eine neue Komponente. Im Gegenteil, besonders in einer reifen Software werden nur mehr bestehende Komponenten oder Datenstrukturen erweitert. Jeder neue oder erweiterte Case bedeutet aber auf jeden Fall mindestens einen neuen Testfall.

Ein Nutzer kann bei einem Problem den richtigen Case zu seinem Problem heranziehen und nachlesen, bevor er eine Fehlermeldung erstellt. Er ist dazu in der Lage, weil in einem Case eine dem Nutzer bekannte Fähigkeit des Systems beschrieben wird. Ist die Ausgangslage im Case gut beschrieben, erkennt ein erfahrener Nutzer vielleicht sogar selbst, dass sein Problem in der Software noch gar nicht gelöst ist und erstellt eine Anforderung, statt einer Fehlermeldung.

Der Auftraggeber ist interessiert, gibt regelmäßig Feedback im Review. Hat er einmal keine Zeit für die Teilnahme am Review, kann ihm ein auf die Bausteine Topic, Epic und Case reduzierter Export der Produktdokumentation zur Verfügung gestellt werden. Dieser Export fühlt sich für den Auftraggeber wie ein Pflichtenheft an, weil es die Fähigkeiten des Systems vollständig beschreibt und einen Hinweis auf die Lösung anhand der Essenzschritte im Baustein Case gibt. Das Pflichtenheft beschreibt aber exakt den Zustand des aktuell vorliegenden Produktinkrements. Die Gültigkeit des exportierten Dokuments endet aber mit dem Abschluss des nächsten Sprints.

Interessierte Parteien kennen nicht immer die Sprache in einem Entwicklungsprojekt. Durch den Komponentenüberblick mit den abstrakten Diensten und der visuellen Darstellung der Datenströme können interessierte Parteien diese Sprache leichter erlernen. Sie beginnen damit, die Systembeschreibung zu lesen und landen sehr schnell in der Hierarchie beim Baustein Case. Dort können sie mit der Kommentarfunktion im Wiki sehr zielgerichtet nicht nur Feedback zu den Bausteinen der Systembeschreibung geben, sondern aufgrund der Navigation über die Essenzschritte im Abschnitt Lösung auch Feedback zu Datenstrukturen, Geschäftsregeln, Algorithmen oder Statusautomaten in den Bausteinen der Systemstruktur geben.

Die Systemstruktur bekommt durch die Veröffentlichung von Spezifikationen direkt aus dem Code-Repository (z.B. eine Konfiguration mit Yaml, eine REST-API-Referenz mit Asciidoc oder ein Nachrichtenobjekt mit Avro) in den Seiten im Wiki ihren Inhalt. Mit den Bausteinen Service, Event, Entity und Layout kann die Systemstruktur auf ein Verzeichnis von Komponenten und Datenstrukturen reduziert werden, mit eindeutigen Namen und einen Steckbrief. Die Bausteine sind miteinander verlinkt und werden im Komponentenüberblick schematisch dargestellt. Damit werden Spezifikationen der Entwickler auch für die interessierten Parteien im Wiki sichtbar – inklusive der Kommentarfunktion für Feedback.

Die Systembeschreibung ist aber etwas, was sich interessierte Parteien, Auftraggeber und Auftragnehmer erarbeiten müssen. Es ist Wissen, dass in dieser Form nicht in der Software vorhanden ist. Es ist Wissen, dass durch Feedback der interessierten Parteien die notwendige Qualität erreicht. Und es ist vor allem Wissen, dass eine Brücke zwischen den Fähigkeiten des Systems aus Nutzersicht und den Komponenten und Datenstrukturen der Software aus Sicht der Entwickler schlägt. Im Grunde genommen unbezahlbar, aber mit CARDS+ leistbar.