Neues Jahr, neues Design - neuer Titel? Nicht ganz. Ich habe mich entschieden mein Blog ein wenig umzugestalten. Dabei meine ich aber nicht nur das Aussehen, sondern auch den Titel. „IT in Unternehmen“ wird in diesem Jahr einmal mehr mein Leitsatz für die Beiträge hier sein. Der Schwerpunkt liegt in diesem Jahr auf agilen Methoden und Projektmanagement. Allerdings werde ich auch versuchen hin und wieder technische Beiträge zu veröffentlichen – nur damit ich in Übung bleibe

Also viel Spaß beim Lesen und Kommentieren.

Ich habe mich während der Weihnachtsferien ein wenig mit dem Groovy Framework Grails auseinander gesetzt und bin positiv überrascht. Ich war auf der Suche nach einer einfachen Möglichkeit RESTful Webservices an einem Beispiel darzustellen und Grails war hier das Tool der Wahl. Das bringt mich aber zu meinem eigentlichen Thema nämlich die Wahl der Technik.

In der IT wird häufig noch strategisch vorgegeben welche Technologie eingesetzt wird. Sei es die Programmiersprache, das Framework, der Anwendungsserver oder die Datenbank. Gründe dafür sind häufig die Lizenzkosten, das vorhandene know-how oder einfach der Einfluss der „grauen Eminenzen“. Die Betroffenen wissen meist, dass es einen „besseren Weg“ gibt den Job zu erledigen, der sich aber nicht so gut in das Gesamtkonstrukt einfügt. Das Ergebnis ist zumeist ein frustriertes Entwicklungs- oder Administrationsteam.
Eine Lösung könnte der Blick auf das seit Mitte Oktober 2009 existierende SOA Manifesto sein. Insbesondere die ersten drei Punkte halte ich in diesem Zusammenhang für nennenswert:

• Geschäftswert über technische Strategie
• Strategische Ziele über projektspezifischen Nutzen
• Immanente Interoperabilität über maßgeschneiderte Integration
• …

Das schreit doch gerade danach das beste Tool für den Job einzusetzen. Wenn es da nicht die unterschiedlichen Bereiche für einen Softwaresystem gäbe. Nämlich die Entwickler auf der einen Seite und die Administratoren auf der anderen. Es liegt in der Natur der Sache, dass der Admin ein gehöriges Wort bei der Technologie mitreden möchte, wird er doch in der Nacht aus dem Bett geklingelt. Ein konservatives Vorgehen ist hier also angebracht. Die Entwickler hingegen möchten natürlich die neusten Frameworks oder sonstigen Technologien einsetzen, damit sie ihre Arbeit effektiver erledigen können. Allerdings liegt aus meiner Sicht genau hier das Problem. Durch die Aufteilung in Entwicklung und Betrieb verfolgt man nicht den ganzheitlichen Ansatz. Gilt es doch eine Software zu erstellen und zu betreiben, die einen Geschäftswert erzielt – einen Service also.

Warum sollten dann nicht auch gemischte Teams, die für die Entwicklung und den Betrieb von Services zuständig sind, sich auch das beste Tool aussuchen dürfen? Diese spezialisierten Einheiten könnten sich die Programmiersprache, den Anwendungsserver oder die Datenbank frei aussuchen und damit vermutlich effektiver arbeiten. In großen Unternehmen wie beispielsweise Amazon wird das so praktiziert. Die kleinen Einheiten sind dort für die Entwicklung und den Betrieb zuständig und dabei nicht an bestimmte Infrastruktur gebunden – außer der Amazon EC2 (Elastic Compute Cloud).

Und wenn man den SOA-Gedanken noch nicht für tot hält, dann ist das sicherlich ein Schritt in die richtige Richtung.

Ich wünsche all meinen Lesern ein frohes Jahr 2010. Das allein ist noch kein Blogeintrag wert. Aber vielleicht nochmal ein Blick auf Gartner’s Hype Cycle der Technologien für 2010. Welche Technologien sind “in”, “fad” oder “out”?

