Für den IBM Sales Guy ist alles ganz einfach: Wer den Notes Fat Client nicht mehr mag, der soll ratzfatz alles auf XPages umstellen und dann brauch er nur noch den Browser. Ganz easy, kostet fast nichts, passiert fast von selbst und ist wie durch ein Wunder auch noch viel performanter.

• Problem A: Ist nicht in allen Fällen ganz easy.
• Problem B: Eine XPages Entwicklung kostet nach wie vor mehr als die gleiche Applikation im klassischen Notes.
• Problem C: Die Performanz fällt nicht vom Himmel, dagegen tut sich die eine oder andere Falle auf. Das XPages Framework hat (noch) nicht den gleichen Soliditätsgrad wie die klassische Notes Entwicklungsumgebung.

Unsere aktuelle Story: Die Suche über eine Datenbank schwemmt trotz limitierender Parameter den Arbeitsspeicher voll und führt zu kommentarlosen Serverabstürzen. Mein Kollege Greg hat dies in seinem Blog Reeder Programming in deutlichen Worten beschrieben.

Das ökonomische Problem besteht dann darin, dass wir mehr als 7 Tage investieren mussten, um das Problem sauber zu identifizieren, ein PMR-Ping-Pong mit der IBM zu starten und einen Workaround zu finden. Der Kunde möchte diesen Aufwand nicht bezahlen und hat die witzige Idee, dass die IBM doch den Aufwand bezahlen könne. Selten so gelacht. Die Dummen sind natürlich wir und man bekommt noch den zynischen Trost „Lessons learned“ nachgereicht.

Damit will ich nicht den Stab über XPages brechen. Man kann schöne Sachen damit machen. Aber die Erwartungshaltung des Kunden, vor allem in Sachen Implementierungskosten, Betriebskosten, zu denen ich auch das lästige Stochern im Nebel zähle, und Zuverlässigkeit passen allzu oft nicht zu den realen Fakten.

P.S.
Java und .NET ist mindestens genauso teuer. Ach wie schön war doch solides Rapid Application Development.