Service Ownership

Einleitung

Jedes Unternehmen, das auf Microservices setzt, profitiert ungemein von Service Ownership – ein Best Practice-Ansatz, der die Kundenzufriedenheit steigert, die team- und abteilungsübergreifende Kooperation stärkt und IT-Vorfälle reduziert. Selbst kleinen Unternehmen, die Microservices nutzen, wird empfohlen, eine „You build it, you run it“-Mentalität zu leben.

Und hier ist der Grund dafür: Anstatt den Entwickler und den Verantwortlichen einer App aufzuteilen, betreut eine Person oder ein Team den Services über seinen gesamten Lebenszyklus hinweg. Das bedeutet, dass sie auch volle Verantwortung für die Sicherheit, Leistung, Qualität und Zuverlässigkeit der Applikation übernehmen.

Nachdem Sie klare Verantwortlichkeiten hinsichtlich Ihrer Microservices geschaffen haben, können Teams zuverlässiger arbeiten und Software sowohl schneller als auch effizienter bereitstellen. Daraus resultiert natürlich auch ein Wettbewerbsvorteil gegenüber der Konkurrenz hinsichtlich der Marktanteile, der Rentabilität oder anderer Metriken, die für Sie und Ihr Unternehmen wichtig sind. 

Service Ownership ist jedoch ein relativ neuer Ansatz, der sich in eher traditionellen Unternehmen mit monolithischen Systemen nicht finden lässt. Damit Service Ownership in einer Microservice-Umgebung funktioniert, müssen Teams erst einmal dazu befähigt werden, Ownership zu übernehmen und letztendlich näher am Kunden zu sein.

Erfahren Sie mehr zu der Bedeutung von Service Ownership und wie Sie mit der Transformation Ihrer Unternehmenskultur bessere Produkte und Services bieten können.

Was ist Service Ownership?

Service Ownership basiert auf einer einfachen Annahme: Entwickler bzw. Entwickler-Teams, die ein Produkt oder einen Service bauen, sind auch nach dem Deployment für den jeweiligen Code und die Performance verantwortlich.

Es lässt sich in allen Branchen und Industrien ein grundlegender Wandel beobachten. Unternehmen entfernen sich von On-Premises-Technologien und setzen immer stärker auf Cloud-Umgebungen und Microservices, die ihnen mehr Flexibilität, eine bessere Skalierbarkeit und einfachere Wartung bieten. Was häufig mit ein paar groben Services beginnt, entwickelt sich schnell zu Services mit einem hohen Maß an Granularität. Dies ist völlig normal, da die Microservices-Architektur reift und Services aufgeteilt und angepasst werden. Schließlich lassen sich Services viel einfacher warten und bereitstellen, wenn sie in ihre einzelnen Komponenten zerlegt werden.

Nachdem Sie eine hohe Service-Granularität erreicht haben, werden viele Applikationen aus mehreren spezifischen Microservices bestehen, die jeweils eine kleine Aufgabe erfüllen. Bei einem IT-Vorfall kann der Owner, als die für den Microservice verantwortliche Person, umgehend ausgemacht sowie kontaktiert und das Problem dadurch behoben werden. Wenn jedoch kein richtiger Service Ownership vorhanden ist, kann es sich für Unternehmen durchaus schwierig gestalten, Probleme frühzeitig zu beheben. Daher erfordert die Umgestaltung der IT-Infrastruktur Ihres Unternehmens und die zunehmende Anzahl an Microservices auch eine Neugestaltung der Unternehmensstruktur.

Wenn Unternehmen weiterhin an ihrer zentralen Organisationsstruktur festhalten und IT-Teams folglich nicht optimal zusammenarbeiten, sondern in ihren alteingesessenen Silos festhängen und es eine klare Aufgabentrennung gibt, werden sie niemals die vielen Vorteile der Microservices-Architektur für sich nutzen können. Die Zentralisierung des IT-Betriebs basiert auf monolithischen Systemen und findet ihren Ursprung in den späten 2000er und frühen 2010er Jahren, also große konsolidierte Unternehmen zunächst Kosteneinsparungen erzielen konnten. Aber selbst damals forderte das starre Modell seinen Tribut. Es beeinträchtigte die Leistung, weshalb auch kleinere und flinkere Unternehmen dazu in der Lage waren, den Branchenführern gefährlich zu werden.

Mit Service Ownership können die typischen Probleme monolithischer Strukturen überwunden werden. Deswegen braucht es neben der Einführung von Microservices vor allem einen kulturellen Wandel innerhalb der Unternehmen. Auch wenn Microservices Ownership bedeutet, dass ein bestimmtes Team für die Sicherheit, Leistung, Qualität und Zuverlässigkeit eines Service verantwortlich ist, sollte der Code dennoch offen und für alle Entwickler zugänglich sein, um die teamübergreifende Zusammenarbeit zu stärken. Damit wird sichergestellt, dass andere Entwickler schnell einspringen können, wenn der Service Owner gerade einmal nicht da ist oder das Unternehmen verlassen hat. 

