Passt IT-Outsourcing noch zu den aktuellen Anforderungen der digitalen Transformation? Diese Frage wird mitunter kontrovers diskutiert. Auf der einen Seite werden heute mehr und mehr Dienste als Cloudservice genutzt und der Bedarf an physischer Infrastruktur geht zurück. Mit der Auslagerung an IT-Dienstleister, die sich um den Betrieb und teilweise auch um die Entwicklung neuer Anwendungen gekümmert haben, sind gerade mittelständische Unternehmen gut gefahren, zumal sich hier Personalkosten für IT-Experen einsparen lassen.

Auf der anderen Seite hat das Outsourcing dazu geführt, dass vielfach wertvolles IT-Know-how verloren gegangen ist und Unternehmen dem IT-Partner blind vertrauen mussten. Ohne ausreichend interner Expertise wird der Dienstleister zur Black Box und weder die Qualität noch die Effizienz lässt sich angemessen beurteilen. Zudem sind auch Dienstleister nicht vor Cyberattacken gefeit und ein erfolgreicher Hackerangriff hat unmittelbare Folgen für den Kunden. Im Zweifelsfall fällt das eigene System aus, ohne die geringste Möglichkeit, selbst den Betrieb wieder aufnehmen zu können.

Dieser Kontrollverlust und die Sorge vor Abhängigkeiten – gerade im Betrieb der eigenen IT – führt nun zum Umdenken. Im Zuge der IT-Modernisierung sollen technische Schulden abgebaut und der Weg in die Cloud forciert werden. Damit wird die IT strategisch relevant und interne Ressourcen sollen an die Stelle des Dienstleisters treten. Es gilt, die Kontrolle über die eigene Cloudinfrastruktur zurückzugewinnen und den Betrieb selbst sicherstellen.

Das Selbstbild der IT-Administration wandelt sich
All diese Entwicklungen haben zur Folge, dass sich die Arbeitsinhalte in der IT-Administration verschieben. Die Anforderungen an Infrastruktur und deren Administration haben sich stark gewandelt: Wo bisher vor allem das infrastrukturnahe Arbeiten die Regel war, kommen durch die Cloud immer mehr Tätigkeiten mit Blick auf softwarenahes Arbeiten auf. Mit dem Shared-Responsibility-Modell werden heute de facto Managed Cloudservices konsumiert, doch ohne Orchestrierung entstehen Silos und Ineffizienzen.

Im Cloud-Native-Bereich setzen viele Unternehmen auf Open-Source-Komponenten und auch diese gilt es intelligent zusammenzubringen. Dieser Prozess beginnt bereits auf der Infrastrukturebene und damit im Verantwortungsbereich der IT-Administration. Statt hauptsächlich die Hardware zu verwalten, sind die einzelnen Infrastrukturkomponenten zu orchestrieren, um einen reibungslosen Betrieb zu gewährleisten, nicht zuletzt mithilfe eines lückenlosen Monitorings. Infrastructure-as-Code ist hier das Mittel der Wahl, erfordert jedoch von IT-Administratoren, selbst in der Lage zu sein, Skripte für die Automatisierung der Bereitstellung von Cloudumgebungen zu erstellen.

Damit einhergehen sollte auch die Anpassung des Selbstbilds in der IT-Administration: Welcher Mehrwert wird künftig erbracht und in welcher Intensität und (Reaktions-)Geschwindigkeit? Letztere hängt schließlich maßgeblich mit der Entwicklungsgeschwindigkeit zusammen und die Bereitstellung von Umgebungen für Entwicklung, Testing und Betrieb geraten zum limitierenden Faktor.

Platform Engineering für hohe Entwicklungsgeschwindigkeit
Hier kommt das Platform Engineering ins Spiel. Dabei werden standardisierte Stacks aufgebaut, die dann für die Entwicklung bereitstehen. Dieser Ansatz verabschiedet sich von der Fokussierung auf einzelne Komponenten und abstrahiert die Infrastruktur. Es entsteht ein Platform-Layer, der im Unterbau für Standardisierung sorgt und dadurch den Administrationsaufwand erheblich reduziert. Gleichzeitig kommt das der Entwicklung zugute: Durch den Layer, der auch unter dem Begriff "Internal Developer Platform" (IDP) an Bekanntheit gewinnt, lassen sich Self-Service-Funktionen und wiederverwendbare Tools für Entwickler bereitstellen. Diese reduzieren deren kognitive Belastung und sorgen auch für schnellere und kontinuierliche Softwarebereitstellung.

Im Grunde soll dadurch die wiederkehrende Friktion zwischen Softwareentwicklern und Betrieb in DevOps-Teams aufgelöst werden. Ein Beispiel macht das ganze Thema etwas deutlicher: Ein Unternehmen hat verschiedene Infrastrukturdienste und möchte sowohl eigene als auch die der Public Cloud nutzen. Dabei spielt es für Entwickler meist gar keine Rolle, welche Infrastrukturkonfiguration exakt zugrunde liegt, sondern vielmehr, welche Freiheiten er oder sie in der Entwicklung bekommt und welche Services sich standardmäßig konsumieren lassen. Mithilfe von Containern und Kubernetes wird die Infrastruktur ohnehin immer öfter abstrahiert. So hat der Administrator die volle Kontrolle über die Infrastruktur und der Application Owner sowie die Developer alle Freiheiten, die sie brauchen.

Ein zentrales Problem beim Einsatz von DevOps ist die mangelhafte Umsetzung in vielen Unternehmen. Anstelle eines integrativen Prozesses zwischen Entwicklungs- und Betriebsteams tritt die Abschaffung der formalen Operations. Stattdessen werden teure Senior-Developer-Ressourcen geblockt, da diese mit der Verwaltung von Umgebungen und der Infrastruktur zu tun haben. Anstatt wertvollen Input in den Code und die Produktentwicklung zu geben, sind sie damit beschäftigt, das Setup zu gestalten und Anfragen der weniger erfahrenen Kollegen zu bearbeiten. Dadurch leidet die Entwicklungsgeschwindigkeit sowie die Qualität.

Das soll nicht bedeuten, dass DevOps im Mittelstand keine Relevanz hat. Vielmehr gilt es, den Ansatz neu zu interpretieren: Auf der einen Seite muss die Entwicklung "operations"-orientiert und die Operations "dev"-orientiert werden, und auf der anderen Seite soll es weiterhin eine gewisse personelle Trennung geben. Das ist der Fall, wenn die IT-Administration in der Lage ist, Platform Engineering zu betreiben und eine IDP aufzubauen. Dann kann die Entwicklung auf Umgebungen unterschiedlicher Güte zugreifen – von vollständig kontrollierbaren Umgebungen mit Zugriff auf Kubernetes Services bis hin zu umfassend provisionierten Umgebungen, bei denen sich die Entwickler nicht darum kümmern müssen, wo ihr Code läuft.

Mit Mixed Teams die Rolle des IT-Admins stärken
Wie lassen sich aber nun die Insourcing-Bestrebungen mit den neuen Anforderungen an die IT-Administration vereinbaren? Und welche Rolle spielen bestehende Dienstleister? Ein pragmatischer Ansatz, der sich bewährt hat, ist der des "Mixed Teams". Dabei arbeiten interne Mitarbeiter in einem Team mit dem IT-Dienstleister. Denn auch wenn der Entschluss zum Insourcing gefallen ist, stehen weiterhin Entwicklungsprojekte und der laufende Betrieb an. Um hier den Spagat zwischen Aufgabenpaketen und Wissenstransfer zu meistern, empfiehlt es sich, einen gemeinsamen, separaten Backlog aufzubauen. Hier werden neue Verantwortlichkeiten vergeben und dann die Automatisierungslogiken und Standards gemeinsam erarbeitet – unabhängig vom Tagesgeschäft, das vorerst weiter über den Dienstleister läuft.

