SharePoint Fakten im Praxiseinsatz

Andi Fandrich Als Antwort am 21 Juli 2011 11:58

Puh, ein sehr langer Beitrag. Ich habe leider wenig Zeit genauso ausführlich zu antworten - obwohl die eigentlich angestrebte Diskussion sicher interessant wäre. Das ist aber IMHO eher etwas für Usergroups o.ä.

Deshalb nur ein paar Anmerkungen:

1) Entwicklung: ich denke Du hast Dich noch nicht ausführlich genug mit der SharePoint-Entwicklung beschäftigt. SP bietet hier wirklich ein sehr gutes Grundgerüst auf dem man aufsetzen kann. Der Entwickler muß sich nicht mehr um die ganzen Grundlagen (Benutzer- und Rechteverwaltung, Design, Navigation, Datenablage, usw.) kümmern, sondern kann sich auf die eigentliche Aufgabe nämlich Lösen einer Aufgabe oder Bereitstellung eines Prozessablaufs konzentrieren. Ich gebe aber zu, daß es sehr viel Zeit braucht die SP-API zu verstehen und nutzen zu können.

2) Anwender: die von Dir angesprochenen Punkte (entstehendes Chaos) lassen sich in der Praxis meist durch Schulung vermeiden. Am Anfang bekommen eben nur wenig Poweruser erhöhte Rechte. Mit wachsender Erfahrung werden das mehr und man kann ihnen dann auch mehr Rechte geben. Chaos entsteht dabei eher selten, weil die User selbst ein Interesse daran haben es nicht entstehen zu lassen. Außerdem entsteht mit der Zeit ein ganz anderes Navigationsverhalten: man klickt sich nicht mehr durch unzählige Websites und Menüs, sondern man benutzt einfach die wirklich gute Suche und landet dann sofort an der gewünschten Stelle.

3) Insellösungen: SP hilft wirklich dabei Inseln abzuschaffen. Wenn Anwendungen in SP verlagert werden, arbeiten sie alle auf derselben technologischen Grundlage. Und die Daten werden alle an derselben Stelle (SQL Server) gespeichert. Das erleichert deutlich die Wartbarkeit (Backups, Updates, usw.). Außerdem hat es den Vorteil, daß alle Anwendungen gleich aussehen und gleich funktionieren, was die Anwender sehr freut und damit die Akzeptanz erhöht.

MarcoBeyer Als Antwort am 21 Juli 2011 12:10

Hallo Andi,

zu Punkt zwei:

Da sehe ich eher in deiner Aussage eher eine Unterstützung meiner Aussage: Warum braucht man Google? Weil das Internet nicht strukturiert ist und weil man keine festen Struturen hat. Warum braucht man die SharePoint suche? Weil SharePoint gut darin ist, mit unstrukturierten Inhalten umzugehen, weil die User sich eben nicht die Zeit nehmen, Strukturen für etwas zu entwickeln.

Ich bezweifle nur, dass in der Praxis Schulungen wie angestrebt durchgeführt und dann auch noch umgesetzt werden.

Zu Punkt 1:

Ich habe ein bisschen ein Problm mit Hiearchien im SharePoint: Wie gesagt, SharePoint ist genau für das gut, was du schon sagtest (Benutzer- und Rechteverwaltung, usw.), aber ich sehe große EInschränkungen in der Abbildung hierarchischer Zusammenhänge.

Würdest du z.B. sagen, dass SharePoint Listen ein Ersatz für Datenbanktabellen sind?

Marco

Andi Fandrich Als Antwort am 21 Juli 2011 12:34

1) Natürlich hast Du genauso Recht. Man kann aber durchaus versuchen den Wildwuchs einzudämmen. Und eine Suche kann auch bei gut strukturierten Daten schneller sein, als die manuelle Navigation an den Ablageort - insofern kein Widerspruch.

Und die Sache mit den Schulungen: auch ich kenne natürlich die Probleme der Praxis. Deshalb mein Hinweis, mit wenigen Power-Usern anzufangen und es später zu erweitern.

2) Ich würde nicht generell und um jeden Preis alle Daten in SP packen. "Einfache" Dinge mit nur wenigen Relationen lassen sich aber sehr gut damit abbilden. Schwierig wird es zum Einen bei sehr großen Datenmengen und zum Anderen bei extrem verschachtelten Daten und der Notwendigkeit mit einer Abfrage Daten aus vielen Listen zu erhalten (SQL: inner join). In solchen Fällen kann man durchaus auf eine eigene Ablage in einer (externen ) DB zurückgreifen. Die Vorteile von SP (Benutzerverwaltung, UI, usw.) hat man trotzdem.

Frank Daske Als Antwort am 21 Juli 2011 13:43

Marco,

man kann SharePoint mit vielen anderen (insbesondere marktführenden) Anwendungen vergleichen, z.B. Datenbanken, DMS Systemen, BI-Systemen oder insbesondere auch Web Content Management Systemen. In vielen Vergleichen könnte es dabei eng werden für SharePoint, da dieser mögliche spezielle Anforderungen nicht oder nur ansatzweise abbildet. Da kann ich Dir zustimmen.

Andererseits gibt es wohl aktuell keine Plattform, die die wichtigsten Funktionen aus all diesen Bereichen für Anwender einheitlich und übergreifend als Oberfläche und Framework (API) bereitstellt. Entwickler sind oft auf Details fixiert - klar: Sie müssen diese ja am Ende auch implementieren ;-) 
Gute Implementierungen versuchen aber, die ganz vielen Möglichkeiten der Plattform (out-of-the-box + 3rd party) gewinnbringend zu nutzen - und nicht "dagegen anzuimplementieren".

Das sollte man in Projekten berücksichtigen.

Notes 2 SharePoint Als Antwort am 21 Juli 2011 13:47

Hallo Marco,
hallo Community-Mitglieder!

0) Mein Vorwort

An diesem Beitrag muss ich mich beteiligen, weil ich diese Diskussion schon oft geführt habe und es mich im Prinzip jeden Tag betrifft. Microsoft betitelt SharePoint in der Tat als eine Art "Wunderwaffe" und das agressive (aber gekonnte) Marketing verleitet diverse Entscheider zur Ablösung ganzer Systeme und diese möchten dann z.B. ganze Infrastrukturen samt Applikationen auf SharePoint migrieren. In diesem Zusammenhang rede ich jetzt aus meiner Perspektive von der Migration IBM Lotus Notes/Domino nach Microsoft SharePoint 2007/2010. Dass das so ist, zeigt mir wieder die jüngste Vergangenheit: Ein Europa-weit aufgestellter Finanzdienstleister möchte diese Transformation vornehmen, gesteuert durch die Zentrale im Ausland. Eine politische Entscheidung, keine sinnvolle! Letztendlich hatte am runden Tisch keiner Ahnung, was SharePoint überhaupt ist und dennoch wird es auf jeden Fall eingeführt! Das ist doch einfach nur irrsinnig. Also wird man als Consultant gebucht, um jenen Menschen zu erklären, was SharePoint ist. Das heißt: erst Entscheidungen treffen, dann fragen! Ich habe generell selten Unternehmen erlebt, die SharePoint mit Bedacht einführen, weil das Verständnis für die Plattform und ihre (Un-)Möglichkeiten nicht vorhanden ist. "Echte" (komplexe) SharePoint-Applikationen sind mir bisher kaum untergekommen, nur vom Hörensagen und SharePoint ist oft nur ein Abfallprodukt im Unternehmen, weil irgendjemand mal eine Standalone-Installation ins Leben gerufen hat und dort rumgespielt wurde. Ich höre Mitarbeiter mehr schimpfen bzw. Sätze über die Verwirrung mit der Bedienung der Plattform aussprechen.

1) Entwicklung

Vielleicht kurz etwas zu meinen Skills: ich bin nicht tief in der MS-Programmierung (ich begleite / koordiniere diese eher) und habe aber zuvor mehrere Jahre auch unter Lotus Domino Anwendungen entwickelt. Und hier beginnen die "Schmerzen", wenn man die vielen Notes Ad-Hoc Applikationen sieht, die wirklich etabliert sind und dann die Umsetzungsmöglichkeiten in SharePoint betrachtet. Jeder erwartet eine "stylishe, supercoole, einfache" Plattform (sprich die Wunderwaffe) und die Enttäuschung über die Realität wird mitllerweile zur Routine :o(

Ich habe eine Analyse vorgenommen, um die Transformierbarkeit von Notes nach SharePoint zu beleuchten. Das Ergebnis wurde detailliert technisch begründet und hat folgendes ergeben:

Wo ist Notes gegenüber SharePoint überlegen:
- Berechtigungskonzept / Rollen
- Replikation
- Workflows (aka Agenten)
- Ansichtsgestaltung
- Deployment
- Portierbarkeit (ein Versionsmix ist meist kein Problem!)

Wo ist SharePoint gegenüber Notes überlegen:
- Mehrsprachigkeit

Tolles Ergebnis, oder? Ich finde es erschreckend. Alleine Marcos genannter Anwendungsfall mit der Verschachtelung (Hierarchie) "Projekte, Projektphasen, Projektmitarbeiter" ist ein gutes Beispiel: In SharePoint kann ich in Ansichten keine Masken (forms) auswählen, die Verschachtelung (aufklappbare Bereiche) und Abhängigkeit vom "Vaterdokument" (z.B. das Projekt) ist somit schon mal nicht möglich. Sollten z.B. (intelligente) periodische Benachrichtigungen (z.B. Eskalationen) nötig sein, dann ist ein periodischer Notes-Agent rucki-zucki erstellt, inkl. Zeitplan und das Deployment ist mal gar kein Problem. Aber nicht in SharePoint: da muss ich einen TimerJob in C#.Net programmieren und aus Visual Studio deployen. Das Debugging ist für mein Empfinden nicht wirklich gut möglich, da nicht einmal eine poplige MessageBox genutzt werden kann. Soviel erstmal dazu ...

2) Anwenderseite

