Ich wünsche allen Lesern ein frohes neues Jahr 2011. Zeit genug sich mal wieder mit den IT-Trends für das kommende Jahr zu beschäftigen. Fakt ist wohl, dass die großen Analysten wie Gartner, Ovum, Forrester, PAC und IDC sich diesmal erstaunlich einig sind, was das Thema Cloud Computing betrifft. So sehen alle in dem Thema ein großes Wachstum für das Jahr 2011. Bei Gartner steht das Thema sogar auf dem ersten Platz der wichtigsten strategischen Technologien.

Für mich bedeutet das, dass ich mich verstärkt mit dem Thema Cloud Computing im kommenden Jahr auseinandersetzen werde. Weitere Schwerpunkte dieses Blogs werden die Themen Enterprise 2.0 (z.B. Social Communications and Collaboration) und Projektmanagement sein. Ich werde in Kürze noch die Kategorien entsprechend umorganisieren und damit für eine klarere Struktur sorgen.

Ein Auszug der Gartner Lister, die im Orginal hier zu finden ist:

• Cloud Computing
• Mobile Applications and Media Tablets
• Social Communications and Collaboration
• Video
• Next Generation Analytics
• Social Analytics
• Context-Aware Computing
• Storage Class Memory
• Ubiquitous Computing
• Fabric-Based Infrastructure and Computers

Ich sehe ebenfalls in den Themen Cloud, Apps und soziale Netzwerke einen riesen Markt für die Zukunft. Durch die aktuellen Smartphones und inzwischen bezahlbaren Tarifen, ist das Apps-Thema sicherlich ein stark wachsender Markt. Ebenso wie im letzten Jahr werden uns Facebook und Co. sicherlich noch weiter begleiten. Klar ist auch die Abgrenzung die Gartner in diesem Bereich getroffen hat:

• Social networking
• Social collaboration
• Social publishing
• Social feedback

Die Nutzung von Blogs und Wikis ist im Firmenalltag bereits nicht mehr wegzudenken.  Ebenso die Nutzung von Business-Netzwerken wie Xing. Zunehmend präsentieren Firmen aber auch ihre Produkte, Ideen und Visionen auf Plattformen wie YouTube oder Flickr. Daduch haben sie verstärkt die Möglichkeit Feedback zu den eingestellten Informationen zu erhalten. Bei dem Thema Cloud Computing handelt es sich um eine bestimmte Art des Outsourcings, was sich insbesondere für kleinere und mittlere Unternehmen lohnt. Aber auch große Unternehmen können von diesem Trend profitieren, was sich genau dahinter verbirgt, werde ich in meinem nächsten Blog-Beitrag etwas näher beleuchten.

Ich habe mich vor ein paar Tagen mit dieser Frage beschäftigt, als mein Sohn mir wieder seine Weihnachtswünsche mitgeteilt hat, die vollkommen von der ursprünglichen Planung abweichen.  Dabei ist mir erst die Nähe zum Projektgeschäft aufgefallen und die gemeinsamen Probleme, wenn man die Sache nicht richtig angeht.

Fangen wir mal vorne an. Im Rahmen einer Anforderungsanalyse  (Blättern durch den Spielzeugkatalog) entstehen erste Ideen. Die daraus entstandenen Anforderungen werden bei uns in ein Lastenheft (Wunschzettel) geschrieben.  Dann folgt eine kurze Diskussion darüber, dass nicht alle Anforderungen in der gegebenen Zeit umgesetzt werden können, da die Ziele vollkommen überzogen sind. Zur Umsetzung aller Anforderungen müssten noch weitaus mehr Meilensteine gesetzt werden als in dem ursprünglichen Zeitplan (Nikolaus und Weihnachten). Meilensteine wie Ostern, Geburtstag und nochmal Weihnachten… Also haben wir den Rahmen festgelegt und uns auf den Liefertermin geeinigt – Weihnachten eben.

Das Projektteam (meine Frau und ich) hat also versucht die Anforderungen umzusetzen und dabei in täglichen Meetings (Abends auf dem Sofa) den Projektfortschritt untereinander abgestimmt.  So agil sind wir schon. Die Rückkopplung zum Kunden habe ich übernommen, indem ich hin und wieder mal nachgefragt habe, ob die Anforderungen noch stabil sind. Tatsächlich habe ich vor ein paar Tagen festgestellt, dass sich die Wünsche vollkommen geändert haben.   Nun sollte es ja im agilen Projektumfeld keine große Schwierigkeit geben, wenn sich die Anforderungen ändern. Vermutlich steht auch ein Scrum-basiertes Projekt vor dem Aus, wenn die Anforderungen sich um 180° drehen.  Wir haben so allerdings noch die Möglichkeit Teile der ursprünglichen Planung zu verwerfen und auf die neuen Anforderungen einzugehen. Das Change-Management  wird auch wieder auf dem Wunschzettel durchgeführt. Dabei ist mir aufgefallen, dass es sinnvoll ist auch bei so kleinen Projekten die Anforderungen mit einem Datum zu versehen.

Für mich stellt sich nun die Frage, ob der Weihnachtsmann agil arbeiten  sollte oder eher klassisch Phasenorientiert. Ich bin zu der Überzeugung gekommen, dass ein agiles Vorgehen auch hier hilft. Denn neben den geänderten Anforderungen hat man so großen Einfluss auf die Erwartungshaltung des Kunden – und das ist nicht nur Weihnachten wichtig.

