IT-Architektur 4.0

Strategische Konzepte für moderne Systemumgebungen

Ich möchte an dieser Stelle ein paar Gedanken zu einem neuen Thema vorstellen und einen neuen Begriff prägen, den ich mir in den letzten Monaten ausgedacht habe: „IT-Architektur 4.0“.

Betrachtet man die aktuellen Trends und Entwicklungen in der IT des Jahres 2012, so drängt sich einem der Verdacht auf, dass die gesamte Branche sich im ihrem größten Umbruch der letzten 20 Jahre befindet. Themen wie „Virtualisierung“, „Service (Management)“ oder „Cloud“ geistern mittlerweile nicht mehr nur durch bunte Marketing-Prospekte, sondern auch durch die Strategiepapiere der IT-Verantwortlichen.

Allein dies ist ein guter Grund, sich einige tiefergehende Gedanken zu den grundlegenden Herausforderungen heutiger IT-Abteilungen und deren Konzepte zu machen. Wenn wir doch über so hochgreifende Themen wie globale Public Cloud mit annähernd unendlicher Verfügbarkeit sprechen, warum haben auf der einen Seite die Administratoren in den Unternehmen immer noch mit so lapidaren Themen wie „Hardware-Problemen“ und „Server-Ausfällen“ zu kämpfen? Warum virtualisieren Unternehmen immer noch nicht den kompletten Stack von Storage über Server zu Desktops und Anwendungen? Die Vorteile und Mehrwerte liegen doch klar auf der Hand, so dass man als logisch (technisch-ökonomisch) denkender Mensch gar nicht anders kann, als in technischer Sicht immer weiter nach vorne zu gehen?

Vielleicht gibt es bezüglich dieser Themen immer noch Probleme und neue Herausforderungen, weil sich die jeweiligen Projektverantwortlichen in vielen Fällen zwar viele Gedanken über die Technologien und Konfigurationen machen, im Gegenzug aber sowohl die Gesamtarchitekturen als auch die Bedeutungen und Integrationen in das Gesamtkonstrukt „Unternehmen“ vernachlässigen.

Ich bin fest davon überzeugt, dass wir uns tatsächlich im Umbruch zu einer neuen Evolutionsstufe von IT-Architekturen befinden, die aber nur dann umfassend zu begreifen ist, wenn man sich die vorangegangenen Evolutionsstufen – oder Architektur-Versionen – ansieht und sich mit ihren jeweiligen Ursprüngen, Stärken und Schwächen auseinandersetzt.

Aus meiner Sicht stehen wir an der Schwelle zur vierten Version von IT-Architekturen – zumindest wenn man die heutzutage dominierende Intel-Plattform betrachtet.

Starten wir also einen Blick in die nicht allzu ferne Vergangenheit…

Version 1.0: Alleinstehende Clients (in einer Welt voller Hosts)

Blickt man einmal 20 Jahre in die Vergangenheit, so spielten damals Intel-basierte Systeme (oder: IBM PC-compatible, wie es damals hieß) in den Unternehmen zunächst keine Rolle. Die IT der Unternehmen wurde dominiert von großen Mainframe-Hosts, die auf einer großen Quadratmeterzahl an zentraler Stelle die Rechenleistung für sämtliche Bildschirmarbeitsplätze eines Unternehmens bereitstellten.

Diese Bildschirmarbeitsplätze bestanden aus einfachen Terminals ohne eigene Rechenlogik, die nichts weiter machten, als die Ein- und Ausgaben des Mainframes für den Benutzer zu präsentieren. Alle Benutzer arbeiteten in diesen Umgebungen mit den gleichen zentral bereitgestellten Anwendungen in der – natürlich – identischen Version und mit dem gleichen Datenbestand.

