Operations heute und morgen, Teil 1: Das moderne IT-Unternehmen

Inhaltsverzeichnis

Durch eine zunehmend durchgängigere Unterstützung der Business-Prozesse bestimmt die IT heute den Herzschlag der meisten Unternehmen. Doch wie gestalten diese den IT-Betrieb, vor welchen Problemen stehen sie dabei und welche Lösungsmöglichkeiten gibt es?

Mehr Infos

Operations heute und morgen

Das Business scheint aus IT-Sicht seine Anforderungen und Wünsche nach neuen und aktualisierten Features immer schneller zu ändern. Gleichzeitig gibt es innerhalb der IT fortwährend neue Trends, die umgesetzt werden wollen. Doch wo steht der IT-Betrieb bei der Umsetzung der Anforderungen und Wünsche? Haben die Entwickler mit dem agilen Trend die Mauern zum Business eingerissen, kam in den letzten Jahren zunehmend der Wunsch nach DevOps auf. Dev steht für Development/Entwicklung und Ops für Operations/Betrieb. Damit soll auch die Mauer zwischen Entwicklung und Betrieb überwunden werden. Doch was hat sich bisher wirklich durchgesetzt? Das betrachtet die Artikelserie "Operations heute und morgen":

• Das moderne IT-Unternehmen
• DevOps im Jahre 2015
• Virtualisierung & Containerisierung
• Hochverfügbarkeit
• Big Data aus Betriebssicht
• Monitoring

IT-Betrieb ist in den meisten Unternehmen eine von der Entwicklung strikt getrennte Angelegenheit. Er wird meist ab einer gewissen Unternehmensgröße (ab ca. 150 Mitarbeiter) weiter unterteilt. Es steht dann auf der einen Seite der Anwendungsbetrieb, der sich um das Bereitstellen, Warten und Testen von Systemen rund um den Betrieb von Anwendungen kümmert. Gleichzeitig leistet er oftmals den 2nd- beziehungsweise 3rd-Level-Support und überarbeitet das Betriebshandbuch. Auf der anderen Seite steht das Infrastruktur-Team, das sich um Themen rund um Hardware, Netzwerke, Betriebssysteme, Zertifikate und mittlerweile auch um die Virtualisierungsschicht kümmert.

Schließlich übernehmen, nicht generell, aber gerade in größeren Firmen weitere Teams die Quality Assurance (QA) und IT-Sicherheit. Aus Betriebssicht sind, mit jeweils unterschiedlichem Fokus, die QA genauso wie die IT-Sicherheit für das Überwachen der Hardware und Systeme zuständig und informieren bei Problemen die jeweiligen Teams. Diese Strukturen kommen oft von der Ausrichtung der Unternehmen an ITIL und der darin definierten Ableitungen her. Die Abbildung 1 zeigt, wie die Service-Operationen nach ITIL strukturiert sind: "Service Operation beinhaltet die Erfüllung von Anwender-Anfragen und Erarbeitung von Problemlösungen ebenso wie die Erbringung von Betriebsaufgaben im laufenden Tagesgeschäft".

Wird das Ganze weiter aufgebrochen, finden sich meist folgende Arbeitsfelder in den Unternehmen:

• Service Desk
• Incident Management
• Change Management
• Release Management
• Configuration Management
• Compliance
• Access Management

IT-Betrieb in Unternehmen: Das Problem

Schon 1968 hat Melvin E. Conway formuliert: "Organisationen, die Systeme modellieren, [...] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden." Längst ist bekannt, dass bei solch einer Struktur Probleme auch aufgrund komplexer Kommunikationsstrukturen vorgezeichnet sind. Die Abbildung 2 zeigt, dass die agile Bewegung geholfen hat, Feedback-Zyklen zwischen Business und Entwicklung einzurichten und zu stärken. Sie zeigt aber auch, dass das über den Lebenszyklus einer Anwendung nur eine kurze Teilstrecke ausmacht.

Für den IT-Betrieb bedeutet das, dass Feedback-Zyklen eingerichtet und gelebt werden müssen genauso wie zwischen der Entwicklung und dem Business. Zur Verdeutlichung sei ein gängiges Beispiel herangezogen: Werden über das Business neue Anforderungen an die Entwicklung herangetragen, leiten die Programmierer die Systemanforderungen an den Anwendungsbetrieb weiter. Derzeit findet in den meisten Unternehmen an dieser Stelle eine eindimensionale Kommunikation statt: von den Entwicklern in Richtung des IT-Betriebs. Dass der Anwendungsbetrieb bereits in den ersten Meetings, in denen die Systemanforderungen definiert werden, mitsprechen darf, passiert selten. Aber schon an diesem Punkt kann der IT-Betrieb seine Stärken ausspielen, da er das Fachwissen mitbringt, welche Vor- beziehungsweise Nachteile gegebenenfalls bei bestimmten Systemen und Techniken zu erwarten sind und wie diese am besten in eine Systemarchitektur passen.

Auch in der späteren Phase, der Entwicklung, schreiben die Programmierer oft ohne Absprache mit der QA die Texte für Log-Nachrichten. Manch ein QA-Mitarbeiter hat sich beim Lesen der Nachricht dann gefragt: "Was sagt denn diese Log-Nachricht aus?". Auch aufgrund der fehlenden Feedback-Zyklen bekommt der Anwendungsbetrieb von den Entwicklern immer wieder zu hören, dass die für ein neues Projekt benötigten Systeme besser gestern als heute bereitstehen sollen. Der Anwendungsbetrieb wartet dabei möglicherweise selbst auf die Hardware beziehungsweise die VM, die das Infrastruktur-Team nicht liefern kann, da die Bestellung zu spät unterschrieben wurde. Aus Sicht des Managements stellt sich das Ganze dann so dar, dass mittlerweile Features in kurzen Zyklen ausreichend schnell entwickelt werden, diese aber als totes Kapital bis zum nächsten Deployment brachliegen.

Die soeben beschriebenen Mängel zeigen, dass in Zukunft Barrieren eingerissen, Arbeitsabläufe visualisiert und Aufgaben gemeinschaftlich angegangen werden müssen. Nur so ist es möglich, der Geschwindigkeit des Business folgen zu können und gegebenenfalls sogar den lang gehegten Wunsch zu erfüllen, als IT der Treiber des Unternehmens zu werden und nicht wie bisher der Getriebene.

Die Abbildung 3 zeigt ein weiteres Problem an den aus Sicht des Managements klar strukturierten Prozessen: Aufgrund der sich oft ändernden und unbekannten Anforderungen und durch den Einsatz neuer weniger bekannter Techniken wird die Arbeit, die in den IT-Bereichen anfällt, eher zum Chaos, als vorhersagbar und zuverlässig zu sein. Das Ziel eines modern aufgestellten Unternehmens muss es also sein, die wenig vorhersagbare Arbeit wieder in geordnete Bahnen zu lenken.