IT-Architekturstrategie: Gegen den blinden Aktionismus
Business und IT geschickt miteinander verbinden
Obwohl wir es in der IT eigentlich besser wissen sollten, werden Technologie- und Architekturentscheidungen noch aufgrund von Glaubenssätzen getroffen – oder weil es einfach "trendy" ist. Die versprochenen Mehrwerte der Digitalisierung werden in dieser Form aber nicht erreicht, da die IT so nicht die Strategie und Fachlichkeit eines Unternehmens nachhaltig unterstützen oder gar transformieren kann. Der Architekt bekommt hier eine interessante Position: er befindet sich genau im Mittelpunkt zwischen Technologie, Menschen und der Fachlichkeit. Durch geschicktes Kommunizieren und Aufzeigen von Technologieansätzen kann diese Rolle dafür sorgen, dass sich IT und Business weiter nähern.
Die ideale Welt
Aus einem technischen und wirtschaftlichen Blickwinkel betrachtet leben wir in spannenden Zeiten. IT wird mehr und mehr als wertschöpfender Faktor betrachtet. Fachabteilungen sind sich der Wichtigkeit ihrer Anwendungen und Prozesse bewusst. Geschäftsführungen fördern aktiv die digitale Transformation ihres Unternehmens und investieren in technische Systeme und die Ausbildung aller Mitarbeiter. Eine Unternehmensvision existiert, die von Mitarbeitern verstanden und unterstützt wird. Aufgaben, Projektplanungen und entsprechende Vorgehensweisen sind so gewählt, dass diese auf die Vision einzahlen. Das Erreichen der Vision wird agil gestaltet, sodass man neue Themen oder neu Erlerntes berücksichtigen kann. Das Unternehmen verbessert und wandelt sich kontinuierlich.
Doch stopp! Viele von uns werden sich in dem oben beschriebenen Sachverhalt nicht oder nur zum Teil wiederfinden. Der Wunsch nach dieser neuen Arbeitswelt wird zwar vielfach gepredigt und es wird an ihrer Umsetzung gearbeitet, dennoch fühlt es sich häufig noch nicht richtig an.
Ehrlich gesagt ist es auch kein einfaches Unterfangen. Unternehmen, die bereits ein funktionierendes Geschäftsmodell besitzen, müssen an drei Fronten gleichzeitig arbeiten: Organisation, Technologie und Menschen.
Spricht man über die Rolle eines Architekten, wird häufig die Metapher des Fahrstuhlfahrens verwendet. Wie ein Fahrstuhl fährt er tagtäglich die einzelnen Hierarchieebenen in einem Unternehmen ab. Der Architekt ist das Bindeglied zwischen der Technik, den Menschen und der Organisation. Er interagiert mit den Entwicklern, kommuniziert in die Organisation und zu seinen Ansprechpartnern und achtet auf die Einhaltung von Absprachen und Rahmenbedingungen. Unbewusst steht der Architekt im Zentrum der Digitalisierung vieler Unternehmen. Dabei kann gerade seine Rolle Fachlichkeit, Technologie und Menschen zusammenbringen.
Herausforderungen aus dem täglichen Leben
In meiner bisherigen Karrierelaufbahn habe ich verschiedenste Unternehmen und Menschen kennengelernt. Ich bin immer wieder beeindruckt, wie unterschiedlich die Firmenkulturen und das Miteinander der Kollegen aussehen. Nichtsdestotrotz sehe ich eine Reihe von wiederkehrenden Mustern.
IT als zahlengetriebener Dienstleister
Die klassische Separierung der IT vom eigentlichen Kerngeschäft ist eines der häufigsten Muster, die ich kennengelernt habe. Mit der Betrachtung der IT als Kostencenter mit festem Budget oder Sparzielen, sind Strukturen entstanden, durch die häufig mehrere Wochen benötigt werden, um Projekte und Ressourcen freizugeben.
Entsprechende Strukturen können durchaus Sinn machen. Wenn diese aber auf eine Vielzahl von Projekten oder auch Priorisierungsänderungen stoßen, wird häufig die eigentliche Arbeit gelähmt.
Technische Entscheidungen aus dem Management
Entscheidungen aus dem Management für bestimmte Technologien und Architekturansätze sind per se nicht schlecht. Problematisch wird es, wenn diese Entscheidungen nicht zum eigentlichen Unternehmen passen. Wenn die Entscheidung für eine API-basierten Integrationsarchitektur getroffen wird, da APIs gerade hip sind, heißt es noch lange nicht, dass das Unternehmen von dieser Strategie profitiert. Vielmehr entstehen Kosten und Ressourcen werden blockiert, die an anderer Stelle effektiver hätten genutzt werden können.
Angst vor dem Coding
Applikationen, die genau den Bedarf und die Wünsche einer Fachabteilung erfüllen, existieren in der Regel nicht am Markt und müssen individuell entwickelt werden. Für Standardaufgaben kann Standard-Software eingesetzt werden. Dies ist ein wenig überspitzt, da auch durchaus über Customizing individuelle Anforderungen erfüllt werden können. Interessant ist aber, wenn Lösungen bevorzugt werden, nur um der Eigenentwicklung zu entgehen. Konfigurationen und Anpassungen können durchaus so komplex und kostenintensiv werden, dass eine eigene Entwicklung im Betrieb und in der Wartung einfacher wären. Wenn Systeme nicht mehr upgedated werden können, da Konfigurationen und Anpassungen dann nicht mehr funktionieren, läuft etwas schief.
Betrachtung des gesamten Lebenszyklus
Gerade bei der immer stärker werdenden Vernetzung von Dingen, Menschen und Maschinen wird nicht nur die Betrachtung des Lebenszyklus einer Anwendung, sondern der gesamten Landschaft wichtig. Je digitaler Produkte werden, desto genauer sollte ein Unternehmen auch darauf schauen, wie es Support und Wartung seines digitalen Angebots umgeht. Ein einfacher Weiterverkauf von Produkten ist häufig nicht mehr möglich und muss anders gedacht werden. Nehmen wir beispielsweise eine intelligente Pumpe oder ein intelligentes Türschloss, das Daten zur Cloud funkt. Schaltet der Anbieter das zugehörige Backend einfach ab, wird das eigentliche Produkt für den Kunden ebenfalls nutzlos.
Reaktiver Aktionismus
Über Ängste lässt sich viel erreichen. Die Aussage "investiert in Digitalisierung, sonst werdet ihr disruptiert", hat durchaus seine Berechtigung. Ein Abwägen, ob bestimmte Technologien und Ansätze für ein Unternehmen förderlich sind, ist aber genauso wichtig. In künstliche Intelligenz zu investieren und Projekte zu starten, die massiv von Daten abhängen, macht nur Sinn, wenn man erkannt hat, dass entsprechende Daten wichtig und auch zentral abgelegt sind. Sind Daten über mehrere Exceltabellen auf mehreren Laptops im Unternehmen verteilt, bietet es sich an, zuerst einen Ansatz zu entwickeln, der die Sammlung der Daten klärt, anstatt mit einer KI auf diese feuern zu wollen.
Eine tiefe Auseinandersetzung mit den einzelnen Mustern wäre vermutlich eine Artikelreihe wert. Was man an dieser Stelle aber sagen kann: sie weisen alle auf eine fehlende IT-Strategie hin. Anstatt akzeptable Lösungen zu suchen, schränken diese selbstauferlegten Maximen den Lösungsraum ein. Insbesondere, wenn diese Maximen nicht von der Unternehmensstrategie abgeleitet sind.
In einer Technologie- beziehungsweise IT-Architekturstrategie ist klar definiert, welche technologischen Assets vorhanden sind, welche Unternehmensprozesse unterstützt und an welchen Themen in den nächsten Jahren gearbeitet werden soll. Die Unternehmensstrategie zeigt die Marschrichtung und die verfolgte Vision an. Sie ist damit die Basis für weitere Überlegungen. Bindet der Architekt aktiv Fachabteilungen ein und berücksichtigt er die Unternehmensstrategie, besetzt er eine zentrale Funktion um einen nachhaltigen, digitalen Wandel von Unternehmen zu treiben.
Die Tooling-Palette
Die Unternehmensstrategie
Eine Strategie besteht typischerweise aus einer Vision, einer Beschreibung des Umfelds des Unternehmens, einer Beschreibung der Umsetzung zur Zielerreichung, besonderen Assets und Prozessen. Zum Schluss sollten Kontrollinstanzen, zum Beispiel messbare Faktoren wie Kosten, Gewinne aber auch Mitarbeiterzufriedenheit zur Überprüfung der Ergebnisse gelistet sein.
Die Unternehmensstrategie gibt damit den Fokusbereich für die IT-Strategie und die ersten Rahmenbedingungen vor. Technologien und Architekturen sollten nun genau diese unterstützen.
Häufig sind Strategieinhalte nicht in einem einzigen Dokument zusammengefasst, sondern in Protokollen und Köpfen verteilt. Darum ist eine Identifikation der richtigen Stakeholder und Ansprechpartner zur Aufarbeitung der Texte notwendig. Gespräche mit den Fachbereichen helfen ebenfalls weiter.
Der eigene Fortschritt sollte ebenfalls dokumentiert werden, sodass zumindest Ziele des Unternehmens, erste Fokusgebiete als auch Umfeld klar umrissen sind.
Jedes Unternehmen unterliegt besonderen Faktoren, die sich mittels PESTEL oder Porter‘s Five Forces gut beschreiben lassen [1].
Mittels Pestels lässt sich die aktuelle Weltsicht, in der sich das Unternehmen bewegt, aufarbeiten. Abb. 1 zeigt ein Beispiel, in dem einzelne Teilnehmer Themen individuell sammeln können. Diese lassen sich zusammenfassen, gruppieren und gewichten, um die Relevanz für das eigene Unternehmen herauszustellen.
Über Porter’s Five Forces lassen sich in ähnlicher Weise Themen aus der Industrie erfassen und dokumentieren. Besonderheiten bei der Nutzung der Tools durch die Fachbereiche sollten ebenfalls erfasst und strukturiert werden. Ein netter Ansatz kann die Strukturierung über die Value Chain oder ein Organigramm des Unternehmens sein.
Damit sind die generellen, äußeren Faktoren beschrieben, die auf das Unternehmen und damit auch die Anwendungslandschaft Einfluss nehmen.
Systeme sind Assets
Überraschenderweise sind Applikationen in Unternehmen häufig nicht in einer Form dokumentiert, die es ermöglicht auf Managementebene über diese zu sprechen. Zur Unterstützung einer Strategie ist allerdings notwendig, das aktuelle Bild wiedergeben zu können. Ein einfacher und pragmatischer Ansatz, der für kleine Unternehmen und Mittelständler geeignet ist, um dies nachzuholen, ist die Nutzung von Systemkontextdiagrammen in Kombination mit Steckbriefen.
Neben Schnittstellen und Benutzerrollen lassen sich so Kurzbeschreibungen, die Zweckbestimmung, Hosting-Informationen oder auch die Kritikalität direkt mit dokumentieren. Die erfassten Informationen lassen sich gut in einem Wiki pflegen und für jedermann zugänglich machen. Der zeitliche Invest, der für eine vollumfängliche Beschreibung notwendig ist, kann immens werden. Des Weiteren möchte eine entsprechende Dokumentation auch später noch gepflegt werden. Daher kann es sich lohnen, die Aufarbeitung auf bestimmte Fachbereiche zu beschränken, falls diese im Fokus der aktuellen Unternehmensstrategie sind.
Gartner’s pace layered Architecture Approach kann eine zusätzliche Maßnahme sein, die weitere Struktur gibt und zu wichtigen Diskussionen zwischen den Beteiligten führt [3]. Sobald man das Gefühl hat, alle Applikationen ausreichend erfasst und dokumentiert zu haben, kann man mit den Stakeholdern über Workshops oder in Einzelmeetings die Applikationen in die drei Schichten der pace layered Architecture einsortieren. Diese unterteilt Anwendungen in Systems of Record, Systems of Differentiation und Systems of Innovation. Dies fördert eine tiefere Auseinandersetzung mit den Applikationen und deren Rolle im Unternehmen. Sind die Applikationen erst einmal alle eingeordnet, können sich auch hinsichtlich der Lebensdauer der Applikationen, Kritikalität, Deployment als auch Kommunikation zwischen den Anwendungen kritische Fragen stellen lassen. Die Unternehmensstrategie gibt hier bereits erste Hinweise.
Szenarien nutzen und formulieren
Ist das Umfeld genügend aufgearbeitet, lässt sich auch über die Zukunft reden. Hier ist insbesondere das Scenario Planning interessant, das auf strategischer Ebene und gerne auch von Unternehmensberatern eingesetzt wird. Mittels Szenarien wird beschrieben, welcher Plan beim Eintreffen bestimmter Ereignisse ausgeführt wird. Man beschäftigt sich also mit zukünftigen Gegebenheiten. Szenarien sind seit jeher ein Werkzeug in der IT, um zum Beispiel Benutzerinteraktionen oder Anforderungen zu beschreiben. Eine entsprechende Dokumentation ist daher den meisten wohl bekannt. Das Szenario Planning ist eher strategisch. Nichtsdestotrotz ist es aber eine wertvolle Quelle, um das Unternehmen zu verstehen. Szenarien, die in Kraft treten, haben definitiv Einfluss auf Applikationen und IT-Architektur. Dahingehend sollten diese in der IT-Architektur berücksichtigt sein, wenn nicht sogar eigene Szenarien entwickelt werden. Diese können bei Eintritt der beschriebenen Gegebenheiten auch Vorgehenspläne für die IT zur Verfügung stellen.
Strategien und Rahmenbedingungen ableiten
Die bisher erarbeiteten Inhalte bieten nun den Rahmen, um Entscheidungen hinsichtlich Technologien und der Architektur zu treffen. Bei der bisherigen Arbeit sollten bereits einige Punkte aufgefallen sein, die man weiter vertiefen kann. Zusätzliche Themen lassen sich mit verschiedenen Stakeholdern entweder in einem Arbeitsmeeting oder per Telefon sammeln.
Typische Fragen oder Fokusbereiche sind:
- Wie kann die Landschaft auf besondere, externe Faktoren reagieren?
- Welche Möglichkeiten existieren, um neue, digitale Kanäle zu Kunden aufzubauen?
- Wie unterstütze ich die Erprobung neuer Technologien?
- Wie sollen Applikationen miteinander kommunizieren?
- Wie stelle ich sicher, dass die richtigen Daten zum richtigen Zeitpunkt bei der richtigen Applikation sind?
- Wie ermögliche ich den Zugriff auf Stammdaten?
- Welche Applikationen sind kostenintensiv oder haben einen großen Effekt auf die Unternehmensprozesse?
Danach erfolgt eine klassische Priorisierung anhand verschiedener Kriterien wie zum Beispiel Impact, Kostenersparnis oder Zukunftsfähigkeit. Anhand derer können bestimmte Applikationen zur Modernisierung ausgewählt oder auch Transformationsprojekte geplant werden. Falls umfangreiche Änderungen vorgesehen sind, gilt wie immer: Die Vision im Auge behalten, aber in klassischer Divide-and-Conquer-Manier unterteilen.
Auch hier kann Abb. 5 zur Pace Layered Architecture erneut helfen. Sie kann der zentrale Anlaufpunkt werden, um Prinzipien, Kerntechnologien und Applikation in Relation zu setzen, als auch um Themen wie Integration, Prozesse oder angestrebte KPI mit einzubinden.
Bekämpfung von Glaubenssätzen
Greifen wir das Muster "Angst vor dem Coding" aus der Einleitung noch einmal auf. Wird beispielsweise Software benötigt, die direkt von Kunden genutzt wird, über die Funktionen angeboten werden sollen, die so am Markt bisher nicht existieren und für die schnell neue Features veröffentlicht werden sollen, ist eine Eigenentwicklung unumgänglich. Nur Software, die für den eigenen Bedarf entwickelt wurde, kann genau zu den Unternehmensprozessen passen.
Die vorgestellten Tools liefern genau den Rahmen, dies zu verargumentieren. Sie helfen also dem Architekten, das Unternehmen zur richtigen Entscheidung zu führen. PESTEL und Porter’s Five Forces zeigen auf, wie sich eine Lösungsstrategie in der Industrie positioniert oder wie beispielsweise Reaktionen in der Öffentlichkeit aussehen. Des Weiteren kann gezeigt werden, wie die Lösung Szenarien unterstützt, mit welchen anderen Applikationen kommuniziert werden muss oder unter welchen Prinzipien sie entwickelt werden soll. Des Weiteren können auch an der Untersuchung bereits abgeleitete Strategien mit herangezogen werden.
Gesunder Pragmatismus
Die IT ist in vielen Bereichen schnelllebig geworden, was sich auch in der Handhabung von Architekturen und Technologieentscheidungen widerspiegeln sollte. Mit der Aufarbeitung der externen Faktoren und der Unternehmensstrategie für die IT lassen sich Rahmenbedingungen definieren, die für alle Applikationen gültig sind und somit auch wiederverwendbar. Die vorgestellten Tools sind wirklich Werkzeuge und keine Methode. Diese sollten so eingesetzt werden, dass die Kommunikation und Diskussion gefördert werden. Dann werden auch die richtigen Entscheidungen zur Unterstützung des Unternehmens getroffen.
Gerade die etwas nüchternere Betrachtung von Business und IT über die vorgestellten Tools hilft dabei, Vorurteile beziehungsweise Glaubenssätze zu hinterfragen. Sie helfen Ansätze abzuleiten, die wertvoll sind. Initiativen lassen sich in Abhängigkeiten zueinander setzen und technisch untermauern. Sobald die IT sich stärker mit den Unternehmenszielen auseinandersetzt und die Sprache des Business versteht, versteht sie auch die Probleme und kann viel stärker unterstützend eingreifen. Andersherum ist die Einbindung des Business notwendig, um den Einfluss von technischen Entscheidungen als auch die Komplexität transparenter zu machen.
Beide Seiten müssen sich nähern und miteinander arbeiten, um die Digitalisierung meistern zu können. Durch die Nutzung der vorgestellten Tools kann die Annäherung und die Kommunikation gefördert werden.
- Wikipedia: PESTEL
Wikipedia: Porter‘s Five Forces - C4-Methode: Context, Containers, Components and Code
- Accelerating Innovation by Adopting a Pace-LAyered Application Strategy