Wenn ich an meine eigene Vergangenheit zurückdenke, dann habe ich in dieser Zeit meinen Einstieg in die Unternehmens-IT gefunden und zunächst einfache Operating-Tätigkeiten in einer Mainframe-Umgebung durchgeführt. Im Wesentlichen handelte es sich hierbei um das leichte Modifizieren von „Jobs“, die die gespeicherten Daten nach immer leicht unterschiedlichen Kriterien zusammenstellten und im Regelfall in Form von Ausdrucken auf grün-weiß gestreiftem Endlospapier auf extrem lauten Stahlbanddruckern führten. Der anschließende Teil meiner Arbeit war dann eher analog – Zusammenlegen der Listen, einspannen in einen Spannbock, leimen und per Heißstrahler trocknen. Dann waren die Kunden-, Artikel- oder Absatzlisten fertig und konnten an die jeweiligen Adressaten ausgeliefert werden, die sich dann wiederum oftmals mit Hilfe eines Lineals durch die Listen arbeiteten, um die gewünschten Detailinformationen für sich herauszuarbeiten… und auf einem weiteren Block zu notieren. Waren die auf diese Weise zusammengetragenen Informationen immer korrekt und reproduzierbar? Ich weiß es nicht, bezweifle es aber. Was aber außer Frage steht, ist die Tatsache, dass Informationen in Listen mit Tausenden von Zeilen nur sehr schwer zu lesen und noch schlechter zu interpretieren sind.

Was war aber, wenn die gelieferten Informationen oder die gewünschte Funktion von der Mainframe-Anwendung nicht geboten wurden? Dann war der Anwender gezwungen diese außerhalb des Hosts abzubilden – entweder in dem exemplarisch beschriebenen Verfahren – oder eben mittels eines PCs.

PCs hatten zu dieser Zeit zwei wesentliche Vorteile, die aus meiner Sicht auch zu ihrer starken Verbreitung geführt haben: Erstens die Möglichkeit andere oder zusätzliche Anwendungen ausführen zu können, als auf dem Mainframe zur Verfügung standen. Zweitens erweiterte Grafikmöglichkeiten, die sich spätestens seit den grafischen GUIs von Apple und Microsoft als noch wesentlicher herausstellten – denn ein Chart oder eine Tortengrafik sagen oftmals mehr als die längste Liste und sind darüber hinaus deutlich schneller zu lesen und interpretieren.

War die Verwaltbarkeit der PCs zu diesem Zeitpunkt ein Thema, das den IT-Administratoren Kopfschmerzen machte? Nein, definitiv nicht. Warum nicht? Erstens gab es bei Mainframe-Admins überhaupt kein Bewusstsein für den Bedarf an zentraler Verwaltung – schließlich stand diese auf dem Hosts per Architektur nie zur Disposition. Zweitens waren die Benutzer mit PCs in der Regel eher Mitglieder der Führungsriegen und diese sind ja sogar heute noch von den meisten IT-Richtlinien ausgenommen.

Die rasche Verbreitung der einzelnen PCs in den Unternehmen stellt aus meiner Sicht die Version 1.0 der IT-Architekturen dar. Sie beschrieb somit die Emanzipation von der gleichgeschalteten Mainframe-Welt und einen gewaltigen Produktivitätsvorteil für den Anwender.

Auf der anderen Seite war sie aber auch nicht der Weisheit letzter Schluss: Themen wie Datenverlust bei Festplattenausfall oder komplizierte Verfahren zum Datenaustausch sowie die gemeinsame Arbeit mit einem Datenbestand (Datei) führten zu dem Bedarf, diese Architektur weiterzuentwickeln.

Version 2.0: Client-Server-Umgebungen

Die Version 2.0 der IT-Architekturen, die vor etwa 15 Jahren das Licht der Welt erblickte, adressierte genau diese Bedürfnisse nach Zusammenarbeit und Sicherheit. In Client-Server-Umgebungen wurden die Daten wieder zentral gespeichert, bereitgestellt und gesichert. Eine gemeinsame Nutzung von Dateien sowie ein Schutz vor Datenverlust waren somit wieder möglich.

