Ich bin Architekt. Ich habe nie aufgehört, einer zu sein.

🔍„Was machst du genau?"

Drei Worte. Eine kurze Pause. Und wer 25 Jahre in Verantwortung war, hat in diesem Moment ein Problem – nicht weil die Antwort fehlt, sondern weil sie zu groß ist für eine Gesprächspause.

Ich habe diese Frage lange schlecht beantwortet. Nicht aus Unklarheit. Aus Vollständigkeitsanspruch. Der Architekt in mir wollte das System erklären, bevor er das Ergebnis nennt. Die Abhängigkeiten aufzeigen, bevor er die Lösung beschreibt. Den Kontext herstellen, bevor er zur Sache kommt.

💡Das war der Fehler. Aber um den zu verstehen, muss man von vorne anfangen.

Alles beginnt mit einer leeren Seite

Als ich als Anwendungsentwickler angefangen habe, war die erste Frage nie: Wie schreibe ich den Code? Die erste Frage war immer: Wie hängt das zusammen? Was ist Ursache, was ist Symptom? Welche Struktur macht das System erweiterbar – und welche zementiert es in einer Form, die in zwei Jahren niemanden mehr glücklich macht?

💥Softwarearchitektur ist im Kern Komplexitätsmanagement. Du nimmst ein unübersichtliches Problem, zerlegst es in handhabbare Teile, definierst Schnittstellen, machst Abhängigkeiten sichtbar. Du denkst in Modellen, weil Modelle das einzige Werkzeug sind, das Komplexität nicht ignoriert, sondern beherrschbar macht.

Und früh lernt man als Architekt einen Grundsatz, der einen nie mehr verlässt:

📈 Wartbarkeit vor Funktionalität.

Ein System, das heute funktioniert, aber morgen niemand mehr anfassen kann, ist kein fertiges System. Es ist eine Zeitbombe mit Lieferschein. Wer nur an die Funktion denkt, baut für den Abnahmetermin. Wer an Wartbarkeit denkt, baut für die nächsten zehn Jahre. Der Unterschied zeigt sich nicht im ersten Betriebsmonat. Er zeigt sich, wenn sich etwas ändern muss.

Wer das ernsthaft verinnerlicht hat, denkt danach in jedem System so – ob das System aus Klassen besteht oder aus Menschen, Prozessen und Gebäuden. Die Systemebene ändert sich. Die Denkweise nicht.

Das war keine Methode, die ich mir angeeignet habe. Das war eine Haltung, die sich festgesetzt hat. Und ich habe sie nie wieder abgelegt.

Vom Code zur Organisation – und was T-Shape wirklich bedeutet

Der Schritt von der Softwarearchitektur in Führungsverantwortung wird von außen oft als Karrierewechsel beschrieben. Ein Techniker, der Manager wird. Einer, der das Fachliche aufgibt und das Strategische übernimmt.

🧨Das stimmt nicht. Zumindest nicht so.

Was sich verändert hat, war die Systemebene. Nicht die Fragestellung. Als Head of Corporate Operations in einem großen DACH-Finanzinstitut war ich CIO – aber eben nicht nur. IT-Security, Datenschutz, Prozessmanagement, Projektsteuerung, Gebäudemanagement. Für andere klang das nach einem ungewöhnlichen Bündel. Für mich war es die konsequente Fortsetzung einer Architektenperspektive auf eine neue Systemebene.

In der Personalentwicklung spricht man von T-Shape: ein vertikaler Strich, der für tiefes Fachwissen steht, und ein horizontaler Balken, der für Breite an den Schnittstellen steht. Der Begriff ist nützlich, wird aber meistens falsch verstanden. Viele lesen ihn als Kompromiss – ein bisschen Tiefe, ein bisschen Breite, irgendwie beides. Das ist nicht gemeint.

💥T-Shape bedeutet: Du hast eine Domäne, in der du wirklich tief bist. Tief genug, um in der Sache ernst genommen zu werden, um Qualität zu beurteilen, um Risiken zu erkennen, die andere nicht sehen. Und du hast gleichzeitig breites Verständnis für angrenzende Disziplinen – nicht weil du überall mitreden willst, sondern weil 🎯Systeme an Schnittstellen versagen. Wer nur den vertikalen Strich hat, löst Probleme in seiner Domäne präzise – und übersieht, dass das eigentliche Problem eine Ebene höher liegt.

Ein Datenschutzverstoß ist fast immer ein Prozessproblem. Ein Sicherheitsvorfall ist fast immer eine Governance-Lücke. Ein ineffizientes Gebäude ist ein schlecht integriertes System.