Emerging Technologies Hype Cycle

Ich frage mich nur, warum ich noch nicht wirklich was von wireless power gehört habe? Aber schaun wa mal was das Jahr so bringt.

Ich habe seit längerem bereits keine Beiträge mehr verfasst. Das soll sich nun wieder ändern. Allerdings steige ich hier nur mit einem Verweis auf eine Präsentation von Xing ein, die Traian Kaiser und Mark Weber zum SCRUM Day 2009 vorgestellt haben.  Der Informationsgehalt ist ohne Tonspur nicht allzu groß, aber sehenswert ist sie dennoch.

Nachdem die Wikis sich inzwischen in vielen Unternehmen durchgesetzt haben, ist es vielleicht einmal Zeit einen kritischen Blick auf dieses Tool zu werfen.

Ich selbst habe 2005 ein Wiki eingeführt und war damals Feuer und Flamme für das allheilbringende Tool. Kommt doch mit einem Wiki ein echter Web 2.0 –Gedanke auf. Denn ein Wiki ist nach der Einteilung von O’Reilly eine Anwendung mit einem Web 2.0-Gehalt der Stufe 3. (Anwendungen, die nur online existieren und deren Funktionen auf Netzwerkeffekten basieren.) Zentrale inhaltliche Eigenschaft, ist die Entstehung der Inhalte durch die Benutzer. Soweit - so gut. Aber was passiert mit den Inhalten, die einmal in einem Wiki stehen?

Damit es auf Dauer in einem Unternehmen bestand haben kann, ist eine Form der Qualitätssicherung erforderlich. Diese erstreckt sich aber in den meisten Fällen nicht auf alle Bereiche des Wikis. So entstehen mit guter Absicht die unterschiedlichsten Dokumente. Das schöne daran – es können alle mitmachen (das liegt am Wiki). Dies birgt schon die erste Gefahr, dass Inhalte doppelt angelegt werden. Nachdem man es gemerkt hat, ärgert man sich, da die Arbeit nun umsonst war (liegt das auch am Wiki).

Was passiert aber mit den Dokumentationen, die in einem Projekt entstanden sind? Werden diese weiter gepflegt, wenn sich an den Systemen oder Prozessen etwas ändert? Dies geschieht meistens halbherzig – wir alle kennen die Gründe dafür (das liegt definitiv nicht am Wiki). Abgesehen davon, dass man selbst nicht mehr genau weiß, was alles im Wiki steht, hilft es neuen Mitarbeitern enorm sich in ein laufendes Projekt einzuarbeiten.

Binden diese neuen Mitarbeiter vorerst keine Ressourcen aus dem Team und haben dennoch die Möglichkeit einen Überblick zu bekommen – Volltextsuche sei Dank. So kann jeder, der zwei Stunden Ruhe haben, den Neuen mit dem Satz wegschicken: „Das steht doch im Wiki“ (das liegt am Wiki).

Sobald die zwei Stunden vergangen sind und die ersten Rückfragen entstehen, heißt es dann: „Das machen wir schon lange nicht mehr so, das solltest du nachdokumentieren“ (das liegt nicht am Wiki).

Und so bleibt ein Großteil der nicht ganz so häufig gelesenen Dokumentation doch aktuell – aber das liegt natürlich nicht am Wiki. Der Neue im Team hat dann auch den Überblick – nachdem er alles gelesen und nachdokumentiert hat – dank des Wikis.

Ich kann mir ein Arbeiten ohne die Wikis nicht mehr vorstellen. Es ist so einfach abteilungsübergreifend Dokumente zur Verfügung zu stellen, die von allen Beteiligten angereichert werden können.

Welche Inhalte in ein Wiki gehören muss man allerdings vorab festlegen, denn es sinnvoll diese nach Themen zu gliedern. Die Suche liefert  bessere Ergebnisse und die Benutzer können die volle Stärke dieses Tools nutzen.

Haben Sie andere oder ähnliche Erfahrungen gemacht? Lassen Sie es mich wissen!