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.
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.
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:
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.
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ß:
