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 text­basierte Aus­zeich­nungs­sprache. Eine Asciidoc-Datei kann durch eine geeig­nete Konver­tie­rung als Spezifi­kation im Wiki ver­öffent­licht werden.

Produktverantwortliche, Analys­ten, IT- und UX-Exper­ten, Redak­teure und Ver­treter des Realisierungsteams sind Autoren. Interessierte Parteien unter­stützen sie als Co-Autoren. Ein Autor ist berech­tigt, neue Seiten im Wiki anzu­legen und beste­hende Seiten zu ändern oder zu löschen. Seine Auf­gabe ist es, Seiten im Wiki inkre­mentell mit Pro­dukt­wissen zu füllen.

Der Baustein Case gibt einem Anwendungs­fall, 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, Doku­mentation durch Konven­tionen zu ver­meiden oder zu redu­zieren.

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 Ver­stä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 Wieder­holungen von Inhalten im Wiki zu ver­meiden.

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 fach­­lich ver­wand­ten Fähig­­kei­ten, beson­deren Situa­tionen und bekannten akzep­tierten 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 Medien­biblio­thek. Mit dem Baustein werden Präsen­tatio­nen, Filme, Foto­gra­fien, Abbil­dun­gen oder Dia­gramme, die als Datei (engl. file) in ver­schie­denen For­matenvor­lie­gen, zen­tral und ver­link­bar im Wiki abge­legt.

Gärtner sind Experten für Doku­men­tation und Adminis­tra­tor für das Wiki. Sie sind ver­ant­wort­lich für die Aus­wahl der Werk­zeuge für die Erstellung der Dokumentation. Als Trainer für cards+ ist er für Autoren und Leser greif­bar und hilft ihnen bei der Bewälti­gung von all­täg­lichen wie auch spezi­ellen Prob­lemen im Zusam­men­hang mit Doku­men­tation.

«Invest in good stories» defi­niert sechs Kri­terien, die uns helfen, fach­liches Wissen so kompakt und voll­ständig wie mög­lich zu ver­mitteln.

«Keep it simple, stupid» besagt, dass wir eine mög­lichst ein­fache Beschrei­bung für Inhalte wählen sollen. «Weniger ist mehr» sagt schon ein Sprich­wort. 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 Pro­dukt inter­essierte Par­tei. Ein Leser nutzt das Wiki als Hilfs­mittel zur Erfül­lung seiner Auf­gaben im agilen Ent­wick­lungs­pro­zess. Das Wiki ist für ihn eine unver­zicht­bare Quelle für Pro­dukt­wissen. Jeder Leser ist berech­tigt, im Wiki Sei­ten zu lesen und zu kommen­tie­ren.

Der Baustein Link realisiert das Konzept der Link­sammlung. Mit dem Baustein wird eine beliebige Verknüpfung (engl. link) außerhalb des Wikis als doku­men­tierte Infor­mation zen­tral und ver­link­bar 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 Pro­dukt ist das kunden­wirksam ein­geführ­te Pro­dukt­inkre­ment. Es ist gleich­zeitig die Vision für zukünf­tige Pro­dukt­inkre­mente.

Eine Pro­dukt­doku­mentation umfasst Doku­mente, die den Zustand eines Pro­dukt­inkre­ments in einem Wiki beschrei­bt.

Ein Pro­dukt­inkre­ment ist eine lauf­fähige, getes­tete, ange­messen doku­mentierte und gemäß einer DOD über­prüfte und frei­gege­bene Ver­sion des Pro­duktes.

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 Pro­duktes und Ansprech­part­ner für inter­essierte Par­teien für Ver­ände­rungen des Pro­duktes.

Ein Pro­jekt ist nach üblicher Defini­tion ein einmaliges Vor­haben mit einem bestimmten Ziel, in dem eine temporäre Projektorganisation Leistungen erbringt. Das Vorhaben hat einen Beginn und ein Ende.

Eine Pro­jekt­doku­mentation umfasst Doku­mente, die der Pro­dukt­verant­wort­liche oder sein Team für die Planung und Steuerung von Ver­änderungen am Pro­dukt benöti­gen.

Eine Pro­jekt­organi­sation umfasst alle Per­sonen, die in einem Proj­ekt an der Ver­änderung des Pro­duktes zusam­men­arbei­ten.

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 Struk­tur des Wiki wider. Für jede Seite ist klar defi­niert, was in einer Seite beschrieben wird und was nicht in diese Seite gehört.

«Separation of concerns» führt dort zu einer Trennung fach­licher und tech­nischer Doku­mentation, 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­­beschrei­bung werden die Grenzen des IT-Systems definiert und alle Fähig­keiten der Software voll­ständig, wider­spruchs­frei und hierarchisch erfasst. Fähig­keit ist der Sammel­begriff für Anwendungs­­fälle, beson­deren Situa­tionen und bekannten und akzep­tierten Fehler eines IT-Systems.

Die Bausteine der System­­struk­tur haben das Ziel, die Struktur der Software korrekt zu erfassen und einen Überblick über das Zusammen­spiel der Dienste und Objekte zu geben. Ein nach­richten-orien­tierter Architektur­stil ergibt eine andere System­­struktur als die Reali­sierung eines IT-Systems mit einem monolithischen Appli­kations­­servers.

Mit dem Baustein Task erstellen Autoren eine Hand­lungs­anweisung zur Bedienung eines Dienstes. Die Betriebs­organi­sation braucht diese schrittweisen Anleitungen, um einen unter­bre­chungs­losen und stö­rungs­freien Betrieb des IT-Systems gewähr­leis­ten 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 Soft­ware zum Ein­satz kommt, zen­tral und ver­link­bar 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.