arago UpDate! 14

arago

UpDate!

B2B-Magazin mit IT-Fokus Ausgabe 14 · Dezember 2010

Editorial Fokus

Inhalt

3

Capacity Management – Grund genug für die Cloud

7

arago betreibt Online-Handelsplattform von Union Investment

8

Die 5 Stufen von Automation

Development 13

MAID – Monitoring Automation Interface Description

14

Erfahrungen aus der Automatisierungseinführung

16 Wie motiviert man Geeks?

Inside arago 18 Neu bei arago 20 IBM Tivoli Technical Conference 21

15 Jahre arago AG – ein Sommertraum

22 Der arago Autopilot auf Tour 23 Impressum

Comment

14

24 Auf einmal wollen alle Cloud

UpDate! ist das Magazin für Kunden, Partner und Freunde der arago AG arago AG Eschersheimer Landstraße 526–532 · 60433 Frankfurt am Main Internet: www.arago.de · E-Mail: info@arago.de Telefon: 0 69 / 405 68‑0 · Fax: 0 69 / 405 68‑111

Editorial

2 Liebe Kunden und Freunde der arago AG, bereits in den vergangenen Ausgaben des arago UpDate! Newsletters haben wir begonnen, Ihnen das Thema Cloud Computing nicht nur als technologischen Trend, sondern auch als geschäftlich sinnvolle und vor allem bereits verfügbare Alternative zur physischen Hardwareumgebung vorzustellen. Nachdem nun auch prominente Vertreter unserer Branche, wie René Obermann, Vorstandsvorsitzender der Deutschen Telekom, oder Steve Ballmer die Relevanz des Cloud Computing bestätigen, wollen wir Ihnen auch in dieser Ausgabe praktische Hinweise und Wissen übermitteln, wie Sie Clouds für Ihr Unternehmen einsetzen können. Nicht ohne Grund stellte Herr Obermann bei der Cloud Computing Conference im Oktober fest, dass der Markt für CloudServices förmlich explodiere, und Herr Ballmer propagiert gar, dass die Transformation zum Cloud Computing unausweichlich sei – die Frage sei nur noch, mit welcher Geschwindigkeit sich dieses neue Paradigma durchsetze. Eine angeschaffte und betriebene Überkapazität von bis zu 80 Prozent an IT Infrastruktur in den Unternehmen zwingt zum Handeln. Wie man diese Überkapazität abbaut, ohne gleich alle Applikationen neu zu entwickeln und ohne ein unternehmensweites Migrationsprojekt anzustoßen, be-

leuchten wir in dieser Ausgabe mit einem Beitrag zum Thema Capacity Management.

Ist man denn erst einmal auf der Cloud angekommen, stellt sich natürlich die Frage, wie man mit dem entstehenden Overhead an Administrationsaufwand und mit der gewachsenen Dynamik und Komplexität sowie der neuen Skalierungsgeschwindigkeit umgeht. Dass man an eine automatisierte Lösung ganz natürlich heranwächst und sich dieses Heranwachsens nur bewusst werden muss, um mit einem automatisierten IT Betrieb nicht nur auf der Infrastrukturseite das „on Demand Modell“ für Ressourcen zu etablieren, leitet arago Gründer und Vorstand Hans-Christian Boos in einem Beitrag über die fünf Stufen der Automation her.

Die Automation im IT Betrieb entspricht in ihrer Natur der Arbeitswelt in einer Wissensgesellschaft, denn hier werden die Menschen dafür bezahlt Wissen anzusammeln und nicht dafür – wie es in einer produktionsorientierten Gesellschaft der Fall ist – Wissen anzuwenden. Welche Ansätze es gibt, diese neue Erfahrung vor allem bei den Experten, die durch konstantes Lernen heute schon jeden Tag mehr Wissen anhäufen, zu erwirken, wird in einem Artikel zur Einführung der arago Autopilot Engine (aAE) deutlich. Bei arago ist dieser hoch automatisierte Betriebsansatz schon lange State-of-the-Art, doch auch den eigenen Mitarbeitern ist der große Unterschied zur herkömmlichen Arbeitsweise nicht immer völlig bewusst gewesen. Wir wollen Ihnen mit diesen Einblicken zeigen, dass Automation im Systembetrieb kein Hexenwerk, sondern nur die Konsequenz einer entsprechenden Umstellung des Arbeitsmodells ist. Eine Umstellung, die sich – und auch das können Sie im Update! Newsletter nachlesen – auch auf die Motivation auswirkt.

Ich wünsche Ihnen eine anregende Lektüre und verbleibe herzlichst, Ihr

Martin Friedrich

UpDate! Ausgabe 14 · Dezember 2010

Fokus

3

Capacity Management – Grund genug für die Cloud Mit dem Thema Bessere Nutzung der ITRessourcen verbinden sich derzeit viele interessante Schlagworte wie Capacity Management, Green IT, Energy Management und insbesondere Cloud Computing. Wa­ rum diese Themen scheinbar überraschend und mit großer Macht auf den Tischen der CIOs erscheinen, von allen Marketingmaschinen in die Welt geblasen werden und vor allem, was genau dahinter steckt und welche Ansätze man wählen kann bzw. welche Herausforderungen einem dabei begegnen, das soll im Folgenden skizziert werden.

Der Unsinn der Planwirtschaft am Beispiel IT Kapazität In den meisten Unternehmen wird zusammen mit IT Projekten auch die benötigte Infrastruktur angeschafft. Da diese Teil des Projektbudgets ist, wird sie auch nur für dieses Projekt verwendet. Das bedeutet aber auch, dass eine solche Infrastruktur auf drei oder fünf Jahre abgeschrieben wird und dementsprechend von vornherein so ausgelegt sein muss, dass sie in diesem Zeitraum ohne nennenswerte Erweiterungen für den Betrieb der im Projekt erzeugten IT Lösungen ausreicht. Alleine dadurch entsteht eine unglaubliche Überkapazität, denn selbstverständlich sind die Wachstums- und Belastungsannahmen der Planung eher auf der sicheren Seite. Diese massive Überkapazität zu Produktionsbeginn wird mit hoher Wahrscheinlichkeit auch am Ende der Abschreibungsphase noch vorhanden sein.

Statistisch gesehen sind Hard- und Software­investitionen (inkl. Wartung) mit unter 20 % des gesamten IT Budgets noch tragbar.

Bedenkt man aber die durch einmal aufgestellte Hardware entstehenden Energiekosten, die noch einmal ca. 20 % ausmachen, und kombi-

Hans-Christian Boos

niert dies mit den Analystenvorhersagen über massiv steigende Energiepreise, so ergibt sich zwingend die Notwendigkeit, diesen absichtlichen Aufbau von Überkapazitäten sofort zu stoppen. Da der eigentlich für die IT Leistung benötigte Energieanteil nur 1⁄6 der verbrauchten Energie ausmacht und die außerdem verbrauchte Energie in Abwärme verwandelt bzw. für Kühlung und andere RZ-Maßnahmen verbraucht wird, ist der Gesamtenergieverbrauch der Hardware nur in sehr geringem Maße davon abhängig, wie sehr diese Hardware auch genutzt wird.

Aus diesen Gründen sind die Themen Capacity Management und Energy Management wichtige Bestandteile einer modernen IT Strategie.

Capacity Management – Übergreifender Ansatz mit organisatorischem Handlungsbedarf Im Bereich Energy Management gibt es einige sehr IT-typische Ansätze, bei denen durch Management Software in Kombination mit Strommanagement Hardware der Verbrauch bereits vorhandener Hardware gedrosselt werden soll. Das kann durchaus einen positiven Effekt haben, ist aber natürlich längst nicht mit einem Capacity Ansatz zu vergleichen, bei dem nicht benötigte Ressourcen erst gar nicht angeschafft werden geschweige denn Strom oder Administrationskapazitäten binden oder zusätzliche Hardwareinvestitionen nach sich ziehen.

Capacity Management ist also der sauberere Ansatz. Capacity Management setzt aber voraus, dass man, noch bevor irgendwelche ­ technischen Lösungen ins Auge gefasst werden, den IT Projekten das Budget zur Hardwareanschaffung entzieht und es den Fachabteilungen zuschlägt, die dann freilich bei der IT den Verbrauch von IT Ressourcen bezahlen

UpDate! Ausgabe 14 · Dezember 2010

Fokus

4 müssen. An zweiter Stelle – wiederum vor allen technischen Maßnahmen – steht, den IT Architekten plausibel zu machen, dass die Planung von Hardwarepuffern nicht mehr Teil ihrer Architekturen sein sollte, weil damit sofort Effekte des Capacity Management verschenkt werden.

Hat man diese beiden betriebswirtschaftlichen und psychologischen Schritte vollbracht, lohnt es sich, tiefer in die Fragen zur Umsetzung des Capacity Managements einzusteigen.

Capacity Management und seine organisatorische Umsetzung Betrachtet man die gängigen Einführungsstrategien für ein Capacity Management, wird sehr häufig von einer Migration auf eine vollkommen neue Plattform gesprochen. Hält man die erfolgreichen Capacity Management-Umgebungen von z.B. Google oder Amazon dagegen, fällt auf, dass das Ziel gerade dieser beiden stets darin bestand, alte Hardware so lange wie möglich einzusetzen. Es scheint empfehlenswert dieser Maßgabe zu folgen, womit sich die Frage stellt, welche Anwendungen und Umgebungen überhaupt für das Thema Capacity Management in Betracht kommen.

Diese Frage lässt sich im Sinne des Architekten sehr einfach beantworten: ALLE. In der Praxis bietet es sich aber an, hier einige klare Regeln zu definieren, die die Reihenfolge bestimmen, in der Anwendungen in eine Capacity Management Umgebung überführt werden, und die bestimmen, welche Hardware weiter verwendet werden soll, unter welchen Bedingungen Hardware entsorgt wird und unter welchen restriktiven Bedingungen in diesem Zuge neue Hardware angeschafft werden darf. Bei einer angenommenen Überkapazität von mindestens 80 % kann wohl auf einiges an Hardware verzichtet werden.

Ein solches Regelwerk könnte so aussehen: 1. Alle Hardware, die nicht in den nächsten 6 Monaten abgeschrieben ist, wird auf jeden Fall übernommen.

UpDate! Ausgabe 14 · Dezember 2010

2. Alle Hardware, die abgeschrieben ist und deren Wartung bereits periodisch verlängert werden muss, wird abgeschafft.

3. Alle Anwendungen, die in den letzten 12 Monaten mindestens einen Incident auf Grund von Kapazitätsproblemen hatten, werden mit Prio 1 überführt.

4. Alle Anwendungen, für die neue Hardwareanschaffungen bereits beschlossen, aber noch nicht durchgeführt sind, werden mit Prio 1 überführt.

5. Alle Anwendungen, die mit einer Auslastung von unter 5 % arbeiten, werden als Pool für diese Prio 1 Überführungen betrachtet und so lange den überführten Applikationen hinzugefügt, bis die notwendige Spitzenkapazität erreicht ist.

Wie die eigentliche Überführung vonstattengeht, ohne eine manuelle 1:1 Migration aller IT Anwendungen anzustoßen, ist eine große Herausforderung, die an anderer Stelle darzulegen ist. So viel sei aber gesagt: Ohne einen weitreichenden Automatismus ist ein solches Projekt nicht realistisch und sollte erst gar nicht angegangen werden.

Die Architektur einer Umgebung mit Capacity Management Als technische Methode zur Umsetzung einer Umgebung, die den Maßgaben des Capacity Management folgt – die also die vorhandenen IT Ressourcen den Anwendungen so flexibel zur Verfügung stellt, wie sie gerade gebraucht werden – ist Virtualisierung das Gebot der Stunde. Nicht ohne Grund haben diese Technologien in den letzten Jahren einen erheblichen Aufschwung genommen. Neben der Virtualisierung, welche die Simulation mehrerer virtueller Ressourcen auf einer physikalischen Ressource erlaubt und es damit ermöglicht, vorhandene Ressourcen maximal auszulasten, stellt sich auch die Frage nach der Verwaltung einer solchen Umgebung, nach der Kontrolle und Vorhersagbarkeit der benötigten Kapazität und nicht zuletzt nach dem Betrieb einer so geschaffenen neuen Umgebung.

Fokus

5

Summe IT-Ressourcen

die gleiche Plattform unter einem Dach stabiler Wenden wir uns zunächst dem Thema der Schnittstellen und Verfahrensweisen vereinVirtualisierungsplattform zu. Es ist anzunehheitlicht. Erstens, weil nur so die langfristige men, dass man bei den Applikationen, die im Kontrolle über die neu gestaltete IT Landschaft ersten Schritt in eine kapazitätsgemanagte garantiert werden kann, und zweitens, weil nur Umgebung überführt werden sollen, verschieüber derartige Schnittstellen der Übergang dene Plattformen zum Einsatz kommen. Das zwischen den verschiedenen Plattformen im bedeutet, dass man verschiedene Virtualisielaufenden Betrieb und insbesondere während rungstechnologien (z. B. VMware für Linux und der Migration zu automatisieren ist.

Windows Umgebungen, Solaris 10 für SPARC Umgebungen …) verwenden muss oder vor dem Einsatz der Virtualisierung Anwendungen Capacity Management, Work in eine andere Umgebung überführen muss – Load und die Cloud letzteres erscheint eher unrealistisch, wenn kurzfristige Ergebnisse erwartet werden.

Bei der Planung der Größe einer solchen Eine gute Architektur für eine Umgebung, kapazitätsgemanagten Umgebung stellt sich die Virtualisierung für verschiedene Technoloautomatisch die Frage nach der benötigten gien unterstützt und damit ein durchgehendes Gesamtkapazität. Und spätestens an dieser Capacity Management ermöglicht, muss verStelle zeigt sich, dass Cloud Ansätze – die die schiedene Plattformen unterstützen und eine Ressourcenzuteilung selbstständig überneheinfache Schnittstelle definieren, wie ein Sysmen – zwingend erforderlich sind. tem auf diesen Plattformen zu platzieren ist.

Weil man sich nur schwer damit anfreunNur so lassen sich verschiedene, im Hause evenden kann, dass IT Infrastruktur nicht mehr von tuell bereits vorhandene VirtualisierungsinitiaBedeutung ist – ein eher psychologisches Protiven nicht-destruktiv zusammenführen und blem, dessen Rationalisierung mit Sicherheitsgleichmäßig für das große Ziel Capacity Madebatten ermöglicht wird – ist der erste Benagement nutzen. Außerdem hat ein solches rührungspunkt mit einer solchen Umgebung Vorgehen den deutlichen Vorteil, dass – unabhängig Prio 1 Prio 2 Prio 2 Prio 1 von der Plattform – eine Methodik genutzt werden kann und man damit – je nach Marktentwicklung – offen ist, eine Virtualisierungstechnologie durch eine andere und einen Plattformanbieter durch einen anderen zu ersetzen – zum Beispiel, weil man zukünftig an Stelle eines internen RZs auch externe Anbieter in Betracht ziehen will.

Grundvoraussetzung ist also eine gute Architektur, die verschiedene Plattformen und verschieUnterkapazität Überkapazität dene Anbieter für ein und

UpDate! Ausgabe 14 · Dezember 2010

Fokus

6 logischerweise die sogenannte Private Cloud.

Das bedeutet, die technischen Konzepte der Virtualisierung und die dynamische Ressourcenzuteilung auf einer Plattform umzusetzen, die man zu 100 % kontrolliert bzw. die einem tatsächlich selbst gehört. Erst dann sind Überlegungen anzustellen, ob der Einkauf von externen IT Ressourcen überhaupt möglich ist.

Aus den dynamischen Bedarfsanforderungen in Kombination mit den ungleich verteilten Ressourcen ergibt sich also selbst dann der Einsatz von Cloud Technologie, wenn die physikalische Hardware immer noch im Besitz des eigenen Unternehmens bleibt. Es stellt sich aber auch die Frage, in welcher Größenordnung sich die tatsächlich mögliche Kapazitätsverringerung so umsetzen lässt.

Die durchschnittlich benötigte Kapazität lässt sich einfach benennen, indem man die durchschnittliche IT Last in Bezug auf CPU, Speicher, Storage und Bandbreite ermittelt.

Die maximal benötigte Kapazität erhält man, indem man die Zeitreihen der benötigten Kapazität aller Anwendungen addiert und das absolute Maximum dieser neuen Zeitreihe ermittelt. In einem normalen Unternehmen ist die Varianz, also die Spannbreite zwischen maximal und minimal benötigter Kapazität relativ hoch. Denn selbst in Unternehmen mit einem globalen Geschäftsmodell ist die IT Nutzung immer gewissen Zyklen unterworfen. So erfolgt zum Beispiel die Abrechnung immer zum Monatsende, 90 % der Transaktionen werden in einem Markt durchgeführt usw. Das bedeutet, dass die Maximalbelastung der IT und damit die vorzuhaltende Kapazität auch diesem Zyklus unterworfen ist, bei dem sich die benötigte Kapazität vieler Systeme zum selben Zeitpunkt kumuliert.

Um den maximalen Effekt des Capacity Management nutzen zu können, ist es also an sich erforderlich, die Last ganz verschiedener Geschäftsmodelle auf einer physikalischen IT Plattform zu bündeln. Das kann entweder geschehen, indem man selbst zum Cloud Anbieter wird (Beispiel Amazon) oder die genutzten physikalischen Plattformen zumindest mittel-

UpDate! Ausgabe 14 · Dezember 2010

fristig an einen oder mehrere Cloud Anbieter übergibt. Da die notwendige Verteilung der benötigten IT Ressourcen relativ groß ist, muss ein Cloud Anbieter eine gewisse Minimalgröße erreichen und bei dieser Minimalgröße auch noch das Mischungsverhältnis verschiedener Geschäftsmodelle, die die Plattform nutzen, beeinflussen können.

Fazit Die eigene IT unter Capacity Management zu stellen und danach zu streben, dass nur so viele IT Ressourcen vorhanden sind, wie auch tatsächlich zu einem Zeitpunkt benötigt werden, ist ein logischer Schritt auf dem Weg, nicht genutzte Infrastruktur abzustoßen. Die Frage, warum nicht jedes Unternehmen dieses Thema schon lange betrachtet hat, lässt sich einfach damit beantworten, dass bisher der durch brachliegende IT Ressourcen verursachte finanzielle Schaden im Verhältnis zur Marktentwicklung gering war und erst die prognostizierten, stark steigenden Energiekosten in Kombination mit einer ungewissen Zukunft solche Schäden zu einem relevanten Faktor machen.

Außerdem müssen vor der technischen Einführung von Capacity Management zunächst organisatorische Schritte unternommen werden, um die Schaffung weiterer Überkapazitäten zu verhindern und die Budgets von Infrastruktur und Projekten zu trennen.

Will man nun eine Umgebung unter Capacity Management aufbauen, so ist eine Architektur, die über Standardschnittstellen verfügt, welche die Ansteuerung verschiedener Plattformen und Anbieter zulassen, zwingend notwendig, um die gewünschte Flexibilität zu erreichen. Ferner ist aus technischer Sicht eine Kombination von Virtualisierungs- und Managementtechnologie zur dynamischen Ressourcenverwaltung – also Cloud Technologie – erforderlich, um ein solches Unterfangen umsetzen zu können.

Um den maximalen Effekt zu erzielen, müssen sich die Nutzer verschiedener Geschäftsmodelle zwangsläufig eine physische Infrastruktur

Fokus teilen, um die Varianz zwischen durchschnittlichem und maximalem Ressourcenbedarf zu verringern. An dieser Stelle ist also nicht nur der Einsatz von Cloud Technologie, sondern auch die Nutzung von Cloud Angeboten zwingend erforderlich.

Bleibt also Folgendes zu sagen: Das Thema Capacity Management und damit Energie- und

7 Investitionskostensenkung kann und sollte ein wesentlicher Grund für Unternehmen sein, sich dem Cloud Computing zuzuwenden, denn hier sind die niedrig hängenden Früchte zu finden und die Erfahrungen zu sammeln, die man für weitere positive Effekte aus der Nutzung dieser Technologien benötigt.

arago betreibt OnlineHandelsplattform von Union Investment

Fallstudie

Union Investment sichert sich durch Outsourcing-Vertrag mit T-Systems maßgeschneiderte Betreiberdienste von arago

Outsourcing-Vertrag mit T-Systems sichert maßgeschneiderte Betreiberdienste von arago Die Frankfurter Automatisierungs-Experten von arago haben für fünf weitere Jahre den Auftrag zum Betrieb der Online-Handelsplattform von Union Investment erhalten. Bereits seit 2005 kümmert sich arago als Subunternehmer um den Betrieb der unternehmenskritischen und mit den übrigen Systemen eng verzahnten Online-Handelsplattform von T-Systems und setzt dazu auf seine Automatisierungslösung IT-Autopilot.

