Herzlich willkommen zu unserer neuen Folge der Expertengespräche zum Thema Digitalisierung

Heute haben wir ein Thema vor uns, dass erst mal sehr schwierig klingt, dass wir aber verständlich und nutzbringend darstellen werden.

Es geht um Architekturmanagement.

Wir werden erklären, was wir darunter verstehen, was es beinhaltet, wie man es etabliert und was man tun kann, wenn das Architekturmanagement zu Problemen führt.

Dazu sprechen wir heute wieder mit unserem Experten Martin Meister

Martin, Du hast nun schon ein paar Mal gesagt, dass Digitalisierung viel zu technisch gesehen wird. Warum beschäftigen wir uns dann heute mit Architekturmanagement?

Ja, manche Aussagen holen einen dann doch immer wieder mal ein. Das Ganze wird zunächst mal noch schlimmer, wenn ich jetzt behaupte, dass Architekturmanagement auf Dauer zentraler und unverzichtbarer Asset ist, wenn ein Unternehmen mit der Digitalisierung starten und langfristig erfolgreich sein will.

Verwickelst Du Dich da gerade in Widersprüche?

Natürlich nicht. Architekturmanagement ist essenziell aber eben nicht ausreichend.

Meine Kritik richtet sich darauf, dass ich häufig das Gefühl habe, dass nur die technische Seite betrachtet wird. Zu einer erfolgreichen Digitalisierung braucht es eine gut funktionierende IT, aber es braucht vor allem auch eine Strategie, ansonsten weiß ich ja nicht, was meine Technik tun soll und wie ich sie bauen soll.

Es braucht aber natürlich auch die Technologie ohne eine gut gepflegte und sich geplant entwickelnde IT werde ich keine Digitalstrategie umsetzen können.

Es braucht also die Technologie und die Strategie

Genau!  und insbesondere braucht es das richtige Zusammenspiel zwischen Strategie und Technologie und dabei ist das Architekturmanagement quasi das Bindeglied oder das Scharnier.

Und Architekturmanagement ist kein Selbstzweck und nicht Gegenstand von Beauty-Contests. Auch hier geht es um Effektivität und die Unterstützung der IT im Hinblick auf die Unternehmensziele

Und deswegen sprechen wir heute über Architekturmanagement

Deswegen und weil es ein häufig sehr vernachlässigtes Thema ist und diese Vernachlässigung früher oder später schwerwiegende Konsequenzen hat. Wenn ein Unternehmen keine auf die Unternehmensstrategie zugeschnittenes und für den Entwicklungsstand des Unternehmens angemessenes Management seiner IT-Architektur betreibt, wird irgendwann der Moment kommen, in dem die Entwicklung von Produkten, die Schaffung von Effizienz durch IT immer mühsamer wird oder ganz zum Erliegen kommt.

Ok. Dass das nicht gut ist, hatten wir schon in einer der vorangegangenen Folgen angesprochen. Lass es uns trotzdem noch mal kurz zusammenfassen. Worin genau bestehen dann die Konsequenzen?

Zunächst müssen wir 2 Situationen unterscheiden.

Bei einem Unternehmen dessen Umsätze im Wesentlichen durch digitale Produkte getrieben ist, geht es darum, dauerhaft neue Mehrwerte zu schaffen, um Umsatzwachstum zu generieren. Diese Mehrwerte realisieren sich in der Regel durch Veränderungen in der Software.

D.h. es ist für das Wachstum und die Wettbewerbsfähigkeit des Unternehmens von hoher Bedeutung, dauerhaft in hoher Geschwindigkeit solche Veränderungen vorzunehmen.

Wenn das nicht mehr geht, sind Wachstum und Wettbewerbsfähigkeit gefährdet und das kann zur Existenzfrage werden.

OK das haben wir auch bereits im Rahmen der Folge zur Produktentwicklung besprochen. Was ist die zweite Situation?

Ein Unternehmen ist noch dabei, zu digitalisieren und zunächst mal Effizienzen zu heben. Das kann ebenfalls frühzeitig zum Erliegen kommen, wenn die internen Systeme nicht integrierbar oder nicht veränderbar sind. Deswegen ist es wichtig, die Anpassungsfähigkeit der Systeme zu erhalten oder sie muss vor Beginn der Digitalisierung hergestellt werden. Ganz häufig sind Systemlandschaften gewachsen und hier mal was und da mal was ergänzt. Dieses Konzept ist kurzfristig immer verlockend führt aber langfristig dazu, dass die Veränderbarkeit der Gesamtlandschaft nicht gegeben ist.

Häufig sind interne System nicht frei von Redundanzen und Überschneidungen.

ERP-Systeme, CRM, Customer Service, Debitorenbuchhaltung ….

Bei den digitalen Unternehmen kommt häufig der Aspekt dazu, dass sie historisch dazu neigen diesen Teil ihrer IT-Landschaft zu vernachlässigen.

Warum historisch?

Digitale Unternehmen richten ihr Hauptaugenmerk auf die Systeme, die vom Kunden zur Generierung von Umsatz genutzt werden. Dann kommt alles andere schnell mal hinten dran.

