Ein Software Architect entscheidet die Dinge, die man später nicht mehr billig ändern kann.

Software Architect steht auf unserer Teamseite in der Disziplin Architektur und Engineering, neben Solution Architect, Full-Stack Software Engineer, Integration Engineer und Solution Engineer. Beschrieben wird die Rolle meistens als der erfahrenste Entwickler im Team. Das trifft es nicht. Ein Software Architect schreibt nicht zwingend den meisten Code, er entscheidet die Dinge, die man später nicht mehr billig ändern kann. Wir erklären, welche Entscheide das sind, welche davon nur Geschmack sind, warum der Unterschied mit jedem Monat teurer wird und ab wann ein KMU die Rolle braucht.

Architektur sind die Entscheide, die man später nicht mehr billig ändern kann.

Es gibt eine brauchbare Abgrenzung und sie hat nichts mit Technik zu tun, sondern mit dem Rückweg. Ein Entscheid ist Architektur, wenn seine Rücknahme eine Migration ist: Daten müssen umgezogen, Schnittstellen neu gebaut, Abläufe neu erklärt werden. Alles andere ist eine Umsetzungsfrage.

Konkret sind das in einem KMU Projekt fünf bis sechs Fragen. Welches System führt die Kundendaten, wenn es mehr als eines gibt. Wie sieht das Datenmodell aus, also was ist ein Kunde, ein Auftrag, eine Position und was passiert, wenn ein Kunde zwei Standorte hat. Wo liegen die Daten, in der Schweiz, in der EU oder irgendwo. Wie reden die Systeme miteinander, über eine Schnittstelle, über einen nächtlichen Export oder über eine Person, die abtippt. Und was passiert mit allem, wenn der Anbieter in drei Jahren nicht mehr da ist oder der Preis sich verdoppelt.

Das Unangenehme daran: Diese Fragen werden ganz am Anfang beantwortet, in der Woche, in der man am wenigsten über das Projekt weiss. Sie werden auch beantwortet, wenn niemand sie stellt. Dann entscheidet der Entwickler, der gerade anfängt, oder der Anbieter, dessen Standardlösung eingekauft wurde. Beide entscheiden nicht falsch, sie entscheiden nur ohne das Geschäft im Blick.

Geschmack ist alles, was sich in einer Woche zurücknehmen lässt.

Die Ordnerstruktur im Projekt. Wie der Code formatiert wird. Welche Testbibliothek verwendet wird. Ob eine Funktion vier oder sechs Argumente hat. Ob das Framework A oder B heisst, solange beide dieselbe Sprache und dasselbe Hosting Modell haben. Über diese Dinge wird in Entwicklerteams am lautesten diskutiert, weil jeder eine Meinung hat und weil sie sichtbar sind.

Der Test ist immer derselbe: Wie lange dauert es, den Entscheid zurückzunehmen. Eine Woche, dann ist es Geschmack und die Antwort lautet, dass das Team entscheidet und niemand nachträglich daran zieht. Ein Quartal plus Migration, dann ist es Architektur und gehört auf den Tisch der Geschäftsleitung, übersetzt in Geld und Risiko.

Es kommt vor, dass beides verwechselt wird, in beide Richtungen. Ein Team streitet drei Tage über die Ordnerstruktur und hat nebenbei festgelegt, dass die Kundendaten im Onlineshop führend sind, ohne dass jemand im Unternehmen das je bestätigt hat. Das ist kein Vorwurf an das Team. Über Geschmack zu streiten ist billig und macht Spass, die Architekturfrage ist unangenehm, weil sie eine Antwort aus dem Geschäft braucht, die noch niemand gegeben hat.

Die Kosten eines falschen Entscheids wachsen mit jedem Monat, in dem er unbemerkt bleibt.

In der ersten Projektwoche kostet ein Wechsel des Datenmodells einen Tag: Es hängt nichts daran. Nach sechs Monaten, mit zwei angebundenen Systemen und ein paar zehntausend Datensätzen, sind es zwei bis vier Wochen, weil Migration, Schnittstellen und Tests dazukommen. Nach drei Jahren wird der Wechsel nicht mehr gemacht, sondern umgangen: Jeder neue Wunsch bekommt einen Sonderweg und der Satz, der das ankündigt, lautet, dass das mit unserem System leider nicht geht.

Teuer wird nicht der Code, sondern das, was inzwischen daran hängt. Auswertungen, die auf der alten Struktur beruhen. Eine Schnittstelle zur Buchhaltung, die jemand vor zwei Jahren gebaut hat und die niemand mehr anfassen will. Mitarbeitende, die sich einen Ablauf angewöhnt haben, der nur wegen des alten Modells so aussieht. Wer das später aufräumt, zahlt für ein paar Wochen Entwicklung und für Monate, in denen zwei Wahrheiten parallel laufen.

