Das ist mein Blog.

Hier gibts, was ich tue, getan habe und vielleicht tun werde. Auch, wenn und weil das total unwichtig für den weiteren Verlauf der Geschichte ist. Viel Spaß damit.

Wer mich möglichst zeitnah erreichen und/oder beschimpfen will, versuche dies per Email (s.u.), per Twitter, auf Facebook oder im ircnet oder suche mich persönlich auf.

TMG §5 Kontaktdaten.

RSS-Feed Startseite

Einträge nach Kategorien

Einträge nach Datum

RSS-Feed
Startseite

17.06.2010

22:24 Uhr  Mailmigration auf Web2.0

Ich arbeite für eine Web2.0-Butze vom Feinsten - z.B. haben wir vor offiziellen EiPäd-Start so Dinger (die ich übrigens enorm unpraktisch und schwer finde) rumliegen, weil es Kunden danach gelüstet, entsprechende Ääpps zu bekommen und unsere Berater werden gezwungen, auf nem Mac zu arbeiten und überhaupt: Wo wir sind, war schon immer vorne.

Intern haben wir zur Kommunikation und Gruppengewürge nen Exchange-Server benutzt - die Ausgeburt des Bösen. Allerdings hat das Böse ziemlich gut funktioniert, vor allem in der gemeinsamen Nutzung von Kalender, Aufgaben, Mail, Adressen und soweiter mit dem entsprechenden Frontend Outlook. Fast alle, die irgendwie kein Windows hatten, waren (darüber) froh, aber gleichzeitig benachteiligt (durch Entourage aufm Mac) oder mit geringer InterInteraktiontegration mit eigenen Tools angebunden, die die unterschiedlichen Aufgaben meist besser als Outlook erledigen, aber eben nicht gemeinsam.

Mit der Zeit hat unser Exchange (mit etwa 250 realen Usern) aber immer mehr Performanceprobleme bekommen (wohl vor allem verursacht durch die stark wachsende Anzahl von mobilen Devices wie Blackberries und anderen 'push'enden Pulldiensten, die sich dann auch noch immer syncen wollten und daneben durch eine nicht so ganz den technischen Ratschlägen des Herstellers entsprechende Grundkonfiguration).

Der Exchange - die Groupwarelösung - mußte neu. Entsprechende Angebote von MickySoft-Premiumintegrationspartnern waren aber alle so irre teuer, daß relativ schnell auch in eine neue Richtung gedacht wurde, also nicht Exchange renovieren sondern abschaffen und durch was neues, irres ersetzen.

Zurück auf Anfang: Wir sind ne hippe Web-Zwo-Null-Bude, sagte ich schon. Also sind wir auch ziemlich schnell auf Googlemail gestossen.
Googlemail (gmail) bietet fullservice alles an, was man normalerweise in der Unternehmenskommunikation braucht (also Mail, Kalender, Resourcenverwaltung, Instantmessenger, Adressbuch, Dateiablage, News, Websites/Wiki, ...), und man hat damit auch gleich die wirklich leidige Geschichte mit der Hardware nicht mehr an den Hacken, und es skaliert damit wie Sau.

Nach langem hin- und her hat sich unsere Geschäftsführung zu dem Schritt entschlossen, voll auf Googlemail zu setzen - in der Diskussion dahin haben eine Menge Aspekte eine Rolle gespielt, die wahrscheinlich den meisten nicht ganz unbekannt vorkommen:

Eher geschäftliche und soziale Aspekte:

• Google - die Datenkrake...
• Geben wir diese wichtige Infrastruktur wirklich aus der Hand?
• Sitzt einer von denen in Würgereichweite, wer ist da unser Vertragspartner?
• Wie gehen wir mit Vorbehalten unserer Mitarbeiter und (konservativer) Kunden um, wenn sie welche haben?
• Ändern sich unsere Prozesse? Ist das gut? Ist das schlecht? Ist das egal?
• was kostet das an Zeit und Geld, eventuell an Knowhow?
• und noch einige mehr