Der automatisierte Betrieb in Verbindung mit der besonderen Erfahrung von arago im Umgang mit komplexer Individualsoftware hat sich im Laufe der Jahre bewährt und für eine gleichbleibend gute Betriebsqualität mit hoher Verfügbarkeit und schnellen Reaktionszeiten gesorgt. Auf dem Hintergrund dieser positiven Erfahrung fiel es T-Systems leicht, arago als Subunternehmer ins Boot zu holen.

Die ungewöhnliche Zusammenarbeit des großen Generalisten mit einem mittelständischen Spezialanbieter hat sich auf alle Fälle gelohnt. Als Weltkonzern deckt T-Systems die meisten Managed Services der Union natürlich schon mit ihrem Standardangebot ab. Die arago AG kümmert sich mit ihrem Spezialwissen und der AutomatisierungsExpertise wieterhin um die besonders kniffligen Sonderfälle.

Die komplette Fallstudie zur Zusammenarbeit von Union Investment, T-Systems und der arago AG können Sie gebührenfrei über folgende Adresse anfordern:

arago Institut für komplexes ­Datenmanagement AG Annett Boos Tel.: 0 69 / 405 68-104 Fax: 0 69 / 405 68-111 aboos@arago.de

UpDate! Ausgabe 14 · Dezember 2010

Fokus

8 Hans-Christian Boos

Die 5 Stufen von Automation Automation für den IT Betrieb ist derzeit in aller Munde und es ist – gerade wenn man sich schon lange mit dem Thema beschäftigt – sehr auffällig, dass IT Automatisierung für jeden etwas anderes bedeutet.

Es stellt sich in erster Linie die Frage, ob Industrialisierung überhaupt mit ähnlichen Methoden auf die IT angewendet und ob damit dann ein Automationsgrad wie in der physischen Produktion erreicht werden kann. Im zweiten Schritt stellt sich die Frage, ob Automatisierung der IT nicht gleichzeitig das langsame Abgeben von Kontrolle in Richtung der maschinellen Entscheidungen ist. Welche klare Antwort man auf die erste Frage geben kann und in welchen 5 Schritten sich Automatisierung im IT Betrieb bereits lange etabliert hat und damit auch nicht mehr aufzuhalten ist, wird im Folgenden dargelegt.

Industrialisierung im herkömmlichen Sinne reicht für IT nicht aus Seit längerem spricht man von der Industrialisierung der IT und verbindet damit die Anwendung der Erkenntnisse aus der industriellen Revolution und der Massenfertigung auch auf die IT. In der Tat ist es so, dass in den meisten Bereichen, in denen IT „produziert“ wird, eher wie in einem Alchemistenlabor, und wenn es besonders gut organisiert ist wie in einer Manufaktur, gearbeitet wird. Diese Missstände sind aber erkannt und es gibt zwei große Lösungsansätze, um die Betriebsorganisation zu verbessern und die Konzepte der Massenfertigung auch für den IT Betrieb anwendbar zu machen.

Erstens werden Erkenntnisse aus der Organisation von Produktionsprozessen auf die IT angewandt. Die ersten Gehversuche in diesem Bereich waren noch recht holperig, aber spätestens nachdem mit ITIL ein Standard vorliegt, der einer guten Produktionsorganisation ent-

UpDate! Ausgabe 14 · Dezember 2010

spricht und viele der Erkenntnisse notwendiger Kommunikation, Organisation und Verbesserung aus der industriellen Fertigung einarbeitet und dabei auf die Besonderheiten (hohe Veränderungsrate, andere Persönlichkeitsstruktur des Personals, starke Technologielastigkeit) der IT zentral im System verankert, kann man sich nicht über das Fehlen eines guten und anwendbaren industriellen Prozesses zur Organisation der Fertigung, sondern höchstens über dessen mangelhafte Einführung im eigenen Unternehmen beschweren.

Bei der eigentlichen industriellen Fertigung, sprich der Massenfertigung, sieht es etwas anders aus. Denn obwohl kein Mensch in der IT die Notwendigkeit von Standards bestreitet und nahezu jeder Teilnehmer am IT Karussell Standards befürwortet, ist die IT eben doch noch nicht so weit zur „Commodity“ mutiert, dass sich nicht quasi jeder Produzent von der Nichteinhaltung allgemeiner Standards oder von der Schaffung eigener Standardvarianten oder ganzer eigener Standards einen Marktvorteil verspricht. Und so kommt es, dass Standards insbesondere in den Bereichen der IT Fuß fassen, die als nicht mehr marktrelevant betrachtet werden. Als wünschenswertes Gegengewicht zu dieser Entwicklung, die das Einpendeln auf eine gute Lösung zum Vorteil jeweils einzelner Marktteilnehmer möglichst lange hinauszögert, hat sich die Open Source Bewegung erfolgreich platziert. Open Source ist die einzige Quelle kommerzieller Standards, die auf einer breiteren Ebene eingehalten werden. Leider ist auch hier die Dominanz einzelner Marktinteressen durch die Abhängigkeit von Open Source Projekten von kommerziellen Sponsoren stark gegeben. So lange es also auch nur ein Vorteil sein könnte eine individuelle IT Applikation zu erstellen oder einen individuellen Betriebsprozess für eine Umgebung zu schaffen, wird sich das Thema Standardisierung niemals soweit etablieren, wie es in der fertigenden Industrie der Fall ist. Da die Standardisierung aber die Grundvoraussetzung für die Massenprodukti-

Fokus

9

on und damit für Skaleneffekte (Economies of Scale) ist, sind eben jene Skaleneffekte nur in geringen Teilen der IT Produktion – und meist in denen, die ohnehin keine gute Marge mehr versprechen – möglich.

Aber reicht es zu sagen, dass die Marktteilnehmer einfach noch nicht in einem reifen Markt leben und sich damit noch nicht der Industrialisierung unterwerfen müssen? Nein, ganz sicher reicht dies nicht, denn der IT Markt unterscheidet sich in zwei ganz wesentlichen Faktoren von der industriellen Fertigung von Gütern. Erstens hat dieser Markt eine unglaubliche Veränderungsgeschwindigkeit. Auch wenn man manchmal erstaunt ist, welche Dinosaurier man noch unter den lebendigen IT Anwendungen findet und auch wenn es den alten Hasen der IT Branche immer wieder auffällt, dass ein alter Wein in einen neuen Marketingschlauch gefüllt wurde, so ist die Veränderungsrate in der IT so hoch, dass sich die hohen „Rüstkosten“ für eine standardisierte Massenfertigung tatsächlich oft gar nicht rechnen können – schlicht und einfach, weil diese standardisiert zu produzierende Dienstleistung gar nicht lange genug lebt, um die Kosten für ihre

Industry

Knowledge width 0

Economy Today

IT-Today

Knowledge depth 0

Knowledge Work

100

Manufacture

100

Craftsman

Standardisierung hereinzuholen. Zum zweiten – und wahrscheinlich wesentlichen – ist der wichtigste Rohstoff für IT Systeme das Gedankengut und die Kreativität der beteiligten Menschen. Das sogenannte „Intellectual Capital“ treibt die IT voran und sorgt für Marktvorteile oder in manchen Fällen sogar gleich für ganz neue Märkte (siehe z. B. Facebook). Man kann also durchaus von einem „Talent driven Market“ sprechen und obwohl Talent nicht automatisch mit Eigensinn korrelieren muss, so läßt sich Talent und die Anwendung von grauen Zellen zur Ersinnung neuer Ideen nur sehr schwer einem standardisierten Prozess oder gar einem Prozess der Massenfertigung unterziehen.

Das Fazit aus diesen einfachen Erkenntnissen ist, dass es uns schwer fallen wird, ein Fließband für die Erstellung von IT zu erfinden.

Und das hat sofort zur Folge, dass es uns noch schwerer fallen wird, ein Fließband zur Betreuung von IT zu konstruieren. Weil sich dieses Fließband so schnell ändern und mit so vielen Neuerungen versehen werden müsste, käme es innerhalb von kürzester Zeit zum Produktionschaos.

UpDate! Ausgabe 14 · Dezember 2010

Fokus

10 Damit ist klar, dass sich der weitaus größte Kostenblock im IT Betrieb nicht mit herkömmlichen Industrialisierungskonzepten „mal schnell“ managen lässt, sondern dass neue, wissensbasierte Ansätze notwendig sind.

Die Stufen der Automation Automation im IT Betrieb besteht also in erster Linie darin, Wissen verfügbar zu machen und es zur passenden Zeit zur Anwendung zu bringen. Wenn dieser Grundsatz als gegeben angesehen wird, dann ist die Basis des gesamten IT Betriebes das Wissen der IT Experten und seine Anwendung. Automation in diesem Bereich bedeutet also eine gewisse Struktur in dieses Wissen zu bringen oder dieses Wissen irgendwie schneller zur Anwendung zu bringen bzw. dafür zu sorgen, dass es schneller – oder weniger oft – akquiriert werden muss.

Die erste Stufe der Automation ist also die freiwillige Extraktion des Wissens aus den Köpfen der Wissenden. Da die IT Welt sehr werkzeuggestützt und technologieaffin ist, kann man diese erste Stufe leicht mit einem Hype

bestimmter Tools in Verbindung bringen – zum Beispiel der Verbreitung der WiKis. In dieser Stufe der Automation geben Wissende ihr Wissen in einer von ihnen selbst gewählten Struktur ab. Meist tun sie dies, weil sie mit ihren Aufgaben vollkommen überlastet sind (Talente sind in der IT schwer zu finden) und sich von der Weitergabe des Wissens Hilfe erwarten. Andere tun es, weil sie von irgendeiner höheren Instanz (ab und an vom Gewissen) dazu gezwungen werden, das Geheimnis um gewisse Anwendungen und deren Betreuung zu lüften. Auch wenn sich das für eine andere Branche seltsam lesen würde, aber das Unterstützen der Entstehung von chaotischer und relativ unstrukturierter Dokumentation war und ist in der IT und insbesondere im IT Betrieb ein immenser Vorteil. Und im wahrsten Sinne des Wortes wird nun automatisiert, denn Arbeiten können in einem besser organisierten Prozess von weniger qualifizierten Talenten durchgeführt werden (auch wenn dies einen erheblichen Overhead bedeutet). Man hat also – ähnlich wie in der Manufaktur – einen Meister durch mehrere Gesellen ersetzt und der Meister hat Zeit, sich die

Autarke Systeme

z.B. arago Autopilot for IT Operations

Autarke Spezialsysteme

z.B. Cluster-Steuerung

Skripte

z.B. Run Books

Strukturierte Wissensdatenbank

z.B. Knowledge Base

Unstrukturierte Wissensdatenbank

z.B. Wiki

5

4

3

1

