„UMTS wiederholt den Fehler von WAP“

ZDNet: Schön dass Sie bisher noch nicht das allgegenwärtige Totschlagargument unserer Zeit, den ROI angeführt haben.

Radl: Der Return of Investment, oder die Total Cost of Ownership oder der Total Economical Impact, wie es auch gerne genannt wird, ist natürlich eine ganz wichtige Komponente der Mobilität. Ich kann ja nicht erwarten, dass man nur wegen des Spieltriebs einen größeren Rollout veranlasst.

Ein Beispiel: In einen Tablet-PC stecke ich eine Vodafone UMTS-Karte, bin per Bluetooth mit meinem GPRS-Handy verbunden und an ein Wireless LAN angeschlossen. Unsere Software scannt kontinuierlich die verfügbaren Bandbreiten und wählt die jeweils verfügbare günstigste Verbindungsart. Wenn Sie beispielsweise aus dem oft zitierten Starbucks-Cafe herausgehen und auf die Straße treten – und damit Ihren Hotspot verlassen – wird automatisch eine GPRS-Verbindung aufgebaut.

Integration ist ein essentielles Thema, und gerade im Hinblick auf Mobility passiert da einiges. Die Carrier launchen – wie gesagt – UMTS ganz ähnlich wie WAP, mit all den problematischen Folgen. Eine Karte für den Pocket-PC genügt ja nicht, im Gegenteil: Da fangen die Probleme erst an. Wie sicher sind denn die Geräte? Wie sieht’s aus mit dem Application Deployment? Angenommen, ich habe 5000 Geräte draußen und möchte meine Sales-Software von 1.0 auf 1.1 upgraden – muss ich alle Geräte zurückholen oder gibt es einen Mechanismus? Dann möchte ich eine heterogene Geräte-Infrastruktur einsetzen können – ein paar Symbian-Geräte, ein paar Palms, die wir günstig gekauft haben, viele Pocket-PCs und darüber hinaus einige Tablet-PCs. Die müssen alle mit einer Infrastruktur supportet werden können. Darüber hinaus kann ich mit E-Mail alleine nicht auf einen vernünftigen ROI hoffen – ich muss also verschiedene Kanäle in meine Business-Prozesse implementieren. Dann erst rechnet sich der ROI.

ZDNet: Der Integrations-Markt wird ja gerade von der Web Services-Technologie aufgemischt. Wie sieht es mit Ihrem Standing in Sachen WS aus?

Radl: Voraussetzung für Web Services sind gesicherte Bandbreiten, gesicherte Connectivity, IP und geringe Kommunikationskosten. Wenn ich raus ins Feld gehe, habe ich alles andere als ein sicheres Netzwerk, selten eine große Bandbreite und die Antwort ist praktisch immer delayed. Günstig ist es darüber hinaus auch nicht. Im Mobility-Umfeld funktionieren Web Services daher nur sehr begrenzt. Die benötigten Informationen müssen genau anvisiert werden, Transaktionen können nur zeitversetzt abgewickelt werden. Als Beispiel sei erwähnt, dass ein Versicherungsunternehmen kürzlich in Frankfurt auf der Mobile Case Study berichtet hat, dass sie ihre Mobilität hauptsächlich über eine Terminal-Applikation durchgeführt haben. In der Folge musste in rund 20 Prozent aller Fälle der Außendienstmitarbeiter das Telefon ins Fenster hängen. Bei viereinhalb tausend Außendienstmitarbeitern mit fünf Besuchen am Tag haben sie im Jahr rund 60.000 Fälle, wo die Verbindung nicht klappt. Da wurde Mobilität offensichtlich falsch verstanden. Für uns heißt Mobilität, dass ich nur kleine, genau definierte Informationsteile übertrage, oft erst später. Nämlich dann, wenn das Gerät die benötigte Bandbreite gefunden hat.

ZDNet: Lassen Sie uns aber über „klassische“ Integration sprechen – sagen wir, sie müssen eine in Cobol verfasste Bankenapplikation integrieren. Welche Techniken kommen bei Ihnen zum Einsatz?

Radl: Es gibt verschiedene Möglichkeiten, es kommt auf den Kunden und seine Bedürfnisse an. Es gibt die Möglichkeit, Adapter zu schreiben, es besteht die Möglichkeit, in die Mainframe-Infrastruktur einzugreifen, sprich: Cobol umzuschreiben, was aber keiner gerne tut, und es gibt die Möglichkeit auf Presentation-Layer-Ebene zu integrieren. Es besteht die Möglichkeit, über .Net zu gehen oder über J2EE, da kommt ein ganzes Portfolio an Techniken zu Einsatz. Wichtig ist uns auch der nächste Schritt: Dass die abgegriffenen Informationen auf dem jeweiligen Endgerät richtig dargestellt werden. Unsere Präferenz ist jedoch non-invasive – wir wollen nicht irgendwas rumprogrammieren, sondern lieber etwas drauf setzen, entweder eine Application-Ebene auf die Datenbank legen oder wenn’s passt: ein flexibles Screen Scraping.