PrivatesPortal

Das IBM WebSphere Portal verteidigt u.a. auch mit der Softwaremannschaft aus dem deutschen IBM Labor in Böblingen, seine führende Stellung durch Integration von Web 2.0 Funktionen in das WebSphere Portal und baut die integrativen Funktionen (federation, mash ups usw) weiter aus. Hier zeigt sich einmal mehr die Überlegenheit des Portal Konzepts. Durch saubere Trennung von Model-View-Control kann die Technologie der Benutzerschnittstelle z.B. durch Einsatz von AJAX erweitert werden, ohne dass die vorhandenen Applikation davon betroffen sind. Gut Ding hat aber leider auch seinen Preis. Ohne ein vernünftiges Portalangebot und Partner für mittelständische Einsteiger (ähnlich Sharepoint) hat es IBM aber schwer, im Mittelstand Marktanteile zu gewinnen.     

Fast alle Portalhersteller bieten zu den Grundfunktionen des Portals spezielle Features an, die dem Benutzer häufig gebrauchte Funktionen wie z.B. Dokumentenverwaltung, Urlaubslisten, Inventur, usw bieten. Dies soll nach der Installation des Portals schneller zu einer sinnvollen Nutzung z.B. in kleinen Unternehmen führen. Schat man sich diese Funktionen jedoch näher an, so sind sie für die meisten Betreiber eines Portasl wenig sinnvoll. Typisch werden die Funktionen nur in Englisch und für US Betriebsabläufe angeboten. Beim Portal Hosting kann man auch häufig diese Funktionen nicht sinnvoll anpassen. Häufig werden diese Funktionen auch unvollständig installiert. Es lohnt sich also diese Funktionen für den eigenen Betrieb zu evaluieren, bevor man den Einsatz solcher Features im eigenen Betrieb oder Organisation plant. Private Benutzer sind gut beraten diese Funktionen nicht zu verwenden sondern eigene, einfache Listen- und Formularanwendungen zu schaffen, die man selbst auch anpassen kann.       

Sharepoint liefert für kleinere Projekte eine durchaus brauchbare Infrastruktur. Problematisch kann es aber werden, wenn mehrere Sharepoint Projekte und J2EE Lösungen integriert werden sollen. Viele Firmen haben hunderte von Sharepoint Subsites generiert, die man nachträglich nur schwer wieder integrieren kann. Andererseits sind J2EE Portale wie z.B. der IBM WebSphere Portal Server für kleinere Projekte kaum wirtschaftlich einzusetzen.  Auch große Firmen haben Probleme, die Infrastruktur ohne sofort nutzbare Anwendungen und aufwändige Schulung der Mitarbeiter einzusetzen. Es kann durchaus Sinn machen, die Portaltechnologie z.B. mit Sharepoint einzuführen und später auf ein integrierendes J2EE Portal umzusteigen. Mit .Net Extensions für das IBM WebSphere Portal  wird ein interessanter Integrationspfad angeboten.  .Net Programmierer können J2EE Portlets in ihrer gewohnten Entwicklungsumgebung erstellen und damit die Integration erleichtern.  Kombiniert man dies mit der Mainsoft Integrations Software, kann man Sharepoint Sites in WebSphere Portal integrieren. Dies ist durchaus eine interessante Möglichkeit die proprietäre Microsoft Welt zu öffnen. 

Offensichtlich wollen viele Benutzer sich nicht auf eine proprietäre Plattform zwingen lassen, obwohl alle Hersteller dies immer wieder versuchen.

Sharepoint ist im Moment nur für kleinere Gruppen mit limitierten Anforderungen als Portal Infrastruktur geeignet. Es zeichnet, sich aber dadurch aus, dass die Einstiegschwelle sowohl vom Preis (Hosted Service für < 6 € /Monat) als auch von der Benutzung her relativ klein ist. Es spricht also einiges dafür, mit kleinen Installationen von  Sharepoint zu starten und diese dann die übergeordneten Funktionen später in einem großen Portal z.B. mit IBM WebSphere zu implementieren, das einige 100 000 Benutzer unterstützen kann. Dabei kann man die in Sharepoint verfügbaren Webservices zur Einbettung der Sharepoint Daten nutzen.  

Im Moment ist dies für private Gruppen weniger interessant, da in den nächsten Jahren in Deutschland erst die Schulung der Benutzer in Portal- und Web 2.0 - Techniken erfolgen muss bevor größere Netzwerke entstehen können. Die Integration von Sharepoint in Portal Netzwerke sollte man aber als Option im Auge behalten, um Alternativen zur proprietären Microsoft Architektur verfolgen zu können.     

