Ein Unternehmen, das in mehreren Bereichen baut, fordert einen naheliegenden Einwand heraus: dass Breite nur ein beschönigendes Wort dafür ist, keine besondere Kompetenz zu haben. Der Einwand ist berechtigt, und er verdient eine präzise Antwort statt einer Beschwichtigung.
Die drei Bereiche, in denen wir heute bauen, haben auf technischer Ebene wenig gemeinsam. Bei Software und digitalen Plattformen geht es um Architektur, Schnittstellen und Langlebigkeit im realen Einsatz. Bei künstlicher Intelligenz und Daten geht es um saubere Eingaben, erklärbare Ergebnisse und Entscheidungen, die die Person erreichen, die handeln kann. Bei Cloud und Cybersicherheit geht es um Resilienz, Identität und die Kosten einer falsch aufgesetzten Infrastruktur.
Unterschiedliche Bereiche, unterschiedliche Architekturen, unterschiedliche Fehlermuster. Nichts wird zwischen ihnen wiederverwendet, ausser dem Standard.
Der Standard ist eine Definition von fertig
Was sich durch jedes System zieht, das wir bauen, ist weder ein Stack noch ein Framework. Es ist die Antwort auf eine einzige Frage: Was muss zutreffen, bevor wir etwas als erledigt bezeichnen?
Die Bereiche verändern die Einzelheiten dieser Antwort, nie aber ihren Kern. In jedem Fall gilt:
- Das Problem wird formuliert, bevor die Lösung entworfen wird.
- Das Datenmodell und die Grenzen werden vor der Oberfläche festgelegt.
- Sicherheit und Leistung sind Vorgaben ab dem ersten Commit und keine spätere Phase.
- Das System ist so gut dokumentiert, dass jemand, der es nicht gebaut hat, es erweitern kann.
- Nichts wird ausgeliefert, nur weil ein Termin gekommen ist.
Diese Liste ist unspektakulär. Fast jede Technikorganisation würde behaupten, ihr zuzustimmen. Der Unterschied liegt nicht darin, den Standard zu haben, sondern darin, was geschieht, wenn es teuer wird, an ihm festzuhalten. Nur in diesem Moment wird ein Standard tatsächlich geprüft.
Warum der Standard das Übertragbare ist
In der Software gibt es eine nützliche Asymmetrie. Fachwissen ist tief, aber eng: Wer die Abstimmung von Unternehmensdaten versteht, lernt daraus fast nichts über die Evaluation von Modellen, und wer die Evaluation von Modellen versteht, lernt daraus fast nichts über Identitäts- und Zugriffsverwaltung. Urteilsvermögen darüber, wie man baut, ist dagegen breit: Es gilt für alle drei Bereiche, und es wächst mit der Zeit.
Deshalb organisieren wir das Unternehmen nach Methode statt nach Markt. Jeder neue Bereich verlangt, von vorne zu lernen, und diese Kosten sind unvermeidlich. Was nicht neu gelernt werden muss: wie man entscheidet, was man ablehnt, wann ein Entwurf noch nicht gut genug ist und welche Abkürzungen sich wieder korrigieren lassen.
Die drei Bereiche sind kein Anspruch auf Fachwissen in jedem Markt. Es sind die Felder, in denen wir heute bauen, unter einem technischen Standard. Weitere Felder bleiben eine Landkarte dafür, wo Software dauerhafte Vorteile schaffen kann, und keine Broschüre bereits geleisteter Arbeit.
Tiefe hält Breite ehrlich
Das Fehlermuster eines Unternehmens mit mehreren Bereichen liegt auf der Hand: eine Sammlung oberflächlicher Produkte, von denen keines gut genug ist, um etwas zu bedeuten, und denen allen die Aufmerksamkeit fehlt, die sie gebraucht hätten.
Der Schutz davor ist die Reihenfolge, und unsere ist klar formuliert: Tiefe vor Breite. Bestehende Systeme werden zur Reife und zu kommerzieller Zugkraft gebracht, bevor die nächste Front eröffnet wird. Wachstum, das der Technik davonläuft, ist genau das Scheitern, das dieses Unternehmen vermeiden soll, und es wird vermieden, indem wir Dinge gar nicht erst beginnen, statt sie später retten zu wollen.
Wie das von aussen aussieht
Meist sieht es nach Ruhe aus. Ein richtig angewandter Standard bringt sehr wenig hervor, das sich ankündigen liesse: keinen Neubau, den man erklären müsste, keinen Vorfall für eine Nachbetrachtung, keine Migration, die man feiern könnte. Das Ergebnis guter Architekturentscheidungen ist das Ausbleiben von Ereignissen.
Das ist schwer zu vermitteln, und wir nehmen das in Kauf. Ankündigungen sind keine Leistungen, und ein ruhiges Unternehmen ist nicht zwangsläufig ein untätiges. Der Beleg für einen Standard ist nicht, was über ihn gesagt wird. Er liegt darin, ob die Software in fünf Jahren noch gut ist, und dieser Beleg braucht fünf Jahre, bis er vorliegt.