Ich habe den berechtigten Eindruck, dass SharePoint genutzt wird, weil man es MUSS. Aber wollen tut das irgendwie keiner. Bei vielen Kunden (die auch externe Dienstleister im Haus haben) und SharePoint als Collaboration-Tool einsetzen, höre und sehe ich immer wieder dasselbe: Frustration über die Bedienung, keiner findet etwas, Chaos bei den Zugriffen ... viel wird per "Flurfunk" erledigt und das Portal hat kein valides Berechtigungskonzept und wächst planlos. Wie soll sich da auch jemand wohl fühlen.
Auch IT-affine Mitarbeiter haben z.B. Probleme mit der Office-Integration (die Ribbons in SharePoint 2010 sind nicht intuitiv). Und was bringt es, dass Dokument lokal abzuspeichern  und dann manuell in eine SharePoint-Dokumentbibliothek hochzuladen. Wenn man es per Email verschicken darf und SharePoint ein "nice-to-have" ist, dann wird es augenscheinlich nicht genutzt! Eine gute Suche ist an dieser Stelle auch kein Argument. Genauso wenig wie Schlungen oder PowerUser, die ggf. Mitarbeiter mit weniger Skills unterstützen.
Zudem macht SharePoint 2010 mit der Nutzung des Internet Explorer teilweise mehr Probleme als mit dem Firefox. Somit ist es verständlich, dass bei solchen MS-hausgemachten Fauxpas die Stimmung kippt.

3) Insellösungen

Tatsächlich sehe ich das sehr ähnlich wie Marco es schildert. Niemand weiß mehr wirklich genau, wo die Daten liegen. Über das "gut" und "schlecht" der Lösungen möchte ich, wie das auch vom Beitragsersteller gewünscht wurde, nichts sagen.
ABER: Was passiert wenn ich Release-gleich oder Release-höher migriere. Bei Release-gleich wäre es eigentlich eher als Deployment von Staging- nach Production-Umgebung zu sehen. Es ist einfach ein Problem! Und entsprechende Drittanbieter migrieren allenfalls Content vernünftig. Alles individuelle muss aufwendig nachgezogen werden oder ist ggf. auch gar nicht portierbar. Heisst im Klartext: neue SharePoint-Farm installieren, diverse Anwendungen von der Vorgängerumgebung wegschmeissen und neu machen. Das geht gar nicht!!! Fazit: Der ROI ist langfristig eher negativ und der Begriff "Investitionsschutz" sollte aus dem Vokabular gestrichen werden :o(

So, ich hoffe niemandem zu nahe getreten zu sein oder eine bunte, idyllische MS-Welt in Trümmer gelegt zu haben ;o) Bin auf Eure Statements gespannt ...

Gruß,
N2S

MarcoBeyer Als Antwort am 21 Juli 2011 14:39

Hallo Beitrags-Teilnehmer,

jetzt wird es richtig spannend. Ehrlich.

@Frank:

Im Grunde bestätigt Frank das, was ich vermute und was Notes 2 SharePoint unterstrichen hat: Meine Erfahrung zeigt, dass man gerade ind er Enwicklung sehr tief ins Detail geht - und ja, da geht es darum, die Farbe von Knöpfen bis ins Detail zu ändern und sie sogar benutzerbezogen zu titulieren (ok, ein Extrembeispiel, aber wahr und uns schon untergekommen).

Wenn ich jetzt eine Plattform habe, die Zitat "die wichtigsten Funktionen aus all diesen Bereichen" anbietet, dann kann das unterm Strich nur bedeuten, dass zwar alles theoretisch! möglich ist, aber wenig oder nichts im Detail. Und wenn, dann nur mit enormen Zusatzaufwand.

Ich als Entwickler werde doch aber daran gemessen, was ich im Detail für effiziente, einfach und intuitiv zu verwendene Lösungen implementieren kann, gekoppelt an Wirtschaftlichkeit und damit wettbewerbsfähigkeit.

Was soll ich meinem Kunden sagen, wenn dieser ein Feature von mir wünscht und ich ihm sagen muss, dass mein Unternehmen eben auf "de facto Standard" SharePoint Basis entwickelt und es dieses Feature eben einfach nicht gibt, weil wir nicht Zitat "dagegen animplementieren" wollen?

Und vor allem: Was kostet das ganze im Vergleich zur direkten Implementierung? Wie schnell bin ich diesen Kunden dann wohl los oder es wird erst gar keiner (z.B. weil ich nicht mehr wirtschaftlich bin!)?

@N2S

Ich muss schon sagen, dass sich alles in deinen Aussagen mit dem deckt, was man aus Fachartikeln findet, die sich ernsthaft und ohne politisches Interesse an SharePoint mit dem Thema befassen:

Siehe hier http://sharepoint360.de/2010/11/17/cio-magazin-user-kapieren-sharepoint-immer-noch-nicht/. Das ist genau das, was du mit Flurfunk beschrieben hast. Und das sind ACHTZIG Prozent der Anwender!!!

N2S hat geschrieben, dass ihm noch keine komplexen SharePoint-Applikationen untergekommen sind - das kann ich bestätigen. Ich verfolge das schon einige Jahre und ich sehe immer wieder nur die Oberfläche von SharePoint und ein paar Webparts. Und das liegt wohl nicht zuletzt an der mangelnden Fähigkeit von SharePoint selbst, als vielmehr daran, dass es 10mal so viel kostet, eine echte Anwendung auf SharePoint aufzusetzen, als es kosten würde, es z.B. direkt zu tun.

Auch dafür findet man massenweise Bestätigung im Web. Vor allem in sehr großen Unternehmen findet man out-of-the box installierte und kaum konfigurierte SharePoint Installationen, die dann dem von mir und N2S beschriebenen Problemen unterliegen und richtig Geld kosten.

Apropos: Es wird damit geworben, dass SharePoint so einen irren, positiven ROI hat und es werden Studien zitiert, in denen User vor SharePoint ca. 45 Minuten pro Tag mit der Suche nach Dokumenten verbringen, während sie mit SharePoint nur 10 - 20 benötigen. Mein Eindruck ist, dass es eher genau umgekehrt ist, weil nichts strukturiert ist und nach dem bemühen der Suche und Klick auf einen Eintrag dann noch mehr Zeit draufgeht, wenn man feststellt, dass das gefundene Dokument doch nicht das richtige ist, da Kollegen die Meta-Tags zu Dokumenten nicht ernst nehmen.

Das ist das Gegenteil von dem, was man mit dem ROI erreichen will. Vor allem, wenn man - wie N2S schreibt - bedenkt, dass man von einem Release zum nächsten mit Sicherheit alles neu aufbauen kann.

Mich würden dazu konkrete Argumente freuen, die das Gegenteil beweisen und die zeigen, dass man so etwas kostengünstig, administrativ überschaubar und mit akzeptablen Aufwand realisieren kann - also SharePoint inkl. allen darin eingebauten Sonderlösungen. Hier vermute ich einen gigantischen Kostenberg, der auf ein Unternehmen zukommt.

Wir haben es in der Praxis in mehreren Projekten erlebt, vor allem im Projektbetrieb mit vielen Mitgliedern aus unterschiedlichen Ländern: Ob mit oder ohne Schulung: Die Benutzer verstehen die Prinzipien nicht und investieren auch nicht die Zeit, um z.B. Inhalte vernünftig zu taggen (immerhin: wenn ich etwas falsch mache und Inhalte deswegen nicht gefunden werden, bin ich ja auch dafür verantwortlich, also mache ich es gar nicht erst). Und das liegt sicher nicht zuletzt daran, dass alles wie ein Baukasten wirkt.

Ich suche nach Beiträgen von Leuten, die aus der Praxis zeigen können, dass man eben doch entwicklerisch und vor allem aus wirtschaftlicher Hinsicht in der Lage ist, auf Basis von SharPoint komplexe Anwendungen entwickeln kann.

Ich würde gern konkrete Argumente sehen, wie man die von mir eingangs erwähnte komplexe Hierarchie abbilden kann - und das muss SharePoint nativ können, denn sonst ist es weder eine Wunderwaffe noch eine Entwicklungsplattform.

Ich möchte sehen, dass Entwickler in der Lage sind, z.B. das Event beim Löschen eines Benutzers aus einer Gruppe abzufangen und darauf in seiner Anwendung zu reagieren (z.B. Löschung mit den damit in Relation stehenden Daten).

Wenn das nicht möglich ist, dann befürchte ich geflickschusterte Lösungen, die nur für Abneigung sorgen und die mit vernünftigem Softwareengineering nichts mehr zu tun haben. Ich finde, ein Webentwickler muss so etwas wie Logging, Authentifizierung, etc. beherrschen oder zumindest adequaten Zugriff auf die API-Funktionen haben, um diese eben zu verwenden / zu erweitern.

Gruß,
Marco

FCaprio Als Antwort am 21 Juli 2011 15:07

Hallo,

ich werde heute Abend noch ausführlicher Antworten aber das muss ich jetzt mal loswerden:

Diese ganze Argumentation mit alles endet im Chaos liegt allein an den Mitarbeitern. Das passiert mit jedem anderen System auch. Wenn die Mitarbeiter nicht mit ziehen ist es sowieso zum scheitern verurteilt. Wer glaubt bitte, dass Sharepoint von Haus aus Struktur automatisch hinbekommt? Welches Programm kann das bitte? Selbst wenn es eines gibt, so ist das immer nur in Spezialfällen so.

Vielleicht sollten sich mal die Vertriebler an die nase fassen und nicht zu sehr ihre Versprechungen über die Eierlegende Wollmilchsau Sharepoint verbreiten. Das ist Sharepoint nicht.

Es ist wie mit der bei Chefs ach so beliebten Dokumentation. Keine Dokumentation der Welt ersetzt gute und erfahrene Mitarbeiter. Genau so wenig ersetzt Sharepoint einen ordentlichen und verantwortungsbewussten Mitarbeiter.

Man muss die Mitarbeiter langsam an Sharepoint heranführen und Ihnen zeigen wie es gemacht werden soll. Wie Andi schon sagte nicht gleich allen Power User Rechte geben.

Bei einem großen Kunden (HiFi Geräte Hersteller) wurde frühzeitig die Bremse gezogen und die Mitarbeiter mit Arbeitsanweisungen geführt (ala Metatags pflegen). Fällt jemand stark auf dies nicht zu tun gibts eine Abmahnung. Siehe da, es gibt kaum Abmahnungen und bei dieser Firma läuft Sharepoint 1a und wird gerne genutzt.

MarcoBeyer Als Antwort am 21 Juli 2011 15:25

Hallo CarePackage,

ok, bevor das aber in einen Beitrag zur Mitarbeiterschulung wird, möchte ich dich bitten, das ganze von Seiten der Entwicklungsfähigkeit anhand konkreter Beispiele zu beleuchten. Dabei ist die Kernaussage "SharePoint als Entwicklungsumgebung" und "SharePoint als Wunderwaffe".

