Service Provider

An der JAZOON 2011 haben wir zu ersten mal an einer Konferenz öffentlich über das Thema gesprochen: Wir wollen als Software Engineers zugleich Service Provider sein. Aber was bedeutet das?

Grundlagen

Um ein Service Provider zu sein, gilt es zunächst einmal festhalten, was genau man unter Service Management versteht, was ein Service ist, und welche Dimensionen hierbei relevant sind. Unter Service Management verstehen wir folgendes:

„Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.“ [ITSMF]

Eben diese Service selbst sind für uns von grossem Interesse:

„A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific cost and risks.“ [ITSMF]

Dieser Wert (Value) ist es, was wir gerne unseren Kunden schaffen wollen. Er ergibt sich aus der Kombination von Utility und Warranty:

Utility bezeichnet [ITIL Blues] als Funktionalität eines Produkts oder Services um ein bestimmtes Bedürfnis zu befriedigen. Dies wird oft auch als „was macht es“ zusammengefasst (für Software-Entwicklung ist dies auch als funktionale Anforderungen bekannt).

Die Warranty hingegen ist ein Versprechen bzw. eine Garantie, dass das Produkt oder der Service seine vereinbarten Anforderungen auch tatsächlich erfüllen kann (der Software-Entwickler spricht hierbei von nicht-funktionalen Anforderungen).

Was hat Service Management mit der Giniality AG zu tun?

Als Firma, die kundenspezifische Individual-Software herstellt ebenso wie das Tor zu einer Vielzahl von „Cloud“-Services für ihre Kunden öffnet, gilt es eine Vielzahl an Herausforderungen zu meistern.

Gerade als KMU ist es eine enorme Herausforderung, dass wir (analog Herstellungsbetrieben in der Industrie) die Kontrolle über unsere Produktionsstrasse und -elemente haben müssen:

  • Wir müssen die Abhängigkeiten unserer eigenen und externer (gekauft wie open-source) Komponenten und Bibliotheken kennen.
  • Wir müssen eine Nachvollziehbarkeit von Auswirkungen bieten können: im Fehler- sowie im Änderungsfall.
  • Wir müssen die Auswirkungen möglicher Änderungen abschätzen können.

Ebenfalls müssen wir sehr effektiv und effizient in Bezug auf die Erstellung und Verwaltung von Dokumentation sein: durch die Einhaltung von Standards können wir auf Standard-Dokumentation verweisen, und müssen so nicht Zusätzliches schaffen.

Auch ist es immer wieder von Nöten, dass wir in Bezug auf unsere Software-Fabrik effektiv und effizient mit Änderungen umgehen:

  • Änderungen an den Engineering-Plattformen und Server-Teilen müssen professionel geplant, geändert und dokumentiert werden.
  • Sich stetig wiederholende Änderungen müssen auch im Sinne des Request Fullfilments sehr schnell durchlaufen werden (bspw. Upgrade einer Continous Integration Lösung).
  • Standard-Prozesse und Prozeduren müssen definiert sein und eingehalten werden.
  • Informationen über Änderungen müssen zielgruppengerecht zugänglich sein bzw. vermittelt werden.
  • Wir müssen stabile Umfelder in Entwicklung, Integration, Test und nicht nur in der Produktion haben.
  • Wir müssen bestehende Leistung messen und auf Basis der erhaltenen Zahlen auch optimieren können.

Entscheidend ist für uns, dass wir uns auf unsere Kernkompetenzen konzentrieren können, und nicht mit einer Vielzahl an Verwaltungsaufgaben selbst in unserer Leistungskraft reduzieren.

SOA und Service Management

Einhergehend mit unserer Spezialisierung auf (Cloud)-Services, deren Integration und der Fokussierung in Richtung SOA war uns schnell klar, dass Service Management und SOA-Governance einen hohen Grad and deckungsgleichen Aufgaben haben. Dies sind beispielsweise:

  • Service Katalog Management
  • Kapazitäts-Management
  • Change Management
  • Konfigurations-Management
  • etc.

Schritte zum Service Management

Aller Anfang ist schwer – und so mussten wir uns für die ersten Schritte entscheiden, mit deren Hilfe wir das Service Management bei uns etablieren wollten:

  • Fokussierung auf die prozessorientierte Software-Entwicklung
  • Wandlung der Entwicklungsplattform zur Service Plattform
  • Aufbau einer Definitive Media Library (DML)
  • Aufbau der „Traceability“ von elektronischen Assets
  • Aufbau eines pragmatischen Wissens-Managements
  • Aufbau eines Kapazitätsmanagements
  • Akzeptenz von Continual Service Improvements als Qualitätstreiber
  • Integration SOA und ITIL zu einer Service Platform
  • Berücksichtigung der „Human Engine“ als treibende Kraft

Prozessorientierte Software-Entwicklung

model-designerinJim Reardan behauptet: „The true, precise point of origin of a requirement is the process the person or persons participate in.“ Nicht nur diese Aussage von Reardan, sondern auch unsere eigene Erfahrungen in einer Vielzahl von Projekten bestätigt diese Tatsache: Anforderungen können am besten aus den Prozessen abgeleitet werden, welche sie hervorufen.

Das Bindeglied zum Service Management liegt auf der Hand: um Services bereit zu stellen, bedarf es einer Vielzahl an Werkzeugen und Rollen/ Personen, welche gemeinsam Prozesse zu einem erfolgreichen Abschluss bringen wollen.