Auf den ersten Blick ist jede Portal Seite sehr ähnlich mit einzelnen Kacheln aufgebaut. Natürlich gbt es bei den verschiedenen Portal Systemen unterschiedliche Funktionen. Das kann man aber zum Teil dadurch wettmachen, dass man z.B. Google Gadgets in Sharepoint integriert oder Sharepoint Webparts in IBM WebSphere Portale einbettet. Ein wesentlicher Unterschied besteht aber darin, wie die Berechtigungen von Benutzern behandelt werden.

Sharepoint hat z.B. die Philosphie dass Benutzer für andere Seiten (Shared View) anlegen und auch personalisieren können. Das funktioniert nicht nur für Gruppen sondern auch für anonyme Benutzer im Web. Man kann also mit Sharepoint auch “konventionelle” Webseiten erstellen. Die Erfahrung bei der Einführung von Portalen zeigt, dass die Benutzer nur einige wenige Seiten ausschließlich für die eigene Nutzung anlegen wollen aber gerne die angelegten Seiten von Kollegen und Gruppen benutzen. 

Bei Google Apps ist keine wirkliche Strategie beim Management der Berechtigungen zu erkennen. Man geht zunächst von privaten, personalisierten Seiten für die Benutzer aus. Das ist für viele Benutzer aber schon zu kompliziert. In Google Apps kann man deshalb Starteseiten für Gruppen anlegen. Damit haben die Benutzer schon einen einfacheren Start. Das Problem dabei ist aber, dass die aktuelle Gruppen Startseite bei der Registration des Benutzers verwendet wird. Spätere Updates bekommt der Benutzer nicht mit! Auch für Google Gadgets gibt es keine Regeln wie Defaults (z.B. Shared Views) gehandhabt werden. Die meisten Gadgets aber auch Google Calender haben keine Möglichkeit einen “Default View” anzuzeigen. Ein Benutzer, der nicht zuvor bei Google Login gemacht hat (für anonyme Benutzer nicht möglich!)  sieht keine Daten. Allenfalls einen Hinweis auf fehlenden Login. Das ist aber eine recht veraltete Methode. Moderne Portale unterdrücken die Anzeige von Elementen, zu denen der Benutzer keine Berechtigung hat.  

Es ist schon verwunderlich, dass die Google Entwicklungsmannschaft (oder die Produkt Manager) solche elementaren Probleme nicht erkannt und gelöst haben. Dabei haben sie es ja besonders einfach - sie bräuchten sich nur einmal die seit langem etablierten Portale von IBM WebSphere Portal oder auch Sharepoint ansehen. Bei Google scheint aber die “Not Invented Here” Barriere ähnlich hoch zu sein, wie bei anderen Firmen.  

Das Problem der Portal Berechtigungen lässt sich übrigens nicht durch Open ID lösen und ist eine ganz elementare Grundlage für die Systembenutzung und die Architektur eines Portals. Das kann man nicht nachträglich in ein System reinflicken. Hier wirkt sich die Entwicklungsmethodik, von Google bei der einzelne Funktionen getrennt entwickelt werden, nachteilig aus!     

Microsoft hat anscheinend noch immer nicht verstanden, dass man mit proprietären Lösungen nicht weit kommt. Nach wie vor wird für interaktive Sharepoint Funktionen der Internet Explorer  (6 oder 7) benötigt! Großzügigerweise kann man mit Firefox oder Opera Sharepoint Seiten wenigstens ansehen. Will man aber Daten eingeben, so funktionieren viele Sharepoint Funktionen mit anderen Browsern nicht! Damit sollte Microsoft eigentlich bei öffentlichen Ausschreibungen in der EU gar nicht zugelassen werden! Microsoft hat sich damit vor allem im mobilen Bereich ein Riesenei auf die Schiene genagelt. Da Microsoft selbst keinen attraktiven mobilen Browser (z.B. Opera Mini) hat, können mobile Benutzer das strategische Microsoft Portal Produkt nicht nutzen. Das ist ein wesentlicher Nachteil gegenüber Google oder auch IBM, die natürlich auch Firefox und andere Browser unterstützen. Anstatt mit viel Geld Yahoo zu kaufen, sollte Microsoft besser einen strategischen Kopf als CTO einkaufen. Ray Ozzie , hat mit Lotus zwar ein wegweisendes proprietäres System geschaffen aber dann schon bei IBM das Web Portal Zeitalter verschlafen. Nach seinem Wechsel zu Microsoft hat er auch dort wohl gegen visionäre Praktiker wie Steve Jobs und den Google Architekten Craig Silverstein wenig Chancen.

