Wir haben nicht einfach nur eine Website gebaut: Wie sie half, das DETai-Ökosystem zu formen

Dieser Post handelt davon, wie unsere Website entstanden ist. Von den technischen und wahrscheinlich auch teilweise psychologischen Aspekten dieses Prozesses.

Wobei nach einiger Zeit immer deutlicher wird, dass die Formulierung „die Website entstand“ eigentlich nicht ganz stimmt.

Genau damit haben wir tatsächlich angefangen. Wir wollten eine moderne DETai-Website bauen: schön, schnell, mehrsprachig, für Menschen verständlich und technisch so solide, dass wir nicht alle paar Monate wieder alles von Grund auf neu machen müssen. Die Aufgabe schien ziemlich klar. Doch je weiter wir mit der Website kamen, desto mehr Fragen tauchten auf, die gar nicht mehr wirklich die Website betrafen.

Was genau gehört zu DET, und was zu DETai? Wo endet ein Bereich und wo beginnt ein Produkt? Welche Teile des Ökosystems brauchen eigene Seiten? Wie hängen Forschung, Bildung, Psychotherapie, Produkte und die technologische Plattform zusammen? Welche Informationen sind öffentlich, welche sollten intern bleiben? Welche rechtlichen Dokumente gehören zu welchen Oberflächen? Wem gehören die Daten? Wo liegt die kanonische Quelle einer Definition und wo ihre öffentliche Interpretation? Dann kamen Lokalisierungen, SEO, GEO, die Herkunft von Bildern, Erstellungs- und Änderungsdaten von Seiten, Identitäten von Personen und Organisationen, Beziehungen zwischen Entitäten und strukturierte Daten hinzu — jene fast unsichtbare Ebene, die Suchsystemen hilft zu verstehen, was genau vor ihnen liegt.

Wer ist hier eine Person, was eine Organisation? Was ist eine Publikation, was ein Produkt und was ein Projekt? Wann ist eine Seite entstanden und wann hat sie sich wirklich verändert? Woher stammt ein Bild? Wie hängt ein Objekt mit einem anderen zusammen? Für einen normalen Besucher existiert fast nichts davon: Er öffnet eine Seite und sieht Text, Bilder und Buttons, während darunter allmählich eine zweite Website entsteht — eine, die weniger für menschliche Augen als für maschinelles Verstehen gedacht ist. Und irgendwann ungefähr am dritten Tag einer weiteren solchen Vertiefung kam mir eine völlig naheliegende Frage: Was, wenn die Hälfte davon in sechs Monaten gar nicht mehr gebraucht wird? Oder sogar schon in zwei Wochen.

Google wird seine Empfehlungen ändern, die KI-Suche wird Websites auf irgendeine andere Weise verstehen lernen, Schema.org wird einen Teil seiner heutigen Bedeutung verlieren, ein neuer Standard wird auftauchen oder das Framework, auf dem alles läuft, wird sich ändern.

In der digitalen Welt kann das, was gestern als Best Practice galt, morgen bereits eine historische Fußnote sein. Bedeutet das, dass man mehrere Arbeitstage einfach wegwerfen konnte? Diese Frage ist besonders komisch, wenn man sich daran erinnert, womit die ganze Geschichte überhaupt angefangen hat. Denn wir wollten einfach nur eine Website bauen.

Als die Website noch einfach nur eine Website war

Irgendwann war WordPress tatsächlich fast eine Gottheit.

Heute klingt das ein wenig ironisch, damals war es vollkommen ernst gemeint. WordPress erlaubte es einem Menschen ohne Entwicklerteam, eine echte Website zusammenzubauen, ein Theme zu installieren, Plugins anzuschließen, einen Blog, Formulare und Analytics einzurichten — und dann Elementor zu öffnen und sich plötzlich fast wie ein Webdesigner zu fühlen.

