Das Cross-Business-Architecture Lab definiert Enterprise Architecture Management neu Multicloud lässt sich mithilfe von EAM besser planen und managen

Für jedes Einsatzszenario der passende Cloud-Service, kein Vendor Lock-in, hohe Ausfallsicherheit bei bestmöglicher Performance – Unternehmen erkennen auf dem Weg der Digitalen Transformation die Vorteile heterogener Cloud-Umgebungen. Ein Whitepaper des Cross-Business-Architecture Lab (CBA Lab) klärt darüber auf, wie sich mit Hilfe von EAM solche Umgebungen planen und managen lassen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

Cloud-Einführungen werden oft von einem Paradigmenwechsel begleitet: Statt langfristig festgelegter Zielarchitekturen werden diese bei iterativen Ansätzen während des Prozesses durch wachsende Erfahrungen angepasst. Klassische Projektorganisationen und Hierarchiestrukturen stoßen dabei an ihre Grenzen und erfordern eine Neuorganisation.

„In der Vergangenheit hat sich Enterprise Architecture darauf konzentriert, mit immer exakterer Planung Risiken einzudämmen. Aber der entscheidende Faktor für die Überlebensfähigkeit eines Unternehmens ist künftig nicht mehr Risikovermeidung, sondern die Anpassungsfähigkeit – und auch die braucht Leitplanken. Enterprise Architecture Management wird um Cloud Management erweitert und muss damit agiler werden. Es muss Ungewissheiten managen können“, erläutert Björn Oestrich, der die Cloud-Arbeitsgruppe innerhalb des CBA Lab leitete, in der das Whitepaper entstanden ist.

Dabei bleibt die eigentliche Kernaufgabe der Architekten unverändert: Die transparente Planung und Umsetzung der Geschäfts- und IT-Strategie mit einer entsprechenden Architektur.

Die Aspekte gehören berücksichtigt

Die folgenden Aspekte sind den Mitgliedsunternehmen im CBA Lab für die Entscheidung für einen Multi-Cloud-Ansatz wichtig. Die Relevanz dieser Aspekte und deren Gewichtung ist von der spezifischen Cloud-Strategie des jeweiligen Unternehmens abhängig.

1. Risikostreuung in Bezug auf

• Vendor Lock-in (bspw. durch Migrationsmöglichkeiten),

• Verfügbarkeitseinschränkungen,

• Compliance Einschränkungen, zum Beispiel wegen des Gerichtsorts des Cloud Service Providers (CSP),

2. Reaktionsfähigkeit in Bezug auf Kosten (nicht als strategischer Treiber),

3. Integrationsfähigkeit, Integrationskomplexität und Interoperabilität der Cloud-Dienste in die eigene Unternehmens-IT,

4. Quality of Service der CSP in Bezug auf

• Verfügbarkeit,

• Security,

• Compliance,

5. Support-Fähigkeit durch den CSP bezüglich

• Automatisierung und

• Unterstützung bei der Anbindung der Cloud an das Unternehmens-Netzwerk,

• Migration von Anwendungen in die Cloud und

• Anwendung und Integration von Cloud-Diensten,

• Verfügbarkeit von Cloud-Diensten in relevanten geografischen Regionen,

6. Support-Fähigkeit der eigenen Organisation im Unternehmen für bestimmte Technologien und Architekturen mit Relevanz für die Auswahl von CSP,

7.Feature-Portfolio, zum Beispiel:

• Innovative Cloud-Dienste, etwas für Künstliche Intelligenz, Internet of Things, Advanced Analytics,

• Transformationsunterstützung, beispielsweise für Migrationsdienste für Server und Datenbanken, Massendatentransfer,

• Security, so: Key Management, Auditierbarkeitsunterstützung und Angriffsabwehr,

8. Erweiterte Recruiting-Möglichkeiten durch das breitere Angebot bei Nutzung unterschiedlicher CSP,

9. Verfügbarkeit von Skills und einem Ökosystem für den CSP am Markt,

10. Reifegrad des CSP.

Auch wenn Multicloud die Verwendung von Cloud-Diensten ausgewählter unterschiedlicher Cloud Service Provider (CSP) bedeutet, sollte es bei der Planung zunächst nicht darum gehen, Anwendungen leicht verschieben zu können. Wichtiger ist die Möglichkeit, die Cloud-Dienste mit dem meisten Mehrwert für das Unternehmen aus dem Angebot ausgewählter CSP zu selektieren. Beispielsweise könnte eine digitale E-Commerce-Initiative eine Cloud-Plattform erfordern, die auf maximale Skalierbarkeit ausgelegt ist, während eine andere Analyse-intensive Arbeitslast in eine Cloud-Plattform verlegt wird, die speziell für die Nutzung großer Speicherpools entwickelt wurde.

Best of Breed

Der Vorteil dieses Multi-Cloud- oder Best of Breed-Ansatzes: Unternehmen nutzen die Innovationskraft des Providers und verteilen gleichzeitig ihr Risiko. Allerdings sollte die Entscheidung für den Einsatz von mehreren Providern niemals aus einem Projekt heraus getroffen werden. „Projektbezogene Entscheidungen führen dazu, dass keine ordentliche Einbindung des CSP in die notwendigen Cloud-Management-Prozesse erfolgt und damit ein unkontrollierter Teil der Unternehmens-IT geschaffen wird“, so Oestrich.