Ich möchte unterm Strich herausarbeiten, in wiefern die Aussage als Entwicklungsumgebung" wahr ist und SharePoint als Universalplattform (also Wunderwaffe). Und das bitte anhand praktischer, konkreter Beispiele.

Und wenn wir von Entwicklung sprechen, möchte ich auch dazu konkrete Beisiele haben, wie man die dann geschilderten Szenarien abbilden kann. Nicht einfach grobe Aussagen.

Es wurde auch von keinem gesagt, dass SharePoint von Haus aus Struktur bietet. Wenn die Plattform jedoch so komplex ist, dass sie nicht verstanden und demnach gelebt wird (und das ist Praxis), helfen dir die geschultesten Mitarbeiter nicht.

Und die Argumentation mit Chaos sehe ich nicht:

Es ging darum, dass Insellösungen und Inhalte, die vorher auf Festplatten oder FileServern lagen, nun eben auf einereinheitlichen Plattform verfügbar sind (siehe Beitrag von Andi). Finden kannst du sie mangels Struktur aber fast ausschließlich durch die Suche. Das war die Kernaussage. Warum sollten User sonst Acces- und Excel-Inhalte einbinden können, wenn man doch so einfach coole, echte Lösungn auf SharePoint aufbauen kann?

Den von dir geschilderten Ansatz von Abmahnungen, wenn z.B. keine Metatags vernünftig eingepfelgt werden finde ich gut und auch konsequent. In den meisten Mittelstandsbetrieben (und eben NICHT Großkonzernen) ist dies jedoch nicht praktikabel.

Aber deine Aussage unterstreicht die Aussage des verlinkten Beitrags (User kapieren SharePoint immer noch nicht...). Das zu widerlegen oder zu bestätigen wollen wir hier diskutieren.

Ich freue mich auf deine Beteiligung,
Marco

Frank Daske Als Antwort am 21 Juli 2011 15:15

Marco,

ja, wenn sich Kundenwünsche nur mit hohem Aufwand oder anders für alle Beteiligten besser implementieren lassen, oder es ggf. bereits Lösungen am Markt gibt, dann sollte der Kunden tatsächlich so beraten werden. Das genau ist Beratung.

Aus diesem Grund ist das auch kein Job für Entwickler (nicht persönlich nehmen - Entwickler haben andere Skills). Der Kunde wird es - früher oder später - danken und bleibt dann auch über das eine konkrete Projekt hinaus erhalten.

Der Vergleich mit einer "direkten" (ohne SharePoint) Implementierung wird unterschiedlich ausfallen. Auch da werden ja normal Frameworks (z.B. für die GUI) verwendet. Einen Workflow oder eine Versionierung wirst Du nicht eben mal so nebenbei entwickeln, wie er in SharePoint einfach verwendet werden kann.

Wir machen ja nicht nur Projekte, sondern entwickeln Komponenten, die weltweit vertrieben werden und sich in ganz verschiedenen Umgebungen bewähren müssen. Ich will ja nicht sagen, das dies ein Kinderspiel ist. Aber wenn der Spezifikations-, Entwicklungs- und QS Prozess stimmt, dann liefert er stabile Implementierungen der gewünschten Features ... notfalls auch SharePoint mit bunten Knöpfen ;-)))))

MarcoBeyer Als Antwort am 21 Juli 2011 15:42

Hey Frank,

mal nebenbei: Ich bin nicht nur Entwickler sondern auch Inhaber eines Unternehmens (wir sind in Kiel).

Ich denke, es ist auch nicht so leicht, einen trade-off zu finden, wann man SharePoint vorziehen sollte und wann eben nicht. Sicher hat es seinen Reiz, ein Framework verwenden zu können und dann mit dem Gedanken zu spielen, da eben alles einzubauen.

Wenn man nachher aber um alle möglichen Ecken und Kanten herum muss und jede Menge Kompromisse eingehen muss, dann kann man ja mal überlegen, ob man ein Projekt auch nicht auch anders lösen kann.

Ich bin interessiert daran, diese Trade-Offs herauszufinden. Ich denke, dafür eignet sich der eingefärbte Knopf nicht so sehr :-) Da sollten wir vielmehr hierarchische Beispiele nehmen.

SharePoint ist ja ein System, dass sehr gut mit unstrukturierten Inhalten zurecht kommt (eben nicht zuletzt durch Taxonomien, Meta-Tags, Suche, usw.). Wie geht man jetzt aber damit um, wenn man eine Anforderung hat, in der man tatsächlich komplexe hierarchische Zusammenhänge abbilden und verwalten muss? (Diese Frage ist mehr als Richtungsfindung für diese Diskussion gemeint!)

Welche Teile von SharePoint kann man dann immer noch verwenden, was sollte man in den SharePoint als Applikation integrieren und welche Teile sollte man komplett ohne SharePoint realisieren?

Dein Beispiel mit den Workflows finde ich nicht so treffend: SharePoint Workflow Engine basiert auf WF. Natürlich kann ich mir ganz schnell mit SharePoint oder dessen Designer mehr oder weniger snnvolle Workflows zusammenklicken (und ja, auch schneller als Direktentwicklung). Wenn ich das nun aber in VS nutze, arbeite ich nativ mit der WF, wobei, wenn ich es für SharePoint nutze, wird die WF in das Objektmodell von SharePoint verpackt und bin ich an die API von SharePoint gebunden, unterliege also dessen Komplexität. Ich bin mir sicher, dass ich einen komplexen Workflow deutlich schneller und flexibler hinbekomme, wenn ich ihn  gleich über die WF realisiere, wenn ich an einem komplexen Problem arbeite. Und genau das ist ja der Punkt, wenn man komplexe Anwendungssysteme entwickeln soll.

Stelle dir an diesem Punkt mal vor, du solltest deinen SharePoint Workflow nun in eine in SharePoint integrierte Anwendung einbinden, die auf eine externe Datenbank zugreift - ich denke, hir wird's schnell abtenteuerlich (siehe Deployement, siehe Debugging, usw).

Das ist nicht so einfach, aber ich finde, das arbeitet die Fachpresse nicht heraus. Aber daran bin ich interessiert.

Marco

Andi Fandrich Als Antwort am 21 Juli 2011 16:19

Wow, hätte gar nicht erwartet, daß sich eine solche (gute!) Diskussion entwickelt :-)

Die meisten meiner Argumente habe ich ja erwähnt, möchte aber noch hinzufügen, daß ich SharePoint zwar gerne und oft lobe und verteidige, aber trotzdem nicht der Meinung bin, man müsse zwingend alles und jedes damit abbilden.

Als Entwickler bin ich aber schlichtweg von den gebotenen Möglichkeiten begeistert. Man ist dabei ja nicht gezwungen alles zu benutzen. Man kann durchaus "nur" die einheitliche Oberfläche und die Benutzerverwaltung verwenden und dann über selbstentwickelte Funktionen mit den Daten einer eigenen Datenbank arbeiten.

Und ich denke, wenn eine Firma ohnehin SharePoint einsetzt, dann lohnt es sich durchaus bei neuen Projekten darüber nachzudenken, ob sie in SharePoint abgebildet werden können. Wichtig bei einer solchen Entscheidung ist aber, daß jemand beteiligt wird, der sich wirklich sehr gut mit SharePoint auskennt. Natürlich gilt dasselbe für Alternativen, über die vielleicht nachgedacht wird. SharePoint ist allerdings dermaßen komplex, daß es fast unmöglich ist alle Nuancen zu kennen. Das macht es zwar auf der einen Seite unheimlich flexibel, auf der anderen Seite aber extrem schwer zu überschauen.

Ob allerdings eine Firma überhaupt SharePoint einsetzen sollte oder nicht steht dabei auf einem ganz anderen Blatt.

C.Kaiser Als Antwort am 21 Juli 2011 19:03

Hallo zusammen,

ich hoffe, dass ich dazu was schreiben darf - ich hab auch schon die ein oder andere Webseite im SharePoint erstellt. :-) Ich hatte dieses Schreiben auch schon vor ein paar Stunden angefangen, musste mich dann aber um dringendere Probleme kümmern, daher verzeihet, wenn ich etwas wiederhole.

Einige, von Dir angesprochene, Punkte (eigentlich fast alle) kann ich in einigen Projekten auch immer wieder nachvollziehen und auch hier im Forum werden die Probleme die SharePoint macht, recht deutlich - gerade jetzt mit dem Release von SharePoint 2010.

Ich persönlich würde das Ganze aber nicht an der Technologie festmachen, sondern einfach an dem häufig mangelnden Wissen (und das ist nicht böse gemeint) der Anwender und Admins. SharePoint wird so propagiert, dass man es einfach installieren kann, ein paar Webseiten anlegen und sofort lösen sich alle organisatorischen Probleme in Luft auf. Einige der Beraterkollegen verkünden dieses Vorgehen auch munter bei vielen Kunden.

Resultat: Bei Unternehmen steht ein schlecht installiertes SharePoint-System (von der Infrastruktur her), auf das die Key-User (meist Anwender) ohne übergeordnetes Konzept drauf losgelassen werden. Dadurch entsteht genauso ein Wildwuchs wie auch im Dateisystem was man eventuell ablösen wollte und die Unzufriedenheit gegen dieses Produkt wächst.

Das derzeitige Kernproblem, was ich zumindest beobachten kann, ist, dass es vielen fachlich Verantwortlichen überhaupt nicht klar ist, wieviel Planungs- und Organisationsaufwand in einer gut organisierten SharePoint Umgebung steckt und das man diesen Aufwand leisten muss, bevor SharePoint wirklich richtig gut nutzen kann.

Ich merke, dass sich diese ganze Problematik mit SharePoint 2010 noch deutlich verschärft hat. Die Installation und Pflege für eine 100%-tig saubere Infrastruktur ist komplexer geworden, die Entwicklung gegen SharePoint ist in meinen Augen komplexer geworden und gefühlt viel mehr Unternehmen setzen SharePoint 2010 ein. Gleichzeitg ist der Markt an erfahrenen SharePoint Entwicklern und Beratern wie leer gefegt und viele User lernen SharePoint einfach in dem Sie es benutzen. Dabei entsteht, wie oben bereits angemerkt, genau so ein Chaos wie auf etlichen File Servern, nur mit dem Unterschied, dass die Oberfläche komplexer ist als ein File System.

Allerdings geht es auch anders: Ich habe bereits eine sehr komplexe Applikation (keine einzelnen Webparts), welche auf SharePoint problemlos läuft, gesehen. Konkret geht es da um eine BI Anwendung in der recht abgefahrene Forecasts, Berechnungen, Cubes usw. dargestellt und bedient werden. SharePoint und Silverlight dient dabei als Front-End, zur Dateneingabe, Verarbeitung und Wiedergabe.

Gleichzeitig sitze ich gerade in einem Projekt in dem seit ein paar Jahren alles schief gegangen ist, was schief gehen kann. Ich denke, da kommt es ímmer auf alle beteiligten Personen an.

Notes 2 SharePoint Als Antwort am 21 Juli 2011 20:45

Hallo Community-Mitglieder!

Ich finde Christians Beitrag wirklich fair und sachlich formuliert. Keine Frage. Aber ich muss es mal skeptisch hinterfragen:
Wieviel Kosten & Aufwand hat die "abgefahrene BI-Anwendung" erfordert? Wenn das entsprechend große Budget zur Verfügung steht, dann darf auch ruhig mehr Aufwand dahinter stehen, weil da schließlich ein zahlender Auftraggeber hintersteckt. Wie beim Metzger: "Darf es noch was mehr sein?" ;o)

Ich mache meinen Gedankengang mal an 2 leidigen kleinen Beispielen klar:

1. Read-Only
Anforderung unter Lotus Notes/Domino: "Das Feld soll berechnet sein und schreibgeschützt (Read-Only)"
Lösung: Ein Klick im Domino-Designer und meist nur eine Zeile mit einer @Formel und die Anforderung ist umgesetzt.
SharePoint: Allein ein Listenfeld kann ohne Programmierung nicht auf Read-Only gesetzt werden. Somit fällt customizing raus! Was nun im Feld enthalten ist, wird dann auch ausprogrammiert.

2. Periodischer Agent
Anforderung unter Lotus Notes/Domino: "Wenn ein Dokument mit einem bestimmten Status im Feld A länger als 3 Tage nicht bearbeitet wurde, bitte einen Email mit Doc-Link senden."
Lösung: Periodischer Agent wird fast programmierfrei erstellt. Die Feldabfrage erfolgt über eine Ansicht, die mittels View-Selection Formel alle Dokumente vorselektiert, somit geht der Agent alle Dokumente nacheinander durch und versendet die E-Mail an den Bearbeiter.
SharePoint: Da es periodisch laufen muss, entfällt ein Workflow mittels SharePoint Designer. Alles muss 100% programmiert werden (TimerJob). Der Agent läuft über alle Objekte in der Liste/Bibliothek, weil SharePoint keine vernünftigen View-Selections unterstützt. Somit kriege ich bei wachsender Anzahl von Objekten ein Performance-Problem.

Fazit: Zwei vermeintlich super-einfache Fallbeispiele mit großer Wirkung. Ich persönlich finde das ziemlich sche****

*Sarkasmus an* Also würde ich nur zu gerne wissen, was diese hippe, supercoole, abgefahrene BI-Anwendung gekostet hat. Das mag vielleicht daran liegen, dass ich derzeit eine Anfrage für die Transition von fast 100 Applikationen habe und falls die Aufwände z.B. bei 700% Mehraufwand pro Applikation gegenüber dem Programmieraufwand aus dem Legacy-System liegen, so macht sich das ggf. bemerkbar!? *Sarkasmus aus*

Gruß,
N2S

MarcoBeyer Als Antwort am 21 Juli 2011 21:19

@Christian und N2S

Ich kann die von N2S aufgezeigten Probleme genau unterstreichen. Ich habe das Gefühl, dass man bei fast jeder einigermaßen aufwändigeren Anforderung überlegen muss, wie man es "in SharePoint" macht, oder "ob überhaupt" und wenn ja, welche Umwege man gehen muss. Den direkten Weg ohne Probleme und vor allem einen aus Sicht des Software Engineering sinnvollen hat auf Basis von SharePoint bislang noch niemand aufgezeigt.

Zumal man ja auch noch anhand der konkreten Architektur dieser "abgefahrenen" Applikation definieren müsste, ob man sie wirklich als echte komplexe Applikation einordnen kann.

Denn Daten aus verschiedenen Quellen irgendwie in SharePoint über eine ApplicationPage zu aggregieren ist nicht so der Hit. Vor allem sieht das dann immer so "abgefahren" aus, wenn man Charts verwendet, um Zahlen ein Bild zu geben. Ich bezweifle aber, dass es sich dabei um eine Anwendung handelt, wie N2S und ich hier angesprochen haben (und die man nirgendwo im Internet sonst findet).

Ich finde es ernsthaft fraglich, ob es immer nur am mangelnden Wissen der Entwickler oder Admins liegt. Wieso findet man dann nicht mal Hersteller-seitig adequate Informationen rund um diese Thematik?

Ich habe noch keinen einzigen konkreten Hinweis bislang bekommen, es wird nur auf die Komplexität, die Kosten, Probleme, Unwissenheit und die Umwege gesprochen. Ich weiß nicht, wie es euch geht, aber ich werde heute daran gemessen, wie beherrschbar und wirtschaftlich meine Anwendungen sind und ob sie länger und kurzfristig einen messbaren Vorteil (horizontal und vertikal) bringen.

Anwendungen, die ich auf SharePoint aufsetze, können das nicht leisten, es sei denn, sie passen genau ins Muster von SharePoint - Content produzieren, diesen Taggen und irgendwie über die Suche verfügbar machen. Kündenwünsche können nicht oder nur sehr eingeschränkt umgesetzt werden, da sie x-fach prozentig mehr kosten, als sie nativ zu entwickeln und da das in der heutigen Zeit eh mein Mensch (vielmehr Unternehmen) mehr bezahlen kann.

Marco

Notes 2 SharePoint Als Antwort am 22 Juli 2011 12:47

Hallo Community-Mitglieder!

Erstmal muss ich mich (wieder mal) Marco anschließen. Denn anscheinend wird hier völlig ignoriert, dass hier von mir ganz konkrete Beispiele genannt wurden, wo ich es mit anderen Systemen besser hinkriege. Und am Ende des Tages ist wirklich nur entscheidend, wie beherrschbar (auch im Hinblick auf den Software-Lebenszyklus) und wirtschaftlich die Applikation ist. Marco hat es absolut treffend formuliert:

[quote user="MarcoBeyer"]Ich habe noch keinen einzigen konkreten Hinweis bislang bekommen, es wird nur auf die Komplexität, die Kosten, Probleme, Unwissenheit und die Umwege gesprochen. Ich weiß nicht, wie es euch geht, aber ich werde heute daran gemessen, wie beherrschbar und wirtschaftlich meine Anwendungen sind und ob sie länger und kurzfristig einen messbaren Vorteil (horizontal und vertikal) bringen. [/quote]

Was Christian sagte: "Nicht falsch verstehen, ich fluche täglich, teilweise stündlich (je nachdem welche Anforderung es gibt) über SharePoint und muss den Anwendern auch hin und wieder sagen, dass einige Anforderungen mit einem vertretbaren Maß an Aufwand nicht umzusetzen sind - aber wo gibt es das denn nicht?"
Das kann ich Dir beantworten!

Ich sehe seit Jahren Ad-Hoc oder Anwendungen, die mit moderatem Aufwand erstellt wurden. Ich sehe genauso komplexe Anwendungen, die absolut wartbar sind deren Funktionsumfang zyklisch in mehr als 10 Jahren gewachsen ist. Und diese Anwendungen laufen unter Lotus Notes/Domino! Warum der Hype da ist, diese Plattform zu verlassen, das soll mir mal einer beantworten, wenn meine Liste unten gelesen und verstanden wurde:

1. Agenten (sequentiell und periodisch)
In Notes gar kein Problem. Der Domino-Designer lässt es zu, den Agenten auch mit ein paar Klicks von sequentiell auf periodisch umzuschalten. Die Domino-Server Logs geben mir immer guten Aufschluss über die Laufzeiten oder Fehler, entsprechende Print-Anweisungen im Code werden auch ins Log geschrieben Unter SharePoint wird der SharePoint-Designer genannt, aber der kommt schnell an seine Grenzen. Also entweder NINTEX Workflow kaufen oder direkt Visual Studio auspacken und fleißig Worklfows in C#.Net codieren (sequential workflow, TimerJob).

2. Read-Only ohne Codierung in einer Maske (Liste) setzen
In Notes ist es ein Klick und fertig. In SharePoint geht es nicht, außer ich programmiere eine Liste. Oder man kaufe sich ein Drittanbieter-Tool, das diese Erweiterung hinzufügt.

3. Berechtigungen und Rollen
In Notes habe ich pro Anwenung (*.nsf) eine ACL (Access Control List) und darüber kann ich Berechtigungen für Server, Gruppen und Personen steuern. Auch Rollen kann ich hinzufügen (z.B. Rolle "Manager"). Dadurch kann ich dynamisch Informationen verbergen oder freigeben. SharePoint kennt z.B. das Rollenkonzept nicht und viele Anwendungen basieren darauf. Personenbezogene Daten werden dadurch beispielsweise geschützt (Datenschutz). Oder spezielle Konfigurationsbereiche werden für eine bestimmte Rolle freigegeben. SharePoint-Gruppen lassen im übrigen auch nicht verschachteln und da das Rollenkonzept schlichtweg nicht existiert, kann ich entweder alles oder nichts freigeben. Dazu gab es auch schon mal nen Beitrag von mir:
http://sharepointcommunity.de/forums/t/10244.aspx
In SharePoint wird das Berechtigungschaos schnell groß, also kauf man sich doch mal Axceler ControlPoint, weil der Standard einfach nur grausam ist.

4. Ansichtsgestaltung
Mit Notes-Views kann ich:
- Objekte bliebig verschachteln
- diese Ansichten auch in Masken einbetten
- Objekte selektieren (z.B. nur Form="Rechnung") anzeigen
- Symbole in Abhängigkeit von Flags anzeigen (z.B. typische KPI-Symbole [Ampel] oder Rechnungen haben andere Symbole als Projekte)
In SharePoint:
Geht es nicht! Verschachtelung in einer View nur bis zu 2 Ebenen möglich und der Rest fällt komplett raus.

5. Deployment
In Notes habe ich ein Template-File (*.ntf), mit der ich jederzeit die produktive Anwendungen (*.nsf) ausrolle oder update. Darin ist alles enthalten: Gestaltung, Logos, Agenten (inkl. Zeitplan falls periodisch), Masken, Ansichten, Skriptbibliotheken, Schnittstellen in andere Systeme (sprich: Nutzung offener Standards), etc.
Bei SharePoint darf man eigentlich gar nicht von Deployment reden? Es gibt nämlich kein richtiges Verfahren für Test, Staging und Production! Das Deployment-PDF für SharePoint 2010 (von Microsoft) absolut unbrauchbar.

6. "Weiche Migration"
Jede Notes-Anwendung (gekapselt in eine NSF-Datei) ist abwärtskompatibel. Wenn ich also eine Anwendung habe, die mit Notes R6 erstellt wurde, dann läuft diese auch unter Notes R8. Falls diese R6 Anwendung keine Funktionen (Codierung) benutzt, die es erst ab R6 gibt, läuft diese auch unter R5. Heisst im Klartext: Ein Serverupgrade ist hinsichtlich der Applikation gefahrlos. Ein Versionsmix bei Servern und Client ist ebenfalls meist unproblematisch.
Bei SharePoint haben die Versionen 2007 und 2010 nur den Namen gemeinsam. Hier ist teilweise gar keine Migration möglich und das heisst: in die Tonne und neu machen!

Mein Fazit:
SharePoint hat die Regeln des Software-Engineering nicht eingehalten ... normale Entwicklungsprozesse über Test, Staging und Production sind nicht möglich. Das Deployment ist bei SharePoint nicht klar geregelt (Deployment per Visual Studio 2010, Deployment per SharePoint 2010-Verwaltungsshell, Deployment per STSADM.exe, Deployment aus InfoPath 2010 oder dem SharePoint Designer). Visual Studio muss sogar auf dem SharePoint-Server ausgerollt sein, wenn man ein Projekt deployen möchte! Das wollte mir niemand glauben. Nur als Solution gekapselt kann ich die Funktion mitnehmen, aber eine QS für den Ziel-Server kann ich nicht wirklich machen. Die SharePoint Sandbox finde ich wenig hilfreich.

Ich könnte noch x-fach mehr Beispiele hier aufzählen, aber langsam geht meine Tippfreude zuneige. Also: in Lotus Notes/Domino habe ich eine tolle Groupware-Software. Diese enthält Zusammenarbeitsfunktionen, die als zentraler Bestandteil der Email-Infrastruktur (Mail-Server) sowie als Plattform für Geschäftsanwendungen (Application-Server) eingesetzt werden.

In SharePoint frage ich mich jedesmal, ob es überhaupt geht. Das tue ich bei Notes-Anwnedungen nicht. Marco hat es auch hier treffend formuliert:

[quote user="MarcoBeyer"]Ich kann die von N2S aufgezeigten Probleme genau unterstreichen. Ich habe das Gefühl, dass man bei fast jeder einigermaßen aufwändigeren Anforderung überlegen muss, wie man es "in SharePoint" macht, oder "ob überhaupt" und wenn ja, welche Umwege man gehen muss. Den direkten Weg ohne Probleme und vor allem einen aus Sicht des Software Engineering sinnvollen hat auf Basis von SharePoint bislang noch niemand aufgezeigt.[/quote]

Also lieber Christian, Du fragtest "...und muss den Anwendern auch hin und wieder sagen, dass einige Anforderungen mit einem vertretbaren Maß an Aufwand nicht umzusetzen sind - aber wo gibt es das denn nicht?"
Frage beantwortet? ;o) Allein die aufgezählten Nachteile (insbesondere dadurch kein ROI, weil man Teile oder gar eine ganze Applikation beim nächsten SharePoint-Release wegschmeissen kann) sollten doch mal wachrütteln.

Gruß,
N2S

FCaprio Als Antwort am 22 Juli 2011 13:09

[quote user="Notes 2 SharePoint"]

Mein Fazit:
SharePoint hat die Regeln des Software-Engineering nicht eingehalten ... normale Entwicklungsprozesse über Test, Staging und Production sind nicht möglich. Das Deployment ist bei SharePoint nicht klar geregelt (Deployment per Visual Studio 2010, Deployment per SharePoint 2010-Verwaltungsshell, Deployment per STSADM.exe, Deployment aus InfoPath 2010 oder dem SharePoint Designer). Viual Studio muss soagr auf dem SharePoint-Server ausgerollt sein, wenn man ein Projekt deployen möchte! Das wollte mir niemand glauben. Nur als Soluion gekapselt, kann ich die Funktion mitnehmen, aber eine QS für den Ziel-Server kann ich nicht wirklich machen. Die SharePoint Sandbox finde ich wenig hilfreich.

Also da muss ich dir wiedersprechen, es ist klar geregelt. Nur muss man die Vorgehensweise verinnerlichen und kennen.

Man muss kein Visual Studio auf dem Server installiert haben. Man kann aus der Solution ein Paket (.wsp) erstellen und dieses dann mit stsadm.exe deployen. Auch kann man hier die Featrues/Funktionen aktivieren. Ich hatte Anfangs auch meine Probleme aber den Weg einmal für mich dokumentiert und gut ist.

Bei InfoPath muss ich dir allerdings zustimmen! Da kommen mir nur Worte wie "WTF!" in den Sinn ;)

Notes 2 SharePoint Als Antwort am 22 Juli 2011 13:18

Hallo CarePackage,
hallo Community-Mitglieder!

Wenn ich keine Solution als Paket (*.wsp) erstelle, muss ich eine lokale Installation auf dem SharePoint-Server haben. Visual Studio "motzt" einen nämlich sonst an, dass er keinen SharePoint-Server kennt. Somit stimme ich Dir zu, aber meine Aussage ist nicht falsch ;o)

Nichtsdestotrotz: Komplexe Anwendungen sind nach wie vor nicht vorhanden! Und wenn es kein Deployment gäbe, so könnte man natürlich auch keine Applikationen ausrollen. Trotzdem ist das SharePoint-Deployment gebenüber Lotus Notes/Domino eine Vollkatastrophe!

Gruß,
N2S

Andi Fandrich Als Antwort am 22 Juli 2011 13:15

Also, ich mache dann auch nochmal mit :-)

[quote user="Notes 2 SharePoint"]Ich sehe seit Jahren Ad-Hoc oder Anwendungen, die mit moderatem Aufwand erstellt wurden. Ich sehe Anwendungen, die absolut wartbar sind deren Funktionsumfang zyklisch in mehr als 10 gewachsen ist. Und diese Anwendungen laufen unter Lotus Notes/Domino! Warum der Hype da ist, diese Plattform zu verlassen[/quote]

Dasselbe könnte ich über SharePoint sagen (seit Jahren Anwendungen mit moderatem Aufwand). Ich gebe zu, daß ich Notes überhaupt nicht aus eigener Erfahrung kenne, aber ich höre immer nur negatives darüber. Und nicht nur, weil ich mich naturgemäß mehr in MS-nahen Kreisen bewege, sondern durchaus auch von Leuten die Notes sehr gut kennen. Wie gesagt, ich kenne es selbst nicht und bin da ziemlich neutral. Woher also der Hype kommt, daß so viele meinen unbedingt wecheln zu müssen, kann ich nicht sagen.

Was ich auch noch sagen kann, ist daß wir schon mehrmals Anwendungen auf SharePoint umgesetzt haben, bei denen hinterher Notes-Entwickler meinten, sie hätten das so nicht mit vergleichbar geringem Aufwand hinbekommen. Ob das so stimmt, kann ich nicht sagen, aber ich halte die nicht alle für unfähig.

Tut mir leid, aber ich habe im Moment (wie fast immer) keine Zeit noch detaillierter auf das Thema einzugehen. Und ich möchte betonen, daß ich keinen Glaubenskrieg möchte und auch nicht SharePoint um jeden Preis verteidigen oder gar als das Nonplusultra herausstellen.

Notes 2 SharePoint Als Antwort am 22 Juli 2011 13:26

Hallo Andi,
hallo Community-Mitglieder!

[quote user="Andi Fandrich"]Dasselbe könnte ich über SharePoint sagen (seit Jahren Anwendungen mit moderatem Aufwand). Ich gebe zu, daß ich Notes überhaupt nicht aus eigener Erfahrung kenne, aber ich höre immer nur negatives darüber. Und nicht nur, weil ich mich naturgemäß mehr in MS-nahen Kreisen bewege, sondern durchaus auch von Leuten die Notes sehr gut kennen. Wie gesagt, ich kenne es selbst nicht und bin da ziemlich neutral. Woher also der Hype kommt, daß so viele meinen unbedingt wecheln zu müssen, kann ich nicht sagen.[/quote]

Komischerweise kenne ich Dutzende Notes-Entwickler oder auch Java-Entwickler und bisher habe ich diese Aussage nicht ein einziges Mal gehört. Aber wie dem auch sei: Lest ihr meine Beispiele nicht? Wofür schreibe ich den ganzen Mist hier, wenn ihr (sorry!) diese Tatsachen unkommentiert lasst und danach allgemeine Statements abgebt. Klar, ein Glaubenskrieg hilft wirklich niemandem. Aber bisher konnte hier niemand meine Fakten widerlegen, geschweige denn selber ein Beispiel geben, wo es mit SharePoint besser geht. Sucht Euch doch aus der Liste einen Punkt raus und beweist mir das Gegenteil.

Gruß,
N2S

MarcoBeyer Als Antwort am 22 Juli 2011 13:36

Hallo Mitglieder,

@Andi

Dein Post war eine totale Null-Aussage und hat nicht mit dem Thema hier zu tun. Wir wollen hier Fakten herausarbeiten und keine Hinweise auf nicht vorhandene Zeit. Mir scheint, als könntest du keine Argumente propagieren.

@N2S

Du bringst sehr gute Beispiele und diese Diskussion voran, aber bitte versuche, das etwas weniger Lotes / Domino-lastig zu gestalten, da dann nämlich (wie wir jetzt sehen) der Glaubenskrieg anfängt und hier einige mitschreiben, die ihre berufliche Tätigkeit sehr auf den SharePoint setzen.

Es ist vielleicht auch gar niht so interessant, wie gut man das mit einem anderen System machen kann, als vielmehr, was SharePoint nicht kann und es demnach auch nicht tauglich als Entwicklungsumgebung macht. Bzw. in welchen Szenarien SharePoint den Entwickler stark einschränkt, was letztlich die immer wieder beschriebenen und bestätigten hohen Kosten einer SharePoint-Installation ausmacht.

Denn: Wenn etwas nicht direkt mit meinem Baukasten / mit meiner Plattform geht, muss ich Umwege suchen, flickschustern und tricken. Das kostet Zeit und damit Geld und führt zu einer schlechteren Software.

@Alle

N2S und ich haben nun wirklich eine Reihe sehr konkreter Aspekte und Fallbeispiel geschrieben. Zielführend wäre, wie wir anhand weiterer, konkreter und prxistauglicher Beispiele eruieren könnten, inwiefern SharePoint denn nun als Wunderwaffe oder Entwicklungsumgebung dient (oder eben nicht).

Bitte Fakten, belegbare Beispielprojekte, usw. Keine Nullaussagen bitte! Bislang wurde kein einziges Argument von N2S und mir wirklich aufgegriffen geschweige denn widerlegt. Eher bestätigt.

Marco

MarcoBeyer Als Antwort am 22 Juli 2011 13:24

Hallo Community-Mitglieder!

ich finde das ganze schon hoch interessant. Wie N2S ja schon schrieb, werden die Argumente, die eigentlich nur er und ich aufgeführt haben, durch ominöse Beispiele in Richtung Machbarkeit verzerrt - dann haben wir wieder jede Menge Masse, kein Mensch weiß mehr, worum es eigenlich ging und die Qualität des Beitrags leidet.

Ich habe mir die Sheets zur Metro-Group mal angesehen und sehe da wieder nur Webparts und ein paar Charts (und bei im Schnitt 3 Entwicklern in einem Zeitraum von 3 Monaten (so steht's im Sheet) zweifle ich die komplexe Anwendung stark an, vermute vielmehr, dass es für Metro ein Einstieg ins Thema war, das steht auch so im Sheet).

Christian, ich finde deine Aussage, dass du deine Kunden dazu bewegen möchtest, so viel Standard wie möglich zu nutzen, Ihnen dann aber auch oft sagen musst, dass das Gewünshte nicht mit vertretbarem Aufwand umzusetzen sind, höchst bedenklich!

Haben wir denn keinen Wettbewerb mehr, wenn alles Standard und gleich ist und bestimmte Sachen einfach mit diesem Standard nicht machbar sind (egal, ob jetzt die Technlogie oder der unwissende Anwender, Entwickler oder Admin dran Schuld ist)?

Seien wir mal ehrlich: Es gibt nur eine Möglichkeit, dass ich eine Aufgabe nicht für einen Kunden realisieren kann: Wenn sein Budget nicht reicht. Wenn ich diese Aufgabe bedingt durch meine Plattform nicht in den Budgetgrenzen des Kunden realisieren kann, dann muss ich mir andere Wege suchen (oder eben meine Plattform oder meinen (sorry) Baukasten in Frage stellen.

Hier kann ich N2S wieder unterstützen: Die meisten Dinge lassen sich mit sehr moderatem Aufwand erstellen, wenn man ein vernünftiges Software Engineering beherrscht. Zumal man ja auch nicht alles neu entwickeln muss, sondern Bewährtes wiederverwenden kann (das übrigens ist eines der Gundkonzepte objektorientierter Programmierung),

Mir fehlen immer noch die konkreten Beispiele und Fakten, die mir zeign, dass SharePoint die Entwicklungsplattform ist. Stattdessen bekomme ich nur Overhead und stark einschränkende Richtlinien bestätigt.

Marco

C.Kaiser Als Antwort am 22 Juli 2011 13:40

[quote user="Notes 2 SharePoint"]

Also lieber Christian, Du fragtest "...und muss den Anwendern auch hin und wieder sagen, dass einige Anforderungen mit einem vertretbaren Maß an Aufwand nicht umzusetzen sind - aber wo gibt es das denn nicht?"
Frage beantwortet? ;o) Allein die aufgezählten Nachteile (insbesondere dadurch kein ROI, weil man Teile oder gar eine ganze Applikation beim nächsten SharePoint-Release wegschmeissen kann) sollten doch mal wachrütteln.

Hallo zusammen,

eins haben wir gemeinsam, ich habe keine Lust und zeit mehr soviel Tippaufwand zu leisten daher nur eine kurze Antwort auf diesen kleinen Textausschnitt:

Nein, die Frage ist nicht beantwortet, weil Du auf den Kern der Frage nicht eingegangen bist: Das Du mit Lotus Notes oder irgendwelchen anderen Systemen alle Anforderungen der Anwender sofort und ohne Probleme umsetzen kannst (und das war meine Frage).

Weiterhin suchst Du dir spezielle Anwedungsfälle heraus wo Notes klar im Vorteil ist (ja das geben ich zu, warum auch nicht). Aber kannst Du mit Lotus Notes das von mir angesprochene Projekt umsetzen? Ich denke da wirds auch wieder schwierig.

Ich kenne Lotus Notes nicht und daher ist es müssig für mich detaillierte Anwendungsfälle rauszupicken was SharePoint gegenüber Lotus für einen Vorteil bietet, aber ich bin mir sicher, dass deine Argumentationslinie genauso "Pro"-SharePoint umgedreht werden kann und Lotus dann ins schlechte Licht rückt - von daher halte ich das persönlich nicht für eine angemessene Argumentationsgrundlage.

Ich habe ein Projekt inkl. Kunde und downloadbarer Präsentation genannt in der SharePoint als Entwicklungs- und komplexerer Anwendungsserver genutzt wird (auf diese Kernfrage "Kennt jemand ein solches System" bin ich eingangen) und das ist auch nicht der einzige Anwendungsfall - weitere projekte werde ich hier im Forum aber nicht ausbreiten, dass kann man gerne mit mir persönlich auf der o.g. User Group besprechen.

Software Engineering Richtlinien & Prozesse kann man ebenfalls einhalten:
- Test-, Staging- & Produktivsystem sind problemlos möglich (klare Regeln müssen natürlich festgelegt werden)
- Vorgehensmodelle wie Wasserfall, V-Modell oder Agil ebenfalls (ich präferiere hier eher das Agile-Modell inkl. Prototyping, weil es aus meienr Sicht besser zu Web-Entwicklungen passt)
- Wartbare und Versions kompatible Software kann man in SharePoint ebenfalls schreiben (da sehe ich dann auch eher den Entwickler in der Pflicht. Überspitzt gesagt: "*** in -> *** out")

Noch ein letzter Punkt, da man hier ja schon fast angefeindet wird, wenn man nicht auf die Kontra-Schiene aufspringt ;-)
Ich persönlich empfinde den derzeitigen SharePoint-Hype ebenfalls als kontraproduktiv. Gründe hierfür kann man meinem ersten Post entnehmen, wenn man ihn verstanden hat - Sharepoint Einführungen sind mir derzeit viel zu politisch geprägt. ;-) :-P

Ich versuche das Ganze nicht "Schwarz - Weiß" zu sehen, sondern habe denke ich klar und deutlich gemacht, dass es durchaus Projekte gibt (und das auch nichtht wenige und egal in welchem Komplexitätsgrad), die sich sowohl wirtschaftlich gelohnt haben und eine große User-Aktzeptanz hervorgerufen haben. Genauso gibt es schlecht gelaufene Projekte wo der genannte ROI einfach nicht gegeben ist und man ordentlich drauf gezahlt hat - beides habe ich erlebt und erlebe es noch. Aber das findet man überall, auch bei Lotus Notes.

Das wars von mir zu diesem Thema :-)

Notes 2 SharePoint Als Antwort am 22 Juli 2011 14:03

Hallo Community-Mitglieder!

[quote user="C.Kaiser"]Ich kenne Lotus Notes nicht und daher ist es müssig für mich detaillierte Anwendungsfälle rauszupicken was SharePoint gegenüber Lotus für einen Vorteil bietet, aber ich bin mir sicher, dass deine Argumentationslinie genauso "Pro"-SharePoint umgedreht werden kann und Lotus dann ins schlechte Licht rückt - von daher halte ich das persönlich nicht für eine angemessene Argumentationsgrundlage.[/quote]

Diesen Einwand und auch Marcos Bitte, es nicht so Domino-lastig zu gestalten, nehme ich für mich mit. Kein Problem ;o)

[quote user="C.Kaiser"]Noch ein letzter Punkt, da man hier ja schon fast angefeindet wird, wenn man nicht auf die Kontra-Schiene aufspringt ;-)
Ich persönlich empfinde den derzeitigen SharePoint-Hype ebenfalls als kontraproduktiv. Gründe hierfür kann man meinem ersten Post entnehmen, wenn man ihn verstanden hat - Sharepoint Einführungen sind mir derzeit viel zu politisch geprägt. ;-) :-P[/quote]

Anfeindungen sind sicherlich nicht zielführend, aber bei Deinem Zitat kommen wir zum Resultat der ganzen Geschichte. Daher musste ich faktisch dennoch aufzeigen, dass der Hype "funktionierende Systeme sinnlos ersetzen" (Beispiele gab's ja genug) kontraproduktiv ist.

Und Marco, natürlich verdiene ich auch mein Geld mit SharePoint ... aber mich betreffen insbesondere die Transitionen von der IBM-Plattform auf die MS-Plattform. Und wenn meine von Christian als "speziell" betitelten Anwendungsfälle hier zu jede Menge Contra führen, dann lest sie Euch nochmal durch. Denn das ist ganz allgemein in vielen Anwendungen nötig und im Prinzip ist es total egal, ob das eine Notes-Anwendung ist oder eine ganz andere Plattform als Grundlage dahintersteht. Faktisch sind das wirklich "No-Go's" und im Prinzip gibt es hier keinen, der mir sagt, wie es besser geht. Natürlich nur, weil die Anwendungsfälle so speziell sind ;o)

Zum Schluss nehme ich nur einen Punkt (rein auf SharePoint bezogen): siehe "6. Weiche Migration" in meinem Beitrag von 12:47 Uhr
Bei SharePoint haben die Versionen 2007 und 2010 nur den Namen gemeinsam. Hier ist teilweise gar keine Migration möglich und das heisst: in die Tonne und neu machen!
Der Grund reicht mir vollkommen!

Gruß,
N2S

C.Kaiser Als Antwort am 22 Juli 2011 14:16

Hi - ich kann nicht anders ;-)