Die eben erwähnten Überlappungen und Inkonsistenzen sind im Tagesbetrieb vielleicht noch so auszuhalten, sind aber schwer zu überwinden, wenn die IT-Landschaft erweitert werden soll.

Und beim wichtiger werdenden Thema Datenhaltung schlagen diese Defizite ebenfalls zu.

Also braucht es Architekturmanagement, um dauerhaft erfolgreich zu sein in der Digitalisierung und um dafür zu sorgen, dass sie nicht und schon gar nicht in einem frühen Stadium zum Erliegen kommt.

Was genau ist dann nun Architekturmanagement?

Ich versuche mal das ohne zu abstraktes Definitionsdeutsch zu formulieren.

Der eine Teil ist ein fachlicher Bauplan. Ich nenne das die Produktlandkarte. Es geht um eine geeignete Darstellung der externen Produkte und internen Systeme und deren Zusammenspiel und das insbesondere fachlich. Auch hier gilt. Es ist Technik. Aber der entscheidende erste Schritt ist die inhaltliche und fachliche Abgrenzung zu finden. Ich spreche hier von der fachlichen Architektur. In der Regel hat ein Unternehmen mehr als 1 Produkt oder das eine Produkt besteht aus mehreren Teilen. Dann ist es wichtig, die Grenzen der Produkte oder Teile festzulegen und genau zu definieren, was diese Produkte leisten und was nicht.

Zudem gibt es immer wieder Bestandteile, die von mehr als einem Produkt genutzt werden. Beispiele sind Login und Registrierung oder Bezahlung, die Suche oder ähnliches. Dann ist wichtig, festzulegen, was genau diese Bestandteile auch Services genannt leisten, was nicht und wie sie integriert werden.

Zudem habe ich dann noch die internen Systeme. Da geht es um Grenzen und Überlappungen

Dann muss ich definieren, wie ich den grundsätzlichen technischen Aufbau gestalte und das technische Zusammenspiel löse. Hier geht es um Schichten und technische Module und technische Integration der Services. Die Services, die ja von mehreren Produkten benutzt werden, will ich so integrieren, dass ich den Service selbst verändern kann, ohne jedes einzelne Produkt zu verändern.

Das zweite sind Standards, Vorschriften, und Prozesse, die dafür sorgen, dass meine IT sich entlang dieses Plans entwickelt.

Dazu gehören Vorschriften, wie Layer, Serviceorientierung, Programmiervorschriften, Logging, Datenhaltung, Schnittstellen ….

Zusammengefasst: Fachlicher Bauplan, technischer Bauplan, Datenhaltung, Standards, Technologien.

Ich bin jetzt keine absolute Expertin, aber ich sehe immer mal wieder Überschriften von Artikeln, in denen es darum geht, welche Technologie besser ist als eine andere. Das spielt für dich keine Rolle?

Doch natürlich. Ist aber eine Überbetonung eines einzelnen Aspekts.

Zum Architekturmanagement gehören auch technische Entscheidungen. Aber bitte die Fragen in der richtigen Reihenfolge stellen und beantworten.

Zunächst mal muss ich die fachliche Architektur festlegen. Fehler, die ich auf dieser Ebene mache, lassen sich durch keine technische Lösung beheben

Dann lege ich den technischen Bauplan fest.

Das kann in Einzelfällen noch mal Rückkopplungen haben auf die fachliche Ebene und zu leichten Veränderungen führen. Trotzdem ist die Reihenfolge einzuhalten.

Dann muss ich mich mit Datenhaltung und Datenflüssen beschäftigen. Wo werden Daten erzeugt, wo habe ich Redundanzen, wie gehe ich mit Ihnen um, wo werden die Daten wann und wie gebraucht.

Dann erst beschäftige ich mich mit konkreten Technologien. Das kann auch zu Rückwirkungen auf die Ebene davor führen. Trotzdem auch hier ist die Reihenfolge einzuhalten. Wenn die fachliche Architektur schief steht, die Technische Grundarchitektur nicht passt, wird mir die Frage nach einer konkreten Technologie in den meisten Fällen nicht helfen.

Auch hier ist es wieder so, dass bestimmte Technologien Rückkopplung auf die Architektur haben, sie retten aber keine Fehler auf den Ebenen davor.

Also erst fachlicher Bauplan oder Landkarte, dann technischer Bauplan und dann konkrete Technologien und dann noch Standards. Klingt wieder nach einer Menge Holz.

Das ist eine Menge Holz und nur zu Beginn des Lebenszyklus eines Unternehmens noch einfach. Hier kann ich auch nichts sagen, dass die Situation entspannen würde. Es ist komplex und Bedarf sorgfältiger und guter Arbeit.

Dafür wird dieser Aufwand aber auch reich belohnt.

Zusammen mit den jeweiligen Teams konnte ich so etwas häufiger etablieren. Das war nie ganz einfach. Wir haben uns in der Folge aber immer sehr daran erfreut, weil es die Wirksamkeit des einzelnen massiv steigert.

