„Trägt unsere IT überhaupt, was wir vorhaben?“
Hinter vielen KI- und Digitalisierungsvorhaben steckt am Ende eine unspektakulärere Frage: die nach dem Unterbau. Wenn Informationen über gewachsene Ablagen, historische Sonderlösungen und Systeme verteilt sind, die nicht miteinander sprechen, scheitert das Vorhaben nicht am Modell – sondern daran, dass die Daten nicht dort sind, wo sie sein müssten.
Deshalb gehört die Architekturfrage in dieselbe Diskussion. Sie beginnt nicht mit einer Zielarchitektur auf dem Reißbrett, sondern mit einer Bestandsaufnahme: Welche Systeme sind wirklich geschäftskritisch? Wo liegen die Daten, die Sie nutzen wollen? Welche Abhängigkeiten haben Sie sich über die Jahre eingehandelt – von einzelnen Herstellern, von einzelnen Personen, von Software, für die es keinen Nachfolger gibt?
Woran wir dann arbeiten
- Sortieren statt sanieren: Nicht alles Gewachsene muss weg. Vieles läuft stabil und sollte genau deshalb in Ruhe gelassen werden. Wichtig ist zu wissen, was in den nächsten drei Jahren zum Problem wird – und was nicht.
- Cloud dort, wo sie trägt: Die Frage ist nicht „Cloud oder nicht“, sondern für welches System welcher Betriebsweg wirtschaftlich und organisatorisch sinnvoll ist. Beides pauschal zu beantworten, geht regelmäßig schief.
- Abhängigkeiten bewusst wählen: Jede Entscheidung erzeugt Bindung. Das ist in Ordnung, solange man weiß, wie teuer ein späterer Wechsel wäre – und solange die Entscheidung bewusst fällt und nicht nebenbei.
- Offene Standards, wo sie passen: Ich arbeite gern mit Open-Source-Lösungen, weil sie Nachvollziehbarkeit schaffen und die Kontrolle über Daten im Haus halten. Nicht aus Prinzip: Wo ein kommerzielles Produkt das Problem besser löst, empfehle ich das.
Das Ergebnis ist kein Architekturhandbuch, das niemand liest, sondern eine überschaubare Zielrichtung mit einer Reihenfolge – damit die nächste Investition auf die übernächste einzahlt statt gegen sie zu arbeiten.