Ich habe auf Slideshare eine interessante Präsentation zum Thema Deployment gefunden. Interessant aus zwei Aspekten. Zum einen, da wir uns derzeit auch mit dem Thema “Releasemanagement” auseinandersetzen und zum anderen, weil Flickr laut der Präsentation zehn Mal pro Tag deployed! Das halte ich persönlich für eine starke Leistung, die sicherlich gut vorbereitet wurde.

In der Präsentation geht Flickr auf die technischen Aspekte ein, die ich interessant finde. Hier kann man sich sicherlich noch die ein oder andere Anregung holen. Das wirklich Spannende liegt aber wieder mal in der Zwischenmenschlichen Kommunikation der Beteiligten – nämlich der Entwickler und der Administratoren. Die zentrale Botschaft lautet hier:

Schaffe eine Kultur, die von Respekt, Vertrauen und einer gesunden Einstellung zu Fehlern geprägt ist und in der das Thema “Schuldzuweisung” ein Fremdwort ist. Nur so können die Entwickler und Administratoren an einem guten Geschäftsergebnis mitwirken.

Dann sind die restlichen technischen Spielereien nur Administrivialitäten:

1. Vorbereiten der Infrastruktur mittels einer großen Anzahl von Tools wie beispielsweise CFengine,  Bcfg2,  System Imager, Cobbler etc.
2. Geteiltes Wissen zum Versionsstand.
3. Automatisierung von Build und Deployment.
4. Einsatz von Feature flags und private Betas, arbeiten im Trunk.
5. Visualisierung des Systemzustandes und der Einsatz von Metriken.
6. Informationsaustausch der Entwickler und der Administratoren.

Die Präsentation ist auch optisch ein echter Hingucker – also viel Spaß damit.

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.

Im Rahmen meiner Diplomarbeit beschäftige ich mich gerade mit dem Teilthema Systemintegration. Insgesamt habe ich zwei Ziele der Integration von Systemen identifiziert.

1. Konsistenzsicherung
   Die Integration wird zur Vermeidung von Mehrfacherfassungen eingesetzt, damit die Daten in allen beteiligten Systemen konsistent sind.
2. Informationsintegration
   Die Integration wird für den globalen Zugriff auf die Unternehmensdaten genutzt. Alle beteiligten Informationssysteme werden integriert, damit auf die unternehmensrelevanten Daten zugegriffen werden kann.

Da ich allerdings bei meiner täglichen Arbeit auch immer wieder mit dem Thema konfrontiert werden, prägte ein Kollege bei einer Diskussion ein weiteres Ziel der Integration: Integration durch Armut. Dieser eher scherzhaft gemeinten Aussage kann ich aber durchaus was abgewinnen. Denn man neigt schon eher dazu, viele kleine Systeme die vielleicht sogar Open-Source-Systeme sind aufgrund der Informationsintegration zu verbinden. Würde die IT-Landschaft nun aus einer großen sehr teuren Anwendung bestehen (sagen wir SAP), hätte man vermutlich weniger komplett integrierte und vermischte Anwendungen. Man würde sich einfach damit zufrieden geben was man hätte und nicht ständig nach einer Möglichkeit suchen doch noch den bereits vorhandenen Datenbestand zu nutzen…

Die Vorteile von agilen Vorgehensweisen in IT-Projekten sind hinlänglich bekannt (oder hier nachzulesen).  Kritiker meinen, dass bei diesen Methoden häufig der Gesamtüberblick verloren geht. Dadurch dass das Big Design Up Front (oder Bug Desgin Up Front) fehlt, und die Systeme iterativ entworfen werden, kann man schnell das ingenieurmäßige Vorgehen vermissen.

Agile Projekte stehen aber nicht im Konflikt mit den Ingenieurswissenschaften. Ganz im Gegenteil, dort werden sie seit den 80 erfolgreich eingesetzt. Ziel agiler Projekte ist vielmehr der Blick auf das Wesentliche zu beschränken. Dennoch fehlt häufig das „Big Picture“ für den Gesamtüberblick.

Genau dort kommt das Fundamental Modeling Concept (FMC) zum Einsatz. Mit Hilfe des FMC kann man Fach- und IT-Landkarten erstellen,  die allen Projektbeteiligten helfen einen schnellen Überblick zu bekommen.  Ich habe mir das Landkartenkonzept einmal näher angesehen und bin davon überzeugt. Im Vergleich zu Unified Modeling Language (UML), kann man FMC –Blockdiagramme ohne großen Lernaufwand auf Anhieb verstehen.  Das genügt um nach meinem Grundsatz zu handeln:

“So einfach wie möglich – aber nicht einfacher”

Probieren Sie es mal aus: http://www.fmc-modeling.org/

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]

Mashups beziehen ihre Daten von verschiedenen Quellen, transformieren sie und stellen sie in einem anderen Kontext dar. Dieses Konzept verfolgt die Enterprise Application Integration (EAI) ebenfalls. Die Unterschiede liegen in der Umsetzung. Während EAI von der IT-Abteilung mittels Bus-Systemen umgesetzt wurde, werden Mashups im Frontend von den Usern umgesetzt. Bei der EAI ist also die IT im Mittelpunkt bei den Mashups der Benutzer. Beispiele dafür gibt es genug: Google Mashup Editor, Google Maps API, Yahoo! Pipes usw. Wie können nun Unternehmen von dieser Art der Anwendungsintegration profitieren?

Für die Umsetzung eines Mashups gibt es aus architektonischer Sicht viele Lösungsmöglichkeiten. Wenn man allerdings die beiden „Extreme“ unterscheidet, spricht man von Server-Side Mashup und von Client-Side Mashup. Diese lassen sich noch weiter unterscheiden, wie in dem Blog von Dion Hinchcliffe zu lesen. Wenn also die IT-Ableitung eines Unternehmens Server-Side Mashups erstellt bedient Sie sich Frameworks, die das agile erstellen von Web 2.0-Anwendungen erleichtern. Die bereits bestehenden Anwendungen müssten nur mit APIs angereichert werden, damit eine Integration möglich ist. Hierfür bieten sich RESTful Webservice an, die in der Server-Side Mashup integriert werden. Aber auch andere Technologien lassen sich einfach integrieren. RSS/ATOM Feeds, SOAP-Webservices oder Screen scraping um nur einige davon zu nennen. Durch das „Mashen“ solcher Dienste bestenfalls aus Legacy-Anwendungen kann im Frontend mittels AJAX eine neue Anwendung entstehen, die Geschäftsprozesse abbildet, leicht erweiterbar ist und nicht so komplex wie der Serviceorientierte Ansatz. Man kann also davon ausgehen, dass Mashups ein leichtgewichtiger EAI-Ansatz ist.