UpDate! Ausgabe 14 · Dezember 2010

2

Fokus nächste Generation Methoden oder Werkstücke auszudenken.

Die zweite Stufe der Automatisierung ist eine Verbesserung der ersten. Hat man einmal eine chaotische, selbstwachsende Wissenslandschaft geschaffen, so fällt einem schnell der bereits erwähnte Overhead auf, der für den Zugriff auf das Wissen entsteht oder sogar die steigende Fehlerrate, die durch Missverständnisse und Fehlinterpretationen ob der inkonsistenten Struktur und Vernetzung des Wissens gefördert wird. Die nächste Stufe der Automatisierung ist also eine Art Metastandardisierung des Wissens. Man standardisiert nicht das abzugebende Wissen selbst (das würde dem System IT wiedersprechen), sondern legt einen Rahmen und eine Struktur fest, in dem Wissen abgegeben werden muss. Letztendlich fällt man wieder in alt bewährte Muster zurück und presst das chaotische Konstrukt „Wissen“ in einen Standard. In diesem Bereich sind ebenfalls wieder Werkzeuge zu beobachten, die wie Knowledge Bases oder Best Practice Archives oder im ganz besonders modernen Falle RunBook-Automation das Wissen um die Erfüllung einer bestimmten Aufgabe gut strukturieren.

Und auch wenn diese alten Muster einen guten Effekt und ihre Berechtigung haben, so reichen sie doch bei Weitem nicht aus, weil sie einen enormen Overhead auf das System Wissen aufsetzen und dieses System diesen Overhead auf Grund kurzer Lebenszyklen einzelner Vorgehensweisen oft nicht überbieten kann.

Die dritte Stufe der Automatisierung – also jene Stufe, in der sich die meisten Unternehmen mit ihrem Personal befinden – ist die Nutzung von Skripten und deren besonders gute Verwaltung. Ein Skript ist das IT Äquivalent eines Fließbandes. Es ist eine vorgefertigte Produktionsstraße, ein Programm oder gar eine Sammlung von Programmen, die aus standardisierten Eingaben immer und immer wieder dieselben Ausgaben (in der produzierenden Industrie die Produkte oder Produktvarianten) erzeugen kann. Dies ist ein sehr wichtiger Schritt in der Automatisierung. Vor allem aber ist es ein Schritt, der schon seit jeher von den IT Talen-

11 ten in allen IT Umgebungen angewendet wird.

In letzter Zeit sind lediglich gute Methoden hinzugekommen, die es erlauben, die Vielzahl von Skripten, die durch die hohe Anzahl verschiedener Aufgaben (kein produzierender Betrieb würde so viele Produktvarianten unterstützen wie ein IT Betrieb, schon allein weil es für so viele Varianten keine Distribution gäbe) entstanden sind, erfolgreich zu verwalten und für einen gewissen Grad an Konsistenz zu sorgen.

Die Werkzeuge, die diese Stufe der Automation unterstützen, fallen dann in die Kategorie Data Center Automation oder Process Automation.

Dieser Schritt ist wichtig und sinnvoll und wird wie gesagt schon lange in der IT angewendet, worüber auch neue Oberflächen nicht hinwegtäuschen können. Er ist aber noch eine unzureichende Antwort für den Umgang mit sich schnell veränderndem Wissen, da in den komplex verwalteten Skripten das Wissen gefangen ist.

Die vierte Stufe der Automatisierung ist die Übertragung der Kontrolle vom Menschen, der das Wissen nutzt und dessen Anwendung steuert, an die Maschine in klar definierten Nischen. Normalerweise sind dies Nischen, die aus irgendwelchen Gründen gar nicht mehr von einem Menschen gesteuert werden können. Zum Beispiel kann die Ansteuerung oder die Kontrolle von Clustern aus vielen Rechnern auf Grund der notwendigen Geschwindigkeit bei der Fällung von Entscheidungen und bei der großen Menge an auszuwertenden Daten für das Fällen dieser Entscheidungen gar nicht mehr von einem Menschen durchgeführt werden. In diesem Falle überträgt man das notwendige Wissen wohl strukturiert, aber nicht fest verdrahtet in eine Maschine, die dann autonom und in ihrer spezifischen Nische das mitgegebene Wissen nutzt, um Entscheidungen zu treffen und Wissen anzuwenden, um die erforderliche Aufgabe zu erfüllen. Auch diese Systeme finden sich in vielen Spezialanwendungen und Sonderautomatisierungen für einen definierten Bereich. Misstraut man dem „Expertensystem“ solcher Maschinen, lässt sich quasi als Vorstufe eine Nachfrage beim Benutzer einfüh-

UpDate! Ausgabe 14 · Dezember 2010

Fokus

12 ren. Das System trifft also eine Entscheidung, stellt diese beim Benutzer vor und lässt sich die Durchführung vom Benutzer genehmigen oder unterstützt den Benutzer bei der manuellen Ausführung (zum Beispiel, indem alle Kommandos vom Benutzer nur noch kopiert und wieder eingefügt werden müssen).

Die fünfte Stufe der Automatisierung ist die Anwendung der Autonomen Systeme nicht nur auf Nischen, sondern auf die gesamte IT Umgebung. Dabei wird das Wissen der heutigen Experten Stück für Stück und ohne Zusammenhänge an die Maschine übertragen. Die Maschine muss dann an Hand einer gestellten Aufgabe – ganz wie ein Mensch – die notwendigen Wissenspartikel aus dem großen Pool an möglichem Wissen extrahieren und nacheinander ausführen. Um die psychologische Barriere dieser Kontrollverschiebung abzuschwächen, bietet es sich in diesem Falle an, im ersten Schritt noch keine vollkommen autonome Ausführung vorzusehen, sondern eine Freigabe von den Benutzern anzufordern. Wenn das Vertrauen einmal geschaffen ist, kann diese Stufe abgeschafft werden und die aktive Maschine arbeitet auf der ihr übergebenen IT Umgebung wie ein autonomer Autopilot. Nach der ersten Stufe der Automatisierung ist dies die einzige Stufe von Automation, die mit den besonderen Gegebenheiten der IT auch besonders umgeht und nicht nur versucht, Altbekanntes auf die IT anzuwenden.

UpDate! Ausgabe 14 · Dezember 2010

Der Status Quo in der Automationspyramide Abschließend ist zu sagen, dass die meisten Organisationen sich momentan irgendwo zwischen Stufe 2 und 3 für den Großteil der Aufgaben befinden, die in ihrer IT abzuwickeln sind.

Nischen, die gar nicht mehr manuell bedient werden können, kommen auch schon für Stufe 4 Lösungen in Frage. Der konstante Druck auf Kosten und Qualität macht aber eine Weiterentwicklung unbedingt notwendig. Führt man sich die Kette der Automationsstufen vor Auge, so kann man den logischen Aufbau betrachten und eventuell rein psychologisch begründete Ressentiments überwinden. Die Maschine kann den selben Vorsichtsmaßnahmen folgen, die wir heute auch Menschen vorgeben, und ist der einzige Weg, für immer dynamischere Umgebungen den schnellen Betrieb zu gewährleisten. Viel mehr aber noch ist diese Maschine für die IT Talente der einzige Weg, wie sie die Zeit frei bekommen, um all die Anforderungen und Verbesserungen umzusetzen, die man von Ihnen erwartet und dabei gleichzeitig noch den Beitrag der IT zum Geschäftserfolg zu gewährleisten. Die Talente werden beim Einsatz einer Stufe 5 Maschine – eines Autopiloten – endlich wieder dafür frei, wofür sie am besten qualifiziert sind (und was ihnen auch am meisten Spaß macht): für die Erzeugung neuen Wissens und neuer Ideen.

Development

13

MAID – Monitoring Automation Interface Description

Monitoring

Der erste Schritt ist die Bereitstellung des IT Modells. Da für den Autopiloten ein sehr einfaches Modell benutzt wird, lässt sich dieses Modell aus vorhandenen Daten durch einfache Transformation erzeugen. Entweder es bestehen direkte Schnittstellen zu den Systemen, in denen die Daten heute gehalten werden, oder eine Transformation auf XML Basis lässt sich in kurzer Zeit etablieren. Selbst wenn das Modell neu von Hand geschrieben werden muss, stehen die notwendigen Werkzeuge und Qualitätssicherungsprozesse zur Verfügung.

Auch die Monitoringdaten sind grundsätzlich verfügbar, denn keine Organisation, die den Autopiloten einführen will, benutzt nur Menschen als Monitoringsystem. Die Herausforderung liegt darin Modell und Monitoring zusammenzuführen. Diese Herausforderung ist vielen IT Verantwortlichen bekannt, da sie die gleiche Übung durchführen, wenn sie Dashboards erzeugen CMDB/ wollen, und viele haben dies beModel reits getan. Bei der Integration

von Monitoringdaten mit Modelldaten geht es darum zu definieren, welche Monitoringdaten welche Teile der IT beschreiben, festzulegen in welcher Form, Frequenz und in welchen Aggregationen diese Daten dann vorliegen sollen und letztendlich zu etablieren, wann diese Daten einen Anlass zum Handeln geben.

Da die arago Autopilot Engine (aAE) mit vielen Monitoringsystemen – in vielen Umgebungen sogar mit mehreren gleichzeitig – arbeiten muss, ist eine flexible Integration und Zusammenführung dieser Daten auf dem IT Modell eine wichtige Aufgabe, die nicht individuell gelöst werden darf. Aus diesem Grund wurde ein standardisiertes Interface zwischen Monitoringsystemen und der arago Autopilot Engine etabliert.

Diese MAID – Monitoring Automation Interface Description – führt zu einer einheitlichen Interpretation von Monitoringdaten im Autopiloten und zu einer guten Darstellbarkeit des Monitorings auch ohne die Automation. Die MAID beinhaltet folgende Punkte: 1. Name und Beschreibung des Monitorings Zunächst wird einem Monitor, also einem standardisierten Eintrittspunkt von Daten in das System, ein Name gegeben und eine

aAE Stream

M-ARS Model

MAID Monitoring to Automation Interface Description

Die Herausforderung bei der Automatisierung ist es nicht nur das passende MindSet bei den Technikern zu schaffen, die anfänglich immer noch Skripte ­schreiben wollen anstatt Wisssensbausteine abzugeben, sondern insbesondere die Voraussetzungen für die Automatisierung von Seiten der Datenversorgung zu schaffen. Die notwendigen Daten – IT Modell und Monitoring – sind fast immer vorhanden, müssen aber extrahiert und vor allem integriert werden. Im Folgenden wird die arago Methode der Integration von Monitoring und Modelldaten beschrieben.