Im Folgenden wird aufgeführt, für welche Aufgaben Service Owner zuständig sind und wie wichtig Service Sponsors und Services Manager sind.

Welche Aufgaben übernehmen Service Owner?

Service Owner befassen sich mit der Verwaltung eines oder mehrerer Microservices – und das über den gesamten Lebenszyklus der Services. Sie leisten einen unschätzbaren Beitrag für die Erarbeitung von Service-Strategien und sind für das gesamte Service-Portfolio verantwortlich, unabhängig vom Standort der jeweiligen Technologiekomponenten oder Capabilities.

Der Aufgabenbereich von Service Ownern geht weit über die reine Wartung technischer Servicekomponenten oder Service-Codes hinaus. Die Rolle vereint unterschiedliche Disziplinen und kann daher mit einem „General Manager“ verglichen werden – aber für einen spezifischen Service. Ein General Manager braucht einen fundierten und ausgereiften Business Plan und muss gleichzeitig ein umfassendes Verständnis des aktuellen und zukünftigen Mehrwerts des Service haben. Das Verständnis allein reicht jedoch nicht aus: Er muss diesen Mehrwert auch den jeweiligen Stakeholdern anschaulich vermitteln können. 

Service Owner verwalten das Service Portfolio und sind außerdem für das Risikomanagement betriebener Services zuständig. Im Falle einer großen IT-Störung leiten sie deeskalierende Maßnahmen ein. Neben der Erarbeitung gezielter Sicherheitsmaßnahmen sind sie auch der richtige Ansprechpartner für die Gestaltung einer Service-Roadmap und Priorisierung von Initiativen. Außerdem haben sie jederzeit einen Blick auf die neusten technologischen Entwicklungen, mit denen die Kosten der Services gesenkt werden könnten. Eine der wohl wichtigsten Eigenschaften von Service Ownern sind gute Kommunikationsfähigkeiten und eine enge Zusammenarbeit mit Stakeholdern, um Betriebsprozesse mit den allgemeinen Geschäftszielen abzustimmen.

Manche Unternehmen haben nicht nur Service Owner, sondern auch Service Sponsors und Service Managers. Auch wenn es einige Überschneidungen hinsichtlich der Tätigkeitsbereiche gibt, hat doch jede Rolle einen speziellen Platz innerhalb der Microservices-basierten IT-Infrastruktur. Service Sponsors stellen meist die notwendigen Finanzmittel und Ressourcen für die Entwicklung und das Deployment von Services zur Verfügung. Außerdem genehmigen sie Risiken und Kosten, die mit den jeweiligen Services einhergehen, und nehmen Einfluss auf die strategische Richtung eines Service, bevor der Service Owner eine Entscheidung trifft.

Ein Service Manager kann auch als Business Relationship Manager oder Process Manager betrachtet werden, der den Lebenszyklus eines Service für die Entwicklung von Geschäftsstrategien verwaltet und gleichzeitig für die Geschäftsbeziehung mit Anbietern und anfallende Servicekosten verantwortlich ist. Der Service Manager führt auch Wettbewerbs-Benchmarking oder Marktbewertungen durch und überwacht das interne Supplier-Relationship-Management. Weitere Aufgaben umfassen Analysen zu Finanz- und Kundenmetriken.

Im nächsten Abschnitt wir erläutert, wie Sie Ihre Teams erfolgreich umstrukturieren und Ihr Unternehmen mithilfe von Service Ownerships transformieren können.

Auf Team-Ebene starten

Die Durchsetzung einer neuen Unternehmenskultur oder einer neuen Denkweise ist eine nicht zu unterschätzende Aufgabe, die viel Geduld erfordert. Es ist ein wahrer Balanceakt für Führungskräfte, die Teams an Bord holen müssen, die unterschiedliche Ansichten vertreten.

Da sich Teams, die nicht miteinander, sondern gegeneinander arbeiten, nicht mit dem Ansatz von Microservice Ownership vereinbaren lassen, sollte der Wandel der Unternehmenskultur direkt auf der Team-Ebene beginnen. Das heißt, dass Teams vereint werden und sichergestellt wird, dass ihre Ziele aufeinander abgestimmt sind. Wenn eines der Team-Ziele keinen Beitrag zum übergeordneten Geschäftsziel leistet, muss es überarbeitet und angepasst werden.

Die Führungsebene kann den Service Ownership-Gedanken anstoßen, indem sie Teams mit einem gemeinsamen Ziel zusammenbringen. Im besten Fall ist es ein kundenorientiertes Ziel, da Unternehmen von solchen Zielen in Zukunft profitieren werden.