Seit Entwicklung mit KI schneller geht, fällt dieser Punkt früher an, nicht später. Vibe Coding ist nicht per se schlecht, es verschiebt nur, wo die Fehler auftauchen: An einem Nachmittag steht etwas Lauffähiges und alle sechs Architekturfragen von oben sind damit beantwortet, ohne dass jemand sie gestellt hat. Das Ergebnis kann trotzdem richtig sein. Nur weiss es niemand, weil die Entscheide nirgends stehen.

Der grösste Architekturentscheid ist der, ob überhaupt gebaut wird.

Standardsoftware trifft die Architekturentscheide für dich. Du übernimmst das Datenmodell des Anbieters, seine Vorstellung davon, was ein Kunde ist, seinen Speicherort und seine Schnittstellen. Das ist ein guter Handel, solange das Geschäft in dieses Modell passt und ein schlechter, sobald es das nicht tut. Eigene Software rechnet sich erst, wenn der Unterschied das Geschäft betrifft und genau dieser Unterschied ist eine Architekturfrage, keine Geschmacksfrage.

Ein Software Architect prüft das, bevor die Offerte unterschrieben ist und stellt drei Fragen an den Anbieter. Welche Daten bekomme ich in welchem Format wieder heraus, ohne dich zu fragen. Welche Schnittstellen gibt es und was kosten sie. Und was passiert bei einer Kündigung, technisch und zeitlich. Der Ausstieg ist Teil der Architektur, auch wenn er im Verkaufsgespräch nie vorkommt. Wer ihn beim Einkauf klärt, zahlt dafür nichts. Wer ihn beim Ausstieg klärt, zahlt den Preis, den der Anbieter dann aufruft.

Ein Software Architect entscheidet nicht allein, er macht die Folgen sichtbar.

Die Rolle liefert Optionen mit Konsequenzen: Variante A kostet heute weniger und bindet uns fünf Jahre an einen Anbieter, Variante B kostet zwei Wochen mehr und lässt uns wechseln. Welche davon das Unternehmen will, ist eine Frage von Geschäft und Geld, nicht von Technik. Ein CTO entscheidet, was gebaut, gekauft und gelassen wird und er bringt Architektur, Kosten, Verträge und Datenschutz an einen Tisch. In einem KMU sind Architect und CTO oft dieselbe Person oder derselbe Partner und das ist in Ordnung, solange beide Fragen gestellt werden: was technisch daraus folgt und ob das Unternehmen diese Folge tragen will.

Dazu gehört ein zweiter, unspektakulärer Teil der Rolle: Entscheide aufschreiben, mit Datum, Begründung und der Alternative, die verworfen wurde. Ein halber Bildschirm Text pro Entscheid reicht. Was nicht aufgeschrieben ist, wird in sechs Monaten neu entschieden, meistens anders und niemand merkt es, bis zwei Teile der Software von zwei verschiedenen Annahmen ausgehen.

Ein KMU braucht die Rolle für ein paar Tage, nicht für eine Stelle.

Es gibt vier Auslöser, bei denen sich die Frage stellt. Es wird eigene Software gebaut oder bauen lassen. Eine Standardlösung wird tief in bestehende Abläufe eingebunden. Zwei Systeme halten dieselben Daten und niemand kann sagen, welches führt. Oder ein Anbieter wird gewechselt, was die alten Entscheide auf einen Schlag wieder öffnet.

Als Grössenordnung aus unserer Erfahrung: Zwei bis fünf Tage am Anfang eines Projekts, danach ein halber Tag pro Monat, solange gebaut wird. Bei einem Projekt zwischen CHF 10'000 und CHF 30'000 sind das wenige Prozent des Budgets und sie entscheiden darüber, ob sich das Ergebnis in drei Jahren noch erweitern lässt oder ob es dann ersetzt wird. Eine Vollzeitstelle wird die Rolle erst, wenn ein Unternehmen mehrere eigene Systeme betreibt und eigene Entwicklerteams beschäftigt. Vorher ist es ein Auftrag und er lässt sich an jemanden von aussen geben.

Bei uay gehört Software Architect zur Disziplin Architektur und Engineering, neben Solution Architect, Full-Stack Software Engineer, Integration Engineer und Solution Engineer. Bei jedem Problem schauen wir zuerst, welche Rollen es braucht. Bei einem neuen Projekt, bei einer Offerte für eine Individualentwicklung und bei jedem Anbieterwechsel ist diese fast immer dabei. Sie muss nicht bei uns liegen: Wenn der Entwicklungspartner sie besetzt und die Entscheide aufschreibt, ist das der einfachere Weg. Wenn niemand zuständig ist, übernehmen wir es, mit Aufwand und Preis in der Offerte und bleiben gegenüber dem Kunden verantwortlich.