Neben der reinen zentralen Speicherung von Daten entstanden in dieser Zeit auch die ersten Verwaltungsfunktionen für PC-Umgebungen (z.B. bei Novell Netware) sowie Anwendungen, welche zwar auf den PCs ausgeführt wurden, aber direkt auf serverseitige Anwendungen zugriffen – gute Beispiele hierfür sind die ersten Mailsysteme oder Datenbankanwendungen.

Generell war in dieser Zeit ein großer Trend zu erkennen, Funktionen und Teile der Logik wieder auf einem Server abzubilden und die immer noch weitgehend unabhängigen Clients von den Serverfunktionen profitieren zu lassen. Auf Grund der damals aktuellen technologischen Möglichkeiten (8bit / 16bit) und Hardwaredimensionen waren aber nicht alle zentral gewünschten Funktionen über einen einzelnen Server zu realisieren – ganz im Gegenteil: Mit der Zeit schlich sich die Vorgehensweise ein, pro Funktion einen einzelnen Server, natürlich physikalisch, zu installieren. So war es in Umgebungen ab einer gewissen Größe keine Besonderheit den oder die Dateiserver, den Druckserver oder in Windows-NT-Umgebungen den WINS-Server jeweils als eigenständige Windows-Server-Systeme zu betreiben.

War das immer sinnvoll? Nein, eher nicht – aber trotzdem Fakt. Und genau hier offenbarte sich die größte Schwachstelle dieses Architekturmodells: Es wurde eine große Anzahl von physikalischen Servern betrieben, die zwar im Zweifel im tägliche Betrieb recht wenig ausgelastet waren, aber trotzdem Energie sowie Platz benötigten und gewartet werden mussten. Neben diesen „harten“ Fakten gab es darüber hinaus auch den Nachteil, dass eine Skalierung nach oben – also ein Erweitern der Umgebung immer mit der Anschaffung von Hardware und Lizenzen einher gehen musste, was eine Kostenplanung oder eine relativ gleichmäßige Verteilung von Kosten nur sehr schwer bzw. unmöglich machte.

Da aber insbesondere um und nach dem Jahrtausendwechsel immer stärker auch betriebswirtschaftliche Aspekte in die IT Einzug erhielten, begann in den ersten 2000er Jahren die Zeit der dritten Evolutionsstufe von IT-Architekturen.

Version 3.0: Konsolidierung, Skalierung und Virtualisierung

In der Version 3.0 ging es im Wesentlichen um die Adressierung von zwei Kern-Themen: Kostenreduktion und Kostenkontrolle.

Und wie adressiert man diese Themen aus Sicht einer IT-Architektur? Man wendet sich zunächst der Kostenreduktion zu, welche dadurch erreicht werden sollte, dass mittels Konsolidierung und Virtualisierung einfach weniger physikalische Server in den Rechenzentren zum Einsatz kamen. Das Bündeln von vielen virtuellen Systemen auf wenigen physikalischen Servern führte nicht nur zu deutlich weniger Energie- und Platzbedarf, auch der anzahlmäßig geringere Bedarf an Hardware reduzierte die Kosten – selbst vor dem Hintergrund der Lizenzkosten für Virtualisierungsprodukte. Ein weiterer Aspekt der Kostenreduktion lag natürlich in der wesentlich schnelleren und einfacheren Bereitstellung von neuen virtuellen Systemen ohne lästige und langläufige Beschaffungsprozesse. Virtuelle Server konnten innerhalb weniger Minuten in Betrieb genommen werden, ohne das hierfür eine Freigabe von Finanzmitteln notwendig war oder eine Rechnung ins Haus flatterte.

Genau dieser Aspekt war also die Antwort auf die Frage nach der Kostenkontrolle: Sofern die Hardware-Plattform entsprechend dimensioniert war, konnte man z.B. über eine Laufzeit von drei oder fünf Jahren recht gut voraussagen, was einen die Plattform kosten würde.

Eine mögliche Aussage hierzu war: Die Leasingkosten für Hard- und Software zuzüglich der Personalkosten der IT und „ein bisschen Strom“. Diese Kosten würden durch einen weiteren virtuellen Server in der Regel nicht steigen oder auch keine Investitionen notwendig werden. Sofern nichts Unvorhergesehenes passierte, war die Kostenkontrolle und Planbarkeit nahezu perfekt.

Im Prinzip stellte die Version 3.0 somit schon einen recht guten – und heute häufig noch aktuellen – Status für die IT dar, da sie nicht nur technische sondern auch kaufmännische und organisatorische Themen in gleichem Maß berücksichtigte.

Warum aber stellt diese Architektur dann nicht nach wie vor das Non-Plus-Ultra für den IT-Betrieb dar? Weil sie zwar Kostenersparnis und Kostenkontrolle mit sich bringt, aber nicht zwangsläufig die geringsten Kosten.

Manchen wir uns ein paar Gedanken dazu, warum dies nicht der Fall ist bzw. eigentlich auch nicht sein kann. Hierzu gehen wir nochmal in Gedanken einen kleinen Schritt zurück…

Die Idee hinter der Kostenkontrolle über eine gewisse Laufzeit liegt darin, dass zum Beginn der Laufzeit eine entsprechende System-Plattform aufgebaut wird, die dann für die geplante Laufzeit alle auftretenden Anforderungen an Leistung, Flexibilität und eventuelle neue virtuelle Systeme abdecken kann.

Weiß man zum Beginn der Laufzeit schon direkt, was man ein oder zwei Jahre später an Anforderungen haben wird? Nein, weiß man nicht – man muss schätzen! Und wie schätzt man? Möglichst großzügig und mit Puffern: Es soll ja ausreichen!

Um also den schlecht vorhersehbaren Anforderungen an Leistung und Flexibilität gerecht zu werden, wurden die Plattformen so groß und leistungsstark wie möglich angesetzt. Der einzig limitierende Faktor bei diesen Planungen waren immer nur die (monatlichen) Kosten beziehungsweise die Investitionssumme, die gewisse Schmerzgrenzen nicht überschreiten durfte.

Auf den Punkt gebracht war also die Herausforderung an den Planer / Entscheider eines solchen Projektes, den besten Kompromiss zwischen Leistung, Flexibilität und Kosten zu finden. Da es bei diesen drei Punkten einen starken Zielkonflikt gibt, konnten eigentlich immer nur maximal zwei Punkte erreicht werden – niemals alle drei in gleichem Maße.

Aus der Erfahrung vieler Projekte kann festgehalten werden, dass der Großteil der Entscheidungen in letzter Konsequenz in die Richtung der Leistung und Flexibilität gefallen ist. Der passende Satz hierzu war häufig:

„Lieber jetzt einmal etwas mehr ausgeben, als in 12 Monaten nochmal um ein Budget betteln zu müssen!“

Genau aus diesem Grund zahlen Unternehmen, die auf die IT-Architektur 3.0 setzen, zwar wahrscheinlich deutlich weniger als Anhänger der Architekturen 1.0 und 2.0, aber immer noch deutlich mehr, als sie als effektiven Gegenwert von Ihrer IT-Plattform nutzen: Sei es auf Grund von allgemein ungenutzten Puffern, seien es große Leerlaufzeiten in der Monatsmitte oder starke Schwankungen in der Leistungsabnahme in verschiedenen Quartalen (z.B. Oster- und Weihnachtsgeschäfte).

Eine aus Gründen der Kostenkontrolle geplante, starre Umgebung muss immer nach dem Maximal-Prinzip geplant worden sein – und das ist einfach teurer als ein Modell, das sich nach den jeweils abgenommenen Leistungsdaten richtet.

Spätestens an dieser Stelle wird der zweite Zielkonflikt in dieser Architektur-Variante erkennbar: Kostenkontrolle und Kosteneinsparungen gehen nur auf den ersten Blick Hand-in-Hand – ab einer bestimmten Betrachtungstiefe stehen sie in diesem Modell in Widerspruch zueinander.

Version 4.0: Dynamik und Agilität

Genau dieser Zielkonflikt und die Schwächen der IT-Architektur 3.0 sollen in der Version 4.0 adressiert und beseitigt werden. Aus technischer und kaufmännischer Sicht hat dieses Modell hierzu zwei große Zielbegriffe: Dynamik und Agilität.

Es soll jederzeit dynamisch und agil auf Anforderungen jeglicher Art eingegangen werden können – seien sie technischer, organisatorischer oder kaufmännischer Natur: Es soll zu jeden Zeitpunkt die optimale Lösung für den Kunden bzw. das Unternehmen bereitgestellt werden.

Dies scheint auf den ersten Blick sehr vergleichbar mit der Kompromisssuche der Version 3.0, bei der Leistung, Flexibilität und Kosten in Einklang gebracht werden sollten. Und tatsächliche sind es natürlich auch bei der Version 4.0 diese Einflussgrößen, die für die Lösungsfindung zu berücksichtigen sind: Aber nicht einmalig zu Beginn einer definierten Laufzeit!

Dynamik und Agilität beschreibt in diesem Zusammenhang, dass der „Sweet Spot“ – also der für das Unternehmen günstigste Punkt zwischen Leistung, Flexibilität und Kosten – zu jedem beliebigen Zeitpunkt des Architekturlebenszyklus immer wieder neu definiert und gefunden werden kann.

Es geht nicht mehr darum, sich initial auf eine Lösung festzulegen, mit der man dann für Zeit-x leben muss, sondern eine Lösung zu finden, die sich jederzeit den Anforderungen des Unternehmens anpasst ohne nach einem Maximal-Prinzip entworfen worden zu sein.

Betrachtet man diesen Sachverhalt aus technischer Sicht, so wird schnell deutlich, dass dieser Anspruch nicht realisierbar ist, wenn man einzig und allein auf eigene Systeme und Ressourcen zurückgreifen möchte. Will man auf jede Leistungsanpassung – ganz gleich ob hoch oder runter – flexibel reagieren, so muss man den Weg in die Richtung von zubuchbaren Leistungserbringungen und Services gehen: Den Weg in die „Cloud“!

Nur die Nutzung und Integration von temporär nutzbaren und pro Leistungsabnahme bezahlten Diensten aus der Cloud ermöglicht die Überwindung der Schwächen der IT-Architektur 3.0, denn nur hierdurch können beispielweise Lastspitzen abgefangen werden ohne eigene Ressourcen dauerhaft hierfür vorhalten zu müssen.

Hieraus ergibt sich dann die Möglichkeit nur für die Leistung zu bezahlen, die auch tatsächlich benötigt und abgenommen wurde – um so die Kosten im Vergleich zu 3.0 senken zu können.

Aber bleibt nicht auch hierbei der Zielkonflikt zwischen Kostenreduktion und Kostenkontrolle? Wenn das Abrechnungsmodell eine Bezahlung nach Abnahme vorsieht, sind die Rechnungen dann nicht wahrscheinlich jeden Monat unterschiedlich hoch?

Tatsächlich findet sich die „alte“ Vorstellung von Kostenkontrolle mit Monat für Monat gleichbleibenden Kosten in diesem Modell nicht wieder. Aber trotzdem ist auch hier eine Kostenkontrolle möglich: Sie muss nur ebenfalls agiler werden und sich auf andere – und vor allem besser geeignete – Bezugsgrößen beziehen.

Was nützt denn eine Kostenkontrolle nach dem Modell 3.0 in Form von: „Meine IT kostet mich pro Monat x Geld. Und das sicher für die nächsten drei Jahre… naja, es sei denn, es kommen neue Benutzer hinzu oder unsere Anforderungen ändern sich – dann wird’s teurer!“