Für seine Zeit war das ein unglaublich starkes Modell: Man plante kein separates Frontend und Backend, dachte nicht über Infrastruktur als eine Menge miteinander interagierender Systeme nach — man baute eine Website zusammen. Wenn man eine neue Funktion brauchte, gab es fast sicher ein Plugin dafür; wollte man das Aussehen verändern, gab es ein Theme oder einen Visual Builder.

Wir haben lange ungefähr in diesem Denkmodell gelebt, bis sich nach und nach die Frage verändert hat, die man sich zu Beginn der Arbeit stellen muss.

Früher lautete sie: „Welche Website wollen wir bauen?“ Heute muss man immer häufiger fragen: „Welches System wollen wir bauen — und welcher Teil davon wird die Website sein?“

Die moderne Webentwicklung wurde komponentenbasiert, GitHub entwickelte sich zum Arbeitszentrum der Entwicklung, Next.js verband Eigenschaften einer klassischen Website mit denen einer Anwendung, und Vercel machte Deployment fast zu einer natürlichen Fortsetzung einer Codeänderung. Der eigentliche Wendepunkt kam für uns aber, als KI in diesen Kreislauf eintrat. Früher war die Grenze ziemlich klar: Entweder konnte man selbst programmieren, oder man arbeitete innerhalb der Möglichkeiten, die Programmierer vorbereitet hatten.

Mit KI wurde diese Grenze deutlich weniger starr. Das bedeutet keineswegs, dass Programmierung verschwunden wäre oder plötzlich keine professionelle Expertise mehr verlangen würde. Vielmehr wurde es möglich, auf einer anderen Ebene an Engineering-Arbeit teilzunehmen: Datenstrukturen, Ownership, Systemgrenzen, Schnittstellen zwischen Systemen, kanonische Quellen bestimmter Objekte und Folgen architektonischer Entscheidungen zu diskutieren, ohne dabei zwangsläufig jede Funktion selbst zu schreiben. Nach und nach klang die Arbeit ungefähr so: Diese Daten dürfen nicht dupliziert werden; Sprachversionen müssen eigenständige Repräsentationen derselben Bedeutung sein; diese Ebene gehört der Website, diese Storytelling, und diese Knowledge Substrate; hier brauchen wir einen Provider, dort einen Consumer und dazwischen einen stabilen Vertrag. Und genau hier entfernte sich alles endgültig vom ursprünglichen Plan. Denn der Plan war sehr einfach gewesen: noch zwei Wochen — dann ist die Website fertig.

Heute wirkt dieser Satz fast wie ein historischer Witz 🙂

Warum haben wir überhaupt so lange daran gearbeitet?

Irgendwann mussten wir noch eine andere Frage stellen, und sie erwies sich als viel wichtiger als die technischen: Warum können wir nicht einfach aufhören?

Warum nicht die schon schöne Startseite, ein paar Bereiche, eine ordentliche mobile Version und Analytics nehmen und sagen: Fertig, die Website existiert? Vermutlich, weil wir sie nach und nach ganz anders zu sehen begannen. Natürlich existiert keine konkrete Website „für immer“. Das Design wird sich ändern. Der Code wird neu geschrieben. Manche Seiten werden verschwinden. Manche Technologien, die heute modern wirken, werden in einigen Jahren ungefähr so aussehen wie heute eine alte WordPress-Adminoberfläche mit siebenundvierzig Plugins, von denen niemand mehr weiß, wofür die letzten zwölf da sind. Aber die Rolle der Website hält wesentlich länger als ihre aktuelle Umsetzung.

Der Technologie-Stack von DETai kann sich ändern, neue Produkte, Menschen, Forschungsprojekte und Arbeitsformen können entstehen, doch der Ort, über den sich das Ökosystem der Außenwelt präsentiert, wird sehr wahrscheinlich noch lange bestehen bleiben.

Die Website ist eine der wichtigsten öffentlichen Repräsentationen des gesamten Systems.

Und wenn man sie so betrachtet, verändert sich die Aufgabe überraschend. Man muss nicht mehr versuchen, eine Website zu bauen, die niemals geändert werden muss — das ist unmöglich. Man muss eine Grundlage bauen, die sich lange gemeinsam mit dem Ökosystem verändern kann, ohne ihre eigene Identität zu verlieren.

