SAP hat die Unternehmenssoftware modularer gestaltet – und dadurch revolutioniert. Vorher war die Entwicklung entsprechender Software nur von Großunternehmen zu stemmen. Das Resultat: Anwendungen, die – auf die Prozesse des jeweiligen Unternehmens zugeschnitten – niemandem sonst von Nutzen waren. SAP hat mit der Aufteilung einer solchen Standardsoftware in Schichten und Module, die eine benutzerorientierte Präsentationsschicht versorgen, den Markt für eine Heerschar weiterer Kunden geöffnet.
Altsysteme und teils komplizierte Geschäftsprozesse zwingen trotzdem auch Unternehmen, die SAP-Lösungen für ihre ERP-, CRM- oder Business-Intelligence-Prozesse verwenden, eine Vielzahl verschiedener Plattformen, Lösungen und Server zu betreiben. Das wiederum erfordert in aller Regel komplizierte Abläufe bei Entwicklung und Test neuer Software – um sicherzustellen, dass alle Elemente korrekt zusammenspielen und die Geschäftsprozesse reibungslos ablaufen.
Doch jegliche Test- oder Entwicklungstätigkeit erfordert eine physische Kopie der jeweiligen Produktivumgebung. Untersuchungen zufolge zieht somit eine typische SAP-Systemlandschaft von 15 Produktiv-Servern zwischen 30 und 50 Server für Entwicklungsaufgaben nach sich, die meist nur zu 20 Prozent ausgelastet sind.

Ausweg Virtualisierung

Jeder CIO weiß, dass die Implementierung neuer Prozesse und Funktionalität nicht unerhebliche Kosten verursacht. Daran ändern im Zweifelsfall auch Konzepte wie Enterprise SOA nichts. Die Umstellung auf eine Service-orientierte Architektur lässt die Zahl der „Knoten“ in einer Anwendungslandschaft eher steigen. Aber das SOA-Konzept bietet von Prozess-Seite zu viele Vorteile, um es einfach zu ignorieren. Aus Services kombinierte Kleinanwendungen wie SAP xApps, kommunizieren über eine Exchange-Infrastruktur mit den anderen SAP-Anwendungen und erlauben es, Prozesse flexibler und reaktionsfähiger zu gestalten. Doch die Verflechtung der Prozesse wird komplexer. Wer hier über die Hardware skaliert, handelt sich Kosten ein – für Kauf, Unterhalt und Administration.
Die Servervirtualisierung bietet einen Ausweg aus diesem Dilemma. Die Technologie verwandelt einen physisch vorhandenen Server in einen Host für mehrere, vollständig isolierte virtuelle Maschinen, die jeweils aus dem Betriebssystem und der Anwendung bestehen. Zwischen den virtuellen Maschinen auf dem physischen Host findet keinerlei Interaktion statt. Gleiches gilt auch für auf den virtuellen Servern montierte Anwendungen. Damit entfällt die Notwendigkeit, pro Anwendung auch einen dedizierten physischen Server vorzuhalten – der unter Umständen nur zu zehn Prozent ausgelastet ist, weil man es ausschließen will, dass mehrere Anwendungen sich eventuell gegenseitig stören.

Testumgebungen bieten größtes Einsparpotenzial

Da mehrschichtige Test- und Entwicklungsumgebungen beim herkömmlichen Modell der dedizierten physischen Ressourcen einen Großteil der Investitionen für eine SAP-Implementierung ausmachen, bieten sie auch das größte Einsparpotenzial bei einer Serverkonsolidierung. Mit Virtualisierungslösungen kann ein einziger physischer Server als Host für mehr als zehn virtuelle Maschinen fungieren, je nach Nutzungsintensität. Mit der richtigen Virtualisierungsstrategie lässt sich also eine Testlandschaft von 30 bis 50 Servern mit nur drei bis fünf physisch vorhandenen Servern umsetzen – eine interessante Option angesichts des Wartungsaufwand, den Stromkosten, den notwendigen Kühlanlagen und dem Platzverbrauch.

Über diese rein zahlenmäßige Konsolidierung erfordern Entwicklungs- und Testumgebungen auch beträchtlichen manuellen Aufwand. Um eine Multi-Tier-Testumgebungen mit physischer Hardware aufzubauen, müssen Server installiert, Software aufgespielt, Netzwerkverbindungen hergestellt, Rollbacks gefahren werden und vieles mehr. Virtuelle Maschine hingegen lassen sich vom Rechner des Administrators aus konfigurieren. Die Administratoren können sich deswegen darauf konzentrieren, die virtuellen Server-Abbilder gemäß den Wünschen und Anforderungen ihrer Entwickler und der Qualitätssicherung zu konfigurieren.

Automatisierte Replikation und Verwaltung

Ist eine virtuelle Infrastruktur erst einmal etabliert, besteht darüber hinaus die Möglichkeit, durch eine Automatisierung weiter Zeit zu sparen. Einige Virtualisierungslösungen besitzen eine Snapshooting-Funktionalität, mit der die Administrationen virtuelle Maschinen unkompliziert replizieren können.
Dennoch erfordert der Aufbau einer Multi-Tier-Testumgebung mit virtuellen Maschinen für eine SAP-Landschaft einen gewissen Zeitaufwand. Immerhin gilt es beispielsweise, „verschiedene“ virtuelle Maschinen zusammenzuführen – als Web-Server, mit CRM- oder Business-Intelligence-Anwendung und den zugehörigen Datenbanken. Unter Umständen erweist sich hier das Team von IT-Administratoren, die das virtuelle „Testlabor“ betreut, als Engpass.

Anstatt es den IT-Teams für die Entwicklungs- und Testunterstützung zu überlassen, die verschiedenen virtuellen Maschinen bereitzustellen und außer Betrieb zu nehmen, stellt eine entsprechende Virtualisierungslösung Entwicklern und Qualitätsmanagern diese Server in einer Bibliothek zur Verfügung. In diese Bibliothek lassen sich als „Bausteine“ auch bereits konfigurierte Gruppen verschiedener virtueller Server einstellen und auswählen. Die Virtualisierungslösung sucht sich nach der Auswahl automatisch einen Host für diese Maschinengruppen, stellt sie bereit, startet sie und ermöglicht dem Anwender danach den Zugriff seine persönliche Workstation.
Viele Unternehmen, die SAP-Software verwenden, sind global aufgestellt. Dementsprechend arbeiten sie – über alle Zeitzonen hinweg – rund um die Uhr. Einem Unternehmen beispielsweise, das Entwicklungsstandorte im Silicon Valley, in Deutschland und einen Outsourcing-Partner in Bangalore (Indien) hat, bietet ein virtuelles Testlabor Vorteile, auf das über eine solche Automatisierungssoftware für den gesamten Software-Lebenszyklus zugegriffen wird. Allen Entwicklungsteams steht ein gemeinsamer Pool von Entwicklungs- und Testlabor-Ressourcen mit beliebig vielen virtuelle Maschinenkonfigurationen und Multi-Tier-Systemkonfigurationen zur Verfügung. Besonders dringende Entwicklungs- oder Testarbeiten lassen sich somit problemlos von einem Team an ein anderes übergeben, wenn der jeweilige Arbeitstag endet. Team A übergibt hierzu einfach die „Live“-Konfiguration mit mehreren Maschinen in der gemeinsam genutzten Bibliothek an Team B, das nahtlos die Arbeiten fortsetzt.