0800 71 20000
Kontakt
...
Entscheidungen mit Halbwertszeit

Wenige Entscheidungen sind teuer, die meisten nicht

Datenhaltung, Schnitt und die Frage synchron oder asynchron bleiben jahrelang. Bibliotheken und Namen lassen sich jederzeit ändern, und beides zu verwechseln kostet Zeit.

Passende Kurse ansehen Persönlich beraten lassen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Kleine Gruppen Präsenz und Live-Online Zertifizierte Trainer
Worum es geht

Ohne begründete Entscheidungen entscheidet die Reihenfolge der Tickets

In Anwendungen, die über Jahre wachsen, entsteht Struktur auch dann, wenn niemand sie entwirft. Diese Struktur ergibt sich aus der Reihenfolge, in der Anforderungen kamen, aus dem Zeitdruck vor Auslieferungen und aus den Vorlieben der Leute, die zufällig gerade an der Stelle gearbeitet haben. Das Ergebnis ist keine falsche Architektur, sondern gar keine, also eine Anwendung, deren Verhalten sich nur noch durch Ausprobieren erschließt.

Sichtbar wird das an den Kosten von Änderungen. Eine neue Anforderung, die fachlich klein ist, berührt sechs Stellen, weil dieselbe Regel dreimal ausprogrammiert wurde. Ein Wechsel des Zahlungsanbieters greift in die halbe Anwendung, weil seine Datenstrukturen bis in die Oberfläche durchgereicht wurden. Solche Kosten stehen in keinem Ticket, sie erscheinen als allgemeine Langsamkeit des Teams.

Die zweite Fehlerquelle sind unausgesprochene Qualitätsziele. Der Fachbereich sagt, die Anwendung müsse schnell und immer verfügbar sein. Ohne Zahl ist das nicht prüfbar, und im Zweifel wird für einen Anspruch gebaut, den niemand verlangt hat, oder eben nicht für den, den jemand tatsächlich hat. Diese Übersetzung ist die eigentliche Arbeit dieser Rolle.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was

Wer entscheidet, und wer setzt um

Die häufigste Ursache für Streit in dieser Rolle ist nicht die falsche Entscheidung, sondern die unklare Zuständigkeit dafür. Diese fünf Zeilen sind die Fälle, um die es fast immer geht.

Auswahl von Sprache, Rahmenwerk und Datenbank

Wer entscheidet
Die Architektur zusammen mit dem Team, die IT-Leitung trägt Budget und Personalfolgen
Wer setzt um
Das Entwicklungsteam, das anschließend jahrelang darin arbeitet
Stolperfalle
Entschieden wird nach fachlicher Eleganz, nicht nach Verfügbarkeit von Leuten und Wartbarkeit über zehn Jahre. Wer eine Technik wählt, für die im Umkreis niemand zu finden ist, hat ein Personalproblem gebaut.

Schnitt der Anwendung in Module oder Dienste

Wer entscheidet
Die Architektur, entlang fachlicher Zuständigkeiten und in Abstimmung mit den betroffenen Fachbereichen
Wer setzt um
Die Teams, die entlang dieses Schnitts arbeiten und ihn im Alltag prüfen
Stolperfalle
Der Schnitt folgt der Technik statt der Fachlichkeit. Ergebnis sind Dienste, die sich bei jeder Anforderung gegenseitig ändern müssen, also ein verteilter Monolith mit allen Nachteilen beider Welten.

Qualitätsziele wie Antwortzeit und Verfügbarkeit

Wer entscheidet
Der Fachbereich und die Geschäftsführung, denn beides kostet Geld und ist eine Geschäftsentscheidung
Wer setzt um
Die Architektur übersetzt die Ziele in prüfbare Größen, die Teams messen sie im Betrieb
Stolperfalle
Es bleibt bei muss schnell sein. Ohne Zahl und Messpunkt lässt sich weder etwas dagegen bauen noch nachweisen, dass es erreicht ist, und im Zweifel diskutiert ihr über Eindrücke.

Querschnittsthemen wie Anmeldung und Protokollierung

