CW: Visual Studio ist vom einfachen Tool für Windows-Entwickler zu einer komplexen Produktfamilie herangewachsen. Mit der Team Edition for Database Professional steht schon wieder eine neue Variante an - wen adressieren Sie damit?
Die Vision einer automatischen IT
Unter Schlagworten wie dynamische IT propagieren immer mehr Anbieter die Automatisierung von IT-Systemen und Rechenzentren. Microsoft arbeitet in diesem Zusammenhang seit einigen Jahren an der Dynamic Systems Initiative (DSI). Ziel ist es, den Austausch zwischen den drei zentralen IT-Organsationseinheiten (IT- und Projekt-Management, Entwicklung sowie Betrieb und Systemverwaltung) zu verbessern und zu automatisieren.
Bisher haben beispielsweise die Bereiche Entwicklung und Betrieb wenig miteinander zu tun. Neue Anwendungen werden hinsichtlich ihrer fachlichen Funktion erstellt und anschließend der Administra- tion zur Verteilung und für den Betrieb übergeben. Dort setzt man externe Betriebs- und Systemverwaltungswerkzeuge ein, mit denen man das Verhalten von Applikationen überwacht, die Interaktion mit anderen Systemkomponenten steuert und Aktualisierungen einspielt.
DSI-fähige Entwicklungs-Tools wie Visual Studio statten die Anwendungen künftig mit Sensoren und Schnittstellen aus, so dass diese mit Systemkomponenten und Verwaltungswerkzeugen selbständig interagieren können.
Guckenheimer: Wie der Name schon sagt, richten wir uns damit an Datenbank-Professionals. Diese Leute spielten in Softwareprojekten bisher eine Nebenrolle. Sie arbeiteten üblicherweise getrennt von den normalen Quellcodeentwicklern und benutzten andere Tools. Da sich mit unserer neuen Edition sowohl Quellcode als auch Datenbankobjekte bearbeiten lassen, finden die Datenbank-Professionals nun auch ihren Platz in den Entwicklungsteams.
CW: Ändert sich für die Spezia- listen neben solchen organisatorischen Dingen auch von der funktionalen Seite her etwas, zum Beispiel in Form neuer Features?
Guckenheimer: Ja, wir gehen mit der Einbindung der Datenbanker zwei altbekannte Probleme in Softwareprojekten an: erstens die Einbeziehung von Datenbankschemata in die Quellcodeverwaltung und zweitens Datenbanktests. In der Vergangenheit wurden Programmcode und Datenbankartefakte getrennt bearbeitet, es fehlte ein einheitliches Change-Management. Nun lassen sich Ände- rungen an Datenbankschemata und Stored Procedures offline und versionierbar vornehmen. Durch automatisierte Update-Skripte können diese Ände- rungen dann wieder in die Produktivsysteme eingespielt werden.
CW: Auf welche Weise haben Sie das Problem der Datenbanktests gelöst?
Guckenheimer: Bei Softwareprojekten galten Datenbanktests bisher immer als großer Unsicherheitsfaktor. Entwickler stehen nämlich beim Testen in der Regel vor zwei Alternativen: Entweder testen sie ihren Code mit Zugriffen auf die echten Betriebsdatenbanken und verstoßen damit bewusst gegen Datenschutzvorschriften. Oder aber sie bauen mit einem gewissen Aufwand Dummy-Datenbanken auf, die erfahrungsgemäß aber nur sehr ungenau das Verhalten der Betriebsdatenbanken simulieren können. Mit unserer Database-Edition haben wir dieses Manko beseitigt. Anstelle von praxisfernen Dummys lassen sich nun Simulationsdatensätze generieren, die von den Inhalten, ihrer Struktur und Größe her praktisch identisch mit der Betriebsdatenbank sind, aber dabei dem Datenschutz gerecht werden. Zusätzlich sind nun auch Unit-Tests für Datenbanken möglich, wie man sie für Quellcode schon seit Jahren kennt.
CW: Mit jeder neuen Version von Visual Studio erweitern Sie die Zielgruppe. Software-Entwicklungsprozesse werden ja nun weitgehend abgedeckt. Wie sieht es mit der Integration von Business-Analysten und Geschäftsprozess-Designern aus?
Guckenheimer: Wir adressieren derzeit Architekten, Entwickler, Tester und Projekt-Manager. Erst in den kommenden Ausbaustufen werden wir auch Business-Analysten unterstützen. Für die Prozessmodellierung existieren jetzt Lösungen von Partnern, ebenso für die Übersetzung von Storyboards. Es geht uns aber nicht nur um die Erweiterung in Richtung Fachabteilung, sondern auch nach hinten in den Betrieb und das Management von Anwendungen. Wir haben dazu vor einiger Zeit die Dynamic Systems Initiative (DSI) ins Leben gerufen, um die drei Eckpfeiler einer IT - die Bereiche Projekt-Management, Entwicklung und Betrieb - miteinander zu verbinden.
CW: Auch einige andere Anbieter versprechen eine dynamische IT, bei der alle Instanzen im Rechenzentrum automatisch miteinander kommunizieren und so der IT-Organisation Arbeit abnehmen. Wenn man sich die Konzepte aber näher ansieht, dann sind wir doch vom vollautomatischen Rechenzentrum noch weit entfernt.
Guckenheimer: Ich gebe Ihnen Recht, wir haben da noch einiges vor uns, aber die ersten Schritte in diese Richtung sind bereits getan. Zum Beispiel kann ein Architekt mit Design for Operations schon zu Beginn eines Projekts anhand eines Rechenzentrumsmodells überprüfen, wie sich die Anwendung im späteren Betrieb verhalten wird. Mit Konkurrenten wie BMC, HP und IBM haben wir uns diesbezüglich auf den SML-Standard (Service Modeling Language) geeinigt. Statt nur im Rahmen einer Simulation zu testen, kann man so eine Kopie des laufenden IT-Betriebs mit all seinen Maschinen, Netzwerken und der Software erzeugen, um darin neu entwickelte Anwendungen zu evaluieren.
CW: Rationalisierung in der IT bedeutet auch eine stärkere Verknüpfung zwischen Business- und IT-Architekturen. Als weithin anerkannter Standard zur einheitlichen Modellierung von Geschäfts- und IT-Modellen gilt die Unified Modeling Language. Wann wird Microsoft UML unterstützen?
Guckenheimer: Unser Partner Sparx Systems bietet eine gut integrierte UML-Lösung an. Aus meiner Sicht ist UML aber zu beschränkt, sie reicht nicht, um Business- und IT-Architekturen zu verbinden. Der Entwickler, der mit Code arbeitet, verwendet zum Beispiel Sprachen und Frameworks, die man mit UML nicht modellieren kann - so gibt es keine UML-Entsprechung für die Partial-Klasse in .NET. Versucht man in so einem Fall, aus einer UML-Beschreibung Programmcode zu generieren, und ändert anschließend etwas am Code, lässt sich eine solche Modifikation nicht automatisch wieder ins Modell zurückführen. Wir setzten daher auf Domain-spezifische Sprachen (DSL) - die genannte SML ist ein Bei- spiel dafür. Im Gegensatz zu UML lässt sich so beispielsweise eine Rechenzentrumsarchitektur modellieren. Daneben spielen auch Activity Diagrams und andere Artefakte wie Storyboards bei der Modellierung eine wichtige Rolle. Ich glaube nicht, dass man die unterschiedlichen Bedürfnisse mit einer einheitlichen Sprache befriedigen kann. (ue)