Vor knapp einem Jahr habe ich ein einem meiner Blog-Einträge ("Die Microsoft Plattform...") die verschiedenen Plattformen, die sich innerhalb der gesamten Microsoft Plattform befinden, zueinander in Beziehung gesetzt und ein Gesamtbild skizziert. Nun, in einem Jahr ist viel passiert, so dass meine damaligen Ausführungen wohl nicht falsch, aber doch leider nicht mehr ganz vollständig sind. Deshalb möchte ich hier eine Aktualisierung vornehmen

Mit der "Software-plus-Services" Strategie schlägt Microsoft ein neues Kapitel in der Evolution seiner Plattform auf. "Software-plus-Services" geht ja davon aus, dass Unternehmen in Zukunft für ihre IT-Anforderungen eine Kombination aus Internetservices und lokal betriebenen Client- und Server-Anwendungen einsetzen. D.h. Unternehmen sollen von Fall zu Fall entscheiden können, welche Teile ihres IT-Portfolios lokal und welche in der "Cloud" betrieben werden. Diese Entscheidung soll sowohl für ganze Anwendungen, für einzelne Services bis hin zu Anwendungskomponenten möglich sein. Dies hat natürlich tiefgreifende Auswirkungen auf die Plattform, für die ja der Anspruch gilt, dass die Entscheidung für ein Deploymentmodell erst nachgelagert getroffen werden kann.

Mit folgender Abbildung möchte ich die Darstellung der verschiedenen Plattformbegriffe aktualisieren:

Abbildung: Die Microsoft Plattform(en) im Zeitalter von Software-plus-Services 

Wer meinen ersten Blog-Artikel gelesen hat, wird folgende Änderungen bemerken:

• Die "Developer Platform" erstreckt sich bis zur .NET Plattform
• Die "Management Platform" erstreckt sich bis zur Windows Plattform
• Die "Hardware Platform" ist in "Infrastructure Platform" umbenannt
• Die "Infrastructure Platform" enhält nun die verschiedenen Deployment Optionen
• Neu ist die "Services Plaform"

Vier verschiedene Deploymentoptionen in der Infrastrukturschicht

Grundsätzlich stehen Unternehmen für den Betrieb von Softwarekomponenten vier Deploymentoptionen zur Auswahl:

• Betrieb vor Ort
  Zunächst ist und bleibt der klassische Softwarebetrieb vor Ort im Unternehmen möglich. Da die Anwender im Unternehmen auf die IT-Systeme zugreifen, ist dies die einzige Deploymentoption für Client Software, die auf dem Gerät des Anwenders ausgeführt wird. Beim Softwarebetrieb vor Ort hat das Unternehmen volle Kontrolle über mögliches Customizing und die Integration der Software in die restliche IT-Landschaft. Individuelle Anforderungen können im Unternehmen selbst implementiert werden.
• Betrieb bei einem Hosting Partner (Service Provider)
  Die zweite Möglichkeit des Deployments ist der Softwarebetrieb auf der Infrastruktur eines Service Providers, der die Software dann als IT-Service dem Unternehmen bereitstellt. Dieses profitiert von höheren Skaleneffekten des Service Providers. Dieser kann Infrastrukturkosten auf mehrere Unternehmen verteilen. Das nachfragende Unternehmen erkauft sich diesen Vorteil allerdings mit gewissen Einschränkungen beim Customizing. Dieses muss mit dem Service Provider abgestimmt werden und darf nicht mit Softwarediensten anderer Kunden kollidieren. Auch die Integration wird durch die nun zu überbrückende und typischerweise durch diverse IT-Sicherheitssysteme (Firewalls etc.) abgesicherte Unternehmensgrenze erschwert. Je enger die Zusammenarbeit mit dem Service Provider ist, desto leichter lassen sich diese Einschränkungen abmildern.
