In meinen ersten Beitrag habe ich ja schon über die interessanten Nebeneffekte von Sharepoint berichtet. Auch diese Woche hatte ich wieder Nebeneffekte, die schon arg Grenzwertig waren. Eine Technolgie, die sich als Zeitfresser entpuppte war Linq to Sharepoint.

Meine Best Practice - Empfehlung: Nicht einsetzen für Business-Anwendungen, die ihren Namen gerecht werden wollen und auch einiges an Daten zu verwalten haben.

Details und Workaround-Frickelein werden folgen.

Zurzeit bin ich immer noch in der dritten Phase und ich glaube, dass es nach dieser Phase drei mögliche Wege gibt, die von Entwicklern eingeschlagen werden. Aktuell gehe ich tiefer in die Materie zu Workflows ein. Seit der PDC 2008 habe ich mich dazu entschieden, Microsoft-Technologien nur noch systematisch anzugehen, da der pragmatische Weg in meinen Augen unkontrollierbar geworden ist. Linq to Sharepoint hat mich zusätzlich darin bestärkt, hier habe ich zu sehr auf die Aussagen von Sharepoint MVP´s vertraut. Kommt nicht wieder vor.

Im Bereich der Workflows habe ich die möglichen Ansetze und Varianten im nachfolgenden Mind Map festgehalten. Hier muss ich zugeben, dass mich dieser Bereich von Sharepoint sehr interessiert.  

Sharepoint gehört nun seit 2 Monaten zu einem meiner Aufgabenfelder und ich muss sagen, die Lernkurve ist aus meiner Sicht nicht zu unterschätzen. Der Hauptgrund dafür: Es kann viel, aber einiges davon doch noch nicht so richtig oder mit interessanten Nebeneffekten.

Wie bereits erwähnt die Lernkurve wird dadurch unglaublich steil, wohl deshalb hat Sharepoint unter Entwicklern nicht den besten Ruf. Wenn ich in meinem Bekanntenkreis herumfrage, dann sind die Endbenutzer überwiegend zufrieden bis begeistert von Sharepoint, Entwickler dagegen nicht. Es gibt Ausnahmen, diese tragen in der Regel den Zusatz MVP oder wollen es werden. MVP bedeutet in diesem Zusammenhang Marketing Voll Profi.

Gestern habe ich mich mit einem langjährigen Sharepoint-Entwickler unterhalten und dabei auch meinen Frust abgelassen. Die Antwort darauf war: "Das ging mir auch so." Also gehe ich davon aus, dass man als Entwickler für Sharepoint mehrere Phasen durchläuft, bis man die Macken dieser Plattform kennt und somit die Lernkurve überwunden hat.

Grundsätzlich gehe ich immer ohne Vorurteile eine neue Technologie an, ich wurde aber von mehreren Entwicklern vorgewarnt. Mit diesem Schritt startete ich in die erste Phase von Sharepoint.

In dieser ersten Phase habe ich öfter überlegt wie denn wohl die XML-Konfigurationen fehlerfrei zusammenarbeiten (es funktioniert nicht immer), also versucht ein Verständnis für diese Plattform zu entwickeln. Mit dem Kennenlernen der ersten Macken startete ich in die zweite Phase.

In der zweiten Phase überlegte ich, wie sich das Ganze sauber testen lässt. In einigen Bereichen bin ich immer noch auf der Suche nach einer robusten Lösung. Mit Sicherheit weiss ich aber, dass bei Sharepoint die Priorität auf den Integrationstests liegen muss, bspw. mit Testdaten in den Listen über dem Schwellenwert. So lassen sich besonders schnell Macken im System finden, gerade auch bei der Verwendung von Linq to Sharepoint.

Ein paar Gründe warum ich diese Meinung vertrete sind:

• die XML-Konfigurationen
• die starken Abhängigkeiten
• auch die Tatsache, dass der Endanwender die Möglichkeit hat, Einstellungen am System vorzunehmen, die nicht unerheblich sein können (Nebeneffekte).

Des Weiteren kann es gelegentlich auch vorkommen, dass ContentTypes und Features ihre Arbeit verweigern. Für zukünftige Projekte möchte ich hier auch Integrationstests als Frühwarnsysteme einsetzen können, auch um zu sehen, ob es die Konfiguration zerhauen hat. In ein paar Bereichen wird mir T4 ein wenig Arbeit abnehmen können.

Zurück zu den Phasen, nach meinem gestrigen Gespräch ist es wohl die dritte Phase, in der ich mich aktuell befinde, denn auch langjährige Sharepoint-Entwickler hatten mit dem Kopf genickt und sagten, das Gefühl hatten sie auch schon.

In der dritten Phase verspürt man den Wunsch danach, mal eine Person aus dem Sharepoint-Team hauen zu dürfen. Die abgeschwächte Form könnte auch die Frage zu sich selbst sein: Was haben die geraucht? Wie lange diese Phase andauert kann ich jetzt noch nicht sagen und welche Phase danach kommt auch noch nicht. Ich glaube aber, dass es in dieser Phase eine sehr hohe Absprungrate gibt und die zukünftige Meinungsbildung über Sharepoint stattfindet.

Grundsätzlich finde ich den Ansatz von Sharepoint nicht schlecht. Das zum Beispiel die funktionale Ausgestaltung simpler Workflows, mit Hilfe des Sharepoint Designers, durch einen Poweruser erfolgen kann, hat in einigen Situationen sicherlich positive Auswirkungen auf die Unternehmensarchitektur.

Die Herausforderung liegt aber auf der Überprüfung der Funktionalität. Ein weiteres Problem kann sein, dass sich ein Poweruser zuviel zutraut und bei Anpassungen den Bock der Böcke schiesst, was wieder negative Auswirkungen auf das Daily Business haben kann. Es gibt immer Vor- und Nachteile, hier muss im Vorfeld abgewogen werden können, ob der Weg sinnvoll ist.

Ich persönlich interessiere mich primär für die Bereiche Workflows, WCF, WIF und BI mit Sharepoint. Mit CMS basierend auf Sharepoint bin ich nun auch schon in Berührung gekommen und konnte mir mein Urteil darüber bilden.

Da ich nun schon einige Macken kennengelernt habe, werde ich diese in nächster Zeit veröffentlichen, falls mir Sharepoint die Zeit dafür gibt.

Vor allem interessiert mich auch, ob ich die dritte Phase überstehe. Falls nicht: Workflows, WCF, WIF und BI gehen ja zum Glück auch ohne Sharepoint. ;-)