Hans-Christian Boos

Monitoring Data Attached to Model Nodes

UpDate! Ausgabe 14 · Dezember 2010

Development

14 Beschreibung – eine Art kurze Dokumentation – hinzugefügt.

2. Quelle des Monitorings Die Quelle des Monitorings wird identifiziert, also wo aus technischer Sicht das Monitoring ausgeführt wird. Das ist insbesondere dann sinnvoll, wenn man zum Beispiel eine Anwendung von einer anderen Stelle des Netzwerks überwacht.

3. Ziel des Monitorings 4. Art des Monitorings

5. Aggregation des Moniorings 6. Handlungsbedarf, der aus dem Monitoring abgeleitet werden kann.

Mit diesen Informationen lassen sch die Daten verschiedener Monitoringsysteme anbinden und dem Modell zuordnen. Gleichzeitig werden diese Daten normalisiert, so dass sie vergleichbar werden und die daraus abzuleitenden Aktionen eindeutige Startpunkte für die Automation mit dem arago Autopiloten ergeben.

Erfahrungen aus der Automatisierungseinführung

Markus Leven

Der aktuelle Stand Die Einführung der Automatisierung im Hause arago ist heute sehr weit fortgeschritten: Ende dieses Jahres wird das Einführungsprojekt erfolgreich abgeschlossen sein. Aber wieso eigentlich Einführung? Tatsächlich ist die Automatisierung bei arago schon lange Stateof-the-Art und im Einsatz. Um die reichhaltigen Erfahrungen jedoch wiederverwendbar zu machen und damit die Nutzung unserer hoch entwickelten Automatisierungstechnologien auch außerhalb des Hauses arago zu ermöglichen, waren bisher sehr zeitintensive kundenindividuelle Projekte notwendig. Jetzt wird der arago Systembetrieb zum Vorreiter eines Einführungsprojektes mit einer standardisierten Vorgehensweise, so dass umfassende Einführungszeiten und -aufwände spürbar verringert werden können.

Das Projekt Im Laufe des Sommers 2010 entwickelte ein kleines Projekt innerhalb von arago ein ungeahntes Eigenleben. Kollegen aus der Produktent-

UpDate! Ausgabe 14 · Dezember 2010

wicklung und Kollegen aus dem Systembetrieb steckten in einem Büro die Köpfe zusammen und bastelten hinter verschlossenen Türen an geheimen, konspirativen Dingen. Die Beteiligten erzählten voller Stolz von ihrer Mitwirkung am Projekt Automatisierung und trugen ihre Projektshirts wie eine Uniform. Alle anderen konnten sich nur sehr wenig darunter vorstellen. Von Seiten der Geschäftsführung war eine ausgewählte Spezialistentruppe einberufen worden: Produktentwickler, die sich bisher mit der Weiterentwicklung von W ­ atchMe, WisdoMe und der Automatisierungsengine beschäftigt sowie Systemadministratoren, die bisher mit diesen Werkzeugen gearbeitet hatten. Gemeinsame Aufgabe dieser Mannschaft sollte es sein, einen Prozess und die dafür notwendigen Werkzeuge zu definieren, um das Wissen der Admins in den Wissenspool des a ­ rago Autopiloten zu transferieren. Erstes Ergebnis dieser Projektarbeit war ein definierter, darstellbarer und wiederverwendbarer Prozess, der zu diesem Zeitpunkt den anderen Systemadministratoren erstmalig vorgestellt wurde. Ziel war es, alle Administratoren diesen Prozess für die ihnen bekannten Systeme durchlaufen zu lassen und

Development somit einerseits die Adminis­tratoren im Umgang mit dem Prozess und den darin eingesetzten Werkzeugen zu schulen und andererseits das umfangreiche Fachwissen der Mitarbeiter in den Wissenspool aufzunehmen. Allerdings stellte sich heraus, dass diese praktische Umsetzung des definierten Prozesses so nicht funktionierte. Dies ließ sich auf drei zentrale Probleme zurückführen: Es war nicht gelungen, den Kollegen die Bedeutung ihrer Mitarbeit zu vermitteln. Aus diesem Grund wurden Projektaufgaben zugunsten des Tagesgeschäftes immer wieder zurückgestellt. Die Kollegen arbeiteten einzeln an ihren Aufgaben, eine zentrale Unterstützung und organisiertes Feedback gab es zu dieser Zeit nicht. Das dritte Problem bestand darin, dass Verbesserungs-, Erweiterungs- und Veränderungsvorschläge teilweise direkt umgesetzt wurden, um die Methodik und die Werkzeuge zu optimieren. Hierdurch mussten allerdings bereits begonnene Arbeitsschritte erneut ausgeführt oder plötzlich ganz anders erledigt werden als bisher – der angestrebte Arbeitsablauf wurde unterbrochen.

Hieraus ergab sich für die Projektleitung, die zu diesem Zeitpunkt noch identisch mit der Geschäftsführung war, die Notwendigkeit, die Struktur des Projektes zu verändern. Es stellte sich als wichtig heraus, allen Mitarbeiter klar zu machen, dass das Thema Automatisierung im Hause arago zukunftsweisend für den Systembetrieb sowohl innerhalb als auch außerhalb der Firma ist. Gleichzeitig wurde der Bereichsleiter „Projekte“ mit ins Boot geholt, der eine formale Projektstruktur mit konkreter Aufgabenverteilung, einem Terminplan und einem Projektcontrolling aufsetzte. Damit konnten jetzt alle Mitarbeiter gezielt an konkreten Aufgaben arbeiten, eine deutlich bessere Termintreue und Planbarkeit war erreicht.

Dies führte wiederum zu zwei weiteren notwendigen Schritten: Zum einen wurde eine Schulung konzipiert, die jedem arago-Mitarbeiter das Gesamtkonzept der Automatisierungsidee und die gesamtheitliche Funktionsweise

15 der entwickelten Technik vorstellte. Dadurch wurde ihnen die Bedeutung ihres persönlichen Beitrages vermittelt, worauf Termintreue und Qualität deutlich anstiegen. Zum anderen wurde klar, dass es nicht funktioniert, die Mitarbeiter an einem sich ständig verändernden Prozess arbeiten zu lassen. Der Prozess wurde daher „eingefroren“ und Verbesserungsvorschläge gesammelt. Nach einem ersten Durchlauf wurden diese umgesetzt und so die Qualität erneut gesteigert.

Fazit Inzwischen ist der erste große Projektschritt der Automatisierungseinführung im arago Betrieb abgeschlossen. Es sind alle von uns betriebenen Systeme im Modell hinterlegt und alle Standardchecks des Monitorings implementiert. Sowohl für unsere weiteren Projektschritte als auch für Einführungsprojekte bei unseren Kunden haben wir Entscheidendes gelernt: Wir müssen die Administratoren, deren Arbeitsumfeld sich durch die Automatisierungseinführung maßgeblich ändern wird, von Beginn an mit ins Boot holen. Ein Projekt kann nur zu einem Erfolg werden, wenn alle Beteiligten das Ziel verstanden haben und die Bedeutung ihres persönlichen Beitrages dazu erkennen.

Bei Projekten „auf der grünen Wiese“ ist es unrealistisch, eine perfekte Lösung aus dem Boden stampfen zu wollen. Ebenso unrealistisch ist es, im laufenden Projekt die Prozesse ständig anpassen zu wollen. Wir müssen uns dazu durchringen, mit einem gut durchdachten Lösungsansatz zu starten und dann aus dem im Prozess Erlernten mit und für den Kunden aus der sehr guten eine perfekte Lösung zu machen.

Nachdem wir diese Dinge berücksichtigt haben und immer wieder auch in den täglichen Projektverlauf einbringen, haben wir inzwischen eine Vorgehensweise definiert, die bei uns erfolgreich eingesetzt wird und jederzeit auf unsere Kunden transferierbar ist.

UpDate! Ausgabe 14 · Dezember 2010

Development

16 Markus Leven

Wie motiviert man Geeks?

Wenn man aktuelle Zeitungsmeldungen nicht nur aus Deutschland, sondern vor allem auch von Softwarefirmen aus Übersee verfolgt, dann liest man eine Menge Dinge, die getan werden, um Entwickler zu motivieren und zu höheren Leistungen zu bewegen. Ein auf den ersten Blick ganz anderes Bild bekommt man beim Lesen der einheimischen Fachliteratur und eine dritte Sicht auf die Dinge durch Gespräche mit den eigenen Mitarbeitern. Die Frage, die überall dahintersteht, ist eine ganz einfache: Was müssen wir tun, damit unsere Kollegen mit noch mehr Eigeninitiative und kreativen Ideen auf die Suche nach guten Lösungen gehen, so dass wir für unsere Kunden noch mehr zur Ideenschmiede werden und nicht zur Umsetzungsbude verkümmern? Die Reaktionen von Kollegen auf diese Fragen reichen von scherzhaften Antworten – die erstaunlicherweise in großer Anzahl kommen – bis zu durchaus ernstgemeinten Ansätzen. Alle Antworten haben mit den theoretischen Ansätzen der Wissenschaft und den praktischen Ansätzen von US-amerikanischen und australischen Unternehmen zwei grundlegende Dinge gemeinsam: Es kommen zwei Faktoren nicht vor, die man vielleicht ganz vorne in der Liste der Motivatoren erwarten würde – Geld und Spaß an der Arbeit. Warum kommen diese Dinge nicht vor, was spricht gegen sie? Fangen wir mit dem Geld an: Dieser

UpDate! Ausgabe 14 · Dezember 2010

Punkt ist schnell abgehandelt, da hier große Übereinstimmung herrscht. Die eigenen Mitarbeiter haben selbst dann, wenn sie keine konkreten Motivatoren nennen konnten, gesagt, es dürfe „nichts Monetäres“ sein. Studien des MIT, der University of Chicago und der Carnegie Mellon University belegen, dass bei Aufgaben, die über reines Ausführen hinaus auch Kreativität beinhalten, Geld kontraproduktiv ist und die Leistung sinken lässt. (Voraussetzung ist natürlich eine Grundbezahlung, die die normalen Lebensumstände sicherstellt) Der Spaß an der Arbeit ist etwas differenzierter zu sehen: Der Schweizer Professor Fredmund Malik behandelt dieses Thema aus Managementsicht. Im von ihm gegründeten St. Galler Management Zentrum wird gelehrt, dass Spaß an der Arbeit selbstverständlich erstrebenswert und nichts Schlechtes ist. Wichtig ist aber, dass der Spaß weder Selbstzweck der Arbeit noch ein Anspruch ist, den man an seine Arbeit stellen kann. Gute Beispiele hierfür sind Rettungskräfte oder Totengräber. Selbst beim besten Willen kann man sich nicht vorstellen, bei dieser Arbeit Spaß oder Freude zu empfinden. Malik geht hier noch weiter: „Man muss froh sein, wenn die Arbeit im Großen und Ganzen und während des größeren Teils der Zeit interessant ist und ein gewisses Maß an Befriedigung verschafft.“ (Malik, S. 91). Eine solche Aussage bedeutet, wenn man sie alleine im Raum stehen lässt, sicherlich das Ende jeder Debatte über Motivation und den Ansporn zu guter Arbeit. Trotzdem denke ich, dass sie richtig ist. Die Ansätze von Malik weiterzuverfolgen bringt uns zur Ergebnis- oder Zielorientierung: Wichtig ist nicht die Freude an der Arbeit sondern die Freude am Ergebnis.

