Nach all den Jahren bin ich nun fertig mit meinem Studium. Hier meine Präsentation, die ich zu meinem Kolloquium erstellt habe. Mir ist natürlich klar, dass die Tonspur fehlt und daher der Zusammenhang nicht wirklich klar wird - dennoch finde ich sie sehenswert (auch auf die Gefahr hin, dass Eigenlob stinkt)
Die Message, die ich rüber bringen möchte:
“Mashups haben deutliches Potential, um in Integrationsprojekten einen schnelleren Zugang zu Informationen zu liefern. Sie können bestehende Anwendungen aufwerten, verschaffen den Benutzern die benötigten Informationen und können insgesamt zu kürzeren Entwicklungszeiten führen, sofern sie die vorhandenen Hürden überwinden.”
Im aktuellen Linux Magazin habe ich einen interessanten Artikel zum Thema agile Methoden in der Systemadministration gefunden. In der Softwareentwicklung ist der agile Gedanke zunehmend verbreitet. In dem Tagesgeschäft eines IT-Administrators wird agilen Ansätzen derzeit wenig Beachtung geschenkt.
Marcel Wegermann beschreibt in dem Artikel wie sich die agilen Praktiken auf die Arbeit eines Administrators übertragen lassen. Durch Anpassen der Regeln lässt sich so eine ASA (Agile Systemadministration) auf die Beine stellen. So werden in diesem Artikel Zehn agile Regeln für die Systemadministration aufgestellt, die sich an XP Grundpraktiken orientieren:
Jede neue Funktion (z.B. Server, Service, Standleitung oder das Hosting) muss durch automatisierte Tests abgedeckt sein.
Teammitglieder administrieren zu zweit an der Konsole, wenn sinnvoll
Dokumentation auf Papier ist tot. Automatisierte Tests und die Konfiguration selbst sind Dokumentation genug. Kommentare ergänzen die Monitoring-Tests.
Das Team bespricht jeden Notfalleinsatz in der Retrospektive. So findet es die Ursachen für Wochenend- oder Notfalleinsätze und stellt sie zügig ab.
Risiken müssen aufgedeckt und schnell beseitigt werden (Transparenz schaffen)
Technische Entscheidungen liegen beim Team. Alle Mitglieder tragen sie gemeinsam. Das Team allein hat die Verantwortung für den Betrieb. (Team Commitments).
Die Administratoren führen Projekte iterativ und inkrementell durch.
Regelmäßig wiederkehrende Aufgaben erledigen alle Teammitglieder reihum.
Die Administration arbeitet möglichst zusammen an einem Ort in der Nähe des Kunden. (First- und Second-Level-Support, Entwickler oder Endanwender).
Ein großer Bildschirm zeigt nach Art einer Ampel den aktuellen Status der Server und Auslastung für alle gut sichtbar an. Das fördert die osmotische Kommunikation.
Mein Fazit:
Für mich der erste Beitrag zum Thema ASA. Als großer Anhänger der agilen Methoden sind für mich die Punkte eins bis acht lohnend und sicherlich in den meisten Rechenzentren anwendbar. Eine Nagios-Installation leistet bereits in vielen Unternehmen seine Dienste und kann für die gesamte Testautomatisierung herangezogen werden. Allerdings ist es dann umso wichtiger qualifizierte Kommentare in der Konfiguration zu finden.
Punkt zwei und acht sehe ich als besonders effektiv an. Denn hier steht nicht nur der agile Gedanke im Vordergrund, sondern das Vorhandene Wissen wird auf mehrere Köpfe verteilt. Damit kann dem Problem mangelnder Vertretungen entgegen gewirkt und die Abhängigkeit von Einzelpersonen aufgelöst werden.
Aber nicht alle Ansätze lassen sich so einfach umsetzen. Insbesondere den Punkt neun sehe ich als kritisch an, denn in Zeiten von Outsourcing und Service-Rechenzentren ist die örtliche Nähe zum Kunden nicht immer möglich.
Der Einsatz von Whiteboards, Pinnwänden oder Flipcharts im Administrationsbereich kann zur Sprintplanung genutzt werden oder die Teambesprechungen unterstützen. Wie Teamräume aussehen können ist hier zu sehen. Ein Ticket-Trouble-System wie OTRS kann die auftretenden Störungen kanalisieren und ist zudem revisionssicher. Darüberhinaus ist für die Projekte ein Wiki das Tool der Wahl und zur Kommunikation mit der „Außenwelt“ kann ein Blog sehr hilfreich sein. So könnten dort aktuelle Störungen oder Planungen von Downtimes kommuniziert werden.
Insgesamt haben die agilen Methoden potenzial auch in der Systemadministration einzuziehen. Die bisherigen strikten Zuständigkeiten für Systeme oder Anwendungen können so effektiv aufgebrochen und eine höhere Dienstleistungsqualität erreichet werden.
In dem dritten Teil der Reihe “Wissensmanagement im Enterprise 2.0″ berichten Simone, Frank und Christoph auf ihrem Blog wie das Potenzial von Enterprise 2.0 genutzt und die Tools (Wikis, Blogs etc.) eingeführt werden können.
Entscheidend ist es, klein anzufangen und nicht gleich die gesamte Organisation zu verändern. Hier ist der Weg das Ziel. Sobald sich die Social-Software etabliert hat, besitzt man eine unverzichtbare Wissensstruktur im Unternehmen, die einen Mehrwert für jeden Einzelnen darstellt.
Es gibt derzeit ja viele Doku-Soaps im deutschen Fernsehen. Zwischen den ganzen weniger brauchbaren Sendungen finde ich eine dennoch erwähnenswert, “Rach, der Restauranttester”. Diese Sendung ist wunderbar geeignet für Projektmanger oder Berater, da die Konzepte sich sehr gut auf die IT-Projekte übertragen lassen. Vielleicht sollte ich damit anfangen, was Christian Rach überhaupt macht:
Er besucht pro Folge ein Restaurant, das kurz vor der Pleite steht. Seine Aufgabe ist es, das Lokal vor dem Ruin zu retten. Dazu testet er die Küche, den Service und die Führung der Gastronomie.
Das ist alles!
Genau das machen viele Berater aber auch. Sie zeigen auf, dass die Kommunikation unter den Abteilungen schlecht ist, keine klare Aufgabenverteilung besteht und dass bestimmte Bereiche zusammengelegt werden sollen – in Form von Kompetenzzentren. So, oder so ähnlich werden die Vorschläge wohl lauten. Allerdings macht es Rach etwas anders. Er adaptiert nicht ein Schema F auf alle Restaurants, sondern jeder muss sich selbst treu bleiben.
Aber was kann man davon auf IT-Projekte übertragen?
Zuerst die Vorgehensweise:
Probleme offen ansprechen
Wird von vielen Beratern häufig nicht gemacht. Die Gründe dafür sind unterschiedlich. Einerseits könnte man dadurch Folgeaufträge zunichte machen, andererseits kann es klare Vorgaben durch das Management geben, eine bestimmte Meinung zu propagieren.
Eigeninitiative verlangen
Genau das sollte jeder Projektmanager oder Berater von seinem Team oder Kunden verlangen. Es geht nicht darum, einen Alleingang hinzulegen, sondern Teamarbeit ist das Stichwort.
Beteiligte mit einbeziehen
Ist kein Geheimnis, wird in der Praxis aber dennoch selten umgesetzt. Die Beteiligeten haben sich in der Regel bereits mit dem Thema auseinander gesetzt und können guten Input liefern.
Sich selbst treu bleiben
Hier trennt sich die Spreu vom Weizen. Während viele versuchen ihre Methoden, Werkzeuge und bekannte Software in allen Projekten anzuwenden, schaffen es andere die Eigenarten des Projekts und die Besonderheiten des Kunden zu berücksichtigen.
Klare Aufgeben verteilen
Nur Mitarbeiter, die wissen was sie zu tun haben, können sich auf die Arbeit konzentrieren und kommen sich nicht gegenseitig ins Gehege.
Mitarbeiter motivieren
Wenn die vorherigen Punkte umgesetzt werden, schafft das Anreize, damit sich die Mitarbeiter auch motivieren. Getreu dem Amerikanischen Sprichwort:
Tell me and I´ll forget;
show me and I may remember;
involve me and I´ll understand.
Genau an diese Punkte hält sich Christian Rach, wenn er ein Restaurant unter die Lupe nimmt. Nach einer Analyse, spricht er die Probleme offen an - und das mehr als deutlich. Er bezieht von Anfang an die Beteiligten mit ein und verlangt ihnen eigene Ideen zur Problemlösung ab. Dabei versucht er nicht einem traditionellen Wirtshaus eine System-Gastronomie aufzudrücken. Während der Umsetzung findet Rach immer wieder Worte des Lobs, um die Mitarbeiter zu motivieren (sofern diese es verdient haben).
Viele dieser Punkte werden von Projektmanagern und IT-Beratern bereits so umgesetzt, lediglich der vierte Punkt ist mir ein Dorn im Auge. Diesem Punkt wird leider nicht genug Beachtung geschenkt. Das zeigt die zunehmende Verbreitung von Standardsoftware auch in den Bereichen, in denen bisher aufgrund der speziellen Besonderheiten individuell entwickelt wurde.
Die mit Spannung erwartete Fortsetzung der Reihe „Wissensmanagement im Enterprise 2.0“ ist nun erschienen. Schon der erste Teil zeigte sehr kritisch, wie mit neuen Tools alte Konzepte umgesetzt werden.
In diesem Teil präsentieren die Enterprise 2.0-Spezialisten der T-Systems sehr gelungen, welchen konkreten Zweck die Web 2.0-Tools in Projekten haben können.
Die Botschaft ist: „Die Entdeckung des Menschen“ und meint damit, dass nicht nur Wissen verknüpft wird, sondern vor allem auch Menschen.
Wenn man sich die Definition von Enterprise 2.0 einmal ansieht, denke ich dass diese Präsentation ein echter Volltreffer ist:
Enterprise 2.0 ist ein Begriff für die Technologien und Geschäftspraktiken, die die Mitarbeiter von den Fesseln der Altlasten der Kommunikations- und Arbeitsmittel wie E-Mail befreien. Es gibt dem Management durch ein Netz von miteinander verbundenen Anwendungen, Diensten und Geräten Zugriff auf die richtigen Daten zur richtigen Zeit. Enterprise 2.0 macht die kollektive Intelligenz Vieler zugänglich und ergibt damit einen Wettbewerbsvorteil in Form von erhöhter Innovation, Produktivität und Wendigkeit.
