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.
Ich selbst schwanke in der Stimmungslage bezüglich des XPage-Frameworks zwischen einerseits Zuversicht und gelegentlicher, freudiger Begeisterung über Teilergebnisse und andererseits Frust, Entsetzen und einer gehörigen Wut auf die IBM angesichts der ökonomischen Desaster, die wir mit XPage-Projekten bereits erlitten haben. Die Entscheidung über den Reifegrad dieses Frameworks würde ich als „offen“ bezeichnen. Unser Kollege Gregory Reeder ist seit 2 Jahren die Speerspitze der XPage-Entwicklung bei holistic-net. Wir haben unseren „Amerikaner“ u.a. wegen seiner „native English“-Kenntnisse auf dieses Thema angesetzt. Er sollte sich ohne Hemmungen in den englischsprachigen Blogs und Foren zum Thema XPage bewegen können, und das tut er auch. Vor ein paar Tagen habe ich ihn gebeten, seine Erfahrungen über die letzten beiden Jahre mal „kurz“ zusammenzuschreiben. Daraus sind dann 8 DIN-A4 Seiten geworden. Er hat sie unter