Stewart Brand formuliert in How Buildings Learn: What Happens After They're Built einen Gedanken, der erstaunlich genau dazu passt:

„Ein Gebäude ist nichts, was man beendet. Ein Gebäude ist etwas, das man beginnt.“

Brand schrieb über Gebäude, die weiterleben, nachdem der Architekt die Arbeit für abgeschlossen hält: Menschen verändern sie, bauen sie um, passen sie an neue Umstände an, und gerade die Fähigkeit, diese Veränderungen auszuhalten, bestimmt in hohem Maß die Qualität der ursprünglichen Architektur. Irgendwann ertappte ich mich bei dem Gedanken, dass mit der Website fast dasselbe passiert. Wir bauen keine Seite, die wir eines Tages feierlich für abgeschlossen erklären werden.

Wir starten eine langlebige digitale Konstruktion, in der sich noch viele Male fast alles verändern wird.

Wenn eine Website einen zwingt, auf alles eine Antwort zu geben

Und hier passierte wohl das Unerwartetste: Die Website begann DETai nicht nur abzubilden — sie zwang uns, DETai zu definieren.

Solange ein Ökosystem in Gesprächen, einzelnen Dokumenten, Repositories und Vorstellungen von Menschen existiert, kann man viele Grenzen lange etwas unscharf lassen. Alle verstehen ungefähr, worum es geht. Aber versucht einmal, das Ganze auf konkrete Seiten zu verteilen.

Was gehört in die Hauptnavigation? Was verdient eine eigene Seite, was ist Teil einer anderen Entität? Wenn auf einer Seite „Produkte von DETai“ steht — was genau nennen wir eigentlich ein Produkt? Wenn es einen eigenen Forschungsbereich gibt, wo verläuft die Grenze zwischen Forschung, Methode und technologischer Plattform? Wenn ein Projekt eigene Nutzerdaten hat, gehören sie zum gemeinsamen Ökosystem oder zu einem bestimmten Produkt? Wenn jemand ein rechtliches Dokument öffnet, zu welcher Oberfläche gehört es? Wenn dieselbe Idee in Knowledge Substrate, einer Publikation und auf der Website existiert — wo liegt ihre kanonische Definition und wo die Anpassung für eine bestimmte Zielgruppe?

Irgendwann wurde klar, dass die Arbeit an der Navigation der Website fast unmerklich zu Arbeit an der Ontologie des Ökosystems selbst wurde. Wir mussten buchstäblich entscheiden, aus welchen Objekten es besteht und wie diese Objekte miteinander verbunden sind. So zog das Design plötzlich Architektur nach sich, und öffentliche Nutzerwege zogen rechtliche Dokumente und Regeln für den Umgang mit Daten mit sich.

Und die Notwendigkeit, all das einem Menschen in einfacher Sprache zu erklären, zwang uns immer wieder zurück zur Architektur und zur Frage: Verstehen wir eigentlich selbst wirklich, was wir hier gebaut haben?

Es entstand ein ziemlich interessanter Kreislauf: Wir versuchten, das Ökosystem mithilfe der Website zu beschreiben, doch die Notwendigkeit, eine gute Website zu bauen, zwang uns dazu, das Ökosystem selbst immer präziser zu beschreiben. Am Ende wurde die Website zu einer Art Integrationstest für DETai. Wenn sich zwei Teile des Systems auf einer öffentlichen Seite nicht verständlich miteinander verbinden lassen, liegt das Problem vielleicht nicht an der Seite. Wenn wir nicht erklären können, worin sich zwei Entitäten unterscheiden, haben wir ihre Grenzen vielleicht selbst noch nicht klar genug definiert. Und wenn unklar ist, wem Daten gehören oder woher eine Definition kommen soll, löst eine schöne UI dieses Problem nicht. Vermutlich deshalb umfassten mehrere Monate Arbeit an „der Website“ am Ende Design, Programmierung, Semantik, SEO, rechtliche Architektur, Lokalisierungen und die Arbeit am DETai-Modell selbst: Eine einzige öffentliche Oberfläche verlangte plötzlich, dass das gesamte System dahinter ausreichend definiert ist.

