Konferenzbeitrag
Einfluss von cloud services auf auswahlverfahren für IT-lösungen
Vorschaubild nicht verfügbar
Volltext URI
Dokumententyp
Text/Conference Paper
Zusatzinformation
Datum
2014
Zeitschriftentitel
ISSN der Zeitschrift
Bandtitel
Quelle
Verlag
Gesellschaft für Informatik e.V.
Zusammenfassung
Immer mehr Unternehmen setzen auf IT-Services aus der Cloud. Diese Entwicklung verändert auch die Auswahlverfahren für IT-Produkte und Dienstleistungen. Eine explorative Untersuchung zeigt dies beispielhaft f\?r Entscheidungsprozesse und Kriterien zur Bewertung von Angeboten f\?r betriebliche Anwendungssysteme sowie f\?r IT-Plattformen und Anbieter auf. 1\?Fragestellung und Vorgehensweise Cloud Computing spielt in der Unternehmens-IT eine immer wichtigere Rolle. Typische Gr\?nde hierf\?r sind ein erhšhter Automatisierungsgrad f\?r das Management von IT- Infrastrukturen oder kurze Beschaffungszeiten von IT-Services. Aufgrund der wachsenden Bedeutung von Cloud-Angeboten, stellt sich die Frage, ob und ggf. wie existierende Auswahlprozesse f\?r IT-Lšsungen angepasst werden m\?ssen. Die vorliegende explorative Untersuchung analysiert erstmals Vorgehensweisen zur Auswahl von IT-Systemen und Infrastrukturen, die Cloud Services ber\?cksichtigen und von bisher verwendeten Standardverfahren abweichen. Hierzu wurden exemplarisch mehrere Unternehmen zum Vorgehen bei der Bewertung von Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) Angeboten befragt. Die hierbei extrahierten Ergebnisse kšnnen in nachfolgenden Untersuchungen quantitativ erhŠrtet werden. Trotz der zu diesem Zeitpunkt wissenschaftlich nicht zuverlŠssig gesicherten Resultate, erscheinen die gemachten Beobachtungen interessant genug, um hier zusammengefasst zu werden. Die von uns gemachten Beobachtungen liefern wertvolle Ansatzpunkte f\?r weiterf\?hrende Analysen und f\?r die Verbesserungen der Auswahlpraxis von IT-Lšsungen, die auf Cloud Services beruhen. Die Untersuchung fokussiert sich auf den operativen Auswahlprozess von Cloud- Lšsungen f\?r Softwareanwendungen aus den Anwendungsbereichen Customer Relationship Management (CRM) und Groupware/E-Mail sowie f\?r IT- Plattformkomponenten. Hierzu wurden qualitative Interviews mit IT-Spezialisten und Managern verschiedener Gro{\S}unternehmen durchgef\?hrt. Die Ergebnisse der Befragung werden in den nachfolgenden Abschnitten beschrieben. Abschnitt 2 gibt einen allgemeinen $\dagger $berblick \?ber die Resultate. GrundsŠtzliche $\dagger $berlegungen zu einem Einsatz von SaaS werden in Abschnitt 3 skizziert. In Abschnitt 4 werden verŠnderte 453 Kriterien f\?r eine Bewertung von betrieblichen Anwendungen vorgestellt. Abschnitt 5 erweitert diese Diskussion f\?r IT-Plattformen. Abschnitt 6 fasst die gemachten Beobachtungen zusammen. 2\? EURnderungen in Systemevaluation und Auswahl Viele Anwenderunternehmen folgen bei der Auswahl passender IT-Lšsungen und deren Anbietern typischen Standardverfahren. Der Abgleich funktionaler und nichtfunktionaler Anforderungen f\?r IT-Infrastrukturkomponenten oder Informationssysteme lŠuft meist nach Šhnlichen Mustern ab (siehe z.B. [BWV07], [Gr10]): Nach Projektvorbereitung und Ist-Analyse wird ein Soll-Konzept aufgestellt, das auf den Anforderungen der Auftraggeber basiert. Anschlie{\S}end wird nach der Systemevaluation in mehreren Schritten der beste Anbieter ausgewŠhlt: Marktsichtung und Vorauswahl auf Grundlage der Anforderungen, Systemtests einschlie{\S}lich Detailanalyse, nachfolgend Verhandlungen und Abschluss. Unsere Untersuchung konzentriert sich auf den Ablauf der Systemevaluation und Auswahl. Die Ergebnisse der vorangehenden Phasen Projektvorbereitung, Ist-Analyse und Soll-Konzeption werden als Input f\?r die Phase der Systemevaluation angenommen. So wird z.B. durch einen Abgleich der Ist-Analyse und der Soll-Konzeption der Handlungsraum aufgedeckt, der durch funktionale und nichtfunktionale Anforderungen an die neue IT-Lšsung beschrieben werden kann. Die so identifizierten Anforderungen flie{\S}en anschlie{\S}end als Kriterien zur Beurteilung von neuen Systemen in die Systemevaluation ein [BWV07]. Wie in den nachfolgenden Abschnitten gezeigt wird, verŠndern Cloud-Angebote (siehe z.B. [VHH12]) die bestehende Praxis der Systemevaluation. Unternehmen klŠren meist vor den Phasen Marktsichtung, Vorauswahl, Systemtest, Detailanalyse und Auswahlempfehlung, ob und in welchem Umfang ein Cloud-Ansatz wie SaaS, PaaS oder IaaS f\?r die geplante Lšsung \?berhaupt in Frage kommt. Dementsprechend wird eine zusŠtzliche Phase zur grundsŠtzlichen Beurteilung eines mšglichen Einsatzes von Cloud Computing dem bisherigen Vorgehen vorangestellt. Zudem werden in den nachfolgenden, \?blichen Phasen des Auswahlprozesses auch Cloud-spezifische Kriterien zur Beurteilung herangezogen. Abbildung 1 illustriert diese EURnderungen, die in den folgenden Abschnitten detailliert werden. Abbildung 1: Cloud-spezifische Erweiterung des Vorgehens bei einer Systemevaluation 454 Nur wenige der Befragten stellen Cloud-Angebote und klassische On-Premise-Lšsungen gleichrangig nebeneinander und bewerten sie Schritt f\?r Schritt. Vielmehr wird meist schon vorab entschieden, ob Cloud-Lšsungen \?berhaupt in Betracht gezogen werden sollen. Entsprechende Kriterien werden hier beispielhaft f\?r den Bereich SaaS beschrieben. GrundsŠtzliche Entscheidungen f\?r bzw. wider Cloud beruhen oft auf externen und internen Complianceund Sicherheitsanforderungen {\Dj} z.B. auf nationalen Gesetzen, die die Ablage sensitiver Daten in der Cloud einschrŠnken. Interviews mit Unternehmen zeigen aber auch, dass eine pauschale Ablehnung von Cloud-Lšsungen auf Grund solcher Anforderungen hŠufig differenziert hinterfragt wird. Bei genauerer Betrachtung sind oft auch Hybrid Cloud-AnsŠtze (siehe z.B. [Fe14]) mšglich und sinnvoll. Ist beispielsweise die Speicherung von Rechnungsdaten in der Cloud untersagt, kšnnen Unternehmen diese zwar unternehmensintern ablegen und dennoch, z.B. in den Prozessen einer SaaS-Lšsung f\?r CRM verwenden. Auch Token-basierte AnsŠtze ermšglichen oft den Umgang mit strikten Vorgaben zur Datenspeicherung. Dabei werden Daten anonymisiert und zur Identifikation mit einem generierten eindeutigen Token versehen. Die anonymisierten Daten kšnnen dann in die Cloud \?bertragen und dort genutzt werden. Die Tokens verbleiben in unternehmensinternen On-Premise- Systemen und kšnnen so zur Identifikation der Daten herangezogen werden (siehe hierzu auch das Compliant Data Replication Pattern in [Fe14]). Ebenfalls beachtet werden nicht-funktionale Anforderungen, die f\?r On-Premise-Lšsungen meist kein Problem darstellen. So fordern einige Staaten, dass Finanzdaten auf physischer Ebene auditierbar sind. Das bedeutet f\?r SaaS-Lšsungen mitunter eine erhebliche H\?rde, weil die gro{\S}en Anbieter normalerweise keinen Zugang zu ihren Rechenzentren gewŠhren. Dar\?ber hinaus werden bei der Grundsatzentscheidung f\?r oder gegen die Cloud všllig neue Aspekte wichtig. Ein Beispiel hierf\?r sind Risiken durch Imageverlust. So erscheint vielen Unternehmen eine Schlagzeile wie ãHacker laden vertrauliche Kundendaten der Firma XYZ aus der Cloud herunterÒ weit schŠdlicher als eine Meldung \?ber einen Einbruch in das firmeninterne IT-System. Aber auch die Frage, wie Cloud- Anwendungen in eine komplexe IT-Landschaft integriert werden sollen, ist nicht immer leicht zu klŠren. Beispiele aus Unternehmen zeigen, dass genauere Untersuchungen hierzu bei der Softwareauswahl oft zur\?ckgestellt werden {\Dj} oder die Unternehmen vertrauen den Zusicherungen von Implementierungsdienstleistern. Es erscheint aber sinnvoller, den Integrationsgrad schon zu Beginn des Auswahlprozesses zu klŠren. Denn je mehr die angestrebte Cloud-Lšsung mit unterschiedlichen Systemen \?ber Schnittstellen verbunden werden soll, desto hšher ist im Allgemeinen die H\?rde f\?r ein SaaS-Angebot. Im Fall von CRM-Systemen kommen viele Unternehmen allerdings mit wenigen Schnittstellen aus. Eine mšglicherweise schwierige Integration taugt also nicht per se als Argument gegen eine Cloud-Lšsung. Aus Architektursicht spielt schlie{\S}lich auch eine Rolle, dass Cloud-Lšsungen zu hšherer Standardisierung beitragen kšnnen. Denn mehrere Erfahrungsberichte zeigen, dass beispielsweise Marketing und Vertrieb bereitwilliger einen durch SaaS vorgegebenen 455 hšheren Standardisierungsgrad akzeptieren, wenn sie dadurch schnell eine flexibel skalierbare CRM-Lšsung bekommen. Einige Unternehmen setzen Cloud-Lšsungen deshalb bereits bewusst als Mittel ein, um strategische Konsolidierungsma{\S}nahmen rascher und mit hšherer Akzeptanz umzusetzen. 4\?Neue und verŠnderte Bewertungskriterien Wenn eine SaaS-Lšsung prinzipiell in Frage kommt, untersuchen Unternehmen die Anbieter in der nŠchsten Phase anhand der \?blichen Kriterien: $\dagger $bereinstimmung mit GeschŠftsanforderungen, funktionale Bandbreite, Usability, Konsens mit Architekturprinzipien, etc. Bei einigen dieser Punkte ergeben sich allerdings f\?r Cloud- Anwendungen neue Fragestellungen: \?\? Ist eine schnelle Umsetzung durch SaaS f\?r uns ein Vor- oder Nachteil? Die kurze Zeit bis zum Rollout wird hŠufig als Argument f\?r Cloud-Lšsungen genannt. Denn diese Geschwindigkeit erlaubt es beispielsweise, CRM- Anwendungen in neuen, dynamischen MŠrkten z\?gig auszubauen und Vertriebsorganisationen flexibel einzubinden. In einigen Unternehmen ging dies aber so schnell, dass Mitarbeiter hinterher beklagten, es habe keine Zeit mehr gegeben, die anfŠnglichen Konzepte noch einmal anzupassen. \?\? Bekommen wir eine Komplettlšsung? Mehrere Unternehmen betonen, wie wichtig es ist, ganzheitliche Lšsungen zu evaluieren. Denn SaaS-Dienstleister bieten nicht immer alles aus einer Hand. So werden in China Anwendungen, Rechenzentren und Netzwerkservices oft nicht als Gesamtpaket bereitgestellt, sondern m\?ssen von mehreren Dienstleistern bezogen werden. Zu einer CRM- Anwendung gehšren auch Komponenten, die gew\?nschte FunktionalitŠten abdecken, jedoch nicht Teil des SaaS-Standardprodukts sind (etwa eigenstŠndige Call-Center-Lšsungen). Zwar kšnnen solche Zusatzkomponenten spŠter noch auf der Technologieplattform des Cloud-Anbieters entwickelt und bereitgestellt oder als On-Premise-Applikationen eingebunden werden. Aber das bedeutet in der Regel zusŠtzlichen Integrationsaufwand und hšhere Betriebskosten. Auch die Integration der SaaS-Lšsung in das Data Warehouse des Unternehmens oder Backup-Konzepte gehšren zu einer Komplettlšsung und sollten bei der Angebotspr\?fung nicht \?bersehen werden. \?\? Wie innovativ ist der Anbieter? F\?r Endanwender erscheinen SaaS-Lšsungen oft attraktiv, weil sie eine hohe Usability aufweisen und innovative FunktionalitŠten schnell bereitstellen. So bot ein CRM- Dienstleister k\?rzlich seinen Kunden an, Sentiments aus aktuellen chinesischen und russischen sozialen Netzwerken in Neartime auszuwerten und in die Unternehmensprozesse einzubinden. Eine solche FŠhigkeit zur Innovation haben Unternehmen bisher selten auf der Liste funktionaler und nichtfunktionaler Anforderungen an Anbieter von SaaS- und On-Premise-Systemen. 456 \?\? Wie kšnnen interne Stakeholder von der Lšsung \?berzeugt werden? In mehreren FŠllen wurde die f\?r den Nutzer attraktive Usability einer Groupware/E-Mail SaaS-Lšsung verwendet, um das Change-Management f\?r einen unternehmensweiten Ident-Service zu erleichtern. \?\? Brauchen wir die angebotenen Anpassungen und Erweiterungen? Wenn Unternehmen SaaS-Angebote mit funktionalen Anforderungen abgleichen, fŠllt meist auf, wie viele Optionen f\?r Anpassungen und Erweiterungen die Anbieter sowie deren Implementierungsund Softwarepartner offerieren (z.B. zu CRM- Analytics). Diese Optionen sollten die Unternehmen sorgfŠltig evaluieren, weil sie hŠufig im Widerspruch zu Standardisierungsbestrebungen oder einer gew\?nscht hohen FlexibilitŠt stehen {\Dj} und so dem eigentlichen Ziel der SaaS- Lšsung zuwiderlaufen. Bei den Interviews zeigte sich, dass Unternehmen f\?r ein SaaS-Produkt in einem Anwendungssegment oft nur den jeweiligen Marktf\?hrer in Betracht ziehen. Dahinter steckte die Annahme, dass andere Anbieter wichtige Anforderungen bez\?glich Sicherheit oder Compliance kaum gen\?gen werden, wenn diese von den f\?hrenden Anbietern nicht erf\?llt werden. Zudem sind Unternehmen meist nicht bereit, Pilotkunden kleinerer SaaS-Dienstleister zu werden, insbesondere weil die langfristige MarktfŠhigkeit dieser Anbieter noch nicht erwiesen ist. Konsens aus den Interviews war zudem, dass ma{\S}gebende SaaS-Anbieter mit gro{\S}en, dynamisch wachsenden $\dots $kosystemen aus Systemintegratoren, unabhŠngigen Softwareherstellern (ISV) und weiteren Partnern punkten. Dadurch kšnnen sie Standardlšsungen an die Anforderungen bestimmter Branchen und Regionen anpassen oder f\?r NischenmŠrkte erweitern. Zudem sichern die Netzwerke gro{\S}er SaaS-Anbieter global verf\?gbare Ressourcen f\?r Implementierungsprojekte, Rollout und Wartung. Viele SaaS-Innovationen kommen auch gar nicht vom Anbieter selbst, sondern von ISV oder aus dem $\dots $kosystem des Anbieters. Unternehmen sollten allerdings darauf achten, dass solche Anpassungen, Erweiterungen und Innovationen schon in den Lizenzkosten ber\?cksichtigt sind. Wer das versŠumt, muss damit rechnen, spŠter das vorgesehene Budget zu \?berschreiten. Dar\?ber hinaus gilt es zu ber\?cksichtigen, dass Zusatzlšsungen, die auf dem PaaS- Angebot eines Dienstleisters aufbauen, nicht immer auf dem gleichen technischen Stand sind, denn oft werden nicht die neuesten Plattformservices und Funktionen genutzt. Dies kann zu Komplikationen bei der Integration und beim Zusammenspiel verschiedener Lšsungsbausteine f\?hren. So wurde beispielsweise der Datenaustausch einer Zusatzanwendung f\?r ein SaaS-CRM \?ber ein proprietŠres Protokoll gesteuert, obwohl die neueste PaaS-Version des Dienstleisters bereits standardisierte REST- und SOAP- Services zur Verf\?gung stellte. Erhšhte Integrations- und Betriebskosten waren die Folge. 457 Evaluieren Unternehmen PaaS als IT-Plattform, so lassen erste Interviews einen Unterschied zum SaaS-Fall vermuten: In einer ersten Phase der Analyse (siehe Abbildung 1) wird grundsŠtzlich entschieden, ob eine PaaS eingesetzt werden soll. Die nachfolgenden Schritte des Auswahlverfahrens konzentrieren sich dann hŠufig auf die Bewertung verschiedener PaaS-Angebote. Die Trigger f\?r die Einf\?hrung einer PaaS kšnnen vielfŠltig sein. Beispielsweise verspricht ihr Einsatz Vorteile beim Aufbau einer flexibel skalierbaren Plattform, die neue IT-Dienste besser unterst\?tzen und deren Markteinf\?hrung wesentlich beschleunigen kann. Insbesondere lassen sich moderne DevOps-Prinzipien, wie kontinuierliche Delivery [JHDF11] und Integration, optimal umsetzten. In Bezug auf Virtualisierungsmšglichkeiten sind IaaS und PaaS vergleichbar, da PaaS auf IaaS aufbaut und somit den Virtualisierungsund Automatisierungsgrad in Hinblick auf eine Industrialisierung der Lebenszyklen von Anwendungen erhšht (siehe hierzu u. a. das EU-Forschungsprojekt 4CaaSt zur Erstellung einer erweiterten PaaS-Cloud-Plattform [4C14]). Folgende Fragestellungen fanden wir hŠufig bei unseren Analysen vor, wenn in Unternehmen initial \?ber einen Einsatz von PaaS nachgedacht wird: \?\? Wie lŠsst sich der Automatisierungsgrad in der Softwareentwicklung erhšhen, um z.B. dynamisch skalierbare Umgebungen nahezu in Echtzeit bereit zu stellen? Mit PaaS kšnnen Anwendungsumgebungen in Form von vorkonfigurierten Anwendungscontainern, wie beispielsweise JavaEE Anwendungsservern, automatisch zusammen mit der Betriebssystemumgebung deployt werden. Idealerweise werden sŠmtliche Umgebungen von der Entwicklung \?ber die Teststufen bis hin zur Produktion auf die gleiche Weise mit den gleichen Managementwerkzeugen aus identischen Quellen bereitgestellt. Dar\?ber hinaus stehen Anwendungsmanagementdienste wie Health Monitoring, Resource Management, Skalierung und Deployment automatisiert zur Verf\?gung (siehe Elastic Platform in [Fe14]). Durch die Erhšhung des Automatisierungsgrads mit PaaS werden zudem Fehler bei der Umgebungsbereitstellung vermieden. \?\? Wie kann die Systemintegration verbessert werden? Die Kommunikation von Anwendungen untereinander erfolgt in einer PaaS \?ber mitgelieferte Middleware-Komponenten - i.d.R. Messaging Systeme (siehe Message- Oriented Middleware in [Fe14]). Im Vergleich zu Installationen in oft unterschiedlichen Infrastrukturumgebungen entfallen innerhalb einer PaaS umgebungsspezifische Konfigurationen. Es werden modulare, lose gekoppelte Services erstellt, die sich gegenseitig konsumieren kšnnen. Nach au{\S}en lassen sich diese Dienste mithilfe der Prinzipien einer Service Orientierten Architektur (SOA) integrieren, um eine lose Kopplung zu bewahren (siehe [ARE10]). 458 \?\? Wie lŠsst sich die Datenhaltung \?ber Cloud-AnsŠtze optimieren? Bei dieser Fragestellung bedarf es einer sorgfŠltigen Evaluierung: Verwendet man Datendienste innerhalb eines virtuellen Containers, so lassen sich DatenbankzustŠnde automatisch horizontal skalieren. Das f\?hrt allerdings zu einem Paradigmenwechsel in Bezug auf klassische Datenbank-zentrische Anwendungsarchitekturen, in welchen traditionell DatenbankzustŠnde zentral in relationalen Datenbankmanagementsystemen (RDBMS) gehalten werden (siehe Stateless Component und Stateful Component in [Fe14]). Transaktionsmonitore und RDBMS gewŠhren dann die referentielle IntegritŠt gemŠ{\S} dem ACID-Prinzip. Eine Skalierung erfolgt aufwŠndig \?ber die Infrastruktur. In verteilten Systemen bei einer horizontalen Verteilung von DatenbankzustŠnden kommt es zu einem Konflikt der unterschiedlichen ZugŠnglichkeitsaspekte, auch bekannt als CAP-Theorem [GL02]. Hier kšnnen immer nur zwei von drei Skalierungsaspekte gleichzeitig garantiert werden (Consistency vs. Availability vs. Partition Tolerance). Verschiedene NoSQL- Produkte unterst\?tzen diese Aspekte mit unterschiedlichen Schwerpunkten. Die Architektur einer Cloud-Anwendung muss dann gemŠ{\S} ihren Anforderungen ausbalanciert werden, um den benštigten CAP-Eigenschaften bei elastischen Skalierungen zu entsprechen [ACF12]. Stellt sich PaaS als vielversprechende Mšglichkeit dar, zeigen Interviews mit Unternehmen, dass eine grundsŠtzliche Entscheidung f\?r bzw. wider einer Einf\?hrung entsprechender Cloud Services oftmals wesentlich von organisatorischen Gegebenheiten abhŠngt. StŠrker als die Auswahl einer Plattformtechnologie stehen Anpassungen der Arbeitsweise und eine bereichs\?bergreifende Zusammenarbeit bei der Einf\?hrung einer PaaS im Mittelpunkt der Diskussion. Differenzierende Faktoren sind weniger die Produktmerkmale der Plattformtechnologie und die mitgelieferten Standardframewoks, als vielmehr die vorhandenen Rahmenbedingungen innerhalb der eigenen Organisation. In diesem Zusammenhang wurden folgende Fragen hervorgehoben: \?\? Sind interne Strukturen und Schnittstellen zu IT-Infrastrukturkomponenten f\?r eine vollstŠndige Automatisierung hinreichend? F\?r die Implementierung einer PaaS ist die durchgŠngige Automatisierung der Deployment-Mechanismen des vollstŠndigen Plattfom-Stacks erforderlich. Die betrifft insbesondere auch die Integration mit bestehender Abrechnungsund Managementsoftware. \?\? Bieten bereits vorhandene VirtualisierungsansŠtze eine hinreichende Grundlage f\?r eine weitere Dynamisierung? In der Regel f\?hrt der Weg zur Dynamisierung \?ber die sukzessive Virtualisierung der Infrastruktur, die sich meist historisch entwickelt hat. In einem konkreten Fall wurden bestehende AnsŠtze als zu schwerfŠllig f\?r weitere Dynamisierungsbestrebungen erachtet, was dann f\?r die Implementierung eines neuen Cloud-Stacks sprach. \?\? Gibt es geeignete Sicherheitsstandards, die sich auch auf dynamisch skalierende Infrastrukturen anwenden lassen? Sicherheitsstandards sind noch oft auf statische Infrastrukturen ausgerichtet. Auch gibt es in Unternehmen mitunter wenige Erfahrungen mit virtuellen Entkopplungsmechanismen einer PaaS. 459 Daher ist die Zusammenarbeit mit den zustŠndigen Verantwortlichen f\?r Sicherheit sorgfŠltig einzuplanen. \?\? Die Frage, ob mitgelieferten Anwendungsframeworks eine Rolle spielen, wurde als nachgelagertes Problem eingestuft. Ist eine initiale Entscheidung f\?r die Einf\?hrung einer PaaS gefallen, werden in nachfolgenden Phasen des Auswahlprozesses Detailfragen betrachtet. Beispiele hierf\?r sind: \?\? Welche Lifecycle-Services stehen zur Verf\?gung? Um den Industrialisierungsund Automatisierungsgrad in einem Cloud-Stack zu erhšhen, bedarf es aufeinander abgestimmter Hardware- und Softwarebausteine. Dies betrifft insbesondere auch Lifecycle-Aspekte. Beispielsweise sollten alle abhŠngigen Plattformkomponenten in definierten Zyklen \?ber sogenannte Matrix Updates zusammen gewartet werden. \?\? Wie kann eine optimale Integration von Hard- und Softwarebausteinen gesichert werden? Oft reicht es nicht, auf existierenden VirtualisierungsansŠtzen aufzubauen. Im Gegenteil, es besteht dann die Gefahr, dass sich durch zusŠtzliche PaaS-Komponenten die KomplexitŠt der Gesamtlandschaft eher erhšht. Auch wird in vielen Unternehmen im Entwicklungs- und Produktionsbereich separat virtualisiert. Ferner kšnnen bestehende Lizenzmodelle zu dezidierten Umgebungen zwingen. Derzeit entwickelt sich ein Markt f\?r vorintegrierte Technologiekomponenten (Converged Infrastructure, siehe z.B. [Be13]) die den Aufbau von Cloud- fŠhigen Rechenzentren erleichtern kšnnen. (F\?r einen systematischen Einstieg sowie Kriterien f\?r die Auswahl geeigneter Cloud Service Modelle siehe z,B. [Ka14]) \?\? Welche Vorteile bieten Open Source-Plattformen? Open Source-Lšsungen basieren meist auf offenen Standards. Allerdings ist davon auszugehen, dass Modifikationen bzw. ErgŠnzungen notwendig sind. So m\?ssen insbesondere Schnittstellen f\?r eigene Authentifizierungsmechanismen und Self Service- Verfahren implementiert werden. \?\? Wodurch zeichnen sich kommerzielle Produkte aus? Hier ist insbesondere die InteroperabilitŠt vorhandener APIs einer der wesentlichen Faktoren. Diese ist innerhalb des Stacks eines Lieferanten typischerweise gegeben, die Integration mit vorhandenen Management- und Abrechnungssystemen kann jedoch aufwŠndig werden. Es lŠsst sich feststellen, dass PaaS kein Thema f\?r eine einfache, vergleichende Plattformauswahl ist. Stattdessen wird meist in einem ersten Schritt geklŠrt, welche Mšglichkeiten und Ziele f\?r eine bestehende Organisation sinnvoll sind. 460 Cloud-Services verŠndern die Auswahlverfahren f\?r IT-Lšsungen. Dies ist das Fazit der vorliegenden Momentaufnahme. Es zeigt sich, dass dem typischen Muster f\?r die Evaluation von IT-Anwendungen und -Plattformen eine Phase vorgeschaltet wird, in der man grundsŠtzlich dar\?ber entscheidet, ob Cloud-Services in Betracht kommen oder nicht. Nachfolgende Entscheidungsschritte enthalten dann zum Teil geŠnderte Bewertungskriterien, die auf die unterschiedlichsten Aspekte von Cloud-Angeboten eingehen. Eine weiterf\?hrende Analyse zur ErhŠrtung und Detailierung der hier aufgezeigten ersten Beobachtungen erscheint sinnvoll. Sowohl f\?r Anwendungsunternehmen als auch f\?r Anbieter von IT-Dienstleistungen ist ein VerstŠndnis der sich stetig Šndernden Bewertungsprozesse und -kriterien von IT-Lšsungen wichtig. Literaturverzeichnis [ACF12] Andrikopoulos, V.; Fehling, C.; Leymann, F.: Designing for CAP {\Dj} The Effects of Design Decisions on the CAP Properties of Cloud-native Applications, Proceedings of the 2nd International Conference on Cloud Computing and Service Science, CLOSER, 2012; S. 365-374. [ARE10] Simon, A.; Rischbeck, T.; Erl, T.: Modern ESB Architecture for SOA, Pearson Education Schweiz, 2010. [Be13] Bernard, A.: Is Converged Infrastructure the Future of the Data Center?, CIO, 2013