Eher technische Aspekte:

• Wie kann eine Migration stattfinden?
• In welchem Zeitrahmen kann eine Migration stattfinden?
• Wie läuft die Userverwaltung, was kann man automatisieren?
• Bildet das wirklich alles ab, was Exchange/Outlook konnte, was muß anders werden?
• Gibts nen Point of no return?

Eine der großen mentalen Baustellen ist bei so einem Vorhaben natürlich Google. Dem früheren 'dont be evil' Unternehmen wird - völlig zu Recht - eine starke Neigung zum Datensammeln angehängt. Völlig zu Recht, weil das nunmal der Job einer Suchmaschine ist, und auch völlig zu Recht, weil es einige Bereiche gibt, in dem sie damit in die Privatsphäre eindringen, weil sie es schaffen, Daten miteinander zu verknüpfen, die alleine kaum einen Wert haben. Ich will die Debatte um die Streetview-Wlan-Geschichte hier nicht führen (in meinen Augen ist das Hysterie, und mir wäre es lieber, Google behält diese Daten, statt diese an unsere 'Dienste' abzugeben), trotzdem bleibt natürlich die Frage, ob man der Datenkrake Tante Google wirklich seine Mails anvertrauen will.

Dazu ein paar Überlegungen: Mail ist grundsätzlich unsicher, abhörbar, und der Weg einer Mail von der Quelle zum Ziel ist weder sicher vorhersagbar noch in der Verfügungsgewalt des Senders. Alle großen Mailprovider und deren zentrale Mailhubs haben die entsprechende Infrastruktur, Mailverkehr abzuhören. Ich meine damit nicht die (ausgesetzte) Vorratsdatenspeicherung, sondern eben amtliche Schnüffelstücke entsprechend TKÜV, und was sich vielleicht so manchen noch aus eigenem Interesse und wirtschaftlichen Zwängen... - man weiß es einfach nicht.

D.h., es reicht auch bei von vertrauenswürdigen anderen oder selbst betriebenen Mailservern nicht aus, die Transportwege, soweit man sie denn im Griff hat, (also Einlieferung und die Abholung) zu verschlüsseln, sondern wirklich sinnvoll ist nur eine Ende-zu-Ende-Verschlüsselung (s/mime, pgp oder vergleichbares). Dies gilt unabhängig vom Provider. Wer jetzt einwendet, daß das den Kunden und den eigenen Mitarbeiten nicht zumutbar/beizubringen ist, muß sich da dann aber auch keine Gedanken mehr machen, wo er seine Mails lagert - ein bißchen Sicherheit gibts genau so wenig wie ein bißchen schwanger.

Es bleiben letztlich interne Mails auf selbst betriebener Infrastruktur - aber wie intern bleiben die in Zeiten von mobilen Devices wirklich und was macht man mit Mitarbeitern, die sich unabhängig von Google einfach mal so den Laptop klauen lassen? Wenn man dafür kein Konzept hat, braucht man sich um Privacy bei Google nicht so irre große Sorgen zu machen, also - dieses Problem hat man eh, und nicht erst durch Google, wenn man mal genauer nachdenkt.

Im Zuge der Migrationsvorbereitungen haben wir natürlich unseren Kunden erzählt, was wir vorhaben - witzigerweise kam da genau aus dem eher konservativen Bankenbereich ein leises 'da haben wir auch schon intensiv drüber nachgedacht'. Na dann...

Dazu kommt, daß wir hier im Vergleich zu Betrieben mit klassischer IT sehr locker mit dem Umgehen, was normale User im Firmennetz dürfen und welche Rechte sie haben - für uns ist deshalb die zu überquerende Schlucht zu googlemail sicher nicht so groß wie für klassisch-analfixierte IT-Abteilungen.
Das liegt zum einen daran, daß hier IT nicht so sehr ein Werkzeug zum Abarbeiten von it-fremden Problemen, sondern zu einem sehr großen Teil Selbstzweck des Broterwerbs ist; und sicher auch, weil wir (als Firma, nicht die IT) versuchen, jeden aktuellen Hype zu verstehen um absehen zu können, ob sich daraus ein Geschäftsfeld entwickeln kann, das für unsere Kunden interessant sein könnte. Sowas funktioniert mit einem stark restriktiv organisierten Netz eben nicht.

