Jürgen Rühling adesso AG

Design for Operation kann einen wertvollen Beitrag dazu leisten, wirtschaftliche Vorteile zu realisieren.

In Softwareprojekten geht es vornehmlich – und das liegt in der Natur der Sache – um die Entwicklung von Software. Worum es häufig viel zu spät geht, ist der spätere Betrieb dieser Software.

Experten entwickeln unter Hochdruck neue Lösungen mit neuen Funktionen, stimmen sich mit Anwendern ab, testen, verwerfen, programmieren neu. Wie die spätere Umgebung technisch aussehen muss, in der die Software genutzt werden soll, wie die Anforderungen der Stakeholder an Verlässlichkeit, Leistungsvermögen und Rechtskonformität im Tagesbetrieb sind: Diesen Fragen widmen sich die Projektbeteiligten häufig erst später im Ablauf, teilweise zu spät. Dabei könnten Unternehmen die Prozesse am Ende des Softwareprojekts systematisch vereinfachen, wenn die Fachleute sich direkt zu Beginn die richtigen Fragen stellen und auf die richtigen Details achten. Das Konzept des „Design for Operation“ (siehe Kasten) soll den Verantwortlichen dabei helfen, genau diese Risiken am Übergang der Software in den Betrieb zu managen.

Design for Operation

Design for Operation bezeichnet das systematische Vorbereiten und Durchführen der Inbetriebnahme der Releases von IT-Anwendungen:

  • Die Bereitstellung für die geschäftliche Nutzung transformiert jedes Softwarerelease einer IT-Anwendung in einen IT-Service.
  • Die entwickelte Software wird als funktionale Komponente eines IT-Service in einen komplexen technologischen, organisatorischen und regulatorischen Kontext integriert, der bereits in Anforderungsanalyse und Architekturentwurf systematisch betrachtet werden sollte.
  • Design for Operation kann in alle marktgängigen Managementansätze (klassisch, inkrementell, iterativ, agil …) für Softwareentwicklungsprozesse integriert werden.

Mit Liebe zum Detail – und zum Betrieb

Acht Wochen vor dem Abnahmetermin klingelt das Telefon des Betriebsverantwortlichen: Die neue Software steht kurz vor der Fertigstellung, die Entwicklungsabteilung will kurz darüber reden, wie die Inbetriebnahme vonstattengehen soll. Im ersten Termin ist bereits nach ein paar Minuten klar, dass die Einkaufs- und Rechtsabteilung die Beschaffung notwendiger Hardware zur Erweiterung der virtuellen Linux-Serverkapazitäten, der Hochverfügbarkeitsoption für den Datenbankserver des Webshops und eines neuen Cloud-Providers für die CRM-Komponente nicht mehr termingerecht abschließen kann, weil der Kunde seine Security-Policy verschärft hat und daher ein EU-Datentreuhänder für den Betrieb verlangt wird. Über Themen wie den Aufbau von Abnahmetest- und Produktivumgebungen mussten die Experten erst gar nicht mehr diskutieren.

Solch eine Situation ist in der unternehmerischen Praxis nicht ungewöhnlich und – noch besser – sie ist vermeidbar. Allen Beteiligten muss nur klar sein, was Lieferplanung in Softwareprojekten bedeutet: Das Team muss die Software, die die Funktionalität abbildet, liefern; aber ebenso muss es von Beginn an alle Themen mitdenken, die notwendig sind, um diese Software in Betrieb zu nehmen. Dieses Mitdenken wird spätestens dann relevant, wenn die Entwickler die Software in die erste Testumgebung übertragen wollen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

PHP Magazin 4.17 - "Ionic"

Alle Infos zum Heft
579797556Design for Operation: Software-Design für den Alltag
X
- Gib Deinen Standort ein -
- or -