Arbeiten in einer vermurksten technischen Umgebung ist für alle echter Pain und macht keinen Spaß. Und insofern gehen hier Zufriedenheit der Mitarbeiter, Kundennutzen und Zufriedenheit der Stakeholder mal Hand in Hand, aber einfach ist es nicht.

Also auf der einen Seite ein schwieriges Thema mit auf der anderen Seite sehr hohem Potenzial für alle Beteiligten.

Der Blick auf die Potenziale ist sehr wichtig. Unabhängig davon, ob ein Unternehmen an der Effizienz arbeitet oder Wachstum generieren will, sind die Potenziale eben enorm und lohnen die Anstrengung.

Was den Aufwand angeht, kann man zur Beruhigung vielleicht sagen, dass es auch hier immer ein paar einfach zu bergende Potenziale gibt. Eine schlecht gemanagte IT erzeugt immer auch eine hohe Last an Fehler und sogenannten Incidents also Störfällen. Das lässt sich oft, wenn auch nicht immer durch einfache Maßnahmen reduzieren. Und schon das schafft erstmal Entlastung

Spannend ist das Thema auch immer für Start-Ups. Bei denen geht die Geschwindigkeit, in der das Produkt neue Sachen kann, immer über alles. Ein voll ausgereiftes Architekturmanagement kann dann völlig Oversized sein. Es gar nicht zu machen, kann aber zur falschen Zeit dazu führen, dass das Unternehmen zunächst mal vor einer IT-Sanierung steht. Wenn der Wettbewerber das gerade nicht tun muss, überholt er vielleicht.

Was tun?

Lässt sich nicht pauschalisieren. Minimum sollte man in der Lage sein, bewusste Entscheidungen zu treffen, heißt ungefähr abschätzen zu können, welchen Teilsanierungsaufwand man sich gerade einfängt und wie man ihn bearbeiten will.

Die Landkarte würde ich ebenfalls in jedem Fall errichten.

Also pragmatisch und nicht theoretisch

Gibt es für diese Landkarte, von der Du redest, ein Beispiel oder Standards?

Einen Standard oder eine Anleitung dafür kenne ich nicht. Das jetzt einzuführen, würde auch den Rahmen der Veranstaltung sprengen. Deswegen können sich alle die interessiert sind, dort im Detail einzusteigen, eine Videopräsentation runterladen, auf der ich so eine Landkarte mal vorstelle.

Sinn und Zweck dieser Landkarte ist es, Grenzen und Zusammenhänge der Systeme zu erkennen, die gesamte Systemlandschaft zu verstehen, die fachliche Seite nicht aus dem Blick zu verlieren, Daten organisieren zu können und entscheiden zu können, auf welchem Weg ich eine neue Software einbaue.

Wenn man diese Landkarte nicht von Anfang an mitentwickelt hat und der unvermeidbare Eindruck entsteht, dass irgendwie alles nicht mehr zusammenpasst, hilft diese Landkarte das die Größe des Problems zu messen und die entscheidenden Ansatzpunkte zu finden.

Damit kommen wir zu einem wichtigen Thema. Ein Unternehmen hat kein Architektur-Management oder befindet sich sogar in einer Situation, in der alle das Gefühl haben, es gibt kein weiter. Was kann man dann tun?

Tatsächlich ist ein sinnvoll aufgesetztes Architekturmanagement eher die Ausnahme und existiert nicht mal bei allen Unternehmen, die Software als lizensiertes Produkt erstellen.

Im Prinzip gilt: Es ist nie zu spät oder es ist erst dann zu spät, wenn es zu spät ist.

Aber eben auch: je später sich ein Unternehmen auf den Weg macht, desto aufwendiger oder schmerzhafter wird das.

Auf der anderen Seite ist auch wichtig zu sagen, dass Architektur-Management kein Selbstzweck und kein Beauty-Contest ist.

Es gibt immer ein paar Grundlagen und Quick-Wins. Alles weitere hängt davon ab, was als nächstes und Übernächstes erreicht werden soll.

Für die Erreichung des nächsten Levels braucht man einen Plan, der dafür sorgt, dass das übernächste Level gut vorbereitet ist.

Man kann sich ein Zielbild entwickeln, in das man nach und nach reinwächst. Sicher ist mal, dass ohne sinnvolles Architekturmanagement die Digitalisierung häufig nicht starten kann oder irgendwann zum Erliegen kommt.

Architekturmanagement in der IT umfasst auch die Planung der fachlichen Architektur.

Die Instrumente sind fachlicher und technischer Bauplan oder Landkarte und Definition von Standards. Dann entscheide ich über Technologien.

Wichtig ist das gerade in Bezug auf Digitalisierung, weil ich ohne Architektur nicht starten kann oder ins Stocken geraten. Architektur-Management ist also in der Regel existenziell

Die Architektur allein schafft aber noch kein Wachstum. Es braucht den Bezug zur Architektur.

Damit kann man dann auch nachvollziehen, dass die Einführung von Architekturmanagement am besten durch Fachleute geführt, wird, die das schon mal gemacht haben.

Und immer daran denken: Das ganze tun wir, um Potenziale zu bergen, die den Aufwand allemal rechtfertigen.