Wer entscheidet
Die Architektur gemeinsam mit der Informationssicherheit
Wer setzt um
Alle Teams, üblicherweise über eine gemeinsame Bibliothek oder einen bereitgestellten Dienst
Stolperfalle
Jedes Team löst es selbst, weil eine Vorgabe fehlt. Beim nächsten Sicherheitsvorfall gibt es dann sechs Protokollformate und keine Möglichkeit, einen Vorgang durch das System zu verfolgen.

Umgang mit dem Bestand

Wer entscheidet
Die IT-Leitung über das Budget, die Architektur über den Weg
Wer setzt um
Die Teams, meist schrittweise über Schnittstellen um den Bestand herum
Stolperfalle
Der vollständige Neubau wird beschlossen, ohne dass die Fachregeln des Bestands vollständig bekannt sind. Solche Projekte scheitern nicht an der Technik, sondern an dem, was niemand aufgeschrieben hat.

Fünf Entscheidungen, die man später schwer zurücknimmt

  1. 01 Wie und wo Daten gehalten werden.
  2. 02 Wo die Grenze zwischen zwei Diensten verläuft.
  3. 03 Ob Aufrufe synchron warten oder asynchron entkoppelt sind.
  4. 04 Welche Abhängigkeit zu einem Anbieter eingegangen wird.
  5. 05 Wie Anmeldung und Berechtigungen quer durch das System laufen.
Was du mitnimmst

Was die Rolle im Alltag leistet

Architektur ist keine Zeichnung, sondern eine Reihe begründeter Entscheidungen mit einem Ort, an dem sie nachlesbar sind. Die folgenden Punkte beschreiben, was davon in fast jedem Haus anfällt.

Nach Fachlichkeit schneiden

Du teilst eine Anwendung entlang fachlicher Zuständigkeiten und nicht entlang technischer Schichten, weil ein Schnitt nach Technik dazu führt, dass jede fachliche Änderung überall gleichzeitig anfasst.

Qualitätsziele übersetzen

Du machst aus muss schnell sein eine Zahl mit Messpunkt und aus muss immer laufen eine Aussage darüber, welcher Ausfall wie lange hinnehmbar ist.

Teure von billigen Entscheidungen trennen

Du erkennst, welche Festlegungen sich später kaum zurücknehmen lassen, etwa die Datenhaltung oder die Grenze zwischen zwei Diensten, und wo eine Entscheidung jederzeit revidierbar ist.

Entscheidungen festhalten

Du dokumentierst kurz und dauerhaft, was entschieden wurde, welche Alternativen betrachtet wurden und warum, damit in zwei Jahren niemand dieselbe Diskussion von vorn führt.

Querschnittsthemen vorgeben

Du legst fest, wie Anmeldung, Protokollierung, Fehlerbehandlung und Nachvollziehbarkeit einheitlich gelöst werden, statt jedes Team eine eigene Antwort finden zu lassen.

Im Code bleiben

Du arbeitest weiter an der Anwendung mit, weil Entscheidungen ohne Kenntnis des Bestands zu Vorgaben werden, die im Alltag umgangen werden.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Was den Alltag ausmacht, und was Leute falsch erwarten

Erwartet wird ein Schreibtisch mit Diagrammen. Tatsächlich besteht der Tag zu großen Teilen aus Gesprächen: mit Entwicklungsteams über konkrete Umsetzungsfragen, mit dem Fachbereich über Ziele, mit dem Betrieb über Verfügbarkeit und Aktualisierungen, mit der Informationssicherheit über Anforderungen, die jemand umsetzen muss. Wer nicht gern erklärt und zuhört, ist in dieser Rolle unglücklich.

Der zweite Anteil ist die schriftliche Arbeit, und sie ist wichtiger, als sie wirkt. Eine Entscheidung, die nur mündlich getroffen wurde, wird in einem halben Jahr neu diskutiert, meist von jemandem, der die damaligen Gründe nicht kennt. Ein kurzer Eintrag mit Ausgangslage, betrachteten Alternativen und Begründung spart genau diese Runde. Verbreitete Vorlagen für Architekturdokumentation geben dafür eine Struktur vor.