Es macht keinen Spaß eine Toilette zu putzen und es macht wohl auch keinen Spaß einen Menschen aufzuschneiden. Aber es bereitet Freude, das sauberste Toilettenhäuschen

Development der Stadt zu betreiben oder als Chirurg einem weiteren Menschen geholfen zu haben. Motivierend ist also weniger der ständige Spaß an der aktuellen Handlung als vielmehr der Spaß am erreichten Ziel. Um daran Spaß und Freude empfinden zu können ist es aber zwingend notwendig dieses Gesamtziel zu kennen. Hier schließt sich der Kreis zu den aktuellen amerikanischen und australischen Ansätzen. Es werden drei Faktoren als wichtig für die Motivation benannt: Zielorientierung, Kompetenz und Eigenständigkeit. Die Zielorientierung stimmt uneingeschränkt mit dem überein, was unsere eigenen Mitarbeiter sagen, was uns unsere Erfahrung lehrt und was die europäische Managementtheorie sagt: Um Mitarbeiter zur guten, eigenständigen und kreativen Arbeit zu motivieren ist es notwendig, dass ihnen das Gesamtziel und ihr Beitrag dazu bekannt sind.

Als weiterer Punkt, der eng damit einhergeht, ist die Kompetenz zu nennen. Der englische Begriff Mastery lässt sich an dieser Stelle leider nicht besser übersetzen. Aber so, wie Leute in ihrer Freizeit Sport machen oder ein Instrument spielen, engagieren sie sich auch fachlich.

Gerade in unserer Branche sehen wir an vielen Open Source Projekten, dass die Menschen sich engagieren, weil ihre Mastery, ihr Fachwissen und ihre Kompetenz gefragt und geschätzt sind – weil sie als Meister ihres Fachs anerkannt werden. Dieses ist also ein wesentlicher Motivationsfaktor, den wir auch in unseren Projekten berücksichtigen sollten. Es ist sinnvoll, die Mitarbeiter so einzusetzen, dass sie sich mit ihren Fähigkeiten beweisen können; dies führt zum einen zu einer höheren Zufriedenheit der Mitarbeiter und zum anderen zu einer ständigen Bereitschaft, sich in diesen Bereichen immer mehr und weiter zu verbessern. Der dritte Punkt Selbständigkeit wurde am deutlichsten durch Google geprägt: Hier können die Mitarbeiter 20 % ihrer Arbeitszeit ohne Vorgaben an eigenen Projekten und Ideen arbeiten. Das ist in einem kundenorientieren Projektgeschäft nur bedingt realisierbar. Sinnvoll ist es daher, diesen Begriff nicht so weit zu fassen: Die Resultate können und müssen vorgegeben sein

17 (z. B. ein zu einem bestimmten Zeitpunkt fertiges Projekt). Auf dem Weg dahin können mehr Freiheiten dazu führen, dass Probleme kreativer gelöst werden. Es hat sich auch bei uns in der Vergangenheit immer wieder gezeigt, dass Probleme schneller gelöst werden und neue Ideen fruchtbarer sind, wenn man sowohl fachlich als auch personell über den Tellerrand schaut. Eine australische Firma hat die Ideen von Google mit den sogenannten FedEx-Days weiterentwickelt.

Die Softwarefirma Atlassian hat diese Tage eingeführt. Einmal monatlich dürfen alle Firmenangehörigen 24 Stunden lang machen, was sie wollen. Jeder Mitarbeiter darf arbeiten, woran er will und mit wem er will. Der Begriff FedExDays kommt von der einzigen Bedingung, die an die Mitarbeiter gestellt wird: Nach 24 Stunden muss etwas abgeliefert werden. Die Erfahrungen mit dieser Methode zeigen, dass sich Mitarbeiter mit zwei Sachen beschäftigen: Zum einen werden Verbesserungen für konkrete Projekte und Aufgaben gesucht, zum anderen werden Ideen für neue Projekte geboren. Diese Kombination ist etwas, das auch unserem Projektgeschäft sehr zuträglich sein könnte.

Die eierlegende Wollmichsau ist auch in diesem Bereich noch nicht erfunden worden und eine Firma unserer Größe kann nicht auf jeden Zug aus Silicon-Valley aufspringen. Zusammenfassend sehen wir, dass drei unterschiedliche Blickwinkel (Mitarbeiter, konservatives St. Galler Management, High-Tech-Vorreiter) zwar in dem, was sie benennen, nicht aber im Inhalt auseinander liegen. Wir werden uns mit diesem Thema weiter beschäftigen und solche Ansätze nicht nur im täglichen Umgang mit unseren Kollegen berücksichtigen, sondern auch eine firmenweite Gesamtstrategie finden.

Quellen • •

Malik, Fredmund: Führen, Leisten, Leben, Frankfurt am Main 2006 Royal Society for the encouragement of Arts, Manufactures and Commerce (RSA) – comment.rsablogs.org.uk/videos

UpDate! Ausgabe 14 · Dezember 2010

Inside arago

18

Neu bei arago Abteilung Vertrieb Alexander Kouril Seit 1. November 2010 ist Alexander Kouril an Bord der arago AG und unterstützt im Vertrieb und Business Development arago als Senior Vertriebsmanager bei der Positionierung neuer Software-Produkte tatkräftig.

Alexander Kouril verfügt über 17 Jahre Vertriebserfahrung in der ITBranche und hat sich spezialisiert auf den Lösungsvertrieb komplexer Beratungs- und Softwareleistungen an Industrie- und an Verwaltungskunden. Zu seinen Stationen zählten EMC, SAP und BearingPoint. Weitere Schwerpunkte seiner bisherigen vertrieblichen Tätigkeiten waren das Partner Management mit globalen Systemintegratoren und das Business Development für die Positionierung neuer innovativer SoftwareLösungen und Beratungsleistungen bei Kunden.

Herr Kouril hat an der TU Berlin Luft- und Raumfahrttechnik und an der TSM Business School in Enschede Management studiert. Privat ist er ein leidenschaftlicher Läufer und reist gerne.

UpDate! Ausgabe 14 · Dezember 2010

Abteilung Projekt­entwicklung Oliver Eikemeier Hat an der TU Berlin Mathematik und der TU Darmstadt Informatik studiert und arbeitet seit dem 18. 10. 2010 im Bereich Projekte als Projektleiter.

Er hat langjährige Erfahrungen in Kryptographie und Softwarearchitektur und hat sich in letzter Zeit besonders mit dem Thema mobile Clients beschäftigt.

Uwe Romak Seit 6.

9. 2010 ergänzt er das DocMe Support Team im Bereich Projekte. Er hat an der Fachhochschule Frankfurt am Main Elektrotechnik / Technische Informatik studiert und dort seinen Abschluss als Dipl-Ing. (FH) gemacht. In den letzten 15 Jahren hat er bereits erste Berufserfahrung bei Dell gesammelt.

Gelegentlich nimmt er sich die Zeit für einen schönen Waldlauf.

Alexander Follert Seit 18. 10. 2010 ist er bei uns studentischer Mitarbeiter im Bereich Projekte. Nach seinem Studienabschluss als Diplom-Wirtschaftsinformatiker an der Berufsakademie Mannheim, studiert er aktuell an der Goethe-Universität Informatik und Politikwissenschaft für das Lehramt an Gymnasien. In seiner Freizeit singt er im Cäcilienchor Frankfurt, einem der ältesten und traditionsreichsten Oratorienchöre Deutschlands.

Inside arago Abteilung Produkt­entwicklung Stefan Pitz Er ist vor wenigen Tagen als Entwickler im Bereich Produktentwicklung zu uns gestoßen. Er machte dieses Jahr an der FH Gießen-Friedberg seinen Abschluss als Diplom-Informatiker (FH). Während des Studiums sammelte er viele Jahre Erfahrung als Freelancer. Seine große Leidenschaft ist die Entwicklung eines eigenen Web-Desktops. Zu seinen Hobbys zählen Sport und ausgiebiges BBQ.

Daniel Musa Nyuyki Als Student unterstützt er unsere Produktentwicklung seit dem 15. Mai 2010. Dabei beschäftigt er sich mit der Entwicklung von Werkzeugen zur Vereinfachung der Arbeit mit Automationsbausteinen und IT Modellen. Nach seinem Abschluss als Bachelor of Science in Heidelberg studiert Daniel nun Wirtschaftsinformatik an der TU Darmstadt. Neben der IT liegen seine Interessen in den Bereichen Wirtschaft, Geschichte und Fußball.

19 Simon Kanwischer Als Student unterstützt er uns seit 27. 7. 2010 bei der Dokumentation und Oberflächenkonzeption im Bereich Produktentwicklung. Nach seinem Studium an der Universität Osnabrück (Information Systems) studiert er derzeit an der FG GießenFriedberg Wirtschaftsinformatik.

Annie Chancelle Ymga Ndjanteu Seit 27. 7. 2010 absolviert sie bei uns ihr berufspraktisches Semester im Bereich Produktentwicklung.

Geboren in Kamerun, studiert sie an der FH Gießen-Friedberg Medizinische Informatik.

Abteilung System­betrieb Tim Königstein Seit 1. 10. 2010 kümmert er sich bei uns als IT-Experte im Bereich Systembetrieb um die Applikationen unserer Kunden. Sein Studium der Allgemeinen Informatik an der Hochschule Rhein-Main hat er in diesem Jahr als Bachelor of Science (B. Sc.) abgeschlossen. In seiner Freizeit fotografiert er gerne, besucht Konzerte oder bereist die Welt.

UpDate! Ausgabe 14 · Dezember 2010

Inside arago

20

Roland Judas

Andreas Wrobel

Organisation Gabriele Zoll

Seit 1. 8. 2010 unterstützt er unseren Systembetrieb als Praktikant.