Ich habe in den letzten Wochen die UML als Kommunikationsmittel für mich entdeckt. Angefangen mit Activity Diagramme, die ich in Visio gezeichnet habe, über Use Case und Sequence Diagramme.
Ich rede an dieser Stelle aber nicht von UML als Modellierungssprache um daraus fertigen Code zu generieren oder gar erweiterte Ansätze wie MDD/MDA. Ich spreche von der UML als Mittel zur Kommunikation mit Stakeholdern oder Entwicklern.

Für mich der derzeit wichtigste Diagramm-Typ ist das Activity Diagramm. Das nutze ich zur Prozesserhebung und Modellierung. Es ist zwar komplexer als beispielsweise ein Sequence Diagramm, allerdings bietet es die Möglichkeit alternative Szenarien im Ablauf darzustellen. Diese Diagramme zeichne ich mit dem altbekannten Microsoft Visio. Allerdings nutze ich nicht die mitgelieferten Stencils, sondern die von Pavel Hruby, welche sich für das einfache Zeichnen ohne Validieren besser eignen. Zudem unterstützen diese Stencils die UML 2.2 und sind für alle gängigen Visio Versionen frei erhältlich.

Für die Sequence Diagramme nutze ich die Webanwendung Websequencediagrams.com. Ich habe bisher noch kein einfacheres Tool gefunden, um diese Art von Diagrammen zu erstellen. Besonders gefällt mir die Möglichkeit den Style einzustellen.  Für diejenigen, die weitere UML-Diagramme online erzeugen möchten, bietet sich die Website yuml.me an. Dort kann man neben Use Case Diagrammen auch Class- und Activity Diagramme erzeugen.  Alle Schaubilder können mittels URL in Webseiten, Wikis und Blogs eingebunden werden, was den einfachen Sketching und Kommunikations-Charakter unterstreicht.

So kann man mit diesen einfachen grafischen Methoden das Productbacklog detaillieren und User Stories für die einzelnen Sprints vorbereiten.

Innerhalb nur einer Woche erreichte die Petition gegen die Internetsperre die benötigten 50.000 Stimmen, damit der Petitionsausschuss des Bundestages sich mit dem Antrag in einer öffentlichen Sitzung beschäftigt.

Laut dem Gesetzentwurf der Bundesregierung soll das BKA Websites mit Kinderpornografie in einer Liste benennen und die dort aufgeführten Seiten müssen Internet-Provider sperren:

Wir halten das geplante Vorgehen, Internetseiten vom BKA indizieren & von den Providern sperren zu lassen, für undurchsichtig & unkontrollierbar, da die “Sperrlisten” weder einsehbar sind noch genau festgelegt ist, nach welchen Kriterien Webseiten auf die Liste gesetzt werden. Wir sehen darin eine Gefährdung des Grundrechtes auf Informationsfreiheit.

Nun hoffe ich, dass doch noch erkannt wird, dass dieses Vorhaben vollkommen am Ziel vorbeischießt. Denn eine Eindämmung der Kinderpornografie wird damit definitiv nicht erreicht, wohl aber eine Zensur des Internets vorgenommen.

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:

1. Jede neue Funktion (z.B. Server, Service, Standleitung oder das Hosting) muss durch automatisierte Tests abgedeckt sein.
2. Teammitglieder administrieren zu zweit an der Konsole, wenn sinnvoll
3. Dokumentation auf Papier ist tot. Automatisierte Tests und die Konfiguration selbst sind Dokumentation genug. Kommentare ergänzen die Monitoring-Tests.
4. 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.
5. Risiken müssen aufgedeckt und schnell beseitigt werden (Transparenz schaffen)
6. Technische Entscheidungen liegen beim Team. Alle Mitglieder tragen sie gemeinsam. Das Team allein hat die Verantwortung für den Betrieb. (Team Commitments).
7. Die Administratoren führen Projekte iterativ und inkrementell durch.
8. Regelmäßig wiederkehrende Aufgaben erledigen alle Teammitglieder reihum.
9. Die Administration arbeitet möglichst zusammen an einem Ort in der Nähe des Kunden. (First- und Second-Level-Support, Entwickler oder Endanwender).
10. 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.

Immer dann, wenn ich einen Azubi betreue und ihm in die “Kunst” der Perl-Programmierung einführe, bin ich erschrocken wie planlos die jungen Menschen ihre Programme aufbauen. Leider bleibt es bei vielen Programmierern und IT-Administratoren dabei. Dies führte vor ein paar Tagen zu einer Diskussion, ob Perlcode “schön sein muss”. Ich benutze absichtlich diese Formulierung, um die Brisanz deutlich zu machen. Auch viele meiner Kollegen gehen eher den pragmatischen Weg und schreiben ihre Skripte nicht zum lesen. Dies führt immer wieder dazu, dass jemand der das Skript nicht geschrieben hat und “mal eben” eine Änderung vornehmen muss, bei einem 200 Zeilen Skript einen halben Tag braucht. Leider führt die Freiheit alles kurz und “mal eben” zu schreiben häufig dazu, dass Perlcode, und insbesondere die regulären Ausdrücke, als Leitungsrauschen wahrgenommen wird.

Ich habe mir jedenfalls die Mühe gemacht,  die aus meiner Sicht wichtigen Punkte zusammenzutragen, damit man Perlcode schreiben kann, der auch gerne gelesen wird.
Also viel Spaß:

[slideshare id=513528&doc=perl-style-1216114162720667-8&w=425]