Suche
Interview mit Norm Judah

Wie Services die Zukunft der IT verändern werden

Mirko Schrempp
Norm Judah

Norm Judah ist Chief Technology Officer of Worldwide Services bei Microsoft. In dieser Funktion ist er verantwortlich für die globale technische Strategie, Innovationen, technische Communitys und Enterprise Services Strategie sowohl für Microsofts eigene IT, wie auch für Kunden. Im Gespräch mit Business Technology gibt er einen Einblick in die interne Arbeitsweise bei Microsoft und beschreibt seine Vision dazu, wie vor allem Services die Zukunft der IT und des Business verändern werden.

Business Technology: Services sind das aktuelle Paradigma in der IT, und dadurch verändert sich eine ganze Menge. Welche Auswirkungen hat der Servicegedanke für Microsoft als Service und Device Company und Ihre Kunden?

Norm Judah: Wenn wir das bei uns intern betrachten und dabei vor allem die Entwicklungsteams, dann hat sich insbesondere unsere Arbeitsweise geändert. Gerade die Kernprodukte, also das Office- und das Windows-Team, haben festgestellt, dass sie nicht nur darüber nachdenken müssen, was sie entwickeln, sondern auch, wie sie es entwickeln. Sie mussten ihre Arbeitsweise hin zur agilen Entwicklung transformieren und lernen, wie sie dadurch kosteneffektive, effiziente und Cross-Functional-Teams werden. Für die einzelnen Produktgruppen war das sicher ein Prozess, der über die letzten fünf Jahre gelaufen ist, aber heute sind alle wichtigen Entwicklungsteams so aufgestellt.

Zu der neuen Arbeitsweise gehört dann beispielsweise auch, dass wir uns im Windows- und im Serverteam von der Rolle des General Managers verabschiedet haben. Früher konnte man immer jemanden finden, der General Manager eines Produkts war. Den gibt es heute nicht mehr. Dadurch hat sich die Art der Entscheidungsfindung, wie und was entwickelt wird, stark verändert. Heute haben wir drei Kernaufgaben und -rollen, die das übernehmen: das Programmmanagement, das die Spezifikationen schreibt, die Entwicklung und das Testing. Zwischen diesen drei Eckpunkten wechselt die Leitung des Projekts. Auch wenn wir andere Rollen hinzugefügt haben, kamen wir schließlich auf diese drei Kernrollen zurück. Wir hatten beispielsweise Leute, die speziell für User Experience verantwortlich waren, aber es zeigte sich, dass sich eigentlich jeder Entwickler in seinen Aufgaben auch mit UX beschäftigt. Denn selbst wenn er für den Aufbau der Zustandsmaschinen auf dem Server zuständig ist, muss er sich Gedanken darüber machen, wie die Anachronizität für den Nutzer in Erscheinung tritt. Wir hatten aber auch schon DevOps als gesonderte Rolle – also jemanden, dessen Aufgabe der Betrieb war. Die gute Nachricht ist nun, dass jeder Entwickler und jeder Tester heute auch für den Betrieb zuständig ist und sich darüber Gedanken machen muss. Wir haben also im Kern diese drei Rollen; auch wenn es manchmal mehr sind, kommen wir immer wieder dort an.

Als wir begonnen haben, Lösungen und Produkte auf diese andere Art zu bauen, haben wir zunächst Featureteams mit den genannten drei Rollen eingerichtet, die für ein bestimmtes Set von Features verantwortlich sind. Das Interessante daran ist, dass es Cross-Functional-Teams sind, in denen es keine feste Leitungsrolle gibt. Es wird also kein Projektleiter bestimmt, weil die Leitung davon abhängig ist, in welcher Phase des Entwicklungsprozesses sich das Team befindet: In der Anfangsphase liegt die Leitung eher beim Programmmanagement für die Spezifikation, in der Entwicklungsphase bei der Entwicklung und am Ende des Releases übernimmt das Testing. Es zeigt sich also, dass sich die Leitung des Teams mit dem Voranschreiten des Projekts entwickelt und verändert. Es gibt also nicht mehr die „Du bist der Projektleiter und triffst alle Entscheidungen“-Situation, sondern tatsächlich ist es dieses Dreieck von Rollen, zwischen denen die Verantwortung wechselt.