Er besucht die Werner-von-SiemensSchule mit dem Schwerpunkt Informationstechnik und absolviert bei uns ein einjähriges Praktikum, welches für Fachoberschüler vorgesehen ist. In seiner Freizeit beschäftigt er sich gerne mit Computern.

Seit 20. 9. 2010 vertritt Frau Zoll uns täglich zu später Stunde in Teilzeit am Empfang. 30 Jahre Hektik als Anwalts- und Notariatsangestellte in großen Kanzleien waren ihr genug. Jetzt will sie es beruflich etwas langsamer angehen lassen und hat dafür mehr Zeit für ihre Familie samt Hund, Ehrenämter und die Eintracht Frankfurt.

IBM Tivoli Technical Conference Vom 4. bis zum 8. Oktober 2010 fand in Dresden die IBM Tivoli Technical Conference Europe statt. Gelegenheit für die rund 400 aus ganz Europa angereisten Experten, auf hohem Niveau im anregenden Ambiente des Dresdner Kongresszentrums mit den Kollegen den technischen Austausch zu pflegen und die Zukunft zu diskutieren.

Fast alle anwesenden Experten kennen das Problem: Von ihnen wird höhere Effizienz bei geringerem Budgeteinsatz erwartet mit der Zielsetzung, die Kosten zu senken, die Innova-

UpDate! Ausgabe 14 · Dezember 2010

tionskraft zu stärken und damit Wettbewerbsvorteile durch die Nutzung von IT Lösungen zu ermöglichen. Da traf es sich gut, dass arago Vorstand Hans-Christian Boos mit dem arago Autopiloten ein zukunftsweisendes Konzept vorstellen konnte. In seinem Vortrag zeigte Boos, wie diese Ziele mit dem Einsatz des arago Autopiloten erreicht werden können. Er übernimmt dynamisch Aufgaben eines Experten, nachdem das entsprechende Betriebswissen an ihn übertragen wurde. Der Autopilot stellt dabei, analog zum menschlichen Experten, je nach Aufgabe aus dem ihm verfügbaren Wissen einen Ablauf zusammen, der flexibel an die jeweiligen Bedürfnisse angepasst wird.

In seinem Vortrag zeigte Boos nicht nur die Effekte und Möglichkeiten des Autopiloten sowie die Differenzierung zu herkömmlichen Automationslösungen auf, sondern insbesondere auch die Einbindung des Autopiloten in eine mit IBM Tivoli überwachte und gemanagte Umgebung. Da der Autopilot wie seine menschlichen Kollegen auch Informationen benötigt und ein gutes und vor allem integriertes Werkzeugpaket ansteuern will, kann eine IBM Tivoli Umgebung als Beispiel für eine optimale Umgebung gelten.

Inside arago

21

15 Jahre arago AG – ein Sommertraum

Hans Lange

Die arago AG kann in diesem Jahr auf 15 Jahre Firmengeschichte zurückblicken.

Anlass genug, um in Kooperation mit den Deutsche Bank Skyliners für Mitarbeiter, Kunden, Partner und Freunde sowie deren Familienangehörige eine rauschende Geburtstagsparty im Hattersheimer Club Longbeach zu organisieren.

Auf dem Programm standen u. a. eine WiiOlympiade und ein Basketball-Freiwurfwettbewerb, bei denen es tolle Preise zu gewinnen gab. An der Hebung des ästhetischen Empfindens der Gäste hatten die Cheerleader der Deutschen Bank Skyliners mit ihren abwechslungsreichen Choreographien und akrobatischen Breakdance-Darbietungen erheblichen Anteil. Dem leiblichen Wohl diente ein original texanisches Barbecue. Wer nicht gerade auf einer der bereit gestellten Sonnenliegen relaxte, konnte der Live-Musik mit Axel lauschen.

15 Jahre arago AG Chronologie der Ereignisse Das Gründungsjahr

1995

Die A-Klasse kippt, das Geld der Zukunft heißt Euro, die Vergangenheit lebt: Plateauschuhe kommen wieder in Mode.

Es wird und wird und wird

1997

Lady Diana – Königin so manchen Herzens – kommt bei einem Unfall ums Leben. Und auch das eine oder andere Tamagotchi macht‘s nicht lang. Die Titanic sinkt noch einmal und spült viel Geld in die Kinokassen. Gerade mal rund 6 Millionen Computer weltweit sind im Internet verbunden.

Microsoft ist dick im Geschäft. Doch Gründer Bill Gates erwähnt in seinem Buch The Road Ahead das Internet mit keinem Wort. Dann schwenkt er um und bringt die erste Version des Microsoft Internet Explorer heraus. Im gleichen Jahr geht der Vatikan online (www.vatican.va). eBay wird gegründet.

Nachdem das DIT-System online gegangen war, stellt sich die Frage nach dem Systembetrieb. Da die Dresdner Bank nicht darauf vorbereitet ist, einen auf UNIX basierenden Systembetrieb für die von arago entwickelte Plattform zu gewährleisten, erweitert die arago quasi notgedrungen auf diese Weise ihr Spektrum vom Spezial-Entwickler hin zum IT-Betriebsdienstleister.

Hans Christian Boos, zu der Zeit Informatikstudent an der ETH Zürich, ist dagegen sofort überzeugt vom Nutzen und der Bedeutung des Internet. Für sich und die ganze Welt.

Der frühere Jugend forscht-Sieger erledigt seine ersten Aufträge. Er steht nicht allein damit: Die erfahrenen Manager Dr. Bernhard Walter und Martin Friedrich unterstützen ihn.

Gemeinsam gründen sie Ende des Jahres eine GmbH.

In der Folgezeit wird der WebFarm-Standard für die Internetsysteme der Dresdner Bank Gruppe etabliert. Bis 2001 werden nach und nach alle Webanwendungen der Dresdner Bank von der arago betreut. Ende des Jahres sind drei Mitarbeiter von arago ständig vor Ort, Monat für Monat werden bis zu ein Dutzend Server neu angeliefert. Doch auf Servern zu sitzen ist offenbar nicht bequem genug. Das Personal beginnt zu murren und kündigt eine „Meuterei“ an. Der nächste Umzug ist kaum noch abzuwenden.

Das Kind braucht einen Namen. Nicht ganz zufällig, eher im Rahmen ihrer ständigen Weiterbildung, stoßen die Gründer auf den Namensgeber Arago. Das passt vorzüglich: Der Mann kannte sich mit Lichtwellen aus, war Physiker und steht ziemlich weit vorne im Alphabet.

Wer aber ist eigentlich dieser Arago? Der 1786 geborene französische Physiker, Astronom und Politiker Dominique François Jean Arago war ein leidenschaftlicher Naturwissenschaftler und Vordenker seiner Zeit. Seine Forschungen zum Phänomen der Lichtwellenverbreitung im Raum legen den Grundstein für die heutige moderne Kommunikation.

Sein Name ist im Eiffelturm verewigt.

Die kleine Firma hat ihren Sitz in Darmstadt, Nußbaumallee 25. Das ist die Studentenbude von „Chris“ Boos. Da ist kaum Platz. In Ermangelung geeigneter Räumlichkeiten tagen die Gründer deshalb vorzugsweise in Frankfurt, im Lahmen Esel, einer gar nicht übel beleumdeten Apfelweinschänke, keine zwei U-Bahnstationen vom heutigen Standort der arago AG am Weißen Stein entfernt. Der Name dieser Tagungsstätte ist übrigens nicht Programm.

Erste Projekte und erste Mitarbeiter Ganz im Gegenteil. Mit Gründung der Firma steigen die Aufträge, die Mitarbeiterzahlen, die Verantwortung. Doch langsam: Der Chef und zwei Mitarbeiter teilen sich in der Frankfurter Hahnstraße Nummer 70 zwei Büroräume als Untermieter von Omnilink, einem Internet-Provider (1996– 1998), der ihnen eine direkte Anbindung an das WorldWideWeb bietet. Weitere Mitarbeiter kommen hinzu.

Für Stühle ist einfach kein Platz, doch auch auf Servern lässt sich‘s sitzen.

Der Krieg der Webbrowser Netscape und MS Internet Explorer führt zu immer kürzeren Entwicklungszeiten, Betaversionen, auch „Bananen“ genannt, reifen beim Benutzer.

Noch immer aber wird die Rolle des Internet in der Zukunft weitgehend unterschätzt und misstrauisch beäugt. Wer sich damit befasst, ist a) ein Spinner, b) ein absoluter Spezialist.

Wer so einen braucht, zahlt gut. Noch existiert quasi nichts von dem, was heute selbstverständlich ist. HCB geht genau diesen Weg: Student, Entwickler, Freelancer.

Wie es sich gehört, sind die Mitarbeiter der ersten Stunde Studienkollegen von HCB, Enthusiasten wie er selbst, die, wenn es sein muss, Tag und Nacht arbeiten. Auch Quereinsteiger sind nicht selten, der Hype aufs Internet, der bald einsetzt und auch die Internet-Blase beflügelt, lässt ein gut bezahltes Training-on-the-Job ohne weiteres zu.

1996

Man etabliert sich und wächst und zieht um

1998

Die Ära Kohl ist zu Ende. Gerhard Schröder heißt der neue Kanzler. ICANN wird gegründet, die Musiktauschbörse Napster, ein echtes Internet-Gewächs, bringt das Musikgeschäft durcheinander. Der Internet-Hype ist auf Touren.

Google geht online.

Frankfurt am Main, Fichtestraße, Jugendstil, Erdgeschoss.

Die Meuterei konnte abgewendet werden. Dennoch wird man nicht lange hier bleiben und schon im Herbst des kommenden Jahres wieder umziehen müssen. Bereits beim Einzug in die ca. 130 qm Wohnung ist es eng, aber noch hat jeder Mitarbeiter seinen Schreibtisch. Man baut die erste eigene Homepage und erwirtschaftet die erste Umsatzmillion. Der Laden brummt. Die Haus-Nachbarn meckern wegen der lauten Klimaanlage, die auch nachts die Server kühlen muss. Beim Auszug 1999 sitzen drei Mitarbeiter an einem Schreibtisch und man schüttet sich gegenseitig den Kaffee in die Tastatur.

Trotz der guten Geschäftsaussichten pflegt die arago eine eher konservative Firmenpolitik. Dass die Räumlichkeiten sich so schnell als zu klein erweisen, ist dieser vorsichtigen Planung geschuldet, in der rasantes Wachstum nicht als Basis der Entwicklung gesehen wird. So trifft der Wachstumsschub 1998/99 die Firma einigermaßen unerwartet. Von weniger als 20 Mitarbeitern wächst arago auf über 40.