Außerdem erhalten Teams, die einen Service verantworten, beinahe automatisch einen fachübergreifenden Charakter und sind für die Sicherheit, Zuverlässigkeit und Implementierung neuer Features zuständig.

Die Engineering Manager einbeziehen

Sobald alle Team-Ziele aufeinander abgestimmt sind, müssen die Engineering Manager an Bord geholt werden, da der Erfolg des Service Ownership-Konzepts maßgeblich von ihrer Kooperation abhängt.

Engineering Manager informieren die Führungsebene über den „Gesundheitszustand“ der Services und sind für die Kapazitätsplanung und die Überwachung der Geschäftsbedürfnisse zuständig. Sie müssen verstehen, welche Vorteile ihnen Service Ownership bietet – und wie sie dieses Konzept aktiv fördern können.

Wenn Microservice Ownership richtig umgesetzt wird, stellt das Konzept keine Gefahr für Engineering Manager dar, ganz im Gegenteil: Es hilft Ihnen beim Deployment qualitativ hochwertigen Service-Codes, da ein gemeinsames Verantwortlichkeitsgefühl für die Entwicklung leistungsfähiger Produkte herrscht. Dieses gestärkte Verantwortlichkeitsgefühl führt zu weniger Ausfällen und einer besseren Schadensbegrenzung. 

Im Falle von Service-Unterbrechungen kann der Entwickler, der den Code geschrieben hat, direkt kontaktiert werden. Service Engineers können zur Etablierung von Service Ownership in ihren Unternehmen beitragen und Teammitglieder befähigen, indem ihnen mehr Verantwortung zuteilwird.

Im nächsten Abschnitt erfahren Sie, wie Service Ownership mithilfe zweier erprobter Methoden implementiert werden kann.

Kulturwandel: Service Ownership fördern

Da Service Ownership gelebt werden muss und daher nichts Greifbares ist, nimmt der Aufbau und die Umsetzung eines solchen Konzepts einige Zeit in Anspruch. Es gibt jedoch Wege, wie dieser Kulturwandel beschleunigt werden kann und Teams in einer Umgebung aufblühen können, in der ihnen mehr Verantwortung zukommt und den Kunden bessere Services geboten werden. Die im folgenden beschriebenen Methoden stellen Best Practices für die Etablierung von Service Ownership dar und schafft Harmonie zwischen den jeweiligen Stakeholdern.

Kundenzentrierte Unternehmenskultur

Wie bereits erwähnt kann sich Service Ownership nicht entwickeln, wenn die Ziele der unterschiedlichen Teams nicht übereinstimmen. Die einfachste Art und Weise, diese Ziele zu harmonisieren, ist die Festlegung eines gemeinsamen, übergeordneten Ziels, wie etwa der Fokus auf Kundenbedürfnisse. Natürlich vereint solch ein kundenzentrierter Ansatz nicht nur die Teams, sondern führt auch zu einer höheren Kundenzufriedenheit, mehr Wachstum und höheren Profiten. Um Service Ownership in Ihrem Unternehmen zu fördern, können Sie SLOs (Service-Level-Objectives) zur Abstimmung von Metriken und Projekten nutzen.

Fehlschläge und Mut feiern

Verantwortung zu übernehmen kann beängstigend sein. Deswegen könnten die Entwickler nicht sehr erfreut über die Idee sein, dass sie sofort kontaktiert werden, wenn der von ihnen entwickelte Service-Code fehlerhaft ist. Deswegen muss die Führungsebene eine sichere Umgebung für alle Teammitglieder schaffen. Niemand sollte Angst um seinen Job haben, nur weil er einmal einen Fehler gemacht hat. Service Ownership verfolgt einen geradezu konträren Ansatz: Es sollte Konsens dahingehend herrschen, dass Fehler eine Lernmöglichkeit darstellen und letztendlich zu besseren Produkten führen.

Fazit

In den letzten Jahren hat sich Microservice Ownership zu einer Best Practice entwickelt, da hochgranulare Microservices zu immer komplexer werdenden IT-Architekturen führen. Ein Grund dafür ist die Tatsache, dass monolithische Webapplikationen in kleinere, agilere Komponenten zerlegt werden.

Um das volle Potenzial dieser leichtgewichtigeren und agileren Applikationen ausschöpfen zu können, müssen die eher zentral organisierten IT-Teams neu ausgerichtet werden und zu fachübergreifenden Service Ownern werden.

Diesen Kulturwandel anzustreben und auch erfolgreich durchzusetzen erfordert Zeit und harte Arbeit. Sie müssen auf Team-Ebene beginnen, alle Führungskräfte (einschließlich der Engineering Manager) involvieren und gemeinsame, kundenzentrierte Ziele festlegen. Zu guter Letzt müssen Sie eine sichere Umgebung schaffen, in der Fehler als Lernmöglichkeit angesehen und Mut belohnt wird.