Es geht doch nicht darum, dass die Anwednugnsfälle speziell sind, sondern darum, dass gezielt Anwendungsfälle herausgepickt werden die de facto nicht einfach funktionieren im SP-Umfeld - genauso, und das schrieb ich bereits, kann man Anwendungsfälle Pro-SP raussuchen, die mit anderen Systemen nicht funktionieren. Daher mein Hinweis, dass ich diese Argumentationslinie nicht zielführend empfinde.

[quote user="Notes 2 SharePoint"]

Anfeindungen sind sicherlich nicht zielführend, aber bei Deinem Zitat kommen wir zum Resultat der ganzen Geschichte. Daher musste ich faktisch dennoch aufzeigen, dass der Hype "funktionierende Systeme sinnlos ersetzen" (Beispiele gab's ja genug) kontraproduktiv ist.

Davon halte ich genauso wenig und rate auch davon ab und ich habe auch nie mit einer Silbe erwähnt, dass man bestehende einwandfrei funktionierende Systeme sinnlos ersetzen soll.

Ihr habt ein Beispielprojekt gefordert in dem Softwareentwicklungsrichtlinien, Vorgehensmodelle und komplexe Software  mit Sharepoint produziert wurde - das habe ich geliefert und ich bitte darum zu verstehen, dass ich hier öffentlich keine weiteren Projekte oder Kunden ausbreiten werde.

Ihr könnt es mir glauben oder auch nicht, aber ich kenne genügend Projekte, in denen alle von euch geforderten Aspekte wirtschaftlich (ROI), fachlich (Useraktzeptanz, Verbesserung der Abreitsabläufe, vereinfachung) und technisch (Wartbar, Versionssicher & deploybar) umgesetzt wurden - genauso, und da wiederhole ich mich zum letzten Mal, kenne ich die andere Seite der Medaille.

ABER und da bleibe ich bei weil auch schon mehrfach erlebt: Das gibt es überall und in jedem Projekt vollkommen losgelöst von der Technologie.

MarcoBeyer Als Antwort am 22 Juli 2011 14:22

Ich glaube, wir brauchen eine Wende in dieser Diskussion,

N2S hat eine Menge guter Beispiele geschrieben und auch ich finde, dass sie nicht speziell, sondern eher konkret sind. Christian schreibt darauf, geht, geht, geht, geht mit SharePoint, ohne aber konkrete Beispiele zu nenen. Unterm Strich: Es wird nicht konkret darauf eingegangen.

Ich finde, wir brachen Fallbeispiele. Dass SharePoint eine mächtige Plattform ist, habe ich hier nie in Frage gestellt, ich möchte nur wissen, inwieweit SharePoint taugt, wenn:

Wir haben einen fiktiven Anwendungsfall, in dem wir eine Menge Informationen relational Verwalten muss (nehmen wir ein System für das Projektmanagement: Da gibt es Projekte, Projektphase, Projekt- und Projektphasenmitarebiter). Ich brauche demnach eine Rollenverwaltung und muss z.B. darauf reagieren können, wenn ein Mitarbeiter systemseitig gelöscht wird (z.B. alle Zeiteinträge entfernen, die dieser erzeugt hat (nur als Beispiel jetzt)).

Ich möchte über die Oberfläche aber auch suchen können, welche Projekte "Mitarbeiter A" erstellt hat und wer daran mitarbeitet.

Weiterhin möchte ich bestimmte Zusatzeigenschaften für einen Benutzeraccount verwalten können, z.B. welchen Skin oder welche Sprache der Benutzer bevorzugt.

Das ist jetzt mal unsere fiktive Aufgabe.

Wir haben schon gesehen, dass SharePoint keine gute Unterstützung für relationale Abbildungen bietet und dass Listen kein Ersatz für Datenbanktabelen sind. Wenn wir unser System nun auf SharePoint aufsetzen möchten, dann brauchen wir also eine externe Datenbank, die wir (das sage ich absichtlich, damit Ideen entstehen) irgendwie in den SharePoint integrieren.

Auf der einen Seite habe ich ja praktischerweise die Benutzerverwaltung von SharePoint, ich kann also auf den angemeldeten User zugreifen. Auf der anderen Seite brauche ich aber ein sauberes Zusammenspiel zwischen SharePoint und meinen Zusatzdaten, die ich für unser fiktives Projektmanagement in einer externen Datenbank speichere.

Wie seht ihr da konkret das Zusammenspiel? Wo seht ihr Probleme? Seht ihr darin vielleicht sogar einen Anwendungsfall, der "zu stark" relational is und daher lieber nicht in SarePoint umgesetzt werden würde?

Über eine solche Diskussion würde ich mich freuen: Also was geht konkret in SharePoint und was sollte man lieber nicht in SharePoint mache?

Beachtet bitte: Prima wäre auch, wenn ihr selbst mal Szenarien aufzeigen würdet, wofür man SharePoint nicht einsetzen sollte, denn wofür es gut ist, wissen jetzt glaube ich alle. So können andere auch abgrenzen (anhand er Informationen von Leuten mit Praxiserfahrung), wofür sich der EInsatz lohnt und wofür nicht.

Marco

Frank Daske Als Antwort am 22 Juli 2011 14:45

Marco,

Projektmanagement-Lösungen mit SharePoint gibt's wie Sand am Meer. Von

• "Bordmittel mit kleinen Anpassungen", über
• "Komplettlösungen" wie die hier (nein, nicht von uns;-) :
  http://www.lintra.net/deutsch/sharepoint/applications/cpmsharepoint/cpm_sharepoint.html
•  Bis hin zu high-end Project Server Integrationen:
  http://www.layer2.de/de/leistungen/SharePoint-Projektmanagement/Seiten/projektmanagement.aspx

Da kannst Du auch gleich sehen, was mit SharePoint alles so geht ;-) Zur Frage der Relationalität und Integrität: Kann man immer verschieden lösen, auf Application Level, Auf Framework Level (wie z.T. in SharePoint) oder auf Datenbank Level. Für das Ergebnis ist das ziemlich egal...

C.Kaiser Als Antwort am 22 Juli 2011 15:09

[quote user="MarcoBeyer"]

Ich glaube, wir brauchen eine Wende in dieser Diskussion,

N2S hat eine Menge guter Beispiele geschrieben und auch ich finde, dass sie nicht speziell, sondern eher konkret sind. Christian schreibt darauf, geht, geht, geht, geht mit SharePoint, ohne aber konkrete Beispiele zu nenen. Unterm Strich : Es wird nicht konkret darauf eingegangen.

Hab ich nicht geschrieben ;-)

P.S.: Legt mir keine Worte oder Aussagen in den Mund, die ich nicht getroffen habe. Konkret habe ich gesagt, dass die Beispiele nicht zu speziell sind, sondern einfach nur darauf ausgelegt sind "wunde" Punkte aufzuzeigen. Den Spieß kann man genauso umdrehen und andere Systeme in ein schlechtes Licht rücken, wenn man denn will.

Beispiel (auch das habe ich bereits geschrieben): Die genannte BI-Lösung
Zweites Beispiel: Wie siehts denn mit der Office Integration anderer Systeme aus? Übernahme Metadaten direkt ins Dokument?

Es wird sich beschwert, dass man nicht auf Aussagen eingeht, aber gleichzeitig, werden z.B. meine Aussagen nicht beachtet oder falsch wiedergegeben.

Notes 2 SharePoint Als Antwort am 22 Juli 2011 17:50

Hallo Community-Mitglieder!

Langsam wird die Diskussion müßig, aber den letzten Beitrag von Christian kann ich auch nicht unkommentiert lassen ;o)

[quote user="C.Kaiser"]P.S.: Legt mir keine Worte oder Aussagen in den Mund, die ich nicht getroffen habe. Konkret habe ich gesagt, dass die Beispiele nicht zu speziell sind, sondern einfach nur darauf ausgelegt sind "wunde" Punkte aufzuzeigen. Den Spieß kann man genauso umdrehen und andere Systeme in ein schlechtes Licht rücken, wenn man denn will.[/quote]

Ich habe das sicherlich nicht getan. Ich möchte auch kein System in ein schlechtes Licht rücken. Diese Unterstellung lese ich nunmal auch nicht zum ersten Mal bei den Antworten. Von daher möchte ich hier auch darauf hinweisen, dass das nicht meine Intention ist. Ganz im Gegenteil!

[quote user="C.Kaiser"]Es wird sich beschwert, dass man nicht auf Aussagen eingeht, aber gleichzeitig, werden z.B. meine Aussagen nicht beachtet oder falsch wiedergegeben.[/quote]

Von der Vorgehensweise sieht das so aus (sprich: so bin ich herangegangen):
1. Ich habe Funktionen betrachtet, die ich für essentiell erachte, da sie nahezu in jeder Applikation benötigt werden.
2. Speziell für SharePoint (da es die Zielplattform ist) habe ich diese betrachtet (Beispiele wurden genannt)
3. Ich suche Workarounds oder ggf. Lösungen, die ich noch nicht kenne (ich lasse mich auch gerne beraten)
4. Falls ich nicht zum Ziel komme und die Applikation nicht unter SharePoint abzubilden ist, muss ich selbstverständlich die Plattform in Frage stellen.

Natürlich habe ich mich in Teilen beschwert, wozu ich den ganzen Mist hier schreibe, wenn man "betriebsblind" (bitte jetzt nicht auf die Goldwaage legen) ist oder seine heile Microsoft-Welt nicht in Trümmern sehen möchte. Diese Herangehensweise finde ich bedenklich. Ich rede schon lange nicht mehr von anderen Plattformen, sondern nur noch von der Umsetzung in SharePoint. Und wie gesagt: Selbst wenn ich die Software vernünftig abgebildet bekomme, so bleibt dieser (ebenfalls ignorierte) Punkt offen:
Siehe "6. Weiche Migration" in meinem Beitrag von 12:47 Uhr
Bei SharePoint haben die Versionen 2007 und 2010 nur den Namen gemeinsam. Hier ist teilweise gar keine Migration möglich und das heisst: in die Tonne und neu machen!
Der Grund reicht mir nach wie vor vollkommen!

Und jetzt würde ich mich freuen, wenn nicht mehr über die Persönlichkeitsebene diskutiert wird, sondern über die Applikationsebene!

[quote user="C.Kaiser"]weites Beispiel: Wie siehts denn mit der Office Integration anderer Systeme aus? Übernahme Metadaten direkt ins Dokument?[/quote]