• Betrieb auf der Microsoft Cloud Services Plattform
  Bei der dritten Deploymentoption, der Betrieb auf einer sogenannten „Cloud Plattform“, ist eine solche enge Zusammenarbeit mit dem Anbieter nicht mehr möglich. Das Angebot derartiger Plattformanbieter wie Amazon (mit der EC2 Plattform), Salesforce (Force.com) oder Microsoft ist stark standardisiert. Die zu betreibenden Anwendungen müssen ggf. an die Plattform angepasst werden. Diese Einschränkung rechtfertigt sich allerdings durch die hohe Skalierbarkeit der Plattformen.
• Betrieb durch Microsoft
  Während bei den ersten drei Deploymentoptionen die Anwendung selbst vom Unternehmen gestellt wird, bezüglich der Funktionalität also Vorgaben gemacht werden können, greift das Unternehmen bei der vierten Option auf eine durch Microsoft bereitgestellte Anwendung zu. Beispiel für diese Variante ist SharePoint Online von Microsoft. Ein Customizing der Anwendung ist in diesem Fall zwar möglich, die Gesamtfunktionalität ist aber vom Angebot des Herstellers abhängig.

Anstelle des Begriffes "Hardware Plattform" bevorzuge ich jetzt den Begriff "Infrastruktur Plattform". Letzterer ist allgemeiner gehalten und bringt zum Ausdruck, dass die zugrundeliegende Hardware und deren Standort zunehmend irrelevant wird.

Die Services Plattform von Microsoft

Die neu eingeführte Services Plattform von Microsoft erfüllt die hohen Anforderungen an Skalierbarkeit, Stabilität und Funktionalität. Die Funktionalitäten umfassen Unterstützung für Multimandanten-Szenarien, Scale-out (im Unterschied zu Scale-up), Virtualisierung und Virtualisierungsmanagement, verschiedene Abrechnungsszenarien, Überwachung und Management, Verknüpfung von Services und schließlich auch Entwickler-Werkzeuge, die diese Funktionalitäten unterstützen.

Microsoft stellt verschiedene Dienste für Anwender (sogenannte Finished Services) und Entwickler (Building Block Services) zur Verfügung. Für alle Serverprodukte von Microsoft werden in Zukunft entsprechende Services bereitgestellt. Im Falle von Exchange, SharePoint und Dynamics CRM wird es für den Endanwender keinen Unterschied machen, welches Betriebsmodell gewählt wird. Anpassungen und Zugriffe erfolgen in jedem Modell gleich. Daneben gibt es noch sogenannte „native“, d.h. eigens für den Betrieb in der Cloud entwickelter Services. Office Live Meeting, Exchange Hosted Services und Virtual Earth sind alles Beispiele für Services, die nur über die Cloud zugreifbar sind.

Weitere Details zur Services Plattform auf den Konferenzen PDC, Xtopia und Technical Summit

Leider kann ich zum aktuellen Zeitpunkt noch nicht viel mehr zur Services Plattform ausführen. Die gute Nachricht ist aber: Das Warten auf mehr Details hat bald ein Ende: kommende Woche findet in Los Angeles die diesjährige Professional Developer Conference (PDC) statt. Diese Veranstaltung wird es absolut in sich haben. Neben einer Unmenge an Neuigkeiten rund um das Thema "Software + Services" wird es auch Neuigkeiten zu diversen Microsoft-Produkten und -Technologien geben.

Wer es im Oktober nicht nach Los Angeles schafft, dem seien zwei deutsche Veranstaltungen ans Herz gelegt, auf denen sich viele Inhalte der PDC wiederfinden:

Xtopia 2008 und Technical Summit 2008, 16.-21.11.2008 in Berlin

Die Entwickler-Konferenz "Technical Summit 2008" findet vom 19. bis 21. November im Berliner ICC statt; drei Tage vorher – vom 16. bis 18. November – öffnet die Web-Konferenz "Xtopia 08" ebenfalls im Berliner ICC ihre Tore. Die Terminierung dieser beiden Veranstaltungen ca. 3 Wochen nach der PDC ist nicht zufällig gewählt !!! - Besucher können sich sicher sein, all die interessanten Neuigkeiten der PDC in lokalisierter Form mitgeteilt zu bekommen.

Stay tuned!