In den Bausteinen für den Architektur­entwurf werden die vom Auftraggeber geforderten Qualitäts­merkmale, fundamentale Entscheidungen und übergreifende Konzepte nachvollziehbar erfasst. Ein ganz wichtiges Ziel ist die Darstellung und Kommunikation des Architektur­stils.

«Asciidoc» ist eine beliebte textbasierte Auszeichnungssprache. Eine Asciidoc-Datei kann durch eine geeignete Konvertierung als Spezifikation im Wiki veröffentlicht werden.

Produkt­verantwortliche, Analysten, IT- und UX-Experten, Redakteure und Vertreter des Realisierungsteams sind Autoren. Interessierte Parteien unterstützen sie als Co-Autoren. Ein Autor ist berechtigt, neue Seiten im Wiki anzulegen und bestehende Seiten zu ändern oder zu löschen. Seine Aufgabe ist es, Seiten im Wiki inkrementell mit Produktwissen zu füllen.

Der Baustein Case gibt einem Anwendungsfall, einer besonderen Situation oder einem bekannten und akzeptierten Fehler einen eindeutigen Namen und enthält eine fachliche Beschreibung und — sobald die Fähigkeit realisiert wurde — die Essenzschritte der gewählten Lösung.

«Convention over configuration» hat das Ziel, die Komplexität von Konfigurationen zu reduzieren.

«Convention over documentation» hat das Ziel, Dokumentation durch Konventionen zu vermeiden oder zu reduzieren.

Der Baustein Decision wird verwendet, um konsequent alle fundamentalen technischen Entscheidungen oder vom Auftraggeber geforderten Qualitäts­merkmale, deren Rücknahme bzw. Veränderung große Auswirkung auf das Produkt haben, zu dokumentieren.

Eine «Definition of done» verkörpert ein explizites und geteiltes Verständnis davon, unter welchen Bedingungen ein Produkt fertig ist.

Mit dem Baustein Domain geben Autoren einer Zusammenstellung von Diensten und Objekten mit einer starken Kohäsion einen eindeutigen Namen. Die untergeordneten Bausteine bilden einen «bounded context», ein Begriff aus dem Domain-Driven Design.

«Don´t repeat yourself» hat zum Ziel, jede unnötige Wiederholungen von Inhalten im Wiki zu vermeiden.

Mit dem Baustein Entity beschreiben Autoren ein fachlich relevantes Informationsobjekt. Ein Informationsobjekt ist ein Datenspeicher, also «etwas, das existiert». Es ist in der Regel mit einer Identität verbunden und repräsentiert einen Zustand in einem Dienst.

Der Baustein Epic gibt einer produktspezifischen Funktionalität einen eindeutigen Namen und enthält eine fachliche Beschreibung. Er bündelt eine mit den Anforderungen wachsende Menge von fachlich verwandten Fähigkeiten, besonderen Situationen und bekannten akzeptierten Fehlern, die im Detail mit dem Baustein Case dokumentiert werden.

Mit dem Baustein Event beschreiben Autoren ein fachlich relevantes Nachrichtenobjekt. Ein Nachrichtenobjekt ist ein wesentlicher Bestandteil einer event-basierten Schnittstelle eines Dienstes. Ein Nachrichtenobjekt kann eine zeitlich begrenzte Gültigkeit haben.

Der Baustein File realisiert das Konzept der Medienbibliothek. Mit dem Baustein werden Präsentationen, Filme, Fotografien, Abbildungen oder Diagramme, die als Datei (engl. file) in verschiedenen Formatenvorliegen, zentral und verlinkbar im Wiki abgelegt.

Gärtner sind Experten für Dokumentation und Administrator für das Wiki. Sie sind verantwortlich für die Auswahl der Werkzeuge für die Erstellung der Dokumentation. Als Trainer für cards+ ist er für Autoren und Leser greifbar und hilft ihnen bei der Bewältigung von alltäglichen wie auch speziellen Problemen im Zusammenhang mit Dokumentation.

«Invest in good stories» definiert sechs Kriterien, die uns helfen, fachliches Wissen so kompakt und vollständig wie möglich zu vermitteln.

«Keep it simple, stupid» besagt, dass wir eine möglichst einfache Beschreibung für Inhalte wählen sollen. «Weniger ist mehr» sagt schon ein Sprichwort. Einfachheit ist die Kunst, die Menge nicht getaner Arbeit zu maximieren.

Der Baustein Layout enthält Entwürfe oder Skizzen eines Teils der Bedienoberfläche. Layout ist der Oberbegriff für eine ganze Reihe spezialisierter Ausprägungen, z.B. Ansicht und Dialog in einer Website oder Screen in einer Smartphone-App. Window, Panel, Prompt und Widget, u.s.w. sind wiederverwendbare Muster in einem Layout.