Falsch erwartet wird außerdem die Menge an Macht. In den meisten Häusern hat diese Rolle keine Weisungsbefugnis, sondern muss überzeugen. Wer im Code bleibt und Vorschläge an einer echten Stelle der Anwendung zeigt, überzeugt. Wer nur Vorgaben verteilt, erlebt, wie sie im Alltag höflich umgangen werden.

Der Weg hinein, und was der übliche Nachweis ist

Der Einstieg führt fast immer über mehrere Jahre Entwicklung. Wer nie eine Anwendung über längere Zeit gepflegt hat, kennt die Folgen von Entscheidungen nicht, und genau diese Folgen sind der Stoff dieser Rolle. Typisch ist der Übergang innerhalb eines Teams: Erst verantwortest du einen Bereich, dann den Schnitt, dann die Entscheidungen über mehrere Teams hinweg.

Als Nachweis hat sich im deutschsprachigen Raum die Zertifizierung des International Software Architecture Qualification Board etabliert, deren Einstiegsstufe den Wortschatz und die Vorgehensweisen ordnet. Projekterfahrung ersetzt sie nicht, in Ausschreibungen wird sie aber genannt und in der Beratung ist sie teilweise Voraussetzung für die Besetzung von Projekten.

Was im Gespräch tatsächlich zählt, ist eine Entscheidung, die du erklären kannst, samt der Alternative, die du verworfen hast, und samt dem, was du heute anders machen würdest. Wer nur Muster und Begriffe aufzählt, fällt an der ersten Rückfrage nach dem konkreten Fall durch.

Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden

Der erste Unterschied ist die Auswahl der Entscheidungen. Die eine mischt sich in wenige, dafür folgenreiche Fragen ein und lässt den Teams den Rest. Der andere entscheidet alles mit, wird zum Engpass und produziert Vorgaben zu Fragen, die sich in zwei Wochen von selbst erledigt hätten.

Der zweite ist die Nähe zum Betrieb. Wer weiß, wie die Anwendung ausgeliefert, überwacht und im Störfall wiederhergestellt wird, entwirft anders. Architektur ohne Betriebssicht erzeugt Systeme, die im Labor elegant sind und deren Ausfall niemand innerhalb einer vertretbaren Zeit beheben kann.

Der dritte ist der Umgang mit dem eigenen Irrtum. Entscheidungen altern, weil sich Anforderungen ändern. Wer eine frühere Entscheidung offen revidiert und den Grund dazuschreibt, bekommt Vertrauen. Wer sie verteidigt, weil sie von ihm stammt, verliert es, und die Teams bauen ab da an der Vorgabe vorbei.

Wohin die Rolle führt

Drei Wege sind üblich. Der erste geht in die Breite, zur Unternehmensarchitektur, wo es nicht mehr um eine Anwendung, sondern um die Landschaft mehrerer Systeme und ihrer Schnittstellen geht. Der zweite geht in die technische Leitung, also Verantwortung für Teams, Budget und Personalentwicklung. Der dritte bleibt technisch und geht in eine Spezialisierung, etwa Daten, Sicherheit oder Plattform.

Nicht zur Rolle gehört der Betrieb der Plattform selbst, also der Aufbau der Umgebungen, in denen die Anwendungen laufen. Das ist ein eigenes Feld mit eigenen Werkzeugen, und die Abgrenzung dorthin ist in vielen Häusern unscharf. Wer beides gleichzeitig verantwortet, sollte wissen, dass er zwei Rollen ausfüllt.

Zu der Zahl weiter unten: Das Anforderungsniveau Experte beschreibt den Zuschnitt der Stelle und nicht die Dienstjahre. Für diese Rolle ist das besonders wichtig, weil Architektur in vielen Häusern eine Funktion neben der Entwicklung ist und die betreffenden Stellen dann als Entwicklungsstellen gemeldet werden. Der Median trägt weiter als der Durchschnitt, den Spitzenverdienste nach oben ziehen. Die Werte gelten für Vollzeit ohne Sonderzahlungen, Weihnachts- und Urlaubsgeld fehlen darin.

Dazu passende Kurse

Wenn du das an einem echten System üben willst, gibt es Kurse, in denen du Entwurfsentscheidungen begründest statt sie zu behaupten .