Wenn man nun anfängt, komplexere Produkte zu bauen, wechseln die Featureteams je nach Bedarf. Das eine Team erledigt seine spezifische Aufgabe im Projekt und übernimmt nach dem Abschluss eine neue oder wird aufgelöst und die einzelnen Mitglieder wechseln in andere Teams. Hierbei kommt natürlich auch die Frage auf, wie die Leistung des Einzelnen gemessen wird. Das passiert auf zwei Wegen: zum einen anhand der Ergebnisse und der Effektivität des Teams insgesamt. Zum anderen wird die Rolle des Einzelnen im Team bewertet: Wie hat es funktioniert und wie hat er sich im Vergleich mit den anderen Entwicklern mit seinen jeweiligen Schlüsselkompetenzen eingebracht? Die Leute werden also auf diesen beiden orthogonalen Achsen bewertet. Die Entwicklungsteams haben sich in dieser Weise transformiert und damit die Art und Weise, Software zu entwickeln, fundamental verändert.

Dadurch ist es jetzt eine der Kernkompetenzen von Microsoft, große Teams zusammenstellen zu können, die wirklich herausfordernde Softwareprobleme angehen und lösen können. Grundsätzlich arbeiten alle Teams auf diese Weise. Allerdings unterscheiden sich die Frequenzen, in denen Features ausgeliefert werden. Das Yammer-Team arbeitet beispielsweise mit einer zweiwöchigen Frequenz, dass Officeteam mit einer dreimonatigen, das Windows-Server-Team vielleicht mit einer Jahresfrequenz. Die Frequenzen, in denen diese Teams quasi rotieren, sind also unterschiedlich, aber alle folgen dem gleichen grundlegenden Entwicklungsmodell.

BT: Und was bedeutet das in Bezug auf Services und die Produktgruppen?

Judah: Für unsere IT-Pros und das Services Business – rund 20 000 Leute weltweit – bedeutet das, dass wir heute auch anders aufgestellt sind – vor allem, weil die Industrie sich immer mehr dahin bewegt, Servicedesign zu kapseln. Nehmen Sie SaaS aus der Cloud, das wird agil und ökonomisch effizient vor allem durch die extreme Standardisierung – alles ist dort gleich. Unabhängig davon wie und wo man z. B. SharePoint einsetzt – es ist immer das Gleiche und funktioniert gleich. In der extremen Standardisierung liegen ein großer wirtschaftlicher Wert und immense Vorteile für die Agilität. Das bedeutet für alle, die in der IT oder mit IT arbeiten, ob nun Entwickler oder Manager, was wir bauen, managen oder deployen, hat sich verändert und wird sich verändern. Wir mussten lernen, anders darüber zu denken, was die Value Proposition, was wir verkaufen und dessen Simplizität, entscheidend ausmacht. Und es zeigt sich, dass eine der größten Herausforderungen darin besteht, dass wir von unseren Partnern in der IT verlangen müssen, sich mit uns zu verändern, weil unsere Veränderung direkte Auswirkung auf sie hat. Wie wir ändern, was wir verkaufen, ist zu einem bestimmten Grad davon getrieben, was die Produkte machen, aber auch von der Fähigkeit der IT, sich tatsächlich auch zu verändern, und da kommen die Partner in Spiel.

Ich habe natürlich weltweit Kontakt zu unterschiedlichen Unternehmen, und was ich dabei faszinierend finde, ist, wie unterschiedlich der Appetit nach Veränderung in den Unternehmen ist. Manchmal ist es das Business, das nach Agilität, nach schnellen Anpassungen verlangt und die IT sträubt sich und will erst mal sicherstellen, dass die Änderungen deployt und gemanagt werden können usw. Inzwischen kommt das Business aber in vielen Fällen relativ schnell an die Services, weil sie einfach zur Verfügung stehen, was zur Folge hat, dass es die IT nun vorantreibt. Die Konsequenz ist, dass die IT der Unternehmen auf der einen Seite vom Business getrieben wird und auf der andern Seite von der IT-Industrie – mit dem Ergebnis, dass sie selbst in der Mitte gefangen ist und nun entscheiden muss, ob und wie sie sich verändert.

Ich denke daher, die Veränderung, die wir durchmachen und die wir mit den neuen Produkten verkaufen und dabei den Kunden auch vermitteln müssen, ist die gleiche Veränderung, die auch unsere Kunden und ihre Unternehmens-IT durchmachen müssen.

[ header = Seite 2: Was bedeutet Service-Orientierung für die Entwickler? ]

BT: Das betrifft dann vor allem den Betrieb, aber was bedeutet es für die Entwickler?

Judah: Ich bekomme die Frage relativ oft gestellt und denke, für die Entwickler ist das etwas anderes. Ob man vor zwanzig Jahren mit Fortan entwickelt hat oder heute in C# – die grundlegenden Skills für das Was und das Wie sind die gleichen. Die Tools sind unterschiedlich, die Compiler und Editoren sind andere, man kann sich für Wasserfallmodelle oder agile Entwicklung entscheiden. Sie können jetzt wunderbare Sache mit Virtualisierung, Testing oder ähnlichen Dingen machen, aber grundlegend wird sich das Leben eines Entwicklers nicht dramatisch ändern. Was sich tatsächlich ändern wird, ist der Aspekt der User Experience. Wenn es darum geht, moderne Applikationen von Anwendungen, wie man sie bisher geschrieben hat, zu unterscheiden, dann ist der Unterschied vor allem in der User Experience zu finden. Glauben Sie mir, aktuell sieht man einfach noch zu viele Anwendungen mit schlechter UX.

Was sich auch ändern wird, ist die Telemetrie in den Anwendungen. Location ist nur ein einfaches Beispiel für die Telemetrie. Aber je mehr ich über die Anwendung und wie sie verwendet wird weiß, desto mehr kann ich damit machen. Dabei gibt es immer zwei Elemente: die Daten der App selbst und die Daten der Telemetrie. Selbstverständlich müssen dabei Datenschutzfragen berücksichtigt werden. Aber in der Nutzung dieser Daten wird das Unterscheidungsmerkmal für die kommenden Anwendungen liegen. Hierbei geht es für uns im Grunde um Business Intelligence. Es ist ja schon fast lustig, dass wir uns als IT-Industrie darum gekümmert haben, Business Intelligence für das Business zu bauen, aber wir haben uns BI bisher wirklich kaum zunutze gemacht. Es geht also darum, die Tools zu bauen und die Daten zu sammeln, die es uns erlauben, das, was die IT tut, besser zu machen. Wenn Sie heute jemanden fragen, wie eine Anwendung angenommen wird, bekommen Sie die Antwort „Sie ist auf 1 000 Maschinen installiert und läuft“. Aber das ist nicht die Frage. Ich will wissen, was die Leute wirklich damit machen und wie sie es machen – und dann ist die große Frage: Verstehen wir tatsächlich genau, was sie machen? Wir haben dazu ganz interessante Beobachtungen gemacht.

Gehen wir zum Beispiel von den typischen Nutzern aus. Die drei Nutzertypen, die eine Anwendung immer nutzen, sind: ein Neuling, ein erfahrener Nutzer und ein Administrator. Es gibt sicher noch mehr Typen, fünf bis zehn vielleicht, aber bleiben wir erst einmal bei diesen drei. Für diese Typen kann man dann eine Art Reifegradmodell entwickeln, das zeigt, dass der Neuling bestimmte Dinge mit der App macht, und je erfahrener er im Umgang damit wird, umso mehr wird sich seine Kompetenz erweitern. Mit den Ergebnissen der Telemetrie kann man nun die Ziele der Nutzer mit den technischen Möglichkeiten ins Verhältnis setzen und verstehen, was der Nutzer genau macht. Dann kann man auch erkennen, dass ein Nutzer zwar bestimmte Dinge machen könnte und idealerweise auch sollte, aber er macht ganz andere. Daraus ergibt sich für uns die Frage, wie kann man ihm nun helfen, seine Kompetenzen im Umgang mit der App zu verbessern, und das bauen wir dann in die App ein. Daraus wird dann ein geschlossener Kreis von Nutzung der App, Anpassung der App, Steigerung der Kompetenz und wieder der Anpassung an den neuen Reifegrad.

