Technik ist einfach… wirklich?

Auf praktisch jeder Veranstaltung zum Thema Web2.0 oder Enterprise2.0 höre ich als einen der ersten Sätze wenn es um Wikis und Weblogs geht „Technik ist einfach, nur die Einführung ist schwer“.

Das ist meiner Meinung nach eine „relative“ Aussage. Das Einspielen, Einpassen, Anpassen, Aufbereiten eines Weblogs oder Wikis ist harte Arbeit. Sie verlangt zumindest zu Anfang einen kompletten Mitarbeiter, und der Betreuungsaufwand im Nachhinein sollte auch nicht ignoriert werden. Am Ende des Tages ist „gefördertes Wissen“ und „Kommunikationsfähigkeit“ unternehmenskritisch, und zumindest Backup/Restore nie ein triviales Thema.

„Relativ unaufwendig“ sind Wikis und Weblogs nur dann, wenn ich viele Nutzer damit abdecke. Ein bis zwei Administratoren können durchaus hunderte bis tausende von Benutzern betreuen. Das ist akzeptabel. Der Aufwand ist bei einem Dutzend Benutzern aber fast der selbe.

Blog-Einzelkämpfer wissen, wieviel Zeit sie mit dem „Anpassen“ und „Sicherheits-Updates einspielen“ im Vergleich zum „Inhalte einstellen“ verbringen. Im privaten Umfeld ist das auch okay. Im Unternehmen sollte der Aufwand jedoch in vernünftiger Relation zum Nutzen für das Gesamtgebilde stehen. Und „relativ einfach“ ist nicht gleichbedeuted mit „gänzlich ohne Aufwand“.

Vortrag auf der power-society 2008

Seit heute steht der Slot für meinen Vortrag zum Thema Enterprise 2.0 auf der power-society 2008 fest. Freitag, der 14. November 2008 ist es geworden, und ich hoffe um 11:30 sind alle Zuhörer schon wieder frisch von den Events des vorausgehenden Tages.

Titel des Ganzen: „Die Soziale Revolution“ … und es geht darum, wie sich Enterprise 2.0 auf Unternehmen auswirken wird. Ich muss sagen ich freue mich schon jetzt total auf diese Gelegenheit. Die IBM Common-Veranstaltungen waren immer eine Sache auf der ich gerne als Sprecher aufgetreten bin. Besonders wegen der Diskussionen im Anschluß.

Enterprise 2.0 und wie das mit meinem ADC-Beitritt zusammenhängt

Ab und an sollte man auch mal was Neues ausprobieren, und so bin ich gestern der Apple Developer Connection beigetreten. Eine kostenfreie Online-Mitgliedschaft zwar nur, aber für erste Schritte mit XCode und dem iPhone SDK wird es reichen. Ich bin sehr neugierig auf die Qualität der Frameworks, und war überrascht, wieviel Videomaterial und Dokumentation Apple einem zur Verfügung stellt. Ich habe schon viele Entwicklungsplattformen ausprobiert, aber hier fühlt man sich von Anfang an blendend betreut. Ich mag das:

adc2008

Wofür das Ganze? Ich denke derzeit darüber nach, ob das iPhone auch für Enterprise-ApplikationenSinn macht. Mir war dabei nicht klar, wie ich Anwendungen „auf den Firmenrahmen begrenzt“ auf Smartphones ausrollen kann. Klar, es gibt den iTunes AppStore um selbstentwickelte Programme auszurollen, aber ich denke nicht, dass ich über kurz oder lang ein eigenes Programm auf den freien Markt werfen will. Was Applikationen Im Firmen-Extranet angeht sieht es da schon wieder anders aus. Und hierfür möchte ich Smartphone und Netbookansätze unbedingt ausprobieren.

Ein anderer Gedanke: Auf dem Enterprise 2.0 Forum, dass ich diese Woche in Köln besucht habe, wurde mehrmals angesprochen, dass Computer und Smartphones immer mehr in das Privateigentum der Mitarbeiter übergehen werden. Das hätte etwas mit der Bequemlichkeit der Leute zu tun, die nicht 2-3 mal das selbe Gerät mitschleppen wollen. Firmen stellen ihre Arbeitsplattformen ohnehin mehr und mehr via Internet bzw. Extranet zur Verfügung, das individuell genutzte Gerät spielt damit immer weniger eine Rolle. Da Reisekosten immer mehr steigen, die Welt aber zeitgleich immer globaler wird, werden mehr und mehr Mitarbeiter ihre Arbeit „fern von der Firma“ erledigen. Da es darüber hinaus in Mode kommt, Zielerfüllung statt Stundenzahl zu honorieren, steigt die Anzahl der Jobs die ein einzelner Mensch ausführen wird. Sicher gilt das nicht für jedes Feld, aber ein Trend ist da.

Als abschließendes illustrierendes Beispiel haben wir gehört, dass Anfang des vorigen Jahrhunderts Mitarbeiter in Banken nur die Federkiele und Tinten der Bank nutzen durften, damit in den Büchern ein einheitliches Schriftbild herrschte. Davon ist ziemlich wenig übriggeblieben: Ich denke wir haben alle unsere eigenen Kugelschreiber inzwischen. Ich werde jedenfalls auf Weihnachtsgeschenke meiner Familie im Job nicht verzichten.