⚠️Wer das in Silos denkt, löst Symptome. Wer es als Architektur denkt, verändert Strukturen.

Der horizontale Balken des T war keine Ablenkung vom vertikalen. Er war die Voraussetzung dafür, dass der vertikale überhaupt wirkt.

🔥Die Lektion, die keine Architektur lehrt

Irgendwann – und das war kein einzelner Moment, sondern eine schleichende Erkenntnis über Jahre – habe ich verstanden, dass die eleganteste Struktur wertlos ist, wenn die Menschen, die darin arbeiten sollen, sie nicht verstehen, nicht akzeptieren oder still und konsequent umgehen.

⚡Software kann man zwingen. Menschen nicht.

IT-Security scheitert fast nie an der Technik. Sie scheitert am Verhalten. An dem Mitarbeiter, der das Passwort auf einen Zettel schreibt, weil die Richtlinie praxisfremd ist. An der Führungskraft, die die Ausnahmeregelung durchsetzt, weil Prozesse unbequem sind. An der Organisation, die Security als Kontrollmechanismus versteht statt als gemeinsame Verantwortung.

KI-Prozessautomation scheitert nicht an Algorithmen. Sie scheitert an Organisationen, die sich nicht verändern wollen – oder denen niemand erklärt hat, warum die Veränderung ihnen nützt und nicht schadet. Wer Automatisierung einführt ohne die Menschen mitzunehmen, bekommt bestenfalls Widerstand. Meistens bekommt er beides: Widerstand und ein teures System, das niemand benutzt.

🎯 Strukturen sind Mittel. Menschen sind Zweck.

Das klingt nach einem Satz aus einem Managementseminar. Es ist aber das Ergebnis aus dem Scheitern gut gemeinter Architekturen, die an der Wirklichkeit von Organisationen gebrochen sind. Und aus der Erkenntnis, dass Veränderung nicht durch bessere Strukturen entsteht – sondern dadurch, dass Menschen in besseren Strukturen arbeiten wollen.

Das ist, was ich mit „Mittelpunkt Mensch" meine. Nicht als Gegensatz zur Architektur-Perspektive. Als ihre notwendige Ergänzung. 📌Ein System, das den Menschen ignoriert, ist kein fertiges System. Es ist ein Entwurf, der auf Umsetzung wartet, die nie kommt.

🚀Drei Säulen, eine Wurzel

Seit 2020 bin ich selbständig. Drei Beratungsangebote: CISO as a Service, KI-Prozessautomation, Connected Spaces. Alle drei kommen aus echter Praxis. Kein Marketing-Konstrukt, kein aufgeblasenes Kompetenzversprechen. Aber wer sie nebeneinander hört, hört ein Portfolio. Und der Markt kauft keine Portfolios. Er kauft Lösungen mit Namen.

Was ich lange nicht klar genug kommuniziert habe: Diese drei Angebote sind kein Widerspruch. Sie sind dasselbe T, drei Mal auf unterschiedliche Systemebenen angewendet. Und alle drei haben dieselbe Wurzel – Architektur, die den Menschen einbaut.

🧩 CISO as a Service ist strukturierte Sicherheitsarchitektur. Für Unternehmen, die keinen eigenen Architekten in dieser Rolle haben – und ihn nicht dauerhaft brauchen. Wer IT-Security als Governance-Thema versteht und nicht als Technologie-Einkaufsliste, baut etwas Belastbares. Aber Governance ohne Akzeptanz ist Bürokratie. Der Mensch muss verstehen, warum die Regeln gelten – sonst gelten sie nicht wirklich.

🧩 KI-Prozessautomation beginnt nicht mit KI. Sie beginnt mit IT-Architektur. Wer Prozesse automatisieren will, braucht zuerst eine Infrastruktur, auf der Automatisierung aufsetzen kann – saubere Datenbasis, integrierte Systeme, definierte Schnittstellen. KI auf chaotische IT-Landschaften zu setzen ist wie Präzisionswerkzeug auf wackeligem Fundament.

Schlechte Prozesse auf schlechter Infrastruktur werden durch Automatisierung nicht besser. Sie werden schneller schlechter.

Und noch etwas: Bei Prozessen geht es um Ergebnisse, nicht um Aktivitäten. Das klingt selbstverständlich – ist es aber nicht. Viele Automatisierungsvorhaben optimieren fleißig das Falsche. Sie beschleunigen Abläufe, ohne zu fragen, ob der Ablauf überhaupt zum richtigen Ergebnis führt. Deshalb greift Prozessautomation, wenn sie ernst gemeint ist, weiter als KI, IT-Systeme und digitalisierte Abläufe. Sie stellt Organisationsstrukturen in Frage. Wer ist wofür zuständig? Welche Hierarchiestufe fügt Wert hinzu – und welche verwaltet nur sich selbst?

Manchmal ist das Ergebnis einer guten Prozessanalyse kein Automatisierungsprojekt, sondern eine andere Aufbauorganisation. Das ist unbequem. Und meistens wirksamer.

🧩 Connected Spaces ist Gebäudearchitektur, die mit der IT-Architektur zusammenwächst. Sensorik, Automatisierung, Integration. Kein Komfortthema – Betriebseffizienz und Sicherheit auf Gebäudeebene. Aber auch hier: Ein intelligentes Gebäude, das von den Menschen, die darin arbeiten, als Überwachungssystem wahrgenommen wird, hat ein Akzeptanzproblem, das keine Technologie löst.

Drei Angebote. Dieselbe Frage dahinter:

✅ Wie bauen wir das so, dass es funktioniert, änderbar bleibt – und von Menschen getragen wird?

📣Das eigentliche Kommunikationsproblem

Der Markt kauft keine Denkweisen. Er kauft Lösungen mit Namen. Das ist keine Kritik – das ist Marktlogik. Und wer diese Logik versteht, kommuniziert anders: nicht breiter, sondern schärfer. Nicht mehr, sondern gezielter.

Die Aufträge, die reinkamen, kamen auf zwei Wegen.

Der erste: jemand hat ein konkretes Problem, hört den einen Satz, der trifft – und ruft an. Jemand hat mich als „den CISO-Mann" weiterempfohlen. Jemand anders hat gesagt: „Der versteht, wie Prozesse und Automatisierung zusammenhängen." Ein dritter hat mich angerufen, weil er ein Gebäude hat, das intelligent werden soll, und jemanden braucht, der IT und Facility zusammendenkt.

Der zweite Weg: jemand hat kein einzelnes Problem. Er hat eine gewachsene IT-Landschaft, die niemand mehr überblickt – und will kein Flickwerk mehr, sondern eine Neukonzeption. Virtualisierung und Netzwerk neu gedacht, Cloud wo es Sinn ergibt, Architektur die trägt. Kein Auftrag für einen Spezialisten. Ein Auftrag für jemanden, der das Ganze sieht.

Keiner davon hat gesagt: „Ich suche jemanden, der alles kann." Sie haben gesagt: „Ich habe dieses Problem. Bist du der Richtige?"

🎯 Der Unterschied ist nicht die Kompetenz. Der Unterschied ist der Einstiegssatz.

🏁Die Antwort

🔍„Was machst du genau?"

♻️ Ich bin Architekt. Ich baue Strukturen, die Menschen ermöglichen, Unternehmen sicherer, effizienter und zukunftsfähiger zu machen.

Und wer jetzt denkt, das klingt nach einem großen Anspruch für ein mittelständisches Unternehmen mit dringenderen Problemen: Man kann klein anfangen, wenn man groß denkt. Ein ISMS, das auf Wachstum ausgelegt ist statt auf Compliance-Kosmetik. Eine erste Automatisierung, die wirklich auf die IT-Architektur aufsetzt statt daran vorbeizulaufen. Ein Gebäude, das mit einem Sensor anfängt und mit einem System endet.

📈 Think big. Start small. But start.

Den Rest erkläre ich, wenn jemand fragt. Und wer fragt, ist schon dabei.

🔥Erfahrung macht dich glaubwürdig. Denkweise macht dich unverwechselbar. Relevanz macht dich kaufbar. Und wer den Menschen vergisst, baut Architekturen, in denen niemand wohnen will.

Über den Autor

Gerd Kopp ist Wirtschaftsinformatiker, ehemaliger CIO und Head of Corporate Operations eines großen DACH-Finanzinstituts – und seit 2020 selbständiger Interim Manager und IT-Berater für den Mittelstand.

Seine Beratungsschwerpunkte: CISO as a Service, KI-Prozessautomation und Connected Spaces. Sein Ansatz: Strukturen, die Menschen ermöglichen, Unternehmen sicherer, effizienter und zukunftsfähiger zu machen.

Security by Design · Veränderung mit Wirkung

🌐 gerds-it.de 📝 gerds-blog.de 💼 LinkedIn ✉️ info@gerds-it.de