Wie sehr das Weltbild von Microsoft durch den Konkurrenten Google gestört wird, sieht man an den recht hilflosen Versuchen von Microsoft, kleine Anwendungen für die Benutzer schnell zu entwickeln. Die Microsoft Strategie besteht ja darin, umfangreiche Softwareprodukte wie VISTA, SQL Server, Office u.s.w. anzukündigen und dann jahrelang an vielen Funktionen herumzubasteln, die der größte Teil der Benutzer gar nicht benötigt. Dabei steigt die Komplexität der Software immer weiter an, sodaß sich nicht nur die Benutzer sondern auch die Microsoft Entwickler und viele Anwendungsentwickler nicht mehr zurechtfinden. Die Einführung von VISTA ist ein schönes Beispiel, wie diese Strategie in einer Sackgasse endet. Die Strategie von Microsoft wird trotzdem von den vielen Entwicklern und Beratern unterstützt, die sich über Jahre in die komplexe Microsoft Welt eingearbeitet haben,  da ja eine Vereinfachung durch Web basierende Services ihr Wissen weitgehend überflüssig macht. Häufig fehlt auch schlichtweg die Zeit, sich mit anderen Architekturen und Systemen auch nur in der Übersicht zu beschäftigen. 

Nun sind die von Google angebotenen Services weitgehend rudimentär und deren Architektur  noch auf einem doch sehr infantilen Niveau. In der Entwicklungsmethodik jedoch ist Google auf dem neuesten Stand u.a. werden die Benutzer eingeladen, bereits bei der Entwicklung der Komponenten Einfluß zu nehmen und die Komponenten dann auch früh zu testen. 