Die Office-Integration ist schön und gut. Allerdings kratzt die Dokument- und Metadatenebene lange nicht an den Anforderungen, die komplexe fachliche Applikationen erfordern. Das betrifft wieder die Out-of-the-box Bordmittel, die hier nicht von größerem Belang sind, weil wir von SharePoint als Entwicklungsplattform sprechen.

Wenn meine Ausführungen jetzt wieder zu speziell sind, dann tut's mir aufrichtig leid ;o)

Gruß,
N2S

C.Kaiser Als Antwort am 21 Juli 2011 21:27

Moin,

ich kann Dir keine Zahlen nennen, allerdings hat sich das Projekt ca. in der folgenden Größenordnung bewegt:

- sechs Monate Laufzeit bis zum ersten Go-Live (Fixtermin)
- durchschnittlich ca. drei bis vier Entwickler in Vollzeit (zu Spitzenzeiten waren es mal sechs Leute, aber nicht durchgängig) + ein techn. Projektleiter

Das Ganze war ein Festpreisprojekt, so dass die Metzger Metapher nicht passt und der Projektleiter hatte zwischenzeitlich ziemlich zu schwitzen ;-)

Und es geht auch nicht um den Aufwand, sondern um die generelle Aussagen: "SharePoint ist keine Entwicklungsplattform" oder "Es gibt keine großen lauffähigen Anwendungen".

Diese Aussagen kann ich auf alles und jeden ummünzen da ich z.B. auch schon extrem schlecht entwickelte WPF-Projekte gesehen haben die rein gar nichts mit SharePoint zu tun hatten (genauso wie ich gute WPF-Projekte gesehen habe).

Wie ich bereits erwähnte kommt es aus meiner Sicht stark auf das ausführende Team, deren Organisation und deren Wissensstand + Erfahrungen an. Ich hab in den letzten Jahren mehrere große Anwendungen gesehen welche sehr gut laufen (nicht nur das o.g.), aber auch welche (wie ebenfalls o.g.) die ganz einfach voll gegen die Wand gefahren und dann nochmal richtig Schwung geholt wurde. Genauso gibt es es mittelprächte Projekte, wo einiges falsch lief aber andere Sachen auch wieder ganz gut - es gibt da leider kein Schwarz & Weiß.

Ich persönlich versuche meinen Kunden mittlerweile dahin zu bewegen, möglichst viel im Standard zu belassen und eben mit den Einschränkungen zu leben. Alle Features, welche häufiger wiederverwendet werden können (was also mehrere Fachabteilungen nutzen können), werden dann genauer betrachtet und dann versucht entsprechen allgemein zu entwickeln - ähnlich wie Frank das oben beschrieben hat, nur eben halt "Hausintern" und nicht für die kommerzielle Nutzung nach "draußen".

Edit: Das Projekt wurde auf der letzten User Group in Düsseldorf anonymisiert vorgestellt, wer da also Redebedarf sieht oder mir nicht glaubt, kann sich vertrauensvoll auf der nächsten UG an mich (sollte denke ich nicht so schwer rausfinden sein, wer ich bin) oder ich denke auch an meinen Chef (auch das wird nicht so schwer rauszufinden sein) wenden  ;-)

Edit 2: Wer keine Lust hat auf die Usergroup - die Präsentation gibt es auch zum Download auf der ShareConf-Seite siehe hier (http://www.sharepoint-rhein-ruhr.de/events/shareconf-vortraege-unserer-usergroup-kollegen). Titel "Excel Services on Steroids – SharePoint BI bei der Metro Group“. Damit ist auch der Kundenname raus und ihr könnt euch damit auch sicherlich vorstellen, dass die Anwendung nicht nur in deutsch laufen muss oder nur in Deutschland ausgerollt wurde. ;-) Das reicht dann auch an Werbung...

Edit 3:

[quote user="MarcoBeyer"]

Ich habe das Gefühl, dass man bei fast jeder einigermaßen aufwändigeren Anforderung überlegen muss, wie man es "in SharePoint" macht, oder "ob überhaupt" und wenn ja, welche Umwege man gehen muss. Den direkten Weg ohne Probleme und vor allem einen aus Sicht des Software Engineering sinnvollen hat auf Basis von SharePoint bislang noch niemand aufgezeigt.

[/quote]

Sorry... aber das muss man doch bei jeder Anforderung, egal ob aufwändig oder nicht, egal ob SharePoint oder ein anderes System. Einfach drauf los ohne grundlegende Überlegungen zum Aufbau auch kleiner Anwendungen führt doch meist nirgendwo hin.

Nicht falsch verstehen, ich fluche täglich, teilweise stündlich (je nachdem welche Anforderung es gibt) über SharePoint und muss den Anwendern auch hin und wieder sagen, dass einige Anforderungen mit einem vertretbaren Maß an Aufwand nicht umzusetzen sind - aber wo gibt es das denn nicht?

(das war jetzt der letzte Edit)

Notes 2 SharePoint Als Antwort am 21 Juli 2011 15:38

Hallo Community-Mitglieder!

Jetzt wird es wirklich spannend, da gebe ich Marco absolut recht. Was für mich besonders spannend ist, ob hier weitere Menschen Farbe bekennen oder ob rhetorische Umschweifungen von den Fakten ablenken ;o)

Die Historie, warum SharePoint als Ersatz für den "Email-Workflow" und somit die Vermeidung von Doubletten (Stichwort: Versionierung) ursprünglich ins Leben gerufen wurde, ist heute schon lange nicht mehr das Marketing-Instrument. Ansonsten würde nicht die vorherrschende Illusion der "Wunderwaffe" herrschen, mit der man sogar komplexe Applikationen abbilden kann. Klar: wenn man keine Medienbrüche mehr hat und alles Browser-basiert ablaufen kann, dann leuchten beim Kunden die Augen. Wie von Marco im vorletzten Beitrag ausführlich beschrieben, kommt es ggf. gar nicht erst zur Beauftragung durch den Kunden oder es "knallt" halt später beim produktiven Einsatz (der faktisch dann nicht stattfindet!).

CarePackage schrieb: "Vielleicht sollten sich mal die Vertriebler an die nase fassen und nicht zu sehr ihre Versprechungen über die Eierlegende Wollmilchsau Sharepoint verbreiten. Das ist Sharepoint nicht."
Ich sage: "Danke für die klaren Worte!" Aber natürlich ist es immer einfacher den Deal zu holen und sich um die Umsetzbarkeit später Gedanken machen zu müssen ... vor allem weil man den charmanten Vorteil hat, es nicht selber leisten zu müssen ;o) Also, bevor das hier zu polemisch endet: Das hängt natürlich vom Dienstleister ab und wie mit dem Thema "Beratung" umgegangen wird. Es gibt auch auch eine vertriebliche Verantwortung und wer dieser nicht gerecht wird oder gegen diese verstößt, wird auch nicht mehr lange "tolle deals" einheimsen. Die Kunden werden sich melden!

Genauso wie Marco lasse ich mich gerne (in Teilen) vom Gegenteil überzeugen ... also das es ohne "geflickschusterte Lösungen", ein vernünftiges Software-Engineering mit Software-Lebenszyklus, QS und kontrollierte Deployments, adäquates Logging, etc. möglich ist. Aber alleine beim Deployment fängt es schon an ... ich habe Deployment per Visual Studio 2010, Deployment per SharePoint 2010-Verwaltungsshell, Deployment per STSADM.exe, Deployment aus InfoPath 2010 oder dem SharePoint Designer. Deployment-Pfade sind hier nicht klar geregelt und z.B. bei InfoPath-Formularen auch nicht immer gefahrlos.

Zu guter letzt ... ich greife den Einwand von Frank auf "Wir machen ja nicht nur Projekte, sondern entwickeln Komponenten, die weltweit vertrieben werden und sich in ganz verschiedenen Umgebungen bewähren müssen.":
Richtig, da reden wir wieder vom Custom Webpart und so weiter ...
Wie Marco und ich geschrieben haben, geht es um komplexe fachliche Applikationen, die niemand von uns bisher unter SharePoint gesehen hat. Mit weltweit vertriebenen Standard-Komponenten erfülle ich aber nicht spezielle Anforderungen (ganze Applikationen!) einer Fachabteilung. Individual-Applikationen stellen beispielsweise bei Migrationen von Lotus Notes/Domino hin zu SharePoint die Hürde dar. Aber letztendlich bringen diese den Mehrwert und sind somit zu 100% gefordert und der Erfolgsfaktor des Projektes (auch mit der Brille "Benutzerakzeptanz"). Sind die Anwendungen nur Teilen unter SharePoint möglich (und dann noch grausam zu bedienen), möchten die Mitarbeiter postwendend das alte System bzw. die Legacy-Applikation zurück. Das geht weit darüber hinaus, dass die Leute Probleme haben ein Dokument abzulegen und mit Metadaten zu versehen. Und diese fachlichen Anwendungen müssen entwickelt werden, daher widerspreche ich Dir (Frank) energisch, dass SharePoint KEINE Plattform für Entwickler sein SOLL! Was richtig ist: Entwickeln unter SharePoint macht (oft) keinen Spaß. Aber auch der Entwickler muss es fachlich verstehen und ein Stück weit beraten können, sonst würde er nicht wissen, was er da programmieren muss. Und ja, es sind entsprechende Drittanbieter am Markt, die Ihre Komponenten verkaufen können ... aber nur, weil der SharePoint-Standard es out-of-the-box nicht hergibt. Nichtsdestotrotz reicht das nicht und fachliche Individualapplikationen sind für mein Dafürhalten kaum auf SharePoint zu verlagern. Ich habe Website-Collections mit Websites, darin Bibliotheken und Listen ... zwischendurch ein paar Webparts, die mir etwas nett darstellen ... wenn man sich das vor Augen hält, sollte man manche Vorhaben überdenken!

By the way: Ich habe diese Themen bereits an die entsprechenden Instanzen bei Microsoft addressiert. Ohne ins Detail zu gehen: Es gab Ausflüchte und wenig brauchbare Workarounds (da wurde seitens MS nur an der Oberfläche gekratzt!), die wunderbar rhetorisch formuliert wurden, dafür hat man 10 Wochen gebraucht ;o)

Gruß,
N2S

PS: Das interessiert mich auch:
Wer hat ferrari.com gebaut? http://sharepointcommunity.de/forums/t/12101.aspx (bisher 0 Antworten)
Die Entwickler von ferrari.com sollten sich mal an dieser Diskussion beteiligen ;o)