Während sich viele Vorgehensmodelle in der IT mit dem Betrieb der Informationstechnik an sich beschäftigen und IT-interne Prozesse optimieren sollen (so zum Beispiel das mit Hassliebe betrachtete ITIL), dienen die Frameworks der Enterprise-Architektur der Verknüpfung von IT-Aufgaben mit den Unternehmenszielen und erzeugen so sehr viel Transparenz. Keine Angst vor zu viel Overhead: Schon mit der Einführung weniger Prinzipien kann im Unternehmen viel erreicht werden.
Enterprise Architektur – oder besser IT-Unternehmensarchitektur – als Disziplin des IT-Betriebes im Unternehmen hat es nicht einfach. Vielfach als „zu sperrig“, „zu unhandlich“ oder schlicht „zu umständlich“ gescholten, wagen sich nur wenige Unternehmen an die Einführung entsprechender Prozesse und Frameworks. Denn der Respekt vor der Komplexität von Frameworks wie TOGAF oder Zachman ist groß. Und eigentlich befasst man sich lieber mit technischen Themen.
Enterprise Architektur ist auch nicht „mal eben“ oder nebenbei gemacht. Denn es gilt, Unternehmenszweck und IT-Betrieb aufeinander abzustimmen und aneinander auszurichten. Am Ende muss sich der IT-Betrieb an seinem Beitrag zum Unternehmenszweck messen lassen. Oftmals gestaltet sich die Suche nach optimalen IT-Lösungen für eine spezielle betriebliche Herausforderung komplex , es müssen Standards definiert, neue Prozesse und Abstimmungsrunden etabliert und viele Dokumente erstellt werden. Viel Konfliktpotential also. Aber darin steckt ja auch „Potential“
Slicing the elephant
Um den IT-Betrieb an den Unternehmenszielen auszurichten, ist es notwendig, Unternehmensprozesse zu identifizieren und zu beschreiben. Dies führt unmittelbar zu einer besseren Sicht auf die Unternehmensprozesse, ihre Werthaltigkeit (oder ihr Wertschöpfungspotential) und die jeweilige Komplexität. Bereits an dieser Stelle können Unternehmen wertvolle Informationen aus den gewonnenen Daten ziehen: Wo sind zum Beispiel Risiken in der Prozesskette, wo ergeben sich vielleicht schon Ansätze zur Reduzierung der Komplexität und haben alle Beteiligten eine gemeinsame Sicht auf die Relevanz der Prozesse?
Anschließend können die vorhandenen IT-Prozesse gegen die Unternehmensprozesse gematcht und dahingehend überprüft werden, ob sie den entsprechenden Zweck optimal unterstützen, ob der Aufwand für den IT-Prozess der Wertschöpfung des Unternehmensprozesses angemessen ist und der Risikobewertung des Unternehmensprozesses entspricht.
Würde man das Vorhaben „Enterprise Architektur“ an dieser Stelle abbrechen, wären bereits viele hilfreiche Informationen für Unternehmensleitung und IT-Leitung gewonnen. Aber Enterprise Architektur ist kein „BWLer-Pentest“. Erst jetzt beginnt die Arbeit, für die bestehenden Prozesse Optimierungspotential zu finden und für zukünftige Entscheidungen den entsprechenden Rahmen zu finden.
Better done than perfect
Bis jetzt haben wir nicht von Frameworks gesprochen und werden es auch weiterhin (fast) nicht tun. Enterprise Architektur-Tools (wie EA oder ADOit) sind wertvoll und hilfreich, TOGAF und Archimate sind es auch. Aber im Kern lässt sich eine Enterprise Architektur auch mit Hilfe von Stift und Zettel, bzw. mit Visio, diagrams.net oder excalidraw abbilden.
Wie und wo also starten? Bitte nicht warten, bis die Bedingungen optimal sind – es hat sich bewährt, das eigene Vorgehen an ein oder zwei Unternehmensprozessen zu verproben. Dazu gehört:
- Die Unternehmensprozesse und deren Schnittstellen zu anderen Prozessen beschreiben (wie und wo auch immer): Für den Anfang kann das zum Beispiel ein einzelner Prozess sein („Wie bestelle ich neues Verbrauchsmaterial?“). Umfangreicher wird es mit einer ganzen Prozesskette („Wie versende ich Ware in meine Filialen?“).
- Die für diese Prozesse eingesetzten IT-Prozesse identifizieren und in eine zentrale Abbildung übernehmen. Hier ist die Nutzung einer für Enterprise Architektur-Prozesse geeigneten CMDB vorteilhaft. Dies kann für den Anfang eine bereits vorhandene Asset-Datenbank sein (bspw. aus dem JIRA-Kosmos) – dauerhaft empfiehlt sich aber der Einsatz spezialisierterer CMDB-Anwendungen der führenden Anbieter von Enterprise Service Management (z.B. von OpenText, BMC oder ServiceNow). Schnell werden Abhängigkeiten und Risiko-Ketten sichtbar.
- Die Architektur bewerten: Erreichen die genutzten Prozesse und die verwendete Infrastruktur die Anforderungen an Verfügbarkeit und Resilienz? Sind die verursachten Kosten für die Bereitstellung des Service vertretbar? Ist die verwendete Architektur zukunftsfähig?
- Die Ergebnisse bewerten: Die bis hier gewonnenen Daten sind als Grundlage weiterer Betrachtungen (wie z.B. Risikobewertungen, Application Portfolio Management), aber auch für IT-Betriebsprozesse wie Change-, Problem- oder Enterprise Service Management sehr wertvoll.
- Dokumentieren!
Schnell wird man dazu kommen, das entstandene Bild zu erweitern, mehr und mehr Abhängigkeiten zu erkennen und Redundanzen zu identifizieren. Nebenbei entwickelt sich ein einheitliches Vokabular, ein granularer Blick auf die Unternehmens-IT mit einem verfeinerten, verbesserten Asset-Management und ein sehr klarer Blick darauf, welche Prozesse als nächstes entwickelt werden müssen.