Multi-Cloud-Umgebungen haben ihre Tücken: Sie betreffen vor allem das Management der technischen Komplexität, die Datenintegration, die Abrechnungsmodelle und die Datensicherheit - Faktoren, die Enterprise-Architekten vor neue Herausforderungen stellen. Stichwort DevOps: Gefragt ist agiles Projekt-Management, die effiziente enge Zusammenarbeit von Entwicklung, Betrieb und Qualitätssicherung sowie Security.

Um die Komplexität einer Multi-Cloud-Strategie zu beherrschen und die Herausforderungen zu meistern, ist es notwendig, dass das Enterprise Architektur-Management (EAM)auch den Geschäftsnutzen der Cloud-Dienste für das eigene Unternehmen im Blick behält und nicht nur auf der technologischen Ebene verbleibt. Entscheidungen müssen regelmäßig in Bezug auf die Cloud-Strategie überprüft werden.

Das Know-how muss inhouse bleiben

Im Gegensatz zu einem Outsourcing muss auf jeden Fall IT-Know-how im Unternehmen verbleiben: Dies wird mindestens für die Steuerung der CSP, die Integration und das EAM benötigt, selbst wenn keine eigene Anwendungsentwicklung existiert.

Das Know-how, welches im Unternehmen für die Nutzung und Umsetzung von Cloud-Diensten benötigt wird, steigt mit der Komplexität der aus den Cloud-Diensten der CSP realisierten Lösungen. Falls nur IaaS-Dienste konsumiert werden, ist geringeres Know-how notwendig als bei der Verwendung von PaaS oder dem gesamten Portfolio eines CSP.

Bildergalerie

Der Einsatz von SaaS hat einige spezielle Aspekte für die Unternehmens-IT. Viele seit Langem am Markt befindliche Anbieter von SaaS haben ihre Anwendungen noch nicht für die Herausforderungen der Cloud-Integration und der Digitalisierung angepasst.

Diese Anwendungen sind noch auf die früheren Outsourcing-Geschäfte ausgerichtet und haben monolithische Architekturen, so dass sich einzelne Geschäftsfunktionen der Lösung oft nicht über dedizierte APIs als Services ansprechen lassen und eine kleinteilige Integration in die Unternehmens-IT nicht möglich ist. Offene Wertschöpfungsketten können so nicht erstellt werden, bei denen die IT-Unterstützung für die Wertschöpfungskette nicht Ende-zu-Ende unter der Kontrolle eines einzelnen Unternehmens ist, sondern aus Teillösungen oder Teilprozessen einer Gemeinschaft von Geschäftspartnern zusammengesetzt wird.

Knackpunkt Integration

Bei der Auswahl von SaaS ist daher darauf zu achten, dass die Geschäftsfunktionen, Daten und gegebenenfalls das User Interface der Lösung sich in die Prozesse des eigenen Unternehmens und seiner Partner integrieren lassen. Alle Kriterien bei der Auswahl von CSP gelten zusätzlich auch hier. Das Risiko des Vendor Lock-in bei SaaS wird im Allgemeinen höher angesehen als bei CSP.

Da viele Unternehmen zurzeit vor der Aufgabe stehen, die Services verschiedener Cloud Provider geordnet und skalierbar in ihre IT einzubinden, ergibt es Sinn, zu vergleichen, wie die Mitgliedsunternehmen des CBA Lab diese Integration angehen. Im Whitepaper des Workstreams werden dabei die Netz- und Kommunikationsebene, die Applikations- und Service-Ebene und die Datenebene betrachtet.

Im Bereich Netz-Security zum Beispiel nutzen die Mitgliedsunternehmen mehrheitlich zwei Muster: On Premise Control und Cloud Control. Welches davon eingesetzt wird, hängt von der jeweiligen IT-Strategie, von den Zielen und von den Fähigkeiten des Cloud Providers ab. Die Integration mit großen Providern wie Azure von Microsoft oder AWS wird mehrheitlich im Muster Cloud Control umgesetzt, weil sonst zu viel Potenzial in der Network Automation nicht genutzt werden kann.

Das Herangehen des Cross-Business-Architecture Lab

Für die Datenebene sind die Integrationsmuster sehr stark abhängig vom Grad der Schutzbedürftigkeit der Daten. Für solche Daten, die das Unternehmen nicht verlassen dürfen, gibt es naturgemäß keine Muster, für Daten schwächerer Schutzklassen ergeben sich neben der vollständigen Integration in die Cloud noch die teilweise und die verschlüsselte Integration in die Cloud.

Also: Die Cloud Provider werden in ihren grundlegenden Angeboten immer austauschbarer. Deshalb sollten Unternehmen immer zuerst ihre Strategie festlegen und sich zwei Cloud Service Provider suchen, deren Stärken am besten zur eigenen Strategie passen. Das begrenzt gleichzeitig die Zahl der eingesetzten Integrationsmuster. Allerdings ist dafür eine eigene Strategie eine zwingende Voraussetzung.

Hinweis: Das komplette Whitepaper des Cross-Business-Architecture Lab gibt es zum Download.

* Christoph Witte ist freier Autor und betreibt den Blog IT-Rebellen.

(ID:46357305)