Die Website, die aufhörte, nur eine Website zu sein

Die Website selbst ist dabei natürlich nicht verschwunden. Im Gegenteil: Nach und nach wurde sie zu einer der wichtigsten öffentlichen Oberflächen von DETai. Über sie kann man in die Methode, Forschung, Bildung, Produkte, das Team, Veranstaltungen, Publikationen und Dokumentation einsteigen. Diese Rolle ist inzwischen ausdrücklich auf der Knowledge-Substrate-Projektseite „DETai-Website“ festgehalten: Die Website ist die öffentliche Web-Ebene des Ökosystems, erklärt seine Struktur, zeigt Zusammenhänge und führt Menschen zu Produkten, Wissen und Beteiligung.

Gerade deshalb ähnelt sie immer weniger einem Behälter, in den wir fertigen Content einfach hineinlegen. Nehmen wir eine gewöhnliche Publikation: Sie kann mit einem Gedanken oder einer Sprachnotiz beginnen, zu einem Text werden, redigiert werden, Bilder, Metadaten, Sprachversionen und mehrere Repräsentationen für verschiedene Kanäle erhalten — und erst danach auf der Website oder in Telegram erscheinen. Die Website ist also nicht mehr der Geburtsort eines Objekts und besitzt auch nicht dessen gesamten Lebenszyklus; sie wird zu einer Form seiner Präsenz.

Deshalb ist neben der Website nach und nach Storytelling gewachsen — ein eigener Publication Core, der für Vorbereitung und Bewegung von Publikationen zuständig ist; Knowledge Substrate bleibt der Raum für stabile Definitionen, architektonische Grenzen, Ownership, Policies und Versionen; einzelne Produkte behalten ihre eigene Logik und ihre eigenen Daten; und die Website setzt all das für einen Menschen zu einem zusammenhängenden öffentlichen Bild zusammen.

Und genau hier entsteht wohl die Formulierung, die mir im Moment am besten gefällt: Die Website wurde allmählich zu einem System digitaler Präsenz. DETai soll für einen Menschen, eine Suchmaschine und einen KI-Agenten nicht als Sammlung zufällig verbundener URLs existieren, sondern als unterscheidbare Struktur, in der klar ist, was das ist, warum es existiert und wie es mit allem anderen zusammenhängt.

Und hier beginnt die nächste Ironie: Je verständlicher die Architektur wird, desto deutlicher sieht man, wie viel sich darin noch verbessern lässt.

Ein Projekt ohne den Zustand „fertig“

Komplexe Systeme haben eine ziemlich unangenehme Eigenschaft: Solange es sie fast noch nicht gibt, wirken sie sehr einfach. Solange nur die Idee einer zukünftigen Website existiert, erscheint die Aufgabe endlich — Seiten bauen und fertig. Dann entstehen die Seiten, und mit ihnen immer neue Ebenen. Der Zustand „fertig“ scheint sich ständig ein paar Schritte weiter nach hinten zu verschieben.

Man kann das als herrliches endloses Projekt betrachten, das sich niemals abschließen lässt 😅 Oder man bemerkt irgendwann etwas anderes: Vielleicht war schon die Vorstellung endgültiger Fertigstellung der Fehler.

Und damit kehren wir zu der Frage zurück, mit der alles begann: Wenn ein großer Teil der heutigen Arbeit ohnehin irgendwann veraltet, bedeutet das nicht, dass die Mühe umsonst war?

Aus irgendeinem Grund fällt mir dazu eine sehr einfache Analogie mit Training ein.

Wenn ein Mensch lange trainiert, wirkt das Ergebnis ganz materiell: Muskeln, Kraft, Form. Aber jeder weiß, dass ein längerer Trainingsstopp dazu führt, dass ein erheblicher Teil dieses Ergebnisses wieder verschwindet. Man könnte also fragen: Wozu waren all diese Sätze gut, wenn ihre Wirkung nicht für immer bleibt?