Wäre folgende Aussage nach Modell 4.0 nicht viel besser: „Meine IT kostet mich pro Benutzer und Monat y Geld. Wenn sich meine Benutzeranzahl ändert, skalieren die Gesamtkosten entsprechend nach oben oder unten berechenbar mit.“

Die zweite Aussage macht deutlich, wie eine auf realistischen Beinen stehende Kostenkontrolle aussehen kann. Eine Betrachtung der Kosten pro Benutzer, pro Gigabyte oder auch pro Postfach im jeweiligen (kurzen) Abrechnungszeitraum (z.B. Monat), bietet ebenfalls viel planerische Sicherheit. Man ist aber in der Lage, auf Änderungen auch planerisch schnell reagieren zu können.

Der Weg zu „4.0″: Betrachtung von Instanzen und Diensten

Somit liegen die Vorteile dieses neuen Architekturmodells deutlich auf der Hand – es vereint alle Vorteile der vorherigen Evolutionsstufen ohne ihre jeweiligen Schwächen.

All dies soll aber nicht darüber hinwegtäuschen, dass die Einführung und Umsetzung dieser Überlegungen von der IT-Abteilung und auch vom Gesamtunternehmen eine nicht unwesentliche Reife erfordert Bis dieses Modell in der Praxis gelebt werden kann, sind im Unternehmen zunächst viele Hausaufgaben zu erledigen: Offensichtlich und auch in den Medien propagiert sind beispielsweise rechtliche Aspekte wie Datenschutz, Verfügbarkeiten und Vertragsbedingungen zu klären.

Die wahre Arbeit liegt aber in der Organisation der IT und dem Zusammenspiel mit den Geschäftsprozessen: Der Blick auf die IT muss sich wandeln von der Betrachtung von „Servern“ und „Software“ hin zu „Diensten“, die für das Unternehmen erbracht werden. Nur klar definierte Dienste erlauben eine erfolgreiche Auslagerung oder Skalierung in die Cloud.

Ein Beispiel: Wenn heute ein Benutzer meldet, dass er Outlook braucht, so geht es ihm in der Regel hierbei nicht um das Programm, sondern um viele kleine Einzelanforderungen, die sich für ihn hinter diesem Begriff verbergen: Eine Mailadresse, ein Postfach, Kalender, Kontakte, vielleicht ein Disclaimer, eine Archivlösung, ein Viren- und SPAM-Filter und eine Zugriffsschnittstelle, über die er mit einem Programm (Outlook), einem Smartphone und einem Browser zugreifen kann.

Diese Überlegung, was alles dazu gehört, wird für eine umfassende Dienstbeschreibung benötigt – und zwar für jeden IT-Dienst, der den Benutzern zur Verfügung gestellt wird.

Neben ihren Eigenschaften haben Dienste auch entsprechende Dimensionen, also z.B. hat ein Postfach einen bestimmten Speicherplatz und der Dienst wird im Unternehmen von 2000 Benutzern genutzt. Basierend auf diesen Dimensionen kann dann aus technischer Sicht ermittelt werden, wie viele Instanzen einer Infrastrukturkomponente (z.B. Exchange Server) benötigt werden, um die Anforderungen im Hinblick auf Benutzeranzahl und Leistung decken zu können.

Um den Kreis zu schließen: Jede Instanz kostet x Geld und kann y Benutzer bedienen: hieraus kann sich der Preis pro Benutzer und Monat bestimmen lassen.

Jedes Unternehmen, das sich also diesem neuen Architektur-Modell nähern will, sollte somit zunächst Zeit darauf investieren, genau diese Dienste zu erfassen, zu definieren und im Detail zu beschreiben. Basierend auf den entsprechenden Ergebnissen kann dann überlegt werden, welche dieser Dienste welche System-Anforderungen haben, ob hierfür Investitionen für einen Eigenbetrieb notwendig sind oder ob sie sich für den Bezug aus einer Cloud eignen.