Was verdient man

Die amtlichen Zahlen zu dieser Rolle

Softwarearchitektur ist in der Klassifikation der Berufe keine eigene Berufsgattung, deshalb steht hier die Zelle Softwareentwicklung im Anforderungsniveau Experte, und Experte meint den Zuschnitt der Stelle und nicht deine Dienstjahre. Für diese Rolle verzerrt das besonders stark, weil Architektur in vielen Häusern eine Funktion neben der Entwicklungsarbeit ist: Solche Stellen werden als Entwicklungsstellen gemeldet und tauchen in der Expertenzeile gar nicht auf. Wer eine reine Architekturstelle mit Personalverantwortung sucht, findet den Verdienst dafür eher in den Führungszellen, die auf dieser Seite bewusst nicht stehen. Der Median sagt mehr als der Durchschnitt, den einzelne Spitzenverdienste anheben.

Amtliche Medianverdienste, April 2025

Brutto im Monat

Statistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.

Softwareentwicklung Experte 6.000 €

KldB 43414, Durchschnitt 6.313 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen

02k4k6k
  • Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
  • Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
  • Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.

Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.

Konkrete Kurse

Wo du genau das übst

Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
LimeSurvey - Anwendertraining Teil 1 (Grundlagen)
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
BricsCAD 2D Schulung Grundkurs
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
BricsCAD 3D Schulung - Grundlagen

Häufige Fragen

Muss ich als Architekt aufhören zu programmieren?
Besser nicht. Entscheidungen ohne Kenntnis des Bestands werden zu Vorgaben, die im Alltag umgangen werden, und du merkst es erst, wenn es zu spät ist. Üblich ist ein Anteil: weniger Umsetzung als vorher, aber genug, um den Zustand der Anwendung aus eigener Anschauung zu kennen und Vorschläge an einer echten Stelle zeigen zu können.
Brauche ich Microservices, um als Architekt zu gelten?
Nein, und die Frage ist meist falsch gestellt. Ein gut geschnittener Monolith ist für viele Häuser die bessere Antwort, weil verteilte Systeme Betriebsaufwand, Nachvollziehbarkeit und Fehlerbilder mitbringen, für die Personal da sein muss. Entscheidend ist der fachliche Schnitt, und den kannst du auch innerhalb einer Anwendung sauber ziehen.
Lohnt sich eine Architekturzertifizierung?
Für die Sichtbarkeit ja, für die Fähigkeit nur begrenzt. Die verbreitete Einstiegsstufe ordnet Begriffe und Vorgehensweisen und gibt dir eine gemeinsame Sprache mit anderen Häusern. In Ausschreibungen und in der Beratung wird sie genannt, teilweise vorausgesetzt. Ersetzen kann sie die Erfahrung nicht, wie eine Entscheidung nach drei Jahren aussieht.
Wie halte ich Entscheidungen fest, ohne ein Dokumentationsprojekt zu starten?
Kurz und am Code. Ein knapper Eintrag je Entscheidung mit Ausgangslage, betrachteten Alternativen, Entscheidung und Konsequenzen, abgelegt im selben Verwaltungssystem wie der Code. Für den Gesamtüberblick gibt es fertige Vorlagen für Architekturdokumentation, aus denen du die Abschnitte nimmst, die auf euer Haus passen, statt sie vollständig auszufüllen.

Quellen

Passt thematisch dazu

Bevor ihr eine Anwendung aufteilt, gehört die nüchterne Abwägung dazu, wann sich das Zerlegen einer Anwendung wirklich lohnt .

Architektur endet dort, wo der Betrieb anfängt, und deshalb lohnt die Frage, wer die Umgebungen bereitstellt, in denen eure Dienste laufen .

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.

0800 71 20000 E-Mail

Entwurfsentscheidungen begründen, nicht behaupten

Bei cmt zerlegst du eine gewachsene Anwendung, wägst Schnitte gegeneinander ab und lernst, deine Entscheidung so aufzuschreiben, dass sie in zwei Jahren noch nachvollziehbar ist.

Alle Kurse und Termine Frage stellen

Passt dazu

Alle Themen zu IT-Berufe