Die Antwort erscheint gerade deshalb ziemlich offensichtlich, weil das Ergebnis von Training nie nur aus Muskeln bestand. Gleichzeitig entstand die Fähigkeit, Belastung auszuhalten, nach Pausen zurückzukehren, eine Routine einzuhalten, noch einen Satz zu machen, obwohl man gerade keine Lust hat, und nicht jedes Mal von Inspiration abhängig zu sein. Selbst wenn die konkrete Form verschwindet, unterscheidet sich ein Mensch, der einmal gelernt hat, sie aufzubauen, bereits ein wenig von jemandem, der gerade erst anfangen will.

Mit Technologie scheint etwas sehr Ähnliches zu passieren. Man kann konkreten Code wegwerfen, das Framework ersetzen, Deployment neu schreiben, das Datenmodell vollständig ändern und eines Tages sogar die gesamte Website von Grund auf neu bauen — aber die Fähigkeit, sich in einem unbekannten System zurechtzufinden, Zusammenhänge zu sehen, Komplexität auszuhalten und etwas bis zu einem funktionierenden Zustand zu bringen, verschwindet nicht zusammen mit dem Repository.

Noch vor nicht allzu langer Zeit lagen viele Dinge, mit denen wir heute beinahe alltäglich arbeiten, außerhalb unserer vertrauten Sprache. Nicht weil es einen raffinierten Plan gegeben hätte, noch fünf Berufe zu erlernen, sondern weil jede nächste Schicht des Projekts verlangte, ein wenig mehr zu verstehen als die vorherige. Und irgendwann tritt eine ziemlich amüsante Umkehrung ein: Zuerst hat man Angst, den Code zu öffnen und versehentlich etwas kaputtzumachen; dann bekommt man Angst, die Architektur anzufassen; und nach einer Weile entsteht die genau gegenteilige Situation — manchmal ist es viel beängstigender, sie nicht zu verändern, obwohl man bereits sieht, dass die alte Entscheidung nicht mehr zum System passt.

Vielleicht ist das eines der wichtigsten Ergebnisse unserer Arbeit an DETai, die man auf der Website überhaupt nicht sehen kann.

Was man auf der Website nicht sieht

Am Abend dieses dritten Tages wollte mein Kopf überhaupt kein JSON-LD, canonical, provenance, Datumsangaben, Identifikatoren oder Beziehungen zwischen Entitäten mehr sehen. Nach einem vollen Arbeitstag blieb nur gewöhnliche körperliche Müdigkeit, und irgendwo auf dem Fahrradweg nach Hause entstand ein überraschend ruhiges Gefühl: Heute ist etwas besser geworden.

Nicht für immer — und das ist hier vermutlich die wichtigste Einschränkung.

Allmählich verschwindet die Vorstellung, der Sinn von Arbeit müsse zwingend darin bestehen, etwas zu erschaffen, das nie wieder verändert werden muss. Die Website verändert sich, das Unternehmen, der Beruf, der Körper, die Technologie und der Mensch, der sich mit all dem beschäftigt.

Beständigkeit entsteht erstaunlicherweise nicht dann, wenn ein System aufhört, sich zu verändern, sondern dann, wenn es die Fähigkeit entwickelt, sich zu verändern und dabei sich selbst nicht zu verlieren.

Für DETai ergibt sich daraus ein ziemlich natürlicher Widerspruch. Wir bauen ein technologisches Ökosystem um eine menschliche Praxis herum und wollen gleichzeitig nicht zulassen, dass Technologie die Praxis selbst ersetzt; wir schaffen ziemlich strenge architektonische Grenzen gerade deshalb, damit sich das System freier entwickeln kann; wir halten kanonisches Wissen in Knowledge Substrate fest, lassen Publikationen aber das Recht, lebendige Momentaufnahmen eines bestimmten Zeitpunkts zu sein; wir nutzen KI, um uns schneller zu bewegen, und verstehen zugleich immer deutlicher den Wert menschlicher Verantwortung für Bedeutung.