Zum Anderen verursacht allein schon der Versuch der ernsthaften Gängelung der User echt viel Arbeit und schafft damit eine permanente Racecondition zwischen Mitarbeitern, die Grenzen ausloten und Admins, die Löcher stopfen und die Bewegungsfreiheit aller Benutzer immer weiter einengen, bis die Leute ihre IT selbst machen (lies: einen UMTS-Stick benutzen) - das kann auch nicht im Sinne der Firma sein.
Wir fahren damit erstaunlich (aus meiner Sicht als damals klassisch analfixiert-ausgebildeter Admin) gut.

Genauso gibt es auch in einer Firma, die permanent nach neuem (Hype) sucht, Mitarbeiter, die konservativer gegenüber neuer Technik eingestellt sind (z.B. die Admins :-) - eine wichtige Frage ist, wie man diese sinnvoll ins Boot holt, sie dazu bringt, sich mit neuen Arbeitsmitteln zu beschäftigen und zu lernen, diese nach einer Eingewöhnung genauso effektiv zu nutzen, wie vorher Outlook - das ganze am Besten ohne riesigen Frontalschulungsaufwand.

Wir haben das gelöst, in dem wir nicht alle Benutzer auf einmal migriert haben, sondern immer mal wieder ein paar, und mit Leuten begonnen, die von sich aus erkennen liessen, daß sie große Lust darauf haben. Das gab zwar ein paar technische Probleme (die Migration von Userdaten ist ein interessantes logisches Problem, wenn man gemeinsame Resourcen wie z.B. Maildomain-Namen, Konferenzräume, Kalender benutzt, weil man da nach dem eigenen Umzug eine zeitlang zweigleisig fahren muss), aber damit hatten wir gleich von Anfang an überall im Haus Mavens für die neue Technologie, an die sich dann im Laufe der fortschreitenden Migration die jeweiligen Nachbarn wenden konnten, wenn sie ein kleineres Problem hatten.
Dieser Selbsthilfe-Ansatz hat sich sehr bewährt, damit haben wir auch vielen Mitarbeitern ins Boot geholfen, die nicht so große Lust auf eine Umstellung vom Gewohnten hatten, aber letzlich doch neugierig wurden, was die anderen da so machen, und wie das genau aussieht.
Empfehlenswert.

Ebenso gibt es nur sehr wenig fest vorgegebene Arbeitsabläufe - die Geschäftsführung setzt eher darauf, daß sich durch das Arbeiten mit dem neuen System (und dem alten; unser Wiki, die Fileserver und soweiter leben natürlich trotz GoogleApps weiter) sowas wie best practices entwickeln, die angemessen für die durchaus unterschiedliche Arbeitsweise der verschiedenen Teilbereiche und Teams sind.

Ein Schritt vorher haben wir mit einer kleineren Gruppe Benutzer auf einer nicht aktiv verwendeten Domain geübt, da aber vor allem technische Dinge, die dann Inhalt eines Fortsetzungsartikels werden.

Wer nach dem Lesen dieses Artikels dazu konkrete Fragen hat, schreibe diese mir, damit ich darauf eventuell eingehen kann - der zweite Teil befindet sich bisher nur in meiner wetware.

Übrigens hat Google in Europa anscheinend noch nicht so irre viele größere GoogleApps-Kunden - unser Technik-Geschäftsführer hat zu unserer Migration eine Präse zusammengetackert und diese bei Google in München und Zürich gehalten, siehe dazu im Fischmarkt Blog. Wie man so im Flurfunk hört, waren die sehr angetan. Vielleicht werden wir ja noch GoogleApps-Migration-Partner[tm] oder sowas...

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]