Dem IT Service Management obliegt es, dass die IT reibungslos funktioniert und die Geschäftsprozesse des Unternehmens bestmöglich unterstützt. Vor dieser Maintenance und „Reparatur“ kommt aber die Konstruktion. Steht die ganze IT-Architektur auf tönernden Füßen, muss man grundsätzlicher herangehen. Jetzt sind schonungslose Analyse und ggf. Basisarbeiten am Fundament der IT-Infrastruktur nötig. Auch darum kümmert sich SIRIUS und muss feststellen: Selbst Großunternehmen lassen dabei oft die elementarsten Prinzipien vermissen.
Zwei längerfristige Projekte sind, in denen wir uns derzeit mit Architekturthemen beschäftigen: bei einem führenden IT Service Provider sowie einem großen deutschen Softwarehersteller. Im ersten Fall geht es um eine Mischung aus Applikations- und Enterprise-Architektur – letzteres als große Klammer, bei der man mehr über Organisationsstrukturen und das Business spricht als über konkrete Technik. Den Softwarehersteller unterstützen wir bei der Ausarbeitung seiner Cloud-Strategie und Neuausrichtung der Cloud-Architektur.
Bitte keine Lines & Boxes
Ob nun auf Enterprise- oder Applikationsebene: Will man über Architektur gemeinsam denken und sprechen, braucht es ein Diagramm. Solcherlei findet man zwar überall, aber viele sind das (sprichwörtliche) Papier nicht wert, auf dem sie gezeichnet wurden. Nur wenige Firmen lassen hier eine gewisse Mindestsorgfalt walten, so die Erfahrungen aus unseren Architektur-Projekten. Man findet die berüchtigten Lines & Boxes, wie es im Angelsächsischen heißt: Rechtecke, die mit Linien verbunden sind. Wobei die Rechtecke alles sein können – Server, Software, Betriebssystem??? Und die Linien sagen nichts darüber aus, ob eine Beziehung uni- oder bidirektional ist, in welche Richtung sie verläuft etc.
„Der Appetit für notationsstringente Architekturdiagramme ist in deutschen Organisationen nur homöopathisch ausgebildet. Das muss sich ändern. Auch eine engere bessere Zusammenarbeit ist nötig, ohne Herrschaftswissen einzelner Fürstentümer.“
– Volkmar Woinke, Enterprise-Architekt bei SIRIUS
Die Folge sind unaufgeklärte und sich unbemerkt weiterverbreitende Missinterpretationen. Um sie zu vermeiden, benötigt ein Diagramm eine sinnvolle Annotation als Dreh- und Angelpunkt. Welche man verwendet, ist dabei zweitrangig, ob Archimate, den Klassiker UML oder den neuen Rising Star C4. Entsprechend der Zielsetzung ist immer abzuwägen, welche Notation die jeweils passende ist. Archimate zum Beispiel verstehen auch das Business oder Business Analysts, C4 dürfte sich eher eignen für den Dialog mit technisch Affinen. Letztlich geht es darum, Architektur mittels einer verständlichen Darstellung allen zugänglich zu machen. Und das funktioniert nicht ohne Notation.
Fürstentümer nein danke
Zweites Problem sind Unternehmen mit (überspitzt formuliert) anarchischen Zuständen und Fachabteilungen, die autarken Fürstentümern gleichen, mit anderen Worten: Sie scheren sich wenig um Ansagen von oben. Kocht aber jeder sein eigenes Süppchen, kann man kaum Standards durchsetzen. Hier eine Kette im Sinne von ITSM/ITOM zu bilden ist aussichtslos. Sie wird brechen, wenn die einzelnen Abteilungen, von Hardware-Provisioning über Netzwerk bis Customer Service, sich nicht an ein standardisiertes Vorgehen halten.
Die Fachabteilungen zusammenbringen, dabei hilft eine sauber aufgesetzte und annotierte Enterprise-Architektur. Sie stellt Sichtbarkeit her: Welche virtuelle Maschine genau verursacht ein Problem, welche Netzwerkverbindung ist betroffen? Daraus wird dann zum eingegangenen Ticket verlinkt, der dahinter stehende automatisierte Workflow startet. Ein solches Konzept kann mit einer hochgradig autarken Unternehmenskultur nicht funktionieren.
Architekturthema schlägt operatives Klein-Klein
Enterprise-Architekten müssen daher alle Beteiligten an einen Tisch bringen, um gemeinsam an einer Landkarte zu arbeiten, die den momentanen Ist-Zustand der Unternehmens-IT wiedergibt, also nichts weniger als die Wahrheit. Steht diese, sollte sie natürlich nicht in der Schublade verschwinden. Bei den Vorsätzen darf es nicht bleiben, sondern die Architektur muss leben. Nachdem die Enterprise-IT mit all ihren möglichen Schwachstellen daher analysiert wurde, gilt es sie in der Folge auch zu verbessern, d.h. technisch aufzurüsten. Dafür braucht es Rückendeckung von ganz oben, weswegen der Dienstleister Allianzen mit den „Mächtigen“ im Unternehmen schmieden muss. Das Architekturthema sollte im Zweifelsfall die täglichen Klein-Klein-Probleme des operativen Betriebs ausstechen und ihnen gegenüber Priorität genießen.
Ein Verständnis von der Architektur als übergeordnetem Querschnittsthema ist in den Führungsebenen der Unternehmen durchaus angekommen. Was nun noch fehlt, ist der Ritterschlag. Wurde ein Problem identifiziert, darf man nicht einfach zur Tagesordnung zurückkehren, sondern es muss ernst genommen werden.
IT-Landkarten sind nicht für die Schublade
Eine Architektin muss den Dialog steuern, wenn es um Nachhaltigkeit und Zukunftsfähigkeit von Systemen geht. Begreift sie sich als resultatorientiert, müssen auf das Reden anschließend Taten folgen, d. h. die Umsetzung der neuen Architektur muss koordiniert werden. Dafür bedarf es Wissen über die einzusetzenden Technologien, von ABAP über Objektdatenbanken bis zur WLAN-Verschlüsselung.
Als Architekturteam kümmern wir von SIRIUS uns mit dedizierten Streamleads darum, dass die jeweils wertschöpfenden Prozesse im Unternehmen umgesetzt werden. Architektonisches Schaffen hieß z.B. im Projekt bei dem Mittelständler ganz konkret: Ein Service-to-Invoice-Prozess, der bisher im ITSM-Tool Jira ablief, musste mit anderen Kernprozessen im ERP-System verknüpft werden. Es galt festzulegen, welche Daten wann wohin transferiert werden usw.
Sicher: Renommierte Architekturpreise wie ihre Kolleg:innen aus der Baubranche können IT- Fachleute damit noch nicht abräumen. Eigentlich ungerecht, denn ihre Arbeit ist nicht minder wichtig. Ohne ein statisch sauberes, technisch einwandfreies IT-Fundament funktioniert in Deutschland nämlich kein einziges Unternehmen mehr richtig.
Titelbild: © Violka08/Getty Images