Leser ist jede am Produkt interessierte Partei. Ein Leser nutzt das Wiki als Hilfsmittel zur Erfüllung seiner Aufgaben im agilen Entwicklungsprozess. Das Wiki ist für ihn eine unverzichtbare Quelle für Produktwissen. Jeder Leser ist berechtigt, im Wiki Seiten zu lesen und zu kommentieren.

Der Baustein Link realisiert das Konzept der Linksammlung. Mit dem Baustein wird eine beliebige Verknüpfung (engl. link) außerhalb des Wikis als dokumentierte Information zentral und verlinkbar erfasst.

«Principle of least astonishment» spiegelt sich im Aufbau der Seiten im Wiki wider. Jeder Baustein hat genau einen Zweck, festgelegte Abschnitte und ist das Ergebnis eines bestimmten Prozesses.

Das Produkt ist das kundenwirksam eingeführte Produktinkrement. Es ist gleichzeitig die Vision für zukünftige Produktinkremente.

Eine Produktdokumentation umfasst Dokumente, die den Zustand eines Produktinkrements in einem Wiki beschreibt.

Ein Produktinkrement ist eine lauffähige, getestete, angemessen dokumentierte und gemäß einer DOD überprüfte und freigegebene Version des Produktes.

Produktverantwortung bezeichnet die Verantwortung einer Person für ein Produkt entlang des Produktlebenszyklus bis hin zu seinem geplanten Ende. Sie ist Hüter der Vision des Produktes und Ansprechpartner für interessierte Parteien für Veränderungen des Produktes.

Ein Projekt ist nach üblicher Definition ein einmaliges Vorhaben mit einem bestimmten Ziel, in dem eine temporäre Projekt­organisation Leistungen erbringt. Das Vorhaben hat einen Beginn und ein Ende.

Eine Projektdokumentation umfasst Dokumente, die der Produktverantwortliche oder sein Team für die Planung und Steuerung von Veränderungen am Produkt benötigen.

Eine Projektorganisation umfasst alle Personen, die in einem Projekt an der Veränderung des Produktes zusammenarbeiten.

Der Baustein Policy wird verwendet, um konsequent alle Regeln für die Zusammenarbeit und den Einsatz von Anwendungen und Werkzeugen zu dokumentieren. Regeln sind Ausdruck der Qualitäts­politik in der Organisation.

Mit dem Baustein Service beschreiben Autoren einen fachlichen Dienst. Ein Dienst ist ein Akteur in einem IT-System. Der Begriff ist abstrakt. Ein Microservice ist ein ein Dienst. Ein REST-API ist ein Dienst. Eine Komponente in einem Applikationsserver ist ein Dienst.

«Single level of abstraction» spiegelt sich in der Struktur des Wiki wider. Für jede Seite ist klar definiert, was in einer Seite beschrieben wird und was nicht in diese Seite gehört.

«Separation of concerns» führt dort zu einer Trennung fachlicher und technischer Dokumentation, wo es Sinn macht.

«Single responsibility principle» regelt die Verantwortung für den Inhalt im Wiki. Eine Seite hat immer genau einen Autor. Er ist für den Inhalt der Seite verantwortlich, bis sie «fertig» ist.

In den Bausteinen der System­beschreibung werden die Grenzen des IT-Systems definiert und alle Fähigkeiten der Software vollständig, widerspruchsfrei und hierarchisch erfasst. Fähigkeit ist der Sammel­begriff für Anwendungs­fälle, besonderen Situationen und bekannten und akzeptierten Fehler eines IT-Systems.

Die Bausteine der System­struktur haben das Ziel, die Struktur der Software korrekt zu erfassen und einen Überblick über das Zusammenspiel der Dienste und Objekte zu geben. Ein nachrichten-orientierter Architekturstil ergibt eine andere System­struktur als die Realisierung eines IT-Systems mit einem monolithischen Applikations­servers.

Mit dem Baustein Task erstellen Autoren eine Handlungsanweisung zur Bedienung eines Dienstes. Die Betriebsorganisation braucht diese schrittweisen Anleitungen, um einen unterbrechungslosen und störungsfreien Betrieb des IT-Systems gewährleisten zu können.

Der Baustein Term realisiert das Konzept für ein Glossar. Mit dem Baustein wird ein wichtiger Begriff (engl. term) der Anwendungsdomäne, in der die Software zum Einsatz kommt, zentral und verlinkbar im Wiki erfasst.

Der Baustein Topic beschreibt einen klar abgegrenzten Aufgabenbereich (engl. scope), in dem das IT-System Verwendung findet. Er vermittelt einen Überblick und nimmt Bezug auf die Unternehmensprozesse. Er bündelt eine mit den Anforderungen wachsende Menge von Funktionalitäten, die im Detail mit dem Baustein Epic dokumentiert werden.