Tatsächlich machen wir das bei uns genauso. Die Version von Office, die wir intern ausrollen, ist mit Instrumenten zur Ermittlung dieser Nutzungsdaten umfangreich ausgerüstet. Und es gibt eine große Datenbank, mit der wir quasi in die Arbeitsweise bei Microsoft hineinschauen können, um z. B. zu sehen, was heute alle in Excel genau machen. Aus der Analyse dieser vielen Daten ist z. B. Drag and Drop entstanden. Denn an den Mustern konnte man erkennen, dass „auswählen, kopieren, Wechsel des Fensters, auswählen, einfügen“ als Vorgang sehr oft vorkommt. Also war Drag and Drop die Lösung dafür. Das ist natürlich ein einfaches Beispiel, aber wenn man das nun auf Businesslevel machen will, sagen wir für einen Sales-Mitarbeiter, bekommt es eine andere Dimension. Wir sehen dann z. B. wie er mit dem CRM-System arbeitet: Gibt er die Daten so ein, wie wir das erwarten, oder können wir ihm dabei helfen, es besser zu machen? Im Idealfall kann eine adaptive App im Sinne eines Trainings Vorschläge machen, wie er die Daten besser eingibt. Man könnte aber auch die App von unserer Seite aus anpassen. Und genau das wird passieren. Wir werden smarte Anwendungen bauen, die sich durch ihre Verwendung verändern und anpassen. Für den Entwickler bedeutet das nur, dass er weiterhin seinen Code schreiben wird. Aber für den Anwender und die IT insgesamt ändert sich unter Umständen sehr viel.

BT: Das Konzept von Services und Serviceorientierung klar und verständlich zu kommunizieren, ist nicht einfach: Über SOA spricht fünf Jahre nach dem Buzz kaum noch jemand. Dagegen war der Service Bus immer einfach zu verstehen, hat aber nicht so wirklich funktioniert. Jetzt haben wir lose gekoppelte Services, aber es ist immer noch schwierig, den Leuten klar zu machen, was Services sind, wie man sie nutzt und anbietet. Wie machen Sie das Wesentliche eines Service verständlich, das über die komplexen technischen Anforderungen hinausgeht, und wie unterstützen Sie Ihre Partner?

Judah: Ich denke, hier geht es zunächst nicht um Services, sondern um Distributed Computing. Ich versuche das so zu erklären: Bevor ich bei Microsoft angefangen habe, war ich lange Zeit bei Exxon. Dort haben wir damals eine verteilte Anwendung zwischen Mainframe CICS Cobol und OS/2 geschrieben und haben dazu LU 6.2 und RPC genutzt. Das ist etwas ganz anderes, als das, was wir heute machen, aber es ist das absolut Wesentliche, wenn man eine verteilte Anwendung schreibt, die robust und agil ist, Fehler-Recovery beherrscht, in einer verteilten Welt laufen kann, sich verbindet, wenn es nötig ist und so weiter. Hier geht es um die architekturellen Kernprinzipien von Distributed Computing.

Zwischendurch haben wir das dann SOA genannt oder RPC oder wie auch immer. Wir haben der Sache einfach unterschiedliche Namen gegeben. Aber im Wesentlichen geht es darum, wirklich grundlegend zu verstehen, wie man eine robuste, verteilte Anwendung aufbaut. Ob man dazu nun einen Service Bus nutzt, REST oder OData, was wesentlich asynchroner ist, das sind dann nur noch Architekturentscheidungen, die man an einem bestimmten Punkt machen muss.