Die Geschichte der Website war am Ende also offenbar gar nicht in erster Linie eine Geschichte über Next.js, Vercel, GitHub, Schema.org oder KI. All diese Technologien sind wichtig, aber jede von ihnen bleibt ein Werkzeug ihrer jeweiligen Zeit.

Das Interessanteste passierte auf einer anderen Ebene.

Wir begannen mit dem Wunsch, eine Website zu bauen, und lernten allmählich, über ein System nachzudenken. Wir begannen mit einzelnen Seiten — und kamen zu Beziehungen zwischen Objekten. Wir begannen mit der Frage „Was wird ein Mensch sehen?“ und fragen inzwischen parallel „Was wird eine Maschine verstehen?“ Wir wollten ein bereits bestehendes Ökosystem darstellen — und entdeckten dabei, dass allein die Notwendigkeit, es darzustellen, uns zwingt, viel genauer zu verstehen, woraus es eigentlich besteht.

Und deshalb klingt die ursprüngliche Frage — „Was, wenn sich das alles eines Tages als umsonst erweist?“ — heute etwas anders.

Ein konkretes Ergebnis kann tatsächlich verschwinden. Code kann neu geschrieben, ein Standard ersetzt, eine Technologie vergessen und eine Website vollständig umgebaut werden — und höchstwahrscheinlich wird genau das eines Tages mit ihr geschehen. Aber wenn Stewart Brand recht hat und ein Gebäude nicht etwas ist, das man beendet, sondern etwas, das man beginnt, dann sollten wir mit digitalen Systemen vielleicht ähnlich umgehen: nicht versuchen, ihre endgültige Form zu erraten, sondern sie so bauen, dass sie ihre eigene ursprüngliche Architektur überleben können.

Und vielleicht entsteht genau deshalb am Ende eines sehr anstrengenden Arbeitstags manchmal ein merkwürdiges und zugleich angenehmes Gefühl: Fast keine Kraft mehr, der Kopf ist müde, morgen geht alles weiter — und trotzdem fühlt es sich innen gut an.

Denn es gibt Müdigkeit von sinnloser Bewegung. Und es gibt eine ganz andere Müdigkeit — die, die entsteht, wenn man heute zu etwas ein wenig Schwierigerem fähig geworden ist als gestern.

Und vielleicht wird gerade in solchen Momenten ein einfacher Gedanke besonders klar:

Leben ist, wenn du froh bist, müde zu sein.

Quellen und Materialien

1. Brand, Stewart. How Buildings Learn: What Happens After They're Built. Viking Press, 1994. Ein Buch über Architektur als System, das sich nach Abschluss des Baus weiter verändert; daraus stammt das Zitat „A building is not something you finish. A building is something you start“.
   https://www.penguinrandomhouse.com/books/320919/how-buildings-learn-by-stewart-brand/

2. Google Search Central — Introduction to structured data markup in Google Search. Erläutert, wie strukturierte Daten Suchsystemen explizite Informationen über Bedeutung und Typ von Seiteninhalten geben.
   https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

3. Schema.org. Ein offenes Vokabular von Typen, Eigenschaften und Beziehungen für strukturierte Daten im Web.
   https://schema.org/

4. DETai Knowledge Substrate — „DETai-Website“. Kanonische Beschreibung der Rolle der Website als öffentliche Web-Ebene des Ökosystems, ihrer Grenzen und ihrer Beziehungen zu Produkten, Wissen und Storytelling.
   https://docs.detai-x.com/ru/ecosystem/DETai/Platform_DETai/E2-Brand/sites/

5. DETai Knowledge Substrate — „Storytelling — Publication Core“. Kanonische Beschreibung des Publikationskonturs von DETai und der Aufgabenteilung zwischen Vorbereitung von Material und seiner Auslieferung über verschiedene Kanäle.
   https://docs.detai-x.com/ru/ecosystem/STORYTELLING/