Wie in allen großen Firmen gibt es aber auch bei Microsoft kleine revolutionäre Zellen, die gute Ideen haben und meist gegen die etablierten Produkte und deren Manager ankämpfen müssen. Popfly ist zwar noch in Alpha Stadium aber doch eine recht interessante Weiterentwicklung der üblichen Portale wie iGoogle und Sharepoint, bei denen die einzelnen Kacheln (Gadgets, Webparts, Widgets) isoliert nebeneinander stehen. Popfly erlaubt es, die Blöcke miteinander zu verbinden und damit kleine Anwendungen aufzubauen.  Einen kleinen Eindruck gibt die folgende Live demo. Kommunikation zwischen Portal Bausteinen ist zunächst keine neue Idee - bei IBM im Labor Böblingen und im WebSphere Portal Server gab es das bereits vor 8 Jahren und ist in den Portlet Spezifikationen JSR 168 (26  und WSRP standardisiert. Microsoft hat jedoch eine grafische Schnittstelle für die Programmierung sowie Community Verwaltungssoftware erstellt. Ählich wie Gadgets, Widgets usw kann man Popfly Komponenten auch in Sharepoint aber auch in andere Portale integrieren. 

Leider basiert Popfly auf dem proprietären Microsoft Browser Plug In Silverlight , das auch für Firefox verfügbar ist und auch für andere Browser verfügbar gemacht werden soll. Microsoft versucht also einmal mehr mit proprietären Standards und Komponenten den Markt zu beherrschen. Interessant wird werden, wie die  Entwickler und die Mitbewerber Google sowie die JSR Gruppe (IBM, SUN, Oracle, SAP u.a. ) auf den Vorstoß von Microsoft reagieren, Web Inhalte auf einer höheren Text Ebene als HTML zu beschreiben. Letztendlich wird man sich hoffentlich ähnlich wie bei HTML auf einen einheitlichen Standard zum Nutzen der Kunden einigen müssen.

Ein wesentlicher Vorteil der Portal Technologie ist, dass man einzelne Bausteine kontrolliert zum Portal hinzufügen und verwalten kann. In den Marketing Broschüren der Hersteller wird gerne mit der Vielzahl der verfügbaren Bausteine (Webparts bei Sharepoint ) geworben. In der Praxis sieht es aber eher düster aus. Zwar bieten einige Firmen Webparts an - ein typischer Preis ist etwa 500 $ / Webpart. Für kleinere Installationen sind aber wohl nur freie Webparts interessant. Mark Kruger hat eine Liste freier Webparts erstellt.  Schaut man jedoch etwas näher hin, so sind die meisten Webparts nur für Sharepoint 2003 geeignet. Sharepoint 2007 (MOSS) Webparts sind praktisch noch nicht verfügbar. Microsoft muss hier wesentlich mehr investieren, um auf ein ähnliches Niveau wie Gooogle (4000 Gadgets) zu kommen. Man kann zwar Google Gadgets in Sharepoint integrieren - das ist aber eine Notlösung. Der IBM WebSphere Portal Server  hat ein ähnliches Problem mit den Portalbausteinen (Portlets). Im neuen Release wird aber zumindest eine Standard Funktion zur Integration von Google Gadgets angeboten. Das ist ja im Prinzip keine technische Großtat jedoch wird sich Microsoft’s Marketing Abteilung schwer tun, eine ähnliche Lösung anzubieten.   

 Webseiten für mobile Geräte zu optimieren ist recht aufwändig. Häufig genügt es schon einige Portal Seiten (iGoogle, Sharepoint, IBM Websphere usw) so anzulegen, dass sie mobil benutzt werden können. Mit dem Opera Browser kann man sich vorab am PC anschauen, wie die Seiten etwa auf einem Handy dargestellt werden. Ab  Version 7 kann der OPERA Browser Webseiten auch auf einem kleinen Bildschirm anzeigen. Hierzu bei Ansicht [View] -> Kleinbildschirm [small screen] einstellen.

Da der Opera MINI 4.0 nicht total identisch mit der PC Version von Opera ist, muss man doch noch ab und zu auf dem Handy testen. Die Arbeit wird aber wesentlich erleichtert. 

Benutzer von Lotus Notes in Unternehmen wissen die Replizieren Funktion zu schätzen und würden eine ähnliche Funktion auch gerne privat nutzen. Mit dieser Funktion kann man eine lokale Kopie z.B. einer Projektdatenbank auf dem eigenen Laptop erstellen und die Daten dann nutzen, ohne dass eine Verbindung zum Server besteht. Das ist besonders zu empfehlen, wenn man unterwegs nur zeitweise eine schnelle, billige Verbindung zum Server hat. Mit Replicate kann man die Daten auf dem Server und PC synchronisieren, das heißt, die auf dem PC geändert Daten werden auf den PC kopiert und umgekehrt. Colligo bietet eine solche Synchronisationsfunktion für Sharepoint an (auch für mobile Geräte). Hierfür muss ein Colligo Reader auf dem Client installiert werden. Für Privatpersonen ist dies kostenlos.

Meist macht es Sinn, nur bestimmte Sharepoint Bibliotheken und Listen auf das mobile Gerät zu laden. Im Colligo Reader kann man pro Sharepoint Site auswählen, welche Daten repliziert werden sollen. Grundsätzlich sollte man in einer Portalumgebung immer versuchen, die Daten auf dem Server zu halten und Replikation auf dem Clienten nur in speziellen Fällen zu nutzen. (Als Lotus Notes mit extensiven Kopieren der Daten auf den PC konzipiert wurde gab es außerhalb der Unternehmensnetzwerke keine schnellen Datennetzwerke. )  Für solche limitierte Nutzung ist der Colligo Reader mit Sharepoint durchaus brauchbar.   

Der Colligo Reader benötigt eine komplette .Net Umgebung auf dem Client und eignet sich damit nicht für ein öffentliches Portal mit vielen Benutzern, deren Client Installation nicht kontrolliert werden kann. Für Professionals oder Mitarbeiter kleiner Unternehmen, die viel unterwegs sind, ist das eine sehr attraktive Hilfe, die in Großunternehmen in der Lotus Notes Umgebung schon lange erfolgreich genutzt wird. 

Der Colligo Reader benutzt Web Services, um auf den Sharepoint Server zuzugreifen. Achtung nicht alle Sharepoint Hosting Provider haben Web Services freigeschaltet! Häufig wird der Sharepoint Server  installiert, ohne dass die Marketing und Support Leute (manchmal auch die Administratoren) des Hosting Providers wissen, welche Features des Sharepoint Portals überhaupt aktiviert sind und welche auch tatsächlich funktionieren.  Hier hilft nur Nachfragen und Testen während der Probezeit.   

Achtung: der Colligo Reader wird mit Autostart installiert und versucht dann bei jedem Systemstart zu synchronisieren, was den Startup unnötig verlängert (speziell wenn Colligo hängen bleibt!). Man sollte die Synchronisation besser individuell starten, wenn man sie wirklich braucht. Wenn Colligo automatisch gestartet wird, kann man die laufende Software auch nicht deinstallieren. Hierzu zuerst Colligo mit Windows Defender oder mit Autoruns  aus der Startup Liste entfernen.