通过

Anwendungen "für den Betrieb entwickeln"...

  • 项目

Oder in Neu-Hochdeutsch: "designed for operations" - was soll das, oder aber auch: Was heißt das?

Letzte Woche gab es in Hanau das Microsoft System Management Summit (in der dritten Inkarnation). In der Keynote referierte Larry Orecklin unter anderem über "Dynamic IT". In weiteren Sessions haben wir uns unter anderem dem Thema der Systemverwaltung über den Lebenszyklus von IT-Systemen (Server & Desktop) gewidmet. Ein spannendes und nicht immer ganz einfaches Thema.

Zwei Fragen, die sich sofort stellen, sind:

  • Was gehört alles zum "Lebenszyklus" dazu?
  • Wo fängt der "Lebenszyklus" eigentlich an?

Am Rande hatte ich dann auch noch ein Gespräch zu einer typischen Unternehmenssituation - dem "Verhältnis" der internen Anwendungsentwickler und dem Betrieb. Gerade dieses ist häufig sehr "speziell". Die Frage, warum eine Anwendung plötzlich nicht mehr funktioniert, obwohl der gleiche Code auf dem Rechner des Entwicklers noch perfekt funktionierte, ist schon fast das kleinste Problem. Richtig kompliziert wird es erst, wenn alles läuft, da dann der Betrieb verantwortlich ist - dafür, dass alles so bleibt, keine Probleme auftauchen, die Daten sicher sind... Nur: wie unterstützt ihn der Entwickler hierbei?

Wenn man auch die Anwendungen im Kontext des Lebenszyklus sieht, wird klar, dass der Betrieb ein wesentlicher Teil dieses Lebenszyklus ist - immerhin dürfte er in den meisten Fällen die mit Abstand meiste Zeit beanspruchen. Also gehört zur Definition von Leistungsumfang auch der Betrieb dazu - auch, wenn die wenigsten Entwickler das so sehen mögen. Nichts anderes meint übrigens "Designed for Operations".

Was tut Microsoft hier, um den Entwickler zu unterstützen? Eine Menge, an verschiedenen Stellen. Eine davon ist die Unterstützung durch Tools, zum Beispiel die verschiedenen Module des Visual Studio Team System, das verschiedene Designer auch für Architekten beinhaltet. Dazu auch die "Patterns & Practices" auf MSDN und auch verschiedene Add-Ons auf CodePlex, wie z.B. dieses Projekt. So wird es ein natürlicher Bestandteil der Anwendungsentwicklung, die notwendigen Informationen für den Betrieb bereitzustellen. In dieser Hinsicht wird in Zukunft bei den Tools noch einiges passieren. Nachteil (wenn man es denn so nennen will): Man muss auch bei Visual Studio aktuell bleiben, um die Vorteile und Verbesserungen nutzen zu können.

Zugegeben, das ist nur ein Teil. Vernünftige Setup Routinen, Integration in das Software Update Management und mehr gehören natürlich auch dazu, aber irgendwo muss man ja anfangen...