Anpassung der IT-Governance
Im Kapitel 3.2 wurde IaaS als eine Dienstleistung klassifiziert (Sushil et al. 2010, S. 60-63). Nach der Definition zur IT-Governance im Kapitel 2.4.1 beschäftigt diese sich mit dem optimalen Einsatz von IT-Ressourcen und dem Risikomanagement (IT Governance Institute 2003, S. 6-30).
Auf Ebene der Führungsaufgaben, zu der IT-Governance gehört, wird ein effizienter und effektiver Einsatz von IT-Ressourcen verlangt. Dies wird Anhand von drei Grundsatz-entscheidungen erreicht. Die erste Grundsatzentscheidung lautet: Welche Leistung soll erbracht werden? In diesem Fall wird IaaS als Dienstleistung vom Unternehmen bezo-gen. Diese Kernfrage muss auf allen Ebenen des Unternehmens beantwortet werden, woraus sich die Herausforderungen an das Unternehmen ergeben. Die Unternehmens-strategie spiegelt sich im Produkt- und Dienstleistungsportfolio des Unternehmens wie-der. Die IT-Strategie dagegen in der IS-Architektur, IS-Infrastruktur und in den ange-botenen IT-Services. Die zweite Grundsatzentscheidung lautet: Von wem wird die Leis-tung erbracht? Im Kapitel 3.2 wurden einige IaaS Anbieter aufgezählt, wobei nicht be-rücksichtigt wurde, ob die Leistung von einem oder mehreren Anbietern bezogen wird. Nachdem die Entscheidung über das Leistungsprogramm getroffen wurde, erfolgt die Gestaltung der internen Aufbauorganisation der IT-Abteilung sowie des IT-Personalma-nagements. Dazu müssen Fragen bezüglich der IT-Sourcing Strategie geklärt werden. Die dritte und letzte Grundsatzentscheidung lautet: Wird die Leistung richtig erbracht? Die Beurteilung der Leistung kann anhand von Kriterien wie Qualität, Termintreue, Pro-duktivität, Wirtschaftlichkeit oder Effizienz erfolgen. Die Wahl der exakten Kriterien ist Abhängig vom Produkt bzw. der Dienstleistung. Die IT-Organisation verwendet spezielle Methoden zur Steuerung und Kontrolle der Leistungserbringung. Methoden zur Messung der Leistungserbringung sind: Service Level Agreements, Operational Level Agreements (OLA), Underpinning Contracts (UC), Kennzahlensysteme und IT-Servicekataloge (Krc-mar 2015, S. 393-395).
IaaS wird mithilfe von SLAs der IT-Organisation zur Verfügung gestellt. Nach der Defi-nition von Bernhard (2006, S. 22-23) zu SLAs, muss sich die IT-Organisation als Ser-vice-orientierter Dienstleister positionieren. Die Kontrolle einer konstanten Leistung von IaaS muss von der IT-Organisation sichergestellt sein. Eine weitere Herausforderung ist die Entwicklung der IT-Governance zu einer SOA-Governance. SOA steht für Service Orientierte Architekturen (Krcmar 2015, S. 395). Der SOA-Ansatz wird im weiteren nä-her vorgestellt.
SOA-Governance
Der SOA-Ansatz kann gemeinsam oder unabhängig von Cloud Computing stattfinden. Konzepte wie IaaS beeinflussen die Entwicklung einer SOA-Governance (Manvi et al. 2014, S. 425). Durch den Einsatz von IaaS steht die IT-Organisation von der Heraus-forderung und der Chance, die IT-Governance in eine SOA-Governance zu überführen. IaaS bietet der IT-Organisation neue Möglichkeiten. Die eigentliche Herausforderung ist, wie die IT-Organisation IaaS im Unternehmen erfolgreich einsetzt.
Die Autoren Tilkov und Starke (2007, S. 12) definieren SOA wie folgt: „Eine serviceori-entierte Architektur (SOA) ist eine Unternehmensarchitektur, deren zentrales Konstruk-tionsprinzip Services (Dienste) sind. Dienste sind klar gegeneinander abgegrenzte und aus betriebswirtschaftlicher Sicht sinnvolle Funktionen. Sie werden entweder von einer Unternehmenseinheit oder durch externe Partner erbracht“.
Warum überhaupt eine SOA-Governance? Nach Kobielus (2009, o. S.) ist eine starke SOA-Governance der Schlüsselfaktor zur Kontrolle von Cloud-Lösungen.
SOA-Governance hat zur Aufgabe die Komplexität des Managements von Servicekom-ponenten zu begrenzen, die Wirksamkeit zu überprüfen, ihre effiziente Nutzung sicher-zustellen und die damit verbundenen Risiken zu minimieren. Die IT-Organisation hat mit der Möglichkeit von adaptiven IT-Architekturen, die Geschäftsprozesse des Unter-nehmens, kosteneffizient zu unterstützen. IT-Organisationen in typischen Unternehmen (industrielle Sparten) und des öffentlichen Bereiches, weisen Defizite in den Anforde-rungen an Serviceorientierten Architekturen auf. Die IT-Governance wird aus der Cor-porate Governance abgeleitet. Die SOA-Governance wird wiederum aus der IT-Gover-nance abgeleitet. Die Aufgabenstellungen der SOA-Governance ähnelt stark der IT-Governance, daher ist es angebracht, in diesem Zusammenhang von SOA-Governance zu sprechen, auch wenn beide auf verschiedenen Ebenen angesiedelt sind. Der SOA-Ansatz verspricht, aus der Kombination von neuen und bereits bestehenden Service-komponenten, neue Produkte und Geschäftsprozesse zu ermöglichen. Die Kombinatio-nen von Servicekomponenten erfolgt dabei ohne größeren technischen Aufwand. Dies führt dazu, dass die Bereitstellung (Time-to-Market) von neuen Services bzw. Ge-schäftsprozessen erheblich verkürzt wird. Unternehmen können flexibler auf sich än-dernde Marktanforderungen reagieren. Der Wiederverwendungsaspekt von Servicekom-ponenten ist von Interesse für das Unternehmen, da dadurch ökonomische Vorteile er-reicht werden. Dafür müssen Servicekomponenten von Drittanbietern integrierbar sein. Drittanbieter die sich auf eine Marktnische konzentrieren, bieten Dienstleistungen ggf. kostengünstiger an. Dienstleistungen werden potenziell von unterschiedlichen Anbietern bereitgestellt und weisen neben unterschiedlichen Funktionen auch unterschiedliche
Qualitätsmerkmale auf. Die Verwaltung und Steuerung von Servicekomponenten obliegt der IT-Organisation. SOA darf nicht nur technisch gesehen werden, sondern stellt eine Herausforderung an die Struktur der IT-Organisation dar. SOA stellt ein Paradigmen-wechsel in der Softwareproduktion, -bereitstellung und –nutzung dar. Ein Business Case ist von Vorteil, der auch organisatorische Veränderungen berücksichtigt. SOA führt dazu, dass die Zahl und Vielfalt von Schnittstellen drastisch erhöht werden. Für das IT-Management bedeutet dies die Verwaltung neuer Verträge. Die Gefahr bei einer Über-führung der IT-Governance in eine SOA-Governance ist, dass die Ist-Situation des Un-ternehmens falsch eingeschätzt wird. Die IT-Organisation muss sich auf eine SOA vor-bereiten. Operative- und Komplexitätsrisiken müssen frühzeitigt erkannt, ausgeschaltet und eingegrenzt werden. Allgemein müssen Rahmenbedingungen für SOA festgelegt werden, mit denen die Ziele mit der eingesetzten Technologie effektiv und effizient ver-folgt werden müssen. Dabei werden drei Akteure unterschieden, den Serviceanwender, der Servicebetreiber und der Servicehersteller. Die Herausforderungen einer SOA-Governance unterscheiden sich nicht gravierend von der einer IT-Governance. Dafür werden diese spezifischer. Bei der Implementierung und Umsetzung der Servicekompo-nentenstrategie, müssen die eingesetzten Ressourcen, überwacht, gemessen und opti-miert werden. Die mit SOA zusammenhängenden Risiken sind zu identifizieren und mit der Risikobereitschaft des Unternehmens abzugleichen. Es müssen Mitarbeiter für das IT-Risikomanagement zuständig sein. Die Wertbeiträge der Servicekomponenten unter Berücksichtig unterschiedlicher Sourcing-Optionen ist kontinuierlich zu überprüfen. Ein strategischer Business-IT-Alignment ist notwendig, um die Erstellung und Verwendung von Servicekomponenten gegenseitig abzustimmen. Der SOA-Governance werden zwei weitere Aufgabenbereiche zugeordnet. Die SOA-Conformance und das SOA-Lifecycle-Management. Die SOA-Conformance beschäftigt sich mit der Analyse des Unterneh-mens, inwiefern dieses auf SOA organisatorisch, prozessual und technisch vorbereitet ist. Defizite auf Seiten des Unternehmens müssen geschlossen werden. Das SOA-Life-cycle-Management soll den gesamten Lebenszyklus der Servicekomponenten wie z. B. strategischem Alignment, Wertbeitrag, Ressourcenmanagement, Risikomanagement und das Performance-Management kontrollieren (Johannsen und Goeken 2007, S. 273-282). Nach Barros und Dumas (2006, S. 1 ff.) greifen mehr Unternehmen das Konzept von SOA auf. Dies ist auf die Entwicklung von Web-Service-Infrastrukturen zurückzu-führen.
SOA ist eine neue Art von Business-IT-Alignment. Ein Hauptziel von SOA ist die Annä-herung von Fachabteilungen mit der IT-Abteilung. Die IT soll mit SOA effizienter und effektiver bestehende Dienstleistungen und Prozesse des Unternehmens unterstützen. Abhängig von der Unternehmensgrößte und IT-Organisation, muss ein eigenes Gremium für diese Aufgabe eingerichtet werden. Dabei ist zu beachten, dass im Gremium neben IT-Architekten auch Mitarbeiter von Fachabteilungen vertreten sind. Im Vordergrund für die IT-Organisation stehen dabei Architekturentscheidungen und die Festlegung von Standards und Technologien. Es muss sichergestellt werden, dass nur Services in den Betrieb genommen werden, die die internen Sicherheitsregeln als auch die Datenschutz-rechtlichen Standards erfüllen. Eine weitere Aufgabe ist die Abbildung von Abhängig-keitsbeziehungen von Services, falls es zu Störungen im Betrieb kommt. Es muss si-chergestellt werden, welcher Service für welchen Ausfall zuständig ist. Daneben muss zu jedem Service sein zugehöriger SLAs angegeben sein (Tilkov und Starke 2007, S. 14 ff.). Nach Manvi et al. (2014, S. 425) ist IaaS eine neue Art bereits vorhandene Tech-nologien zu liefern. Die IT-Organisation kann sich die Vorteile von IaaS zu Nutze machen um sich auf eine SOA-Governance vorbereiten.
Cloud-Computing-Governance
Cloud Computing stellt eine IT-Governance Herausforderung dar. Die Autoren Johann-sen und Goeken (2011, S. 280 ff.) schreiben von einer Cloud-Computing-Governance, welches auch als Überschrift für dieses Kapitel genommen wird.
Eine SOA-Governance kann auch ohne Cloud Computing stattfinden. Unternehmen die bereits eine SOA-Governance aufgebaut haben, müssen sich ebenfalls den Herausfor-derungen von IaaS stellen. Die Governance-Anforderungen an die SOA und an die Cloud, haben Gemeinsamkeiten aber auch Unterschiede. Deswegen muss die IT-Orga-nisation sich an die neuen Bedingungen anpassen (Kobielus 2009, o. S.). Die Autoren Johannsen und Goeken (2011, S. 288) zitieren Boss et al. (2007), dass Cloud Computing als eine Weiterentwicklung von SOA hin zu mehr oder weniger offenen und nutzbaren Serviceplattformen interpretiert werden kann. Kobielus (2009, o. S.) schreibt weiter, das die Komplexität der gesamten SOA-Governance mit Cloud Computing steigt. Aus der Sicht von SOA-Experten können Cloud-Produkte zu nicht dokumentierten, nicht un-terstützten und zu Nicht-Standard Anwendungen führen. Auf der anderen Seite wird Cloud Computing als die beste Chance gesehen, welche einer SOA-Governance passie-ren konnte. Erst durch Cloud Computing wird Governance allgemein, zu einem kritischen Thema im Unternehmen. Wird die Cloud zusammen mit SOA eingeführt, wird dies zu einem nicht wenigen Komplexen Thema für die IT-Organisation.
Das Unternehmen hat sich dafür Entschieden IaaS einzuführen, nun müssen die be-troffenen Geschäftsobjekte und Risiken identifiziert werden. Eine Hauptproblematik die Beachtet werden muss, ist das Verhaltend er IT-Organisation, wenn der Service auf Seiten des IaaS-Anbieters unterbrochen wird. Im Kapitel 3.1 wurden vier verschiedene Betriebsmodelle der Cloud vorgestellt: Private-, Community-, Public- und Hybrid-Cloud.
Die IT-Organisation muss entscheiden, welches der vier Betriebsmodelle sich am ide-alsten für das Unternehmen eignet. Jedes Betriebsmodell weißt unterschiedliche Risiken auf. Im Vergleich zu den anderen Betriebsmodellen, weißt die Private-Cloud das ge-ringste Risiko auf. Als Nachteil wird die schwächere Skalierung und Agilität im Vergleich zur Public-Cloud genannt. Die Community-Cloud hat zusätzlich zu den genannten Ei-genschaften der Private-Cloud das Problem, dass Daten mit anderen Unternehmensda-ten zusammengelegt werden. Die Public-Cloud hat zusätzlich zu den Community-Cloud Risiken das Problem, dass der Standort der Daten unbekannt ist und es Schwierigkeiten beim Abruf der Daten geben kann. Die Hybrid-Cloud ist eine Kombination aus mindes-tens zwei der vorgestellten Cloud-Betriebsmodelle. Entscheidet sich das Unternehmen für eine Hybrid-Cloud, müssen die Risiken der einzelnen Betriebsmodelle summiert wer-den. Die IT-Organisation muss die Aufgabenbereiche des Risikomanagements um die unterschiedlichen Betriebsmodelle der Cloud erweitern. Es muss sichergestellt werden, dass Daten des Unternehmens verfügbar und sicher abgelegt sind. Es wird Empfohlen einen Information Security Officer einzustellen, der sich auf dieses Themengebiet spe-zialisiert. Die Unternehmensrichtlinien müssen im Kontext von Cloud-Computing ange-passt werden (ISACA 2009, S. 4-7).
Sicherheits- und Datenschutzbedenken sind die häufigsten Ursachen, die eine Nutzung von IaaS verzögern. Dazu gehören Fragen zur Vertraulichkeit und Integrität der Daten sowie Einhaltung von Compliance- und Datenschutzbestimmungen. Diese hängen wie-derum von der Art und Nutzung von Cloud Services ab. Die IT-Organisation hat zur Aufgabe, die beschriebenen Risiken im Unternehmen zu identifizieren und zu kontrollie-ren. Die Thematik über Risiken von Cloud Services werden auch in Studien von Bitkom, EuroCloud, ENISA, Cloud Security Alliance (CSA) und vom Bundesamt für Sicherheit in der Informationstechnik (BSI) behandelt (Höllwarth 2012, S. 91-92).
Der Information Security Officer muss mögliche Risiken analysieren, bewerten und der Unternehmensleitung mitteilen. Inwiefern dies der Information Security Officer über-nimmt, muss die IT-Governance bestimmen. Typische Aufgaben der IT-Governance ist es Ziele zu setzen, Richtlinien zu bestimmen, neue Rollen definieren und Verantwortun-gen festzulegen. Durch den Einsatz von IaaS müssen drei Akteure koordiniert werden. Dies involviert den IaaS-Anbieter, die IT-Organisation und das Unternehmen bzw. die Fachabteilungen. IaaS liefert eine Chance, die IT-Sicherheitsvorkehrungen des Unter-nehmens zu überdenken und neu zu gestalten. Eine der ersten Aufgaben für die IT-Organisation, ist nicht nur das Business-IT-Alignment neu auszurichten, sondern es muss auch die Organisation des IaaS-Anbieters verstehen. Dazu gehört das Verständnis über die internen Ablaufprozesse des IaaS-Anbieters, die Richtlinien, die Kultur und wie die IT-Architektur bei ihm aufgebaut ist. Der IaaS Anbieter muss sorgfältig ausgewählt wählen. Eine Recherche über die vergangenen Erfolge, Reputation und Nachhaltigkeit, helfen bei der Wahl eines IaaS Anbieters. Nachhaltigkeit bedeutet in diesem Kontext, dass der Zugriff auf Daten des Unternehmens, auch in Zukunft, sicher und verfügbar sein muss. Die Verwaltung von SLAs ist eine Kernaufgabe die sich an Organisation des IT-Managements richtet. Die IT-Organisation muss mit SLAs alle Risiken die durch IaaS entstehen, an den IaaS-Anbieter übertragen. Business Continuity und Disaster Recovery sind wichtige Themen die mit dem IaaS-Anbieter besprochen werden müssen. Diese müssen ausreichend dokumentiert und getestet werden. Der IaaS-Anbieter muss seine Rolle verstehen, dass es zu Problemen und Ausfällen der Services kommen kann. Das Verhalten der einzelnen Teilnehmer muss in Verträgen festgelegt werden. Dabei darf es zu keinen Interpretationen kommen (ISACA 2009, S. 4-9).
In SLAs wird auf Key-Performance-Indikatoren (KPI) Bezug genommen. Diese können sich auf die Verfügbarkeit, Bandbreite, Durchsatz, Latenzraten, Paketverluste, Auslas-tung beziehen. Die Ressourcenverteilung über das Netzwerk nimmt eine besondere Rolle ein und muss mit KPI gemessen werden (Höllwarth 2012, S. 87).
Business Continuity bzw. das Business Continuity Management wird von der Internati-onal Organization for Standardization (ISO 2012, o. S.) definiert als: „ISO 22301:2012 specifies requirements to plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system to protect against, reduce the likelihood of occurrence, prepare for, respond to, and recover from disruptive in-cidents when they arise“. Rouse (2016, o. S.) beschreibt Business Continuity als die Fähigkeit eines Unternehmens, essentielle Funktionen, während und nach einem Ausfall von IT-Systemen, aufrechtzuerhalten.
Wie der Titel der Bachelorarbeit dies verdeutlicht, sollen diese Herausforderungen her-ausgearbeitet werden. Jede Organisation muss für sich selbst entscheiden, wie diese gelöst werden. Ziel der Arbeit ist es Herausforderungen mit denen das Unternehmen konfrontiert ist herauszuarbeiten. Eine Herausforderung kann eine Chance oder Risiko sein. Welche Personen diese Probleme im Unternehmen bzw. in der IT-Organisation lösen, ist Angelegenheit des Unternehmens. Das Unternehmen muss zusammen mit der IT-Organisation entscheiden, ob hierfür spezielle Rollen oder Gremien zu bilden sind. Das Business-IT-Alignment ist letztlich für den Einfluss und die Rolle der IT-Organisation im Unternehmen verantwortlich.
Nach Johannsen und Goeken (2011, S. 297) steht die IT-Organisation vor größeren Herausforderungen was die SOA-Governance in Bezug auf Cloud Computing betrifft. Die Anforderungen werden zwar verstanden aber nur zu einem geringen Teil von IT-Orga-nisationen bewältigt. Cloud-Computing-Governance wird zu einem notwendigen Thema
für die IT-Organisation. Dies ist darauf begründet, dass die zunehmende Virtualisierung der IT nicht aufzuhalten sei.
Die IT-Organisation wird von Cloud Computing beeinflusst. Durch den Einfluss von Cloud-Lösungen wie IaaS muss die IT-Organisation zwei Kriterien berücksichtigen. Das Personal der IT-Organisation muss sich neue Fähigkeiten aneignen, um mit Hilfe von IaaS Geschäftsprobleme zu lösen. Das zweite Kriterium stellt die Frage, wie sich die Rolle der IT durch den Einsatz einer neuen Technologie verändert. Die Rolle der IT hat sich nicht zum ersten Mal verändert. Abhängig davon wie schnell sich die IT-Organisa-tion mit der neuen Rolle im Unternehmen identifiziert, desto schneller werden ausge-reiftere Service-Lösungen geliefert (Avram 2014, S. 533).
Beachtung von Gesetzen und Regulierung
Die IT-Compliance ist zuständig für die Einhaltung von Gesetzen, Regulierungen und Standards. Datenschutzrichtlinien können unterschiedlich von Ländern gehandhabt wer-den. Was in einem Land erlaubt ist, muss nicht zwangsläufig für ein anderes Land zu-treffen. Dies ist vor allem beim Cloud Computing der Fall, wenn staatliche Institutionen Interesse an den Daten eines Unternehmens haben. Die Daten eines Unternehmens werden in der Cloud gespeichert, wichtiger ist jedoch der physische Standort der Daten. Einige Cloud-Dienstleister halten sich das Recht vor, Informationen vor Behörden zu-rückzuhalten (ISACA 2009, S. 8-9). IT-Compliance steht im engen Zusammenhang zur IT-Governance und dem IT-Risikomanagement (Klotz und Dorn 2008, o. S.). Umso schwieriger erweist sich eine strikte Trennung der einzelnen Kapitel. In Anlehnung an das Kapitel 2.2 Abbildung 4, wo das IT-Management Modell von Hofmann und Schmidt (2010, S. 3) vorgestellt wurde, umschließt die IT-Governance die Aufgabenfelder des IT-Managements und bildet somit das Rahmenwerk. Daher ist es unausweichlich, dass sich die Aufgabenfelder der IT-Managements, zu einem geringen Anteil mit der IT-Governance überschneiden.
Nach Chaput und Ringwood (2010, S. 241-253) muss eine Information Security Orga-nization etabliert werden. Hierbei wird nicht mehr von der IT-Organisation geschrieben. Dieser Information Security Organization muss ein Jurist zugewiesen werden, der sich auf IT-Recht spezialisiert. Ein Unternehmen wird geografisch an ein Land und dessen Datenschutzgesetze gebunden. Hat ein Unternehmen mehrere Standorte müssen wei-tere Landesgesetze mitberücksichtigt werden. Dies ist auch für den Standort des IaaS-Anbieters der Fall. Der IaaS-Anbieter stellt die Server bereit, die sich wiederum redun
dant an mehreren Orten befinden. Dazu existieren Abkommen, welche über die Landes-grenzen hinausgehen, dies ist z.B. für das US-EU Safe Harbor Abkommen der Fall. Die Information Security Organization hat zur Aufgabe, die relevanten Gesetze und Regu-lierung zu identifizieren, die für das Unternehmen von Bedeutung sind. Darüber hinaus muss im Vertrag festgelegt werden, wer der Eigentümer der Unternehmensdaten ist. Neben technischen Angelegenheiten müssen auch Bedingungen zur Vertragskündigung festgelegt werden. Es stellt sich die Frage, warum beschäftigt sich die IT-Organisation mit vertraglichen und rechtlichen Angelegenheiten? Spätestens wenn der IaaS Anbieter zur Vertragskündigung die Daten und Informationen in einem Nicht-Standardformat ab-liefert, betrifft es die IT-Organisation. In einem Worst-Case-Szenario können die Daten für die IT-Organisation unleserlich sein. Deswegen muss die IT-Organisation sich recht-zeitig mit Vertragsregulierung beschäftigen. Ergänzend empfehlen die Autoren, dass sich die IT-Organisation mit dem Organizational Security Maturity Model befasst. Emp-fohlen für Cloud-Lösungen wird das Sicherheitslevel 4.
Nach einer Literaturrecherche zum Security Maturity Model wurden mehrere Modelle gefunden. Zwei Modelle zum Security Maturity Model werden kurz vorgestellt. Das erste Modell von NIST (2014, o. S.) beinhaltet fünf aufeinander bauende Security Level: 1. Policies, 2. Procedures, 3. Implementation, 4. Test und 5. Integration. Nach dem Modell von Acohido (2015, S. 5-6) sind ebenfalls fünf Security Level erreichbar, die sich jedoch von der Bezeichnung unterscheiden: Initial, Developing, Defined, Managed und Optimi-zing. Es ist nicht eindeutig erkennbar, auf welches Security Maturity Model sich Chaput und Ringwood (2010, S. 242) beziehen. Wichtiger ist jedoch die Tatsache, dass die Organisation des IT-Managements, den Reifegrad der IT-Sicherheit nach einem Security Maturity Model feststellen kann. Die Erreichung eines hohen Levels im Security Maturity Model ist eine Herausforderung, die mit IaaS verbunden ist.
Nach Krcmar (2015, S. 735-736) müssen die Verantwortlichkeiten zwischen den Akteu-ren neu geregelt werden. Der IaaS-Anbieter ist für die Wartung und den Betrieb des Rechenzentrums verantwortlich. Ebenso liegt es in der Verantwortung des IaaS-Anbie-ters für die Rahmenbedingungen zum Datenschutz und zur Datensicherheit zu sorgen. Der Anwender der Leistung hingegen ist lediglich für den Inhalt und die Datenverarbei-tung zuständig. Die Zuständigkeiten und Aufgabenfelder werden über SLAs festgelegt.
Der Autor Höllwarth (2012, S. 113-128) hingegen ist der Meinung, dass der Cloud-Kunde letztlich verantwortlich ist, für die Einhaltung der für ihn geltenden Datenschutz-bestimmungen. Der Cloud-Anbieter kann zwar mit in die Pflicht genommen werden und wird sich bei der Erstellung von SLAs kooperativ verhalten. Die eigentliche Verantwor-tung für die Einhaltung der Datenschutzbestimmungen obliegt dem Cloud-Kunden und somit der IT-Organisation. Die Organisation des IT-Managements muss sich intensiv mit dem IT- und Vertragsrecht beschäftigen. Weitere Aufgabenfelder womit sich die IT-Compliance beschäftigt, werden im weiterem vorgestellt. Ein mögliches Risiko, welches im Vertrag berücksichtigt werden muss, ist der sogenannte Vendor Lock-in. Angenom-men die IT-Organisation entscheidet sich zu Beginn für einen bestimmten IaaS-Anbie-ter. Nach einer bestimmten Zeit möchte der IaaS-Anwender nun Services von anderen IaaS-Anbietern erhalten oder einen Wechsel des IaaS-Anbieters durchführen. Für den Fall, dass der IaaS-Anbieter gewechselt werden soll, genügt es nicht den Vertrag zu beenden. Dabei müssen die Daten von einem Anbieter zu einem anderen Anbieter trans-feriert werden. Dieser Prozess wird als Migration bezeichnet. Zusätzlich zur Datenüber-tragung muss die Funktionalität und Nutzbarkeit der übertragenen Daten gewährleistet sein. Werden mehrere Services von unterschiedlichen IaaS-Anbietern bezogen, so kann es ebenfalls zu einem Vendor Lock-in kommen. Durch die Koppelung von mehreren Anbietern, müssen die Produkte stark aufeinander abgestimmt werden. Als Konsequenz kann ein neuer Anbieter nicht ohne weiteres hinzugefügt werden. Dieses Risiko kann durch eine effektive Vertragsgestaltung, der IT-Compliance, beseitigt oder zumindest vermindert werden.
Nach der Aussage von Krcmar (2015, S. 735-736) ist der IaaS-Anbieter für den Daten-schutz und die Datensicherheit verantwortlich. Wird diese Aussage mit der von Höllwarth (2012, S. 113) verglichen, so tritt ein Konflikt auf. Höllwarth (2012, S. 113) schreibt: „Der Kunde wird stets versuchen, den Cloud-Anbieter für die Einhaltung der Daten-schutzbestimmungen mit in die Pflicht zu nehmen. Der Kunde bleibt jedoch auch dann in der Verantwortung, wenn der Cloud-Anbieter ihm die gewünschten Zusicherungen macht“. Folglich ist dies ein ernstzunehmender Widerspruch. Dieser muss in Absprache mit dem IT-Risikomanagement und der IT-Compliance gelöst werden.
Zur Reduzierung von IT-Sicherheit und –Compliance Risiken sollte sich die IT-Organisa-tion hinaus, über freiwillige Zertifizierungen zu ISO 27001, COBIT oder ITIL erkundigen (Bachmann 2016, o. S.).
Klassifizierung von Daten
Im Rahmen der IT-Sicherheit muss sich die IT-Organisation mit der Klassifizierung ihrer Daten befassen. Durch die Klassifizierung von Daten soll entschieden werden, welche Daten in die Cloud übertragen werden und welche nicht. Die Klassifizierung legt eben-falls die Sicherheitsbedingungen für die Daten fest (Chaput und Ringwood 2010, S. 245-246). Sind die Daten eines Unternehmens nach der Wichtigkeit sortiert, können Kate-gorie spezifische SLAs erstellt werden (ISACA 2010, S. 8). Daten bzw. Informationen werden in sechs verschiedene Kategorien unterteilt: Public, Personal, Proprietary, Con-fidential, Secret und Top Secret. Das Speichern von Daten in der Cloud ist nicht für alle Kategorien empfohlen. Daten der Kategorie Secret und Top-Secret dürfen nicht beim IaaS-Anbieter abgelegt werden. Die Beurteilung, was in solchen Situationen passieren soll, muss das IT-Risikomanagement beantworten (Onwubiko 2010, S. 277-278).
Nach der Datenklassifizierung muss die IT-Organisation entscheiden, wie der Zugriff auf die Daten erfolgt. Authentifizierungskontrollen werden von der IT-Organisation oder vom IaaS-Anbieter durchgeführt. Dabei muss die Verantwortung geklärt werden, wer die Systeme verwaltet und wer die Logdateien untersucht. Beide Varianten haben ihre Vor- und Nachteile. IT-Organisation muss ein Wissen über die dadurch entstehenden Risiken und eingesetzten Technologien aufbauen, unabhängig davon wie diese sich ent-scheidet. Auch müssen bestimmte Fragen geklärt werden. Übernimmt der IaaS-Anbieter die Authentifizierungskontrollen oder muss die IT-Organisation ein Security Information and Event Monitoring (SIEM) einführen. Wird SIEM vom IaaS-Anbieter verwendet, muss überprüft werden, wie wirtschaftlich und zuverlässig diese Entscheidung ist (Chaput und Ringwood 2010, S. 247-248). SIEM ist Bestandteil der IT-Sicherheit und dient dazu sicherheitsrelevante Ereignisse zu identifizieren, zu bewerten und leitende Mitarbeiter über Vorfälle zu informieren. Dabei ist die Effizienz bei SIEM-Systemen, wie schnell si-cherheitsrelevante Vorfälle gefunden werden, besonders wichtig (Sprotte und Augsten 2013, o. S.).
Die Protokollierung aller Zugriffe und Aktivitäten ist eine wichtige Aufgabe bei der Nut-zung von Speicherdiensten. Diese Vorkehrungen sollen vor möglichen Angriffen und er-laubten Zugriffen schützen. Durch die Auswertung der Protokolle kann festgestellt wer-den, ob z.B. der Zugriff auf die Daten zu einer ungewöhnlichen Uhrzeit erfolgt ist. Die IT-Organisation darf sich nicht nur als Kunde von IaaS-Leistungen positionieren und Verantwortungen über SLAs an den IaaS-Anbieter übertragen. Vielmehr muss ein tech-nisches Verständnis über Technologie, die genutzt wird, selbst aufgebaut werden. Die IT-Organisation muss sich darüber informieren, wie die Verschlüsselung (z. B. SSH, IP-Sec, TLS/SSL, VPN) der Daten beim Transport zum IaaS-Anbieter und zwischen den Cloud-Rechenzentren erfolgt (Höllwarth 2012, S. 94-94).
Der Umgang mit der Schatten-IT
Dieses Kapitel kann ebenfalls als ein Bestandteil der IT-Governance Maßnahmen gese-hen werden, es wird jedoch aus Übersichtsgründen und wegen der besonderen Stellung für das IT-Management als eigenständiges Unterkapitel behandelt. Wie bereits zur IT-Compliance erwähnt, ist es schwierig eine klare Abgrenzung von anderen Teilbereichen des IT-Managements zu vollziehen.
Der Paradigmenwechsel, der durch IaaS eingeleitet wird, zwingt die IT-Organisation sich neuen und einzigartigen Herausforderungen entgegenzustellen. Durch die Nutzung von Cloud-Lösungen können Fachabteilungen die IT-Organisation übergehen und direkt Leistungen vom IaaS-Anbieter beziehen. Diese Vorgehensweise war vor IaaS nicht mög-lich, da Fachabteilungen sich mit der IT-Organisation abstimmen mussten, welche Hard- und Software benötigt werden (ISACA 2009, S. 8-9). Im Kapitel 3.2 zum IaaS Ser-vicemodell wurde in Abbildung 11 ein Modell präsentiert, wie Endanwender mit dem IaaS-Anbieter in Kontakt treten und virtuelle Maschinen für ihre Zwecke bereitstellen. Die Autoren Sushil et al. (2010, S. 62) verwenden hierbei explizit den Begriff „Software Owner“. Das Modell von Sushil et at (2010, S. 62) wurde für die Arbeit leicht angepasst. Die Bereitstellung von Anwendungen sollte über die IT-Organisation erfolgen und nicht wie im Original-Modell nur vom „Software Owner“. Nach ISACA (2009, S. 8-9) wird auf dieses Risiko Bezug genommen, dass Mitarbeiter ohne Abstimmung mit der IT-Abteilung neue Dienstleistungen beantragen. Dadurch müssen Sicherheitsrichtlinien und die Ver-antwortungen im Rahmen der IT-Governance neu definiert werden, um ein solches Vor-gehen von Fachabteilungen zu verhindern.
Das Ergebnis eines solchen Vorgehens, wenn Fachabteilungen ohne die IT-Abteilung entscheiden, nennt sich Schatten-IT. Die Autoren von CIO.de (o. J., o. S.) liefern eine prägnante Definition zur Schatten-IT:
„Mit dem Begriff „Schatten-IT“ werden informationstechnische Systeme beschrieben, welche als Zweitsysteme in Fachabteilungen existieren. Die Schatten-IT umfasst infor-mationstechnische Organisationseinheiten, Prozesse und Systeme, welche neben der offiziellen IT-Infrastruktur angesiedelt sind und oftmals nur einen begrenzten Personen-kreis zugänglich sind. Die IT-Instanzen sind zumeist strategisch und technisch von den herkömmlichen IT-Einheiten abgegrenzt und zur Kommunikation von vertraulichen In-formationen gedacht. Eine zu geringe Ausstattung mit IT-Möglichkeiten führt in größe-ren Betrieben regelmäßig zur selbstständigen Bildung von IT-Systemen in kleineren Ar-beitsgruppen.“
Nach einer IT-Studie von Capgemini (2016, S. 10-11) befürchten Unternehmen das Schatten-IT weiter an Einfluss gewinnt. Durch eine Schatten-IT würden beispielsweise Standardisierungs- und Automatisierungsmaßnahmen der IT-Organisation unnötig er-schwert werden. Dabei ist der Faktor „Zeit“ für die Bildung einer Schatten-IT im Unter-nehmen maßgeblich beteiligt. Die Problematik besteht darin das die IT-Organisation die Release-Zyklen im Unternehmen verkürzt hat, diese aber den Fachabteilungen immer noch zu langsam sind. Als Konsequenz beantragen Fachabteilungen externe Dienstleis-ter mit ihren Projekten.
Tabelle 1: Gründe für die IT-Ausgaben der Fachabteilungen
Quelle: Capgemini (2016, S. 11)
Tabelle 2: Die Verwaltung des IT-Budgets durch die Fachabteilung
Eine Schatten-IT kann dadurch verhindert werden, dass die Richtlinien der Governance angepasst werden (ISACA 2009, S. 8-9) oder dass der CIO die Kontrolle über das IT-Budget besitzt (Capgemini 2016, S. 10-11).
Die Autoren Hoberg et al. (2012, S. 296-297) bestätigen, dass durch die zunehmende Verbreitung von Cloud Services, es für Fachabteilungen leichter geworden ist, IT-Inves-titionen ohne das Wissen des zuständigen IT-Bereichs durchzuführen. Für die Bereit-stellung eines Cloud Services ist lediglich eine Kreditkarte und minimale Kommunikation mit dem IaaS-Anbieter notwendig geworden. Der Grund ist eine fehlende Abstimmung zwischen der IT-Abteilung und den Fachbereichen. Eine unzureichende Reaktionsge-schwindigkeit auf Seiten der IT, wenn es um die Bereitstellung neuer Software- und Hardwarelösungen geht, verleitet die Fachbereiche zu externen Lösungen und somit zu einer Schatten-IT. Die Risiken, die mit einer Schatten-IT verbunden sind, reichen von unkalkulierbaren Risiken in Bezug auf die Datensicherheit und den Datenschutz über das Entstehen von Datensilos bis hin zur Verletzung von Compliance-Regeln. Parallel zur Verhinderung einer Schatten-IT muss die IT-Organisation für die zielgerichtete In-tegration und Nutzung von Cloud Services im Unternehmen sorgen.
Während der Literaturrecherche ist aufgefallen, dass die Bezeichnung „Rogue Clouds“ ähnlich behandelt wird wie der Begriff der Schatten-IT. Dabei benutzen Mitarbeiter Spei-cherlösungen wie Dropbox für sensible Daten, ohne die IT-Organisation darüber zu in-formieren (Butters 2013, o. S.). Die Problematik soll anhand des folgenden Szenarios veranschaulicht werden. Der Mitarbeiter einer Fachabteilung nutzt einen externen Spei-cherdienst wie zum Beispiel Dropbox. Nach einer bestimmten Anzahl an Jahren verlässt der Mitarbeiter das Unternehmen und hat dennoch Zugriff auf die sensiblen Daten des Unternehmens (Taylor 2013, o. S.).
Die Schatten-IT wird hinsichtlich Compliance-, Sicherheits- und Architekturanforderun-gen als problematisch gesehen. Auf der anderen Seite bietet sie dem Unternehmen In-novationsmöglichkeiten die aufgrund einer trägen IT-Organisation nicht möglich wären (Ahlemann und Urbach 2016, S. 31). Die Autoren Ahlemann und Urbach (2016, S. 31) schließen mit folgendem Zitat ab: „IT-Innovationen entstehen idealerweise dort, wo sie später auch zum Einsatz kommen – in den Fachabteilungen“.
Das Kapitel 4.6 zur Schatten-IT ist schwierig einzuschätzen. Nach ISACA (2009, S. 8-9) und Hoberg et al. (2012, S. 296-297) stellt Schatten-IT ein Problem für die IT-Gover-nance dar. Beachtet man hingegen Tabelle 1 über die IT-Ausgaben der Fachabteilungen von Capgemini (2016, S. 11) so befindet sich auf Position 3 die „IT kann nicht zeitnah liefern“. Interessant ist auch die Position 1 aus Tabelle 1 das die Verantwortung für die IT-Ausgaben auf Fachabteilungen übertragen wird. Dies deckt sich soweit mit der Aussage von Ahlemann und Urbach (2016, S. 31) das Fachabteilungen selbstständiger wer-den durch Sourcing-Möglichkeiten der Cloud. Letztlich bleibt die Schatten-IT ein span-nendes Thema und eine Herausforderung für die IT-Organisation. Durch die Erkennt-nisse von Capgemini (2016, S. 11) und Ahlemann und Urbach (2016, S. 31) wird es schwierig sein die Schatten-IT zu verhindern, was gleichzeitig bedeuten würde, Innova-tionen im Unternehmen zu verhindern. Vielmehr müssen beide Bereiche intensiver zu-sammenarbeiten.
Wirtschaftlichkeitsbetrachtung
Als einer der Vorteile von IaaS wird das „pay-as-u-go“ Vertragsmodell genannt. Der Kunde bezahlt dabei nur für die in Anspruch genommene Leistung (Sushil et al. 2010, S. 60-63).
Was zu Beginn als Vorteil erschienen ist, stellt das IT-Controlling vor größere Heraus-forderungen. Bei einer traditionellen IT-Landschaft wurde überwiegend mit Fix-Kosten gerechnet. Durch das dynamische Vertragsmodell hingegen wird die Kostenplanung er-schwert, zwar ergibt sich durch das variable Kostenmodell des Cloud Computing mehr Flexibilität aber auch ein größeres Planungsrisiko. Die Problematik besteht darin das selbst IT-Experten nur schwer abschätzen können, wie viel Speicher bzw. wie viele Da-tenbankabfragen für eine Anwendung nötig sind. Hier müssen sich zuerst, abhängig vom Anwendungsfall, Erfahrungswerte mit dem „pay-as-you-go“ Vertragsmodell entwi-ckeln. Diese Werte liefern im Anschluss eine verlässliche Grundlage für das IT-Control-ling (Hoberg et al. 2012, S. 299).
Der vorherige Abschnitt hat verdeutlicht das anstelle von Fixkosten nun variable Kosten durch IaaS im Vordergrund stehen. Ein variables Kostenmodell hat somit seine Vor- und Nachteile. Nach einer Studie zum IT-Budget vom Capgemini 2016, wo 93 Unternehmen im Jahr 2016 und 124 im Jahr 2015 befragt worden sind, steigen die IT-Ausgaben für Betrieb, Wartung und Pflege der Hardware von 40,5 % auf 46,3 % zum Vorjahr an. Das IT-Budget für Betrieb, Wartung und Pflege nimmt Verhältnismäßig den größten der Kos-ten ein (s. Tabelle 3). Allgemein sind die Kosten für Hardware weiter gestiegen wobei die Kosten für Software-Produkte gefallen sind (Capgemini 2016, S. 10-11). Unter der Bachtung der Aussage von Krcmar (2015, S. 735-736) ist der IaaS-Anbieter für die Wartung der und den Betrieb des Rechenzentrums verantwortlich.
Tabelle 3: Verwendung des IT-Budgets
Nun stellt sich die Frage, inwiefern IaaS-Lösungen die Kosten für Wartung und Pflege der Hardware im Unternehmen reduziert. Auf der anderen Seite müssen wegen IaaS die IT-Governance Maßnahmen (Johannsen und Goeken 2011, S. 280 ff.) und die IT-Si-cherheitsvorkehrungen (ISACA 2009, S. 4-9) angepasst werden. Dies stellt das Unter-nehmen zwar ebenfalls vor Herausforderungen, die Frage ist jedoch, ob es sich um einmalig hohe initial Kosten handelt, welche mit der Zeit abnehmen.
Ein weiteres Problem für das IT-Controlling stellt der „Economic Denial of Service“ dar. Dabei werden durch externe Angreifer künstlich generierte Systemanfragen erstellt, die das variable Kostenmodell ausnutzen und somit das Unternehmen zu einem wirtschaft-lichen Schaden führen (Hoberg et al. 2012, S. 299). Die Aufgabe der IT-Organisation ist die Identifizierung solcher Economic Denial of Service Angriffe und das Verständnis, dass solche Angriffs-Möglichkeiten die Kosten von IaaS erhöhen.
Der folgende Abschnitt soll kurz den Begriff des Denial of Service (DoS) vorstellen. Der Angreifer sendet dabei eine hohe Anzahl von Anfragen (Requests) gegen den Server, da der Server nur eine begrenzte Anzahl an Anfragen bearbeiten kann, wird dieser dadurch überlastet. Versucht nun ein Mitarbeiter auf einen Server oder eine Webseite zuzugreifen, so kann die Anfrage des Nutzers nicht bearbeitet werden (McDowell 2009, o. S.). Der Economic Denial of Service wird von den Autoren VivinSander und Shenai (2012, S. 2-3) als Economic Denail of Sustainability (EDoS) bezeichnet. Der EDoS-An-griff wird als Cloud spezifisch eingestuft, hierbei wird der Server nicht direkt überlastet, sondern die Kosten des variablen Vertragsmodells, werden durch eine hohe Anzahl an Anfragen in die Höhe getrieben.
Reorganisation der IT-Abteilung
Nach Sushil et al. (2010, S. 63) übernimmt der IaaS-Anbieter die Verantwortung für die Wartung und Pflege der IT-Infrastruktur. Der Autor Krcmar (2015, S. 735-736) bestätigt dies, dass der IaaS-Anbieter für den Betrieb und Wartung des Rechenzentrums verant-wortlich ist. Mit diesen Informationen wird die Abbildung 9 „IT in der Unternehmensar-chitektur“ von Hofmann und Schmidt (2010, S. 227), welche im Kapitel 2.4.4 vorgestellt wurde, angepasst.
Abbildung 12: IaaS in der Unternehmensarchitektur
Quelle: Eigene Darstellung, angelehnt an Hofmann und Schmidt (2010, S. 227)
Die Applikationsarchitektur ist weiterhin in der Kontrolle der IT-Organisation. Die IT-Architektur wird dabei an den IaaS-Anbieter ausgelagert. Als nächstes soll Abbildung 8 „Aufbauorganisation einer mittleren IT-Abteilung“ von Heilmann (1990, S. 696), welche im Kapitel 2.3.3 vorgestellt wurde, angepasst werden. Dabei sollen folgende Fragen beantwortet werden: Wie wirkt sich IaaS auf die IT-Organisation aus? Welche Aufgaben entfallen durch die Nutzung von IaaS? Welche neuen Aufgaben müssen der IT-Organi-sation durch IaaS hinzugefügt?
Diese Fragen sollen anhand von Modellen beantwortet und veranschaulicht werden. Da-bei werden die Informationen der vorherigen Kapitel berücksichtigt und zum Modell hin-zufügt oder entfernt. Durch die Betrachtung von Abbildung 8 (Heilmann 1990, S. 696) und den Erkenntnissen der beiden Autoren Krcmar (2015, S. 735-376) und Sushil et al. (2010, S. 63), die zu Beginn dieses Kapitels vorgestellt wurden, entfallen folgende Auf-gaben in Abbildung 8: „Systementwicklung und –wartung“, „Anwendungssystement-wicklung und –wartung“, „Rechenzentrum (Betrieb)“, „Arbeitsvorbereitung, Operation, Archiv und Materiallager“, „Eventuell: Zentrale Datenerfassung“. Die „Anwendungssoft-ware-auswahl und –einführung, Endbenutzerservice“ würde sich auf der Applikationsar-chitektur befinden und weiterhin Aufgabe der IT-Organisation sein.
Abbildung 13: Einfluss von IaaS auf die mittlere IT-Organisation
Quelle: Eigene Darstellung, angelehnt an: Heilmann (1990, S. 696)
Nach den Autoren Johannsen und Goeken (2011, S. 273-282) stellt Cloud Computing eine Herausforderung für die IT-Governance und SOA-Governance dar. Die Autoren von ISACA (2009, S. 9) schreiben im Bezug von IaaS von einem Paradigmenwechsel und das die IT-Sicherheitsvorkehrungen durch einen Information Security Officer überarbei-tet werden müssen. Ebenso müssen SLAs verwaltet und die IT-Compliance berücksich-tigt werden. Allgemein soll sich die IT-Organisation zu einer Information Security Orga-nization wandeln (Chaput und Ringwood 2010, S. 241-253). Zusätzlich fallen Heraus-forderungen im Bereich des IT-Controllings an (Hoberg et al. 2012, S. 299). Die ge-nannten Herausforderungen wurden in den vorherigen Kapiteln ausführlich behandelt und sollen nur als kurze Wiederholung dienen. Mit diesen Informationen wird die Abbil-dung 13 „Einfluss von IaaS auf die mittlere IT-Organisation“ angepasst.
Quelle: Eigene Darstellung
Dieses Modell übernimmt keine Gewährleistung für eine Vollständigkeit. Es soll vielmehr anhand der gefundenen Informationen zeigen, wie IaaS sich auf eine mittlere IT-Orga-nisation auswirkt. Durch die Nutzung von IaaS wird die IT-Organisation mit neuen Auf-gaben konfrontiert. Ein anderer Teil der Aufgaben hingegen entfällt und wird an den IaaS-Anbieter übertragen.
Ein wichtiger Aspekt wurde jedoch in diesem Modell und den vorherigen nicht berück-sichtigt, dass Daten der Kategorie „Secret“ und „Top Secret“ nicht in die Cloud übertra-gen werden (Onwubiko 2010, S. 277-278). Durch diese Problematik kann nicht die ge-samte IT-Infrastruktur an den IaaS-Anbieter übergeben werden. Es wurde für die Mo-delle in Abbildung 12, 13 und 14 die Annahme getroffen, dass ein vollkommener Fremd-bezug der IT-Infrastruktur erfolgt. Für den Fall, dass ein Unternehmen doch Daten der Kategorie „Secret“ oder „Top Secret“ besitzt, muss ein Teil der IT-Infrastruktur weiter-hin im Unternehmen bzw. in der IT-Organisation bleiben. Dies bedeutet das die IT-Organisation weiterhin für die Wartung und den Betrieb des Rechenzentrums zuständig bleibt. Jedoch in einem geringeren Ausmaß.
Nach Hoberg et al. (2012, S. 297) müssen Prozesse und Strukturen etabliert werden, um eine konsistente und architekturkonforme Integration der Services in die IT-Archi-tektur des Unternehmens zu ermöglichen. Für den Fall das dezentrale IT-Abteilungen verwendet werden, muss eine Abstimmung mit den Fachbereichen erfolgen. Somit stellt IaaS auch eine Herausforderung an das IT-Architekturmanagement dar.
Durch das IT-Architekturmanagements muss eine anpassungsfähige IT-Infrastruktur für das Unternehmen bereitgestellt werden, die einen fortlaufenden und zuverlässigen Be-trieb gewährleistet. Vor allem da die IT-Infrastruktur in mittleren und großen Unterneh-men organisch gewachsen ist, hat dies zu einer heterogenen IT-Architekturlandschaft geführt. Weitere Faktoren sind die unterschiedlichen Technologien (Clients, Server, Netzwerke, Betriebssysteme), Entwicklungsparadigmen und Werkzeuge die zu einer komplexen Architekturlandschaft geführt haben. Deswegen muss die IT-Organisation sich mit der Verwaltung zunehmend komplexeren IT-Infrastrukturen beschäftigen und eine strategische Planung der IT-Architekturen vornehmen. Gleichzeitig müssen auch höhere Erwartungen an SLAs und an die IT-Sicherheitsvorkehrungen gestellt werden (Tiemeyer 2009, o. S.).
Abhängig davon wie die Herausforderung von IaaS durch die jeweilige IT-Organisation im Unternehmen bewertet werden, treten unterschiedlich große Änderungen der IT-Organisationsstruktur auf. Auch die Größe der IT-Organisation ist Entscheidend für den Umfang der Umstrukturierung. In diesem Kapitel wurde dies Anhand einer mittleren IT-Organisation vorgestellt, welche auch im Grundlagen Kapitel vorgestellt wurde.
Recent Comments