arago entwickelt für den Deutschen Investment Trust, die Fondsgesellschaft der Dresdner Bank, eine Transaktionsplattform und damit das erste Fonds-Online-Banking in Deutschland.

Außerdem entwickelt arago 1996 DocMe 1.0, ein ContentManagement-System der ersten Stunde für Internetportale.

1 Infotafeln 15 Jahre arago 30.08.2010.indd 1

02.09.2010 11:22:36

Unter den etwa 200 Gästen begrüßte der Aufsichtsratsvorsitzende der arago AG, Dr. Bernhard Walther (im Foto li.), auch den Frankfurter Stadtrat Volker Stein (im Foto re.), Dezernent für Ordnung, Sicherheit und Brandschutz. Dieser fand nicht nur für die gelungene Geburtstagsparty lobende Worte, sondern auch für das Engagement der arago AG und ihrer Tochtergesellschaft, der arago Consulting GmbH, für die Region. Besonders anerkennend äußerte er sich naturgemäß über die Tatsache, dass arago nicht wie so viele Firmen in das gewerbesteuergünstigere Umland abgewandert, sondern in Frankfurt geblieben ist.

Da ein Jubiläum ohne Rückblick irgendwie unvollständig ist, übernahmen es dafür bestens geeignete Mitarbeiter und die Drucktochter arago Consulting GmbH, „historische“ Infotafeln redaktionell zu erarbeiten, zu gestalten und zu layouten. Auf ihnen wird die Firmengeschichte der arago AG im Kontext der Geschehnisse und Entwicklungen in Deutschland und der Welt sowie in der Welt der Computer und Netze erzählt und mit passenden Bildern und Grafiken illustriert.

Und so konnten alle Festbesucher amüsiert auf drei großen Stellwänden einen Eindruck von der rasanten und bisweilen sprunghaften Entwicklung der arago AG seit 1995 gewinnen.

UpDate! Ausgabe 14 · Dezember 2010

Inside arago

22 Roland Judas

Der arago Autopilot auf Tour Der Sommer und Herbst waren dieses Jahr geprägt von einer Reihe von Veranstaltungen, bei denen arago-Gründer und -Kopf Chris Boos den Autopilot für den IT-Betrieb präsentierte und dessen Potenzial im Rahmen einiger Veranstaltungen darstellte.

Besonders im Kontext des in aller Munde liegenden Cloud Computings ist der Autopilot nicht nur eine zusätzliche Option, um Kosten zu senken, sondern ein automatisierter IT-Betrieb ist vielmehr die Grundvoraussetzung, um entsprechende Potenziale überhaupt heben zu können: Er hilft, die gestiegenen personellen Aufwände, welche dynamische Infrastrukturen und Cloud Computing mit sich bringen, aufzufangen und vorhandenes Wissen effizienter anzuwenden.

Nachfolgend wollen wir Ihnen einen kurzen Überblick der Veranstaltungen geben, bei denen der Autopilot zu Gast war:

EMC Ionix Partnertag, Köln Der EMC Ionix Partnertag am 13. September stand ganz im Zeichen von IT Service Management Werkzeugen der nächsten Generation.

Hier wurde der arago Autopilot gemeinsam mit einigen neuen Produkten der VMware und EMC

UpDate! Ausgabe 14 · Dezember 2010

Produktpalette einem breiten Fachpublikum vorgestellt.

CloudCamp Hamburg Am 17. September fand in der Uni Hamburg das CloudCamp Hamburg statt. Die arago unterstützte das CloudCamp Hamburg tatkräftig und brachte sowohl finanzielles Engagement als auch Erfahrungen aus dem im vergangenen Jahr in Frankfurt veranstalteten Cloudcamp ein.

Die Keynote von Chris Boos mit dem Titel ­Keine Cloud ohne Automatisierung ermöglichte einen optimalen Einstieg in die Veranstaltung, indem sie den Business-Case des Cloudcomputings von Grund auf darstellte und nachfolgende Redner sich darauf beziehen konnten.

Die Vorträge sowie viele Fotos von der Veranstaltung sind auf der Event-Homepage www. cloudcamp-hamburg.de zu finden.

itMSF Herbstkongress, Köln Der itMSF (IT Service Management Forum) Herbstkongress am 21. September stand ebenfalls ganz im Zeichen von Cloud Computing und SaaS. Im neuen Microsoft-Briefing-Center in Köln trafen sich Anwender und Anbieter, um sich dem Thema Cloud Computing mit dem Blick auf die benötigten Tools und die zugrun-

Inside arago deliegenden IT Service Management-Prozesse zu nähern. Chris Boos sorgte hier mit seinem Vortrag für Gesprächsstoff, denn seine Thesen („Die IT hat sich nicht verändert, auch wenn in der Computerwoche etwas anderes steht“) regten die Diskussionen rund um das Thema an.

Die Folien zu diesem Vortrag finden Sie unter slidesha.re/aPpFaM.

Cloudstorm Frankfurt/ SNW Europe, Frankfurt Die von der SNIA (Storage Networking Industry Association) veranstaltete SNW Europe (Storage Network World) fand am 26. und 27.

Oktober im Congress Center der Messe Frankfurt statt und beherbergte in diesem Jahr neben dem Bitkom Anwenderforum IT-Infrastrukturen auch eine Cloudstorm Veranstaltung, bei der Chris Boos die Keynote hielt. Die SNW Europe konnte in diesem Jahr ein Plus an Ausstellern (+36 %) und Teilnehmern (+7 %) vorweisen, was auch durch das veränderte bzw. erweiterte Konzept erreicht wurde. So wurden neben Storage

23 Networking auch verstärkt die Themen Virtualisierung und Rechenzentrum sowohl im Rahmen der Ausstellung als auch bei den Vorträgen berücksichtigt.

Autopilot Roadshow Neben den genannten Veranstaltungen haben wir gemeinsam mit unserem Partner Syngenio im Sommer und Herbst eine Roadshow veranstaltet, auf der wir in mehreren Städten den Autopiloten und die Einführungsmethodik präsentiert haben und den Interessenten Gelegenheit gaben, sich ausführlich über das Thema zu informieren. Die Veranstaltungen waren allesamt ausgebucht und zeigten besonders während des Networking-Teils nach den Präsentationen, dass das Interesse am arago Autopiloten und an der Einführungsmethodik sehr groß ist.

Wir werden die Roadshow im neuen Jahr mit einer Reihe weiterer Termine in ganz Deutschland fortsetzen. Informationen finden Sie auf der arago Homepage unter www.arago.de.

Impressum Herausgeber

arago AG Vorstände Hans-Christian Boos, Martin Friedrich Eschersheimer Landstraße 526–532 60433 Frankfurt am Main Telefon: 0 69 / 405 68-0 Fax: 0 69 / 405 68-111 info@arago.de www.arago.de

Redaktion und Textbeiträge Hans-Christian Boos, Ulrich Callenberg, Martin Friedrich, Hans Lange, Markus ­Leven, Roland Judas Layout, Grafik & Satz arago Consulting GmbH info@arago-consulting.de www.arago-consulting.de Bildnachweise Titelseite: Andreas Levers (www.flickr.com/ people/96dpi/), Lizenz: creativecommons. org/licenses/by/2.0/deed.de ISSN 1862-6580

UpDate! Ausgabe 14 · Dezember 2010

Comment

24 Hans-Christian Boos

Auf einmal wollen alle Cloud Was wäre die IT Presse heute ohne den Begriff Cloud Computing? Nun, vor allem hätte sie mal höchstens 3 Prozent ihres Umfanges. Scherz beiseite. Dass sich momentan im nebelwerfenden Marketing der IT beinahe alles Cloud nennt, hat vor allem mit einer gravierenden Veränderung zu tun: Auf einmal wollen alle Cloud.

Was 2008 noch ein Thema für die Ingenieure war, hat längst durch einen einfachen und bestechenden Business Case die Schreibtische der Finanz erobert. Allein die Möglichkeit, mit Cloud Computing 50 % oder mehr der kapitalbindenden und abzuschreibenden Investitionen in neue Hardware loszuwerden und gleichzeitig noch die Kosten für den Betrieb der notwendigen Hardware drastisch zu senken, reicht als Motivation ganz sicher. Die Techniker müssen längst niemanden mehr überzeugen, dass Cloud eine gute Idee ist; vielmehr ziehen sie mittlerweile selbst oft die bewährte „Security Bremskarte“, um den Erfolg des von ihnen selbst in die Welt gesetzten Modells zu bremsen. Ganz einfach, weil sie einerseits technisch noch nicht (ganz) bereit sind, andererseits aber nicht bedacht haben, dass die Veränderung, die mit Cloud Computing

UpDate! Ausgabe 14 · Dezember 2010

einher geht, auch ganz massive Eingriffe in den Alltag der technischen Abteilungen bedeutet. So würde die konsequente Nutzung von Cloud Computing zwar den flexiblen Einsatz von IT Umgebungen für kreative Zwecke ermöglichen, gleichzeitig aber Spielwiesen, die nichts und niemandem zugeordnet werden können, der Vergangenheit angehören. Außerdem macht eine Cloud die Kostenstruktur der IT transparenter.

Diese Dinge könnten eine Erklärung dafür sein, warum auch bei vielen Technikern eine gewisse Skepsis gegenüber dem selbst gemachten Hype besteht.

Aber liebe Kollegen auf den Ingenieursbänken: Warum so furchtsam? Wann ist es uns denn das letzte Mal passiert, dass eine Techniker-Idee nach anfänglichen Lacherfolgen auf einmal auf der Agenda jedes CIO und fast jedes CEO steht? Mir fallen nur zwei Gelegenheiten ein: 1. ERP und 2. „das Internet“. Also warum sich gegen etwas stellen, das wir selbst losgetreten haben? Ja, auch ich liebe es einmal ein technisches Tool auszuprobieren und es dann auch wieder im Schrank verschwinden zu lassen – aber genau das wird ja von uns erwartet, Innovation; und zu Innovation gehört es auch, dass man etwas, das nicht funktioniert, nicht weiter betreibt, sondern etwas Besseres findet. Und ist es nicht viel schöner, wenn eine solche Innovation nicht als Nebenprodukt abfällt, sondern gewollt ist und mit Lorbeeren versehen wird? Grund für jeden Techniker, der etwas auf sich hält, sich für das Thema Cloud Computing zu erwärmen und auftretende Schwierigkeiten nicht als willkommene Bremsklötze zu instrumentalisieren, sondern sie als interessante Aufgaben anzunehmen.

Denn auf einmal wollen alle Cloud.