In dieser Phase sollten Unternehmen in die Fortbildung der Mitarbeiter investieren, um sie mit den fundamentalen Konzepten der Softwareentwicklung vertraut zu machen. Dies kann entweder durch externe Schulungen erfolgen oder direkt durch den IT-Partner, sofern dieser entsprechende Bildungsangebote anbietet. Wichtig ist, dass sich die internen Mitarbeiter mit gängigen IaC-Tools vertraut machen. Das Open-Source-Projekt Ansible eignet sich beispielsweise für Unternehmen, in denen die IT-Administration noch wenig Programmiererfahrung besitzt. Die nötigen Module für den Zugriff auf Komponenten oder Umgebungen, die oftmals in Python geschrieben sind, sind heute von zahlreichen Herstellern erhältlich. Auch die Beschäftigung mit Terraform kann sich lohnen, gerade mit Blick auf die langfristige Verwendung in immer komplexer werdenden Cloudumgebungen. Dieses Tool ist heute schon fast so etwas wie ein De-facto-Standard für Infrastrukturprovisionierung mit IaC und eignet sich besonders gut für die Orchestrierung in Hybrid- und Multicloud-Umgebungen.

Im nächsten Schritt empfiehlt es sich, ein Projekt mit strategischer Relevanz zu identifizieren und dieses im Mixed Team anzugehen. Soll beispielsweise ein bestehender Use Case in der Cloud abgebildet werden, ist die Entscheidung zu fällen, ob ein Refactoring erfolgen soll oder ob eine cloudnative Neuentwicklung den sinnvolleren Weg darstellt. Ist das geklärt, geht es an die Erarbeitung des Betriebskonzepts, inklusive der Erstellung von Skripten sowohl für die Provisionierung als auch für den fortlaufenden Betrieb. Gerade die Skripterstellung eignet sich optimal für den Mixed-Teams-Ansatz: Der IT-Dienstleister kann hier die führende Rolle übernehmen und das Plattformteam beziehungsweise die IT-Administration an die Hand nehmen. Gemeinsam erstellen sie dann Skripte und Skriptelemente , die das Plattformteam später wiederverwendet kann. Hohe Standardisierung sowie Manuals und Dokumentationen helfen den internen Teams, schnell in die Thematik einzutauchen und zeitnah einfache Automatisierung selbst zu verwalten.

Ist das Backsourcing des Betriebs schlussendlich erfolgt, kann sich der IT-Dienstleister im Mixed Team eher zurückziehen und in die Rolle des Sparringspartners übergehen. Typischerweise erfolgt dann die komplexere Anpassung von Skripten, etwa wenn diese nicht mehr den Anforderungen des Betriebs gerecht werden. Außerdem kann der Dienstleister QA-Services bieten. Letzteres sollte nicht unterschätzt werden, denn wenn der Betrieb nach innen wandert, fallen typische Leistungsbeziehungen oft weg. Der IT-Partner kann hier auf Basis von Service Level Objectives und Service Level Indicators die Performance weiterhin mitüberwachen und Optimierungsempfehlungen geben.

Fazit
Der Wunsch nach mehr Kontrolle über die eigene Infrastruktur gibt dem Insourcing Aufwind. Damit dabei die Entwicklungsgeschwindigkeit nicht leidet, muss sich das Selbstverständnis der IT-Administration wandeln und neue Fähigkeiten, gerade im Bereich programmierbare beziehungsweise softwaredefinierte Infrastruktur und Automatisierung aufgebaut werden. Der Mixed-Team-Ansatz kann dabei besonders mittelständischen Unternehmen und deren IT-Abteilungen unterstützen, indem er interne Ressourcen projektnah und unter Aufsicht erfahrener Partner auf- und ausbaut.

ln/Maximilian Hille, Head of Consulting bei Cloudflight