Weitere Anforderungen und Voraussetzungen

Ist die Phase der Dienst-Definition erfolgreich abgeschlossen, können je nach Dienst weitere vorbereitende Tätigkeiten notwendig werden, um beispielsweise ein Outsourcing des Dienstes in die Cloud zu vollziehen.

Ein Beispiel: Einer der am häufigsten angedachten Dienste für die Cloud ist etwa der Dienst Storage, also Speicherplatz in der Cloud zu nutzen. Viele Unternehmen überlegen schon lange, wie sie den Speicherplatz für alte und wenig benötigte Daten nicht mehr selbst zur Verfügung stellen müssen, sondern vielleicht auf günstigeren Cloud-Speicherplatz zurückgreifen können. Diese Überlegung ist absolut nachvollziehbar.

Die Problematik fängt allerdings häufig dann an, wenn man die Frage stellt, welche Daten denn in der Cloud gespeichert werden dürfen und welche eben explizit nicht: Kein Unternehmen möchte doch seine Konstruktions- oder Entwicklungspläne außerhalb „der eigenen vier Wände“ ablegen. Im Prinzip ist dies auch kein Problem – es setzt allerdings voraus, dass das Unternehmen sich im Vorfeld Gedanken dazu gemacht hat und ein entsprechendes Kategorisierungs- und Klassifizierungssysteme für seine Daten betreibt (betreibt! …nicht nur auf dem Papier entwickelt hat!)… Die Einführung und Festigung eines solchen Systems kann aber wiederum viele Monate oder Jahre dauern. Dies sollte man sich immer vor Augen halten.

Auch die Anforderungen an das IT-Personal werden sich in dieser Phase ändern müssen: Wenn mittelfristig ein Großteil der Systeme gar nicht mehr physikalisch im Rechenzentrum des Unternehmens betrieben wird, sinkt deutlich der Bedarf an „Schraubern“ – je höher der Cloud-Anteil der IT, desto kleiner der Bedarf an diesem Stellenprofil.

An dieser Stelle ist aber Vorsicht geboten: Weniger „Schrauber“ bedeutet nicht gleichzeitige weniger IT-Personal. Es kann sich in einigen Fällen sogar gegenteilig verhalten. Warum? Weil in einer solchen Struktur andere Tätigkeiten zu erledigen sind, die andere Kompetenzen verlangen.

Wenn die Masse der Dienste durch externe Dienstleister (also aus der Cloud) abgebildet wird, steigt im Unternehmen der Bedarf an Personal, das diesen Dienstleistern zuarbeitet (z.B. Dienstdefinition), das den Wechsel in solche Umgebungen begleitet (z.B. Kompetenzen als Architekt und im Bereich Projekt Management), den Betrieb stützt (Service Management, Risiko Management) und die Leistungen, Qualitäten und Vertragseinhaltungen überwacht (Qualitäts-Management, IT-Controlling). Die personelle Herausforderung, der sich die Unternehmen also stellen müssen, ist, dass vorhandene IT-Personal entweder in diese Kompetenzen hinein zu entwickeln oder Änderungen an der IT-Personalstruktur einzuleiten: beides unter Umständen sehr langwierige Aufgaben – aber für den Erfolg unvermeidbar.

Erst wenn diese Schritte abgeschlossen sind, sich die neuen Denkmodelle auch bei den entsprechenden Mitarbeitern gefestigt haben und das benötigte „Skill Set“ der Administratoren für die neuen Bedürfnisse (z.B. IT-Organisation, IT-Controlling, Service Management, Projekt Management, Qualitäts-Management) aufgebaut wurde, kann die IT-Architektur 4.0 erfolgreich in das Unternehmen eingebracht werden.

Dann aber bringt sie einen großen Mehrwert in Form von Flexibilität, Kostenersparnis und Kostenkontrolle mit sich.