Social Apps und die drei Kernprobleme im Unternehmen

Im Sommer 2007 hatte ich die Gelegenheit, Janne Jalkanen, den Erfinder von JspWiki, über Social Appsreden zu hören. Meines Wissens nach gab es niemals ein Handout zu der Veranstaltung, darum möchte ich hier einige essentiellen Aussagen aufschreiben. Ich denke sie sind relevant für fast jedes Unternehmen.

Social Apps waren im Rahmen der Veranstaltung alle Werkzeuge, die es Menschen erlauben, einfach und umfassend zu kommunizieren.

Wenn wir darüber nachdenken war es in der Vergangenheit fast immer so, dass wenn eine wirklich neue Kommunikationsform auf den Markt kam, diese schnell zur absoluten Killeranwendung wurde. Als Beispiel sei eine Kette von Erfindungen dieser Art genannt: Briefe, Telefon, Internet, Email, Mobiltelefon, Chat, Messaging… alles Erfolgsgeschichten, egal wie sinnvoll Kommunikation über diese Plattformen uns heute erscheint.

Janne stellte Blogs und Wikis im Zusammenspiel mit Newsfeeds als die Social Apps des Web 2.0 vor. Und da es „soziale“ Anwendungen sind, stellt sich eigentlich nicht die Frage, ob sie überhaupt sinnvoll sind, sondern lediglich, wie ich sie sinnvoll im Unternehmen einsetzen kann.

Was meiner Meinung nach Unternehmen derzeit oft fehlt sind Muster (Patterns) für das Bloggen und für die Wiki-Erstellung. Damit diese Muster zweckmässig sind (denn ein ROI ist bei Social Apps kaum messbar), sollten sie die Haupt-Kommunikationsprobleme im Unternehmen angehen.

Und diese drei von Janne als „Painpoints“ bezeichneten Probleme im Unternehmen sind:

  1. Wir erhalten viel zu viel Email
  2. Wir wissen oft nicht wer für ein Problem der richtige Ansprechpartner ist
  3. Bei Dokumenten ist es oft unklar, welches die richtige Version hat

Email ist ein Problem, das durch Blogs in Kombination mit Feeds angegangen werden kann. Dokumentation ist ein eindeutiges Wiki-Thema.

Es lohnt sich also diese Werkzeuge genau anzuschauen und auf den Unternehmenseinsatz hin zu prüfen. Hinweise für den sinnvollen Einsatz will ich hier in nächster Zeit sammeln.

Von Photohosting bis Video-Blogging

Ein Bild sagt mehr als tausend Worte, und im Prinzip ist eine chronologisch rückwärts sortierte Sammlung von Fotos schon ein Blog. Ich habe mich in den letzten Tagen ein wenig mit Photohostern beschäftigt und habe mich nun für mich für Flickr entschieden. Viel Spaß beim Stöbern in  meinen ersten Demo-Bildern.

Photo-Blogging kann man natürlich ziemlich weit treiben, das Photoblog von Robert Scoble zeigt zum Beispiel seine Ausflüge durch die IT-Welt. Falls man es noch etwas weiter treiben will: Robert betreibt auch ein Video-Blog in denen er EDV-Größen dieser Welt interviewt. Wer Blogging lieber klassisch und mit Texten mag, wird auf seinem Scobleizer-Blog fündig.

Doch zurück zum Photohosting: Schön an Flickr ist für mich, dass man Bilder in Alben sortieren kann, Geotagging kein Problem darstellt, und Slideshows reibungslos funktionieren. Dass das Ganze in Dollar statt Euro abgerechnet wird und es zum Ausprobieren auch kostenlosen Speicherplatz dort gibt sind für mich weitere interessante Argumente.

Auf dem Weg zum NLP Practitioner

Insgesamt 8 Kurstage und eine auszuarbeitende Hausarbeit trennen mich noch von meiner Ernennungzum NLP Practitioner. Ich beschäftige mich jetzt seit einigen Jahren immer wieder mit dem Thema, und habe zum Glück einen Lehrtrainer gefunden, bei dem die Sache so viel Spaß macht, dass man auch am Thema kleben bleibt.

Solltet ihr aus dem Raum Deutschland/NRW kommen, werft doch mal einen Blick auf die Webseiten von diedenkweisen.

Anwendungen für NLP habe ich in allen Bereichen gefunden, sei es im Projektalltag in der Firma oder beim Kunden, sei es bei Problemen im Freundeskreis, sei es in der Familie. Ein wenig davon kann man sicher auf meinem eher privat orientierten Vox-Blog mitkriegen und erahnen.

NLP wird oft ein Zusammenhang mit Scientology unterstellt, meiner Meinung nach bedient sich Scientology aber lediglich der Werkzeuge des NLP. Mit der selben Denke wäre NLP auch mit Weight-Watchers gleichzusetzen: Auch hier findet NLP reichlich Anwendung.