Sie haben den Punkt angesprochen, dass die Referenzmodelle und -architekturen und das Verständnis von verteilten Architekturen nicht klar genug dargestellt und verständlich gemacht wurden, sodass eine Millionen Entwickler einfach damit arbeiten können, und es daher eher Expertenwissen ist. Das ist ein interessanter Punkt, ich habe das so noch nicht betrachtet. Ich denke, dass viel Arbeit von den Werkzeugen übernommen wird, die das Ganze dann möglich machen. Wenn Sie über einen Service nachdenken, ist das in der Regel ja eine Abstraktion des eigentlichen Service, und Sie haben nicht wirklich den Einblick oder Überblick, was eigentlich unten drunter passiert. Ein Problem mit SOA war sicher, dass es eine Architektur auf der Suche nach einem Problem war.

Aber natürlich gibt es einige Leute, die ein Message-Bus-System gebaut haben – ob nun SOA-basiert oder auch nicht. Wir selbst haben gerade ein großes Payment-System im UK fertiggestellt, das auf einem BizTalk Service Bus läuft. Es ist ein High-Volume-System mit hoher Integrität, und es ist eine klassische SOA-basierte Architektur. Bei dieser Anwendung stellte sich heraus, dass der eigentliche Durchbruch in der Entwicklung mit der Fertigstellung des ersten Testaufbaus (Test Rig) für die Anwendung kam. Das heißt, dass eine Message vom Source-System zum Zielsystem – noch ohne Inhalt – voll durchlaufen konnte. Nachdem dieser Nachrichtenfluss im Message Bus fertig war, konnten wir den Zeitverlauf der Sequenzen beobachten. Wir brauchten rund zwei Wochen, um den ganzen Rahmen zu bauen. Dann konnten wir die Businesslogik hinzufügen und lernten eine Menge über die Performance, die Kapazitäten, die Bottlenecks, führten funktionale Tests durch und konnten mit dem Fine Tuning des Systems beginnen. Aber das wird alles schnell recht kompliziert, und jemand muss das verstehen und eine Architektur dafür entwerfen.

Unsere Frage ist nun: Wie können wir diese Kompetenz allgemein zur Verfügung stellen, sodass viele Leute das machen können? Dafür haben wir z. B. das Konzept der Product Line Architectures entwickelt, das es erlaubt, die Services, die benötigt werden, in die eigene Entwicklung einzubauen. Was wir dafür z. B. gemacht haben, ist ein Service Level Modelling davon, wie SharePoint as a Service aussieht. Wer nun den SharePoint-Service konsumieren will, nutzt einfach das SharePoint-Servicetemplate. Das Interessante dabei ist, dass SharePoint as a Service tatsächlich SQL as a Service zugrunde liegt, sodass wir also ein Servicetemplate für Data as a Service benötigen, damit der Service einfach konsumiert und aggregiert werden kann. Das sind, glaube ich, gute Beispiele für die Zusammenfassung von Services und unterschiedliche Serviceebenen und wie man diese dann deployt, managt und konsumiert. Was wir also tun, ist am Beispiel zu demonstrieren, was man machen kann, statt eine abstrakte Theorie, z. B. die von SOA, darzustellen. Das ist eine Frage der Werkzeuge, in gewisser Weise auch eine philosophische, aber vor allem die Frage „Was macht ein gutes verteiltes System eigentlich aus?“.

Ich denke, dass wir noch viel dazulernen werden, wenn Apps auf die Geräte kommen. Diese Apps sind in einigen Fällen möglicherwiese nicht wirklich serviceorientiert, sondern holen sich nur Informationen von einer Webseite und präsentieren sie in einer netten Oberfläche. Andere werden allerdings auch weiter gehen und anspruchsvolle, ausgeklügelte Sachen machen können, wie z. B. Flugtickets kaufen, Autos reservieren oder mit Anwendungen wie CRM das Business unterstützen und dabei im Sinne der smarten Apps einen hohen Funktionsumfang haben. Da wird es sehr gut machbare Dinge geben. Aber momentan können das noch die wenigsten der Apps, die wir auf dem Markt sehen.

[ header = Seite 3: Werden wir  nur noch „kleinteilige“ Services haben?]

BT: Dass sie reine Präsentationsflächen sind, ist ja einer der großen Kritikpunkte an Apps. Interessant wird es doch tatsächlich erst, wenn man zu den LOB-Apps mit der von Ihnen erwähnten, umfangreichen Funktionalität kommt. Auf welcher Basis entscheidet man, wie man diese baut? Wie erkennt man die Anteile, die robust sein müssen oder sollen und die flexiblen? Und werden wir dann nur noch „kleinteilige“ Services und Devices haben oder auch noch große Anwendungen?

Judah: Das ist abhängig davon, was man machen will und was man einsetzen möchte. Und es ist abhängig davon, was das architektonische Kernprinzip der Anwendung sein soll – das muss man natürlich kennen. Irgendwer muss entscheiden, dass man die User Experience anpassbar haben möchte und die zugrunde liegende Businesslogik starr ist. Davon sind dann die Prinzipien abhängig, nach denen die Gesamtarchitektur entworfen wird. Dazu wäre es sicherlich gut, eine Bibliothek von Architekturen zu haben, aus der man sich nach Bedarf diejenige auswählt, die die gewünschten Charakteristika aufweist. Aber davon gibt es bisher wahrscheinlich sehr wenige. Zunächst ist es wichtig, das Kernprinzip für seine Anwendung zu haben, dann kann man auf der Basis des von mir vorgestellten Modells sicher auch große Anwendungen bauen. Möglicherweise baut jemand ein neues ERP-System – vielleicht wird das dann die neue SAP, das ist durchaus möglich. Nein, es wird sicher kein ERP-System sein, aber wir werden mit Sicherheit eine Menge Applikationen sehen, die die Art und Weise, wie wir arbeiten, verändern werden. Das werden möglicherweise Anwendungen sein, die so in das soziale Umfeld integriert sind, dass das, was die Leute machen, sich ändern wird, durch die Art, wie die Anwendungen die Anforderungen beantworten. Der Schlüssel dazu wird sein, wie wir unsere Services und wie wir Lösungen um unsere Services herum anbieten – unabhängig davon, ob für Consumer oder Business. Schauen Sie sich beispielsweise CRM an. In unserem CRM-System haben wir den XRM Layer, einen Entity-basierten Abstraktions-Layer. Momentan gibt es dort Entities für Kunde, Produkt, Anbieter, Rechnung – eben die Dinge, die man in CRM erwartet. Allerdings ist es ein erweiterbarer Layer, der es erlaubt, neue Entitäten zu definieren und diese mit den benötigen Services zu verbinden. Das ist ein wirklich mächtiges Environment, in der man durchaus große Lösungen bauen kann. Faktisch haben wir unser CRM-System darauf gebaut, und jetzt entwickeln wir z. B. Managementlösungen für Autohändler, die wir über das XRM-Modell erweitern. Das Entscheidende dabei ist dann, wie man den Service modelliert und mit dem System verbindet. Servicemodellierung ist heute nichts anderes als Datenmodellierung vor zehn oder zwanzig Jahren. Wie man die Technologie baut, ist unterschiedlich, aber Modellierung ist Modellierung. Natürlich kann das nicht jeder, so wie nicht jeder UX kann. Und es wird auch dazu kommen, dass Consumer- und Businesstechnologien sich mischen. Beispielsweise sind die Xbox und die Kinect zunächst keine Enterprise-Produkte und dennoch in unterschiedlichen Systemen integriert: Wir nutzen die Kinect z. B. auch in vielen Enterprise-Szenarien. In einer Bank in England haben wir beispielsweise eine Wand mit Kundenbroschüren gegen ein System mit der Kinect und eine Menge Businesslogik ausgetauscht, sodass der Kunde nun reinkommt und mit der Kinect die Logical Wall nutzt. Und mit Windows 8 und dem Windows Phone werden diese Grenzen weiter verschwimmen und neue Lösungen ermöglichen.

BT: Vielen Dank für diesen Ein- und Ausblick.

Geschrieben von
Mirko Schrempp
Mirko Schrempp
Mirko Schrempp ist Redakteur für den Windows Developer, das Business Technology Magazin und das SharePoint Kompendium.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.