Einsatzpläne für Anwendungsdienste werden durch die Teamstruktur beeinflusst

Entwickler sind wirklich unterschiedlich. Aufgrund ihrer Rollen und Verantwortlichkeiten sowie ihrer Stellung in der Organisationsstruktur sind Entwickler häufig Außenseiter. Man kann sie nicht einmal unbedingt in den Begriff „IT“ einschließen, da Entwicklungsteams einerseits ein Teil der IT und andererseits ein Teil des Geschäfts sind und somit hin- und herpendeln.

Auch wenn DevOps als kultureller Wandel langsam Fuß zu fassen beginnt, sind die meisten Organisationen funktional weiterhin in sogenannten IT-Silos organisiert. In unserer Studie „State of Application Services 2019“ stellten wir fest, dass fast die Hälfte aller Befragten (46 %) immer noch in „Einzelfunktionsteams“ à la „Netzwerk“, „Server“, „Speicher“ und „Sicherheit“ organisiert war. Mehr als ein Drittel (37 %) arbeitete in kombinierten Betriebsteams, die besser in der Lage waren, DevOps-Prinzipien und -Ansätze für die Anwendungsbereitstellung und -implementierung zu übernehmen und anzuwenden. Nur 15 % arbeiteten in kleinen, funktionsübergreifenden Teams, die auf Geschäftseinheiten oder Unternehmensprodukten basierten.

Die Struktur ist wichtig, da sie zum Teil Ihre Ziele und Prioritäten definiert. Dies wiederum bestimmt die Maßstäbe, anhand derer der Erfolg gemessen wird. Siloorganisationen bedeuten isolierte Messgrößen. Das können wir unserer NetOps- und DevOps-Umfrage vom letzten Sommer entnehmen. Wir haben erhebliche Unterschiede bei der Bewertung der Teams anhand ihrer Struktur festgestellt. Die häufigsten Kennzahlen für alle Teamtypen und Rollen waren beispielsweise:

1. Netzwerkverfügbarkeit (60 %)
2. Anwendungsverfügbarkeit (56 %)
3. Prozessoptimierung (40 %)
4. Durchschnittliche Zeit bis zur Lösung (39 %)

Aber wenn wir das aufschlüsseln und uns Kennzahlen basierend auf Teamtypen ansehen, sehen wir, dass die eher kollaborativen – auch bekannt als … – DevOps-ähnlich – eine Teamstruktur ist, Prioritäten verschieben sich. 

In welcher Beziehung stehen nun die Kennzahlen, anhand derer Sie gemessen werden, zu den Anwendungsdiensten? Eigentlich ziemlich viel.

Wenn Ihr Hauptaugenmerk auf der Netzwerkverfügbarkeit liegt, müssen Sie darauf hinarbeiten und Dienste bereitstellen, die diesem Ziel dienen. Dasselbe gilt für die Anwendungsverfügbarkeit. Wenn das Ihre Priorität ist, werden Sie Verfügbarkeitsdienste viel ernster nehmen als die Leute, die an der Bereitstellungshäufigkeit gemessen werden.

In unserer Untersuchung können wir den Einfluss einer Befragtenbasis erkennen, die größtenteils aus „Single-Function-Teams“ besteht, in den Bereitstellungsplänen für Anwendungsdienste. Dies wird deutlicher, wenn wir die Anwendungsdienste danach kategorisieren, was sie für Anwendungen bieten – Sicherheit, Leistung, Identität/Zugriff, Verfügbarkeit und Mobilität. 

Diese Ergebnisse spiegeln die Auswirkungen der Kennzahlen einzelner Funktionsteams wider. Für Entwickler ist die Verfügbarkeit am wichtigsten – wozu oft auch bestimmte Leistungsziele gehören – und sie planen die Bereitstellung von Anwendungsdiensten, die sowohl die Verfügbarkeit als auch die Leistung unterstützen. Ebenso konzentrieren sich NetOps auf jene Anwendungsdienste, die die Netzwerkverfügbarkeit unterstützen, indem sie die Netzwerkprotokolle, auf die Anwendungen angewiesen sind, optimieren, skalieren und schützen. 

Die Teamstruktur ist wichtig. Dies liegt nicht nur an der Notwendigkeit, eine Kultur der Zusammenarbeit zu fördern, sondern auch an der Art und Weise, wie sich diese auf Entscheidungen auswirkt – einschließlich der Auswahl der Technologie. Unterschiedliche Ziele führen zu Reibereien und Frustration. Dies ist einer der Gründe, warum Anwendungsdienste wie Lastausgleich, die traditionell von NetOps bereitgestellt und betrieben werden, von DevOps übernommen und als Teil der Anwendung bereitgestellt werden. Denn in Organisationen mit Teamstrukturen mit nur einer Funktion hat die Anwendungsverfügbarkeit für Entwickler Priorität, nicht jedoch für NetOps.

Um DevOps wirklich nutzen zu können, müssen sich die Teamstrukturen – und die Maßstäbe, an denen sie gemessen werden – von traditionellen Teams mit nur einer Funktion hin zu stärker kollaborativen Modellen verlagern.

Denn Silos gehören auf den Bauernhof, nicht in die IT.