Wie ich NLP beruflich einsetze wird sicherlich häufiger hier Thema in der Kategorie NLP werden. Vielleicht macht das ja Appetit.

MS SQL Server kennenlernen – Tag für Tag

Als Ergänzung zu meinem Eintrag von gestern, mag ich hier noch einmal kurz auf die SQL Server Central Community eingehen. Das ist nämlich der perfekte Ort, um MS SQL Server jeden Tag ein klein wenig besser kennenzulernen.

Neben Artikeln und einem breiten Angebot an Foren haben es mir dort besonders die Fragen des Tages(QOTDs – Question of the Day) angetan, die einen regelmässig auf die Seite zurückziehen. Da es dabei auch Punkte gibt, kann man sich über die Zeit leicht mit anderen DBAs und Entwicklern messen. Doch gerade falsche Antworten sind lehrreich: Die Seite weist in diesem Fall auf die entsprechenden Einträge im Microsoft Developer Network (MSDN) hin.

Auf diese Art geht lernen schnell und macht auch noch Spaß. Einziger Nachteil: man muss seine Email registrieren.

Der zugehörige Link: Welcome to SQL Server Central.

MS SQL Server: Einfach zu einfach?

In meinem Entwickler-Alltag spielt der Microsoft SQL Server oft eine sehr wichtige Rolle und das schon seit der katastrophal fehlerträchtigen Version 6.0. Zwar habe ich auch mit anderen Datenbanken wie beispielsweise DB2Oracle  oder MySQL zu tun, aber der MS SQL Server hat spätestens seit der stabilen 2000er-Version eine Sonderstellung und ist ein Werkzeug, dem ich einfach überall begegne.

Das hat meiner Meinung nach zwei Gründe:

  1. MS SQL Server ist kinderleicht ans Rennen zu kriegen
  2. er wird mehr und mehr zum Komplett-Paket für alle Business Intelligence Belange, und ist (zumindest wenn man einen Großteil der gelieferten Funktionalität auch wirklich einsetzt) einfach kostenmäßig extrem attraktiv.

Der erste Punkt, die problemlose Einrichtung, ist jedoch nicht ganz ungefährlich: Die Einstiegsanforderungen an einen Datenbank-Administrator (kurz: DBA) sind sehr gering, ich kenne sogar Firmen, die auf die dedizierte Rolle DBA weitestgehend verzichten. Stösst man aber irgendwann an die Grenze, an der die Standardkonfiguration ausgereizt ist, wird es ohne DBA schnell kritisch.

Es ist also Vorsicht geboten. Ich möchte darum in diesem Artikel ein paar der Fallstricke aus meinem Projektalltag knapp umreissen.

Es fängt oft mit Trivialitäten an. Die erste Klippe ist der vorhandene Arbeitsspeicher. Solange dieser groß genug ausfällt, ist es möglich, auch mit größeren Tabellen halbwegs performant auszukommen, und das selbst wenn kein einziger Index definiert wurde.

Geht die Performance dann bei steigendem Datenvolumen irgendwann in den Keller, ist das eine Klippe, die man meist mit Programmierern noch lösen kann. Indizes kriegen Entwickler selbstverständlich noch gut in den Griff. Die wenigsten Entwickler kennen jedoch die breite Werkzeugpalette innerhalb MS SQL Servers, die sich diesem Problem analytisch und zum Teil sogar automatisch annimmt.

Sind die Index-Probleme einmal gelöst, kommt bald eine neuer Eisberg auf uns zu. Auf 32Bit-Systemen ist diese Grenze dann erreicht, wenn die erste Tabelle mehr als 2GB Daten umfasst. Ab diesem Punkt spätestens muckt SQL Server auf: Wir haben den Adress-Raum eines 32-Bit-Systems verlassen, einfachste Operationen auf der Tabelle werden langwierig und spannend wie eine Herz-OP, und nichts ist mehr eitel Sonnenschein. Ich sage nicht, dass diese Klippen nicht zu umschiffen sind, aber ab diesem Punkt werden echte DBA-Kenntnisse unabdingbar. Programmierer kriegen diese Problematik in der Regel nicht mehr in den Griff. Es ist einfach kein Software-Problem mehr; ein Index als Zugriffspfad hat noch etwas Entwickler-Nahes, aber die schnöde Probleme Arbeitsspeicher und Plattenplatz haben meiner Meinung nach nichts in Programmierer-Hand zu suchen.

Fazit: Microsoft SQL Server ist kinderleicht einzuführen, das stimmt. Aber man sollte von Anfang an eine DBA Rolle einführen, auch wenn sie zunächst unnötig erscheint.

Ein guter DBA kennzeichnet sich meiner Meinung nach dadurch, dass man seine Arbeit nicht bemerkt. Fehlt er aber, wird das im Falle von MS SQL Server mit gefährlicher Verzögerung offensichtlich. Oft sind eingeführte Systeme dann schon unternehmenskritisch geworden… es ist also Vorsicht geboten!

Es gibt viele Schrauben im Hintergrund von MS SQL Server, aber wenn man sich regelmässig und gewissenhaft mit ihnen beschäftigt, erhält man auch ein auf Dauer stabiles und performantes System.

Links zum Artikel: