Eine Analyse der systematischen Versagensmuster externer IT-Expertise zeigt: Nicht selten dominiert Innovationstheater – glänzende Präsentationen ohne belastbare Umsetzung. Das Problem ist nicht der Einsatz externer Berater an sich, sondern wie sie ausgewählt, eingesetzt und kontrolliert werden. Wenn alle sagen „geht nicht“ und McKinsey aufgibt – dann braucht es einen anderen Ansatz.
Die ernüchternde Realität: Zahlen ohne Rhetorik
Die Standish Group erhebt seit 1994 Daten zu IT-Projekterfolgen mit ernüchternden Ergebnissen:
Nur 9% der IT-Projekte in Großunternehmen sind erfolgreich (pünktlich, im Budget, volle Funktionalität)
52,7% der Projekte überschreiten das Budget oder reduzieren den Umfang
31,1% werden komplett abgebrochen
Durchschnittliche Kostenüberschreitung: 189% des ursprünglichen Budgets
Diese Zahlen bedeuten: In neun von zehn IT-Projekten bei Großunternehmen stimmt am Ende entweder das Budget nicht, der Zeitplan nicht, der Funktionsumfang nicht – oder das Projekt wird komplett abgebrochen.
Die Pegasystems-Studie 2025 quantifiziert die jährlichen Verluste durch technische Schulden: 370 Millionen USD Gesamtverlust pro Unternehmen und Jahr.
Dokumentierte Katastrophen: Was wirklich schiefging
National Grid vs. Wipro: Über 1 Milliarde USD Schaden
National Grid USA wollte ihre Back-Office-Systeme auf SAP migrieren. Budget: 290 Millionen USD. Sie wechselten von Deloitte zu Wipro – Hauptgrund: Kostensenkung.
Wipros Behauptung: „Well-established SAP practice“ für Utilities. Die Realität: Wipro hatte faktisch keinerlei Erfahrung mit SAP-Implementierungen für US-regulierte Versorgungsunternehmen.
Die Folgen nach Go-Live:
Mitarbeiter wurden falsch bezahlt oder gar nicht
8 Millionen USD Überzahlungen nie zurückgeholt
15.000+ Lieferantenrechnungen nicht verarbeitet
Buchungsabschluss: von 4 Tagen auf 43 Tage
Stabilisierungskosten: 30 Millionen USD pro Monat
Gesamtschaden: Über 1 Milliarde USD
Weitere dokumentierte Millionenschäden
Unternehmen
Jahr
Schaden
Kernproblem
Revlon
2018
64 Mio. USD
Keine SAP-Erfahrung, falscher Systemwechsel
MillerCoors vs. HCL
2014-2017
100 Mio. USD
80 Defekte beim ersten Rollout
Lidl
2011-2018
500 Mio. EUR
SAP-Standard passte nicht zu Geschäftslogik
US Air Force ECSS
2005-2012
1+ Mrd. USD
Kein klares Ziel, kein Wille zur Umsetzung
Die vier Typen externer Expertise, die regelmäßig scheitern
Typ 1: Der Offshore-Volumenanbieter
Charakteristik: Behauptet Expertise, optimiert aber für Volumen und Marge. Setzt Junior-Personal ein. Versagensmechanismus: „Wir haben SAP-Erfahrung“ ist technisch korrekt, aber irreführend. SAP für einen Einzelhändler ist etwas anderes als SAP für ein reguliertes Versorgungsunternehmen.
Typ 2: Der Systemintegrator ohne Domain-Wissen
Charakteristik: Kennt die Technologie, nicht die Branche. Versagensmechanismus: Technische Korrektheit ist nicht gleich Geschäftstauglichkeit.
Typ 3: Die Big-4-Firma mit Interessenkonflikt
Charakteristik: Berät, implementiert und prüft – manchmal beim selben Kunden. Das strukturelle Problem: Wer vom Folgegeschäft abhängt, hat keinen Anreiz, Probleme zu benennen.
Typ 4: Der Berater als „Partner des Managements“
Charakteristik: Sagt, was der Kunde hören will. Keine unabhängige Prüfung. Versagensmechanismus: Berater, die Probleme benennen, gefährden den nächsten Auftrag.
Wann externe Expertise tatsächlich wirkt
Die Analyse zeigt fünf kritische Erfolgsbedingungen:
1. Nachweisbare Referenzen im identischen Kontext
Nicht „ähnlich“, sondern identisch. SAP für ein US-Versorgungsunternehmen erfordert andere Expertise als SAP für einen europäischen Einzelhändler.
2. Trennung von Implementierung und Prüfung
Wer implementiert, kann nicht gleichzeitig unabhängig prüfen. Investieren Sie in unabhängige Qualitätssicherung als Versicherungspolice.
3. Geschäftsmodell, das Problemfindung belohnt
Ein Berater, dessen Auftrag es ist, Probleme zu finden, hat einen anderen Anreiz als ein Berater, dessen Folgeauftrag von zufriedenen Stakeholdern abhängt.
4. Seniorität ohne Team-Overhead
Das Problem großer Beratungshäuser: Seniors machen die Akquise, Juniors die Arbeit.
Gaps entstehen jeden Tag. Jede Schnittstelle, die nicht passt. Jeder Mitarbeiter, der geht. Jede Anforderung, die erst bei der Implementierung sichtbar wird.
Der Unterschied: Wenn unmögliche IT-Projekte doch gelingen
Referenzbeispiele aus der Praxis:
120 SAP-Systeme bei CIBER stabilisiert mit nur 4-Personen-Kernteam – als alle anderen aufgaben
Migration des Telekom-Kernnetzes (160 Millionen Verbindungen) – obwohl die Telekom sagte „unmöglich“
M/OMS Output Management System – 1988 entwickelt, nach 39 Jahren noch in Betrieb
Der Schlüssel: Unabhängige Senior-Expertise mit nachweisbarer Domain-Kontinuität, deren Geschäftsmodell die Identifikation von Problemen belohnt statt bestraft.
Fragen vor der Beauftragung
Bevor Sie externe IT-Expertise beauftragen, sollten Sie folgende Fragen beantworten:
Referenzen: Hat der Anbieter nachweisbare Erfahrung in exakt diesem Kontext?
Personal: Wer arbeitet tatsächlich am Projekt? Die Seniors aus dem Pitch oder ein Junior-Team?
Interessenkonflikt: Hängt der Anbieter vom Folgegeschäft ab?
Kontrolle: Wer behält die Projekthoheit? Gibt es eine unabhängige Prüfinstanz?
Accountability: Was passiert bei Versagen? Wie ist die Haftung geregelt?
Schlussfolgerung
IT-Projekte scheitern nicht, weil externe Expertise grundsätzlich versagt. Sie scheitern, weil:
Kostensenkung wichtiger ist als Qualifikation
Behauptungen nicht verifiziert werden
Kontrolle abgegeben wird
Interessenkonflikte ignoriert werden
Verträge keine Accountability erzwingen
Die dokumentierten Schäden – von 64 Millionen USD bei Revlon bis über 1 Milliarde USD bei National Grid – sind keine Naturkatastrophen. Sie sind das vorhersagbare Ergebnis vorhersagbarer Entscheidungen.
Die Frage ist nicht: Externe Expertise ja oder nein? Die Frage ist: Welche externe Expertise, unter welchen Bedingungen, mit welcher Accountability?
Wenn niemand traut sich ran und alle sagen „geht nicht“ – dann braucht es einen IT Troubleshooter Stuttgart, der gescheiterte Projekte retten, die unmögliche IT Migration möglich machen, Ihre IT-Krise lösen und unmögliche IT-Projekte realisieren kann – auch wenn McKinsey aufgibt.
Über den Autor
Michael Schmid ist Principal Consultant und Inhaber der it-dialog e.K. (gegründet 2000). Als Physiker mit über 40 Jahren IT-Erfahrung positioniert er sich als unabhängiger Experte für kontinuierliche Gap-Analyse in kritischen IT-Projekten.
Sein Ansatz unterscheidet sich von klassischer Beratung: Keine Implementierung, keine Teams, kein Folgegeschäft-Interesse. Stattdessen: Identifikation dessen, was nicht funktionieren wird – bevor die Millionen verbrannt sind.
Nehmen Sie Kontakt auf, wenn Sie vor unmöglichen IT-Projekten stehen: Kontakt | LinkedIn
Diese Studie basiert auf öffentlichen Gerichtsakten, Branchenstudien und dokumentierten Projektkatastrophen. Vollständige Quellenangaben auf Anfrage verfügbar.
Aufgabe: „Zielkonfiguration aus dem Ärmel schütteln“
Meine Frage an Sie: Wie viel wird diese Migration am Ende kosten?
Und vor allem: Wie viel hätte man gespart, wenn man mich 6 Monate früher gefragt hätte?
Das Geschäftsmodell „Künstliche Komplexität“
Nach 35 Jahren Enterprise Architecture habe ich verstanden: Der deutsche IT-Markt lebt nicht von Lösungen. Er lebt von permanent beschäftigten Feuerwehren.
Die Mechanik ist simpel:
Phase 1: Vendor erhöht Preise (VMWare/Broadcom ist nur das neueste Beispiel)
Phase 2: Panik-Migration wird gestartet – ohne Gap-Finding, ohne Risiko-Assessment
Phase 3: Mittendrin merkt man: „Das ist komplexer als gedacht“
Phase 4: „Wir brauchen einen Senior Enterprise Architekten – SOFORT“
Phase 5: Teurer Notfall-Einsatz, halbgare Lösung, neue Abhängigkeiten
Phase 6: In 18 Monaten wiederholt sich das Spiel
Jede Phase generiert Umsatz. Für alle Beteiligten. Außer für den Auftraggeber.
Was ich in den ersten 2 Tagen gefunden hätte
Bei dieser konkreten Anfrage hätte ein 2-Tages-Assessment vermutlich ergeben:
Problem 1: Die 27 Leistungsscheine entstehen aus historisch gewachsener Service-Fragmentierung → Konsolidierung spart 40-60% Migrationskomplexität
Problem 2: Die „weltweiten Standorte“ nutzen wahrscheinlich 4-5 verschiedene Netzwerk-Architekturen → Standardisierung VORHER macht Migration trivial
Problem 3: Die VMWare-Umgebung läuft vermutlich auf überalterter Hardware mit jahrelang akkumuliertem Konfigurations-Debt → Clean-up vor Migration spart Wochen
Kostendifferenz zwischen „3 Wochen Feuerwehr“ und „2 Tage Gap-Finding“:
Mit Feuerwehr: €500K-800K Migration, 6-12 Monate Stabilisierung, neue Lock-ins
Mit Gap-Finding: €150K-250K Migration, 2-3 Monate Stabilisierung, echte Flexibilität
Das nennt man ROI von 3:1 bis 5:1. In zwei Tagen.
Warum zahlt niemand dafür?
Weil das System gegen präventive Intelligenz optimiert ist:
IT-Dienstleister verlieren 70% Umsatz, wenn Probleme gar nicht entstehen
Procurement verliert Daseinsberechtigung, wenn 27 Leistungsscheine auf 8 schrumpfen
Internal IT muss zugeben, dass man jahrelang Komplexität akkumuliert hat
Vendor verliert Lock-in-Macht, wenn echte Architektur Flexibilität schafft
Mein Name dafür: „Artificially Increased Emergence“
Komplexität, die nicht aus technischer Notwendigkeit entsteht, sondern aus wirtschaftlichen Interessen BEWUSST aufrechterhalten wird.
Die Rechnung für Portfolio-Eigentümer
Wenn Sie ein PE-Portfolio mit 15 Unternehmen haben:
Durchschnittlich 2-3 solcher „Notfall-Projekte“ pro Jahr und Portfolio-Firma
Durchschnittliche Mehrkosten durch fehlende Gap-Finding: €300K-500K pro Projekt
Portfolio-weite Verschwendung: €9M-22M pro Jahr
Und das ist nur die IT. Manufacturing, Supply Chain, Compliance – überall dieselbe Mechanik.
Was wäre nötig?
Ein Scharnier. Jemand, der NICHT vom Chaos lebt.
Jemand, der:
Vor Vendor-Panik die echten Abhängigkeiten findet
Vor Migrations-Projekten die Kosten-Treiber eliminiert
Vor Consulting-Orgien die vermeidbaren Probleme löst
Das ist kein „Senior Enterprise Architekt für 3 Wochen“.
Das ist ein 2-Tages-Investment, das 6-stellige Summen spart.
Aber dieser Rolle fehlt der Business Case – weil sie zu viele andere Business Cases zerstört.
Meine Frage an Sie
Wenn Sie ein Portfolio-Unternehmen haben, das gerade:
Einen „kritischen“ Cloud-Migration plant
„Dringend“ ein SAP S/4HANA-Projekt startet
„Sofort“ eine Cybersecurity-Initiative braucht
Wie sicher sind Sie, dass das wirklich kritisch, dringend, sofort ist?
Oder bezahlen Sie gerade jemanden, dessen Geschäftsmodell auf artificially increased emergence basiert?
Michael Schmid
Enterprise Architect | Spezialist für Gap-Finding
35 Jahre Erfahrung mit Telekom-Netzen, Automotive, Defense
it-dialog e.K., Stuttgart
„Ich baue Systeme, die 39 Jahre laufen. Ich werde nicht dafür bezahlt, Feuer zu löschen – sondern sie zu verhindern. Das macht mich unbeliebt bei Feuerwehren, aber wertvoll für Eigentümer.“
P.S.: Die Anfrage habe ich abgelehnt. Nicht weil ich die 3 Wochen nicht ausfüllen könnte. Sondern weil ich in 2 Tagen zeigen würde, dass 90% davon vermeidbar gewesen wäre. Und das will niemand hören, der vom Chaos lebt.
Möchten Sie wissen, wo in Ihrem Portfolio künstliche Komplexität Millionen verbrennt?
Sprechen Sie mich an: info@it-dialog.com
Kommentare und Shares willkommen – besonders wenn Sie anderer Meinung sind.
[Dieser Artikel vertieft meinen LinkedIn-Post vom 26. Oktober 2024]
PKI interne Netzwerke sind heute ein Albtraum für jeden IT-Administrator. Was eigentlich eine simple Sicherheitsanforderung sein sollte – verschlüsselte Kommunikation im Firmennetz – ist zu einer komplexen Herausforderung mutiert, für die es keine einfache Lösung gibt.
🧠 Nachgedacht: Wenn man heute im Firmennetz sicher verschlüsseln will, braucht man eine eigene Zertifizierungsstelle – sonst geht es schlicht nicht. Öffentliche Anbieter dürfen keine Zertifikate für interne Netze ausstellen. Selbstsignierte Zertifikate werden blockiert. Warum gibt es dafür kein fertiges, einfaches Produkt? Eine kleine Box, die man einmal einrichtet, prüft, ins Regal stellt – und fertig ist die interne Vertrauensbasis. Ist das wirklich so kompliziert – oder haben wir uns nur daran gewöhnt, dass es das nicht gibt?
Die Reaktionen auf diesen Post waren erhellend. Ein Experte kommentierte mit einer Liste von Lösungen – jede mit einem „wenn“: „Man kann… wenn man einen DNS-Namensraum fährt… wenn man ACME-Automatisierung hat… wenn man als Trusted Roots ausrollt…“
Genau das ist das Problem.
Der Hintergrund: Wie wir hier gelandet sind
2015 traf das CA/Browser Forum eine folgenreiche Entscheidung: Öffentliche Zertifizierungsstellen dürfen keine Zertifikate mehr für interne Domains (wie .local), private IP-Adressen oder nicht-routbare Netzwerke ausstellen. Die Begründung war nachvollziehbar – es ging um die Verhinderung von Domain-Hijacking und Man-in-the-Middle-Attacken.
Was dabei übersehen wurde: Millionen von Unternehmen betreiben interne Systeme, die niemals das Internet sehen werden. Produktionsanlagen, Steuerungssysteme, interne Datenbanken – sie alle benötigen verschlüsselte Kommunikation. Die Lösung? Jedes Unternehmen muss seine eigene PKI aufbauen.
PKI interne Netzwerke: Warum aus Sicherheit Raketenwissenschaft wurde
In meinen 35 Jahren in der IT habe ich viele Technologien kommen und gehen sehen. Aber selten habe ich erlebt, dass eine grundlegende Sicherheitsanforderung so unnötig verkompliziert wurde wie die interne PKI.
PKI interne Netzwerke versagen: Wenn Server die Verbindung verweigern
Das eigentliche Problem ist noch gravierender als die meisten ahnen: Moderne Server und Anwendungen lehnen unverschlüsselte Verbindungen zunehmend kategorisch ab. Nicht aus Böswilligkeit, sondern aus Sicherheitsgründen.
Bei einem Kunden (Energie) weigerte sich die neue Version der ERP-Software, mit den Um-Systemen zu kommunizieren. Der Grund? Man hatte nur ein selbstsigniertes Zertifikat. Die ERP-Software: „TLS 1.3 mit gültigem Zertifikat oder gar keine Verbindung.“
Kosten des Stillstands: 50.000 Euro/Tag.
Die Notlösung? Ein externer Berater baute in 72 Stunden Dauereinsatz eine Minimal-PKI auf. Kosten: 35.000 EUR. Dauerlösung? Bis heute nicht implementiert.
Zero-Trust macht es noch schlimmer:
Mit dem Zero-Trust-Paradigma wird es drastischer:
Jede Verbindung muss authentifiziert sein
Jeder Endpoint braucht eine Identität
Jedes Paket wird validiert
Ohne PKI: Komplette Isolation
In KRITIS-Umgebungen ist das bereits Pflicht. Ein Kunde aus dem Energiesektor musste seine komplette OT-Umgebung nachrüsten. 1.200 Geräte. Jedes brauchte ein Zertifikat. Die manuelle Einrichtung dauerte 8 Monate.
Die Komplexitätsstufen einer „einfachen“ PKI:
Root-CA einrichten – Schon hier beginnt die Philosophiediskussion: Online oder Offline? Hardware-Security-Module? Welcher Algorithmus? RSA 4096 oder doch ECC?
Intermediate CAs – Natürlich braucht man die, sagen die Best Practices. Aber wie viele? Eine pro Abteilung? Eine pro Anwendungsfall?
Zertifikats-Templates – Dutzende Parameter. Key Usage, Extended Key Usage, SANs, Validity Period. Jeder falsch gesetzte Wert kann später zum Problem werden.
Verteilung der Root-Zertifikate – Group Policies für Windows, Mobile Device Management für Smartphones, manuelle Installation für Linux, spezielle Verfahren für IoT-Geräte.
Revocation-Infrastruktur – CRL oder OCSP? Oder beides? Hochverfügbar natürlich.
Renewal-Prozesse – Die neue Mode: Zertifikate mit 47 Tagen Laufzeit. Wer tauscht die manuell in 500 Systemen?
Das ACME-Versprechen
Let’s Encrypt hat mit ACME gezeigt, wie einfach Zertifikatsverwaltung sein kann – für öffentliche Domains. Für interne Netze? Dann brauchen Sie:
Einen öffentlich registrierten Domain-Namen
DNS-Challenge-Unterstützung
Automatisierung in ALLEN Systemen
Und beten, dass Ihre 20 Jahre alte Produktionsanlage das versteht
Historische Parallelen: Wir hatten das Problem schon gelöst
1995 – ich erinnere mich noch gut – hatte Lotus Domino eine eingebaute PKI. Symmetrische Verschlüsselung, ja, aber sie funktionierte. Überall. Automatisch. Ohne Wenn und Aber.
Die Ironie: Heute, 30 Jahre später, kämpfen wir mit Problemen, die damals gelöst waren. Wir haben die Verschlüsselung asymmetrisch gemacht (gut!), aber dabei die Einfachheit verloren (schlecht!).
Bei der Bundeswehr lernte ich in den 80ern: „Ein System, das im Gefecht nicht bedienbar ist, ist nutzlos.“ Das gilt heute für PKI: Ein Sicherheitssystem, das so komplex ist, dass es niemand richtig implementiert, macht uns nicht sicherer – es macht uns verwundbarer.
Was das für Ihr Unternehmen bedeutet
Ich sehe bei meinen Kunden drei Reaktionsmuster:
Die Perfektionisten
Bauen eine Enterprise-PKI nach allen Regeln der Kunst auf. Budget: 500.000 EUR. Implementierungszeit: 18 Monate. Vollzeit-Administrator: 1-2 Personen. Ergebnis: Funktioniert, aber niemand versteht es.
Die Pragmatiker
Nutzen selbstsignierte Zertifikate und klicken Warnungen weg. Kosten: Null. Sicherheit: Auch null. Gewöhnung an Warnungen: 100%.
Die Resignierten
Verzichten auf Verschlüsselung im internen Netz. „Ist ja nur intern.“ Bis zur ersten Ransomware-Attacke.
Meine Lösung: Die PKI-Box
Was die Industrie braucht – und was ich seit Jahren predige – ist radikal einfach:
Eine Box. Fertig konfiguriert. Plug & Play.
So würde sie funktionieren:
Auspacken, anschließen – Wie einen WLAN-Router
Basis-Setup über Web-Interface – Firmenname, Domain, fertig
Automatische Integration – DHCP-Option für Clients, SCEP für mobile Geräte
Compliance-ready – Audit-Logs, HSM-Option für Regulierte
Warum gibt es das nicht?
Die unbequeme Wahrheit: Komplexität ist ein Geschäftsmodell.
PKI-Berater leben von der Komplexität
Software-Hersteller verkaufen Enterprise-Lizenzen
Zertifizierungs-Anbieter verdienen an Schulungen
Hardware-Vendor pushen HSMs für 50.000 EUR
Eine 2.000 EUR Box, die einfach funktioniert? Wo bleibt da das Consulting? Die Wartungsverträge? Die Zertifizierungen?
Weiterführende Gedanken: Der größere Kontext
Die PKI-Komplexität ist symptomatisch für ein größeres Problem in der IT: Wir lösen einfache Probleme mit komplexen Lösungen.
In meinem Buch „Greenfield Approach“ beschreibe ich, wie man radikal vereinfacht. Bei PKI hieße das:
Weg mit der Zertifikats-Hierarchie für kleine Firmen
Ein Zertifikat pro Service, nicht pro Server
10 Jahre Laufzeit für interne Systeme
Automatische Verteilung über bestehende Kanäle
Das ist keine Rocket Science. Das ist gesunder Menschenverstand.
Der Ausblick
Ich arbeite aktuell an einem Proof of Concept. Ein Raspberry Pi 5, ein bisschen Python, eine klare Vision. Die Alpha-Version läuft bereits in meinem Lab.
Was fehlt? Ein mutiger Hersteller, der sagt: „Wir machen Sicherheit einfach.“ Nicht „Enterprise-ready“. Nicht „Cloud-native“. Nicht „KI-powered“. Einfach nur: Es funktioniert.
Fazit: Zeit für eine Revolution
35 Jahre in der IT haben mich gelehrt: Die besten Lösungen sind die einfachsten. M/OMS läuft seit 1985 – weil es einfach ist. Meine Kunden bei Mercedes, Vodafone und der Telekom schätzen mich nicht, weil ich Komplexität hinzufüge, sondern weil ich sie reduziere.
PKI muss nicht kompliziert sein. Wir haben es kompliziert gemacht. Zeit, das zu ändern.
In der digitalen Transformation stehen Unternehmen vor einer zentralen Frage: Brauchen wir einen festangestellten Unternehmensarchitekten oder sollten wir einen externen Unternehmensarchitekt beauftragen? Die Entscheidung zwischen internem und externem Enterprise Architect hängt von den spezifischen Herausforderungen ab, die Ihr Unternehmen meistern muss.
Was macht ein Unternehmensarchitekt grundsätzlich?
Ein Unternehmensarchitekt fungiert als Brückenbauer zwischen Geschäftsstrategie und IT-Umsetzung. Er übersetzt Geschäftsziele in technische Architekturen und sorgt dafür, dass alle IT-Systeme harmonisch zusammenarbeiten. Dabei geht es nicht nur um Technik – ein Unternehmensarchitekt denkt ganzheitlich und berücksichtigt Prozesse, Menschen und Technologie gleichermaßen.
Die Kernaufgabe besteht darin, eine langfristige IT-Landschaft zu entwerfen, die flexibel genug ist, um mit dem Unternehmen zu wachsen, aber stabil genug, um den täglichen Betrieb zu gewährleisten.
Der festangestellte Unternehmensarchitekt: Der interne Stratege
Alltägliche Aufgaben und Verantwortlichkeiten
Ein festangestellter Unternehmensarchitekt kennt das Unternehmen in- und auswendig. Sein Arbeitstag beginnt oft mit der Analyse aktueller IT-Systeme und der Bewertung, ob sie noch den Geschäftsanforderungen entsprechen. Er sitzt in Strategiemeetings, diskutiert mit Fachabteilungen über neue Anforderungen und entwickelt kontinuierlich die IT-Architektur weiter.
Typische Wochensituation: Montags Review der laufenden Projekte, dienstags Workshops mit den Fachabteilungen, mittwochs Architektur-Reviews neuer Anwendungen, donnerstags Abstimmung mit dem IT-Management über Budget und Roadmap, freitags Dokumentation und Planung.
Stärken des internen Architekten
Der festangestellte Architekt bringt entscheidende Vorteile mit sich:
Tiefes Unternehmensverständnis: Er kennt die politischen Strukturen, weiß, wer welche Entscheidungen trifft, und versteht die historisch gewachsenen Systeme. Diese Kenntnis ermöglicht es ihm, Lösungen zu entwickeln, die nicht nur technisch funktionieren, sondern auch kulturell akzeptiert werden.
Kontinuität in der Strategie: Langfristige IT-Vorhaben benötigen einen durchgängigen roten Faden. Der interne Architekt sorgt dafür, dass begonnene Transformationsprojekte auch Jahre später noch im ursprünglichen Sinne weitergeführt werden.
Vertrauensaufbau: Durch die tägliche Zusammenarbeit entwickelt er enge Beziehungen zu allen Stakeholdern. Diese Vertrauensbasis ist entscheidend, wenn schwierige Entscheidungen getroffen werden müssen.
Herausforderungen im Alltag
Die interne Position bringt auch spezifische Schwierigkeiten mit sich. Der Architekt muss oft zwischen verschiedenen Interessengruppen vermitteln und dabei neutral bleiben. Gleichzeitig ist er den täglichen politischen Spannungen ausgesetzt und muss aufpassen, nicht in Grabenkämpfe zwischen Abteilungen hineinzugeraten.
Der externe Unternehmensarchitekt: Der objektive Impulsgeber
Einsatzgebiete und Arbeitsweise
Der externe Unternehmensarchitekt kommt meist in spezifischen Situationen zum Einsatz: bei größeren Transformationsprojekten, Systemmigrationen oder wenn frischer Wind in festgefahrene Strukturen gebracht werden soll. Sein Fokus liegt auf der schnellen Analyse und der Entwicklung konkreter Lösungsansätze.
Typisches Projektvorgehen: Erste Wochen intensive Analyse und Stakeholder-Interviews, dann Entwicklung der Zielarchitektur, Erstellung einer Roadmap und schließlich Begleitung der ersten Umsetzungsschritte.
Die Stärken der externen Perspektive
Neutralität und Objektivität: Der externe Architekt steht außerhalb der internen Machstrukturen und kann unvoreingenommen bewerten. Er kann unbequeme Wahrheiten aussprechen, ohne Angst vor karrieretechnischen Konsequenzen haben zu müssen.
Branchenweites Know-how: Durch die Arbeit in verschiedenen Unternehmen bringt er Best Practices und bewährte Lösungsansätze mit. Er weiß, welche Architekturmuster in vergleichbaren Situationen erfolgreich waren.
Fokussierte Expertise: Externe Architekten spezialisieren sich oft auf bestimmte Bereiche oder Technologien. Diese Tiefe kann besonders bei komplexen Transformationsprojekten entscheidend sein.
Arbeitsweise in Krisensituationen
Wenn IT-Projekte in Schieflage geraten oder wenn scheinbar unlösbare Architekturprobleme auftreten, zeigt sich die Stärke des externen Architekten. Er kann mit frischem Blick an das Problem herangehen, ist nicht von bisherigen Entscheidungen emotional belastet und kann radikalere Lösungsansätze vorschlagen.
Praxisvergleich: Typische Unternehmensszenarien
Szenario 1: Digitale Transformation eines Mittelständlers
Interne Lösung: Der festangestellte Architekt entwickelt über Monate hinweg eine Digitalisierungsstrategie, bindet alle Abteilungen ein und sorgt für breite Akzeptanz. Die Umsetzung dauert länger, ist aber nachhaltig und wird von allen Beteiligten mitgetragen.
Externe Lösung: Der externe Architekt analysiert binnen weniger Wochen den Status quo, entwickelt eine klare Roadmap und stößt die ersten Projekte an. Die Umsetzung geht schneller voran, benötigt aber zusätzliche interne Ressourcen für die dauerhafte Betreuung.
Szenario 2: Komplexe Systemlandschaft nach Fusion
Interne Herausforderung: Der interne Architekt kennt nur eine der beiden zu fusionierenden IT-Landschaften und muss sich erst in die neue Komplexität einarbeiten. Dafür kann er die Integration langfristig begleiten.
Externe Expertise: Der externe Architekt bringt Erfahrung aus ähnlichen Fusionsprojekten mit, kann schnell eine Konsolidierungsstrategie entwickeln und neutral zwischen den verschiedenen Systemwelten vermitteln.
Externer Unternehmensarchitekt oder interner – wann was?
Für den internen Architekten sprechen:
Langfristige Strategieentwicklung: Wenn Sie eine kontinuierliche Evolution Ihrer IT-Landschaft planen
Komplexe Stakeholder-Landschaft: Bei vielen beteiligten Abteilungen und komplexen Entscheidungsstrukturen
Begrenzte Budgets: Für dauerhaft verfügbare Architektur-Expertise bei planbaren Kosten
Spezifische Branchenkenntnisse: In regulierten Industrien mit besonderen Compliance-Anforderungen
Für den externen Architekten sprechen:
Transformationsprojekte: Bei grundlegenden Veränderungen der IT-Landschaft
Zeitkritische Projekte: Wenn schnelle Ergebnisse gefordert sind
Objektive Bewertung: Bei internen Konflikten oder festgefahrenen Situationen
Spezielle Expertise: Für Technologien oder Methodiken, die intern nicht verfügbar sind
Viele Unternehmen entscheiden sich heute für einen kombinierten Ansatz. Ein interner Architekt sorgt für Kontinuität und Unternehmenskenntnis, während externe Experten für spezifische Projekte oder bei besonderen Herausforderungen hinzugezogen werden.
Diese Kombination ermöglicht es, die strategische IT-Entwicklung intern zu steuern und gleichzeitig von externem Know-how und frischen Impulsen zu profitieren. Der interne Architekt fungiert dabei als Schnittstelle und sorgt dafür, dass externe Empfehlungen auch praktisch umsetzbar sind.
Erfolgsfaktoren für beide Ansätze
Unabhängig von der gewählten Lösung sind bestimmte Erfolgsfaktoren entscheidend:
Klare Mandate: Sowohl interne als auch externe Architekten benötigen eindeutige Befugnisse und Unterstützung durch das Management.
Kommunikationsfähigkeit: Die beste Architektur nützt nichts, wenn sie nicht vermittelt werden kann. Sowohl interne als auch externe Architekten müssen komplexe Sachverhalte verständlich erklären können.
Flexibilität: IT-Landschaften entwickeln sich schnell. Architekten müssen bereit sein, ihre Pläne anzupassen, wenn sich Rahmenbedingungen ändern.
Fazit: Strategische Entscheidung mit weitreichenden Folgen
Die Wahl zwischen festangestelltem und externem Unternehmensarchitekt ist eine strategische Entscheidung, die weitreichende Auswirkungen auf die IT-Entwicklung Ihres Unternehmens hat. Beide Ansätze haben ihre Berechtigung und bringen spezifische Vorteile mit sich.
Der interne Architekt ist der richtige Partner für kontinuierliche, langfristige IT-Entwicklung und komplexe Stakeholder-Management. Der externe Architekt bringt frische Impulse, objektive Bewertungen und spezialisiertes Know-how für Transformationsprojekte.
Die Entscheidung sollte auf Basis Ihrer spezifischen Unternehmensituation, Ihrer IT-Strategie und Ihrer verfügbaren Ressourcen getroffen werden. Häufig ist eine Kombination beider Ansätze der optimale Weg, um die Vorteile beider Welten zu nutzen und gleichzeitig die jeweiligen Schwächen zu kompensieren.
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
