Bereitstellungspläne für Anwendungsdienste unter dem Einfluss der Teamstruktur

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Entwickler sind wirklich anders. Von ihren Rollen und Verantwortlichkeiten bis hin zu ihrer Einordnung in die Organisationsstruktur sind Entwickler oft die „Außenseiter“. Man kann sie nicht einmal unbedingt unter dem Begriff „IT“ zusammenfassen, da Entwicklungsteams immer wieder zwischen der Zugehörigkeit zur IT und der Zugehörigkeit zum operativen Geschäft hin- und herpendeln.

Auch wenn DevOps als kultureller Wandel allmählich Fuß fasst, sind die meisten Unternehmen funktional weiterhin in die wenig schmeichelhaft als IT-Silos bezeichneten Bereiche gegliedert. In unserer Studie State of Application Services 2019 stellten wir fest, dass fast die Hälfte aller Befragten (46 %) noch immer in „Teams mit Einzelfunktion“ wie „Netzwerk“, „Server“, „Speicher“ und „Sicherheit“ organisiert war. Mehr als ein Drittel (37 %) arbeitete in kombinierten Betriebsteams, die besser dafür geeignet waren, DevOps-Prinzipien und -Ansätze für die Anwendungsbereitstellung und -implementierung zu übernehmen und anzuwenden. Lediglich 15 % arbeiteten in kleinen, funktionsübergreifenden Teams, die nach Geschäftsbereichen oder Unternehmensprodukten gegliedert waren.

Die Struktur ist wichtig, da sie zum Teil Ihre Ziele und Prioritäten vorgibt. Diese wiederum bestimmen die Kennzahlen, anhand derer der Erfolg gemessen wird. Isolierte Organisationsbereiche führen zu isolierten Kennzahlen. Das zeigt sich auch in unserer NetOps- und DevOps-Umfrage vom vergangenen Sommer. Dabei stellten wir erhebliche Unterschiede bei der Erfolgsmessung von Teams fest, die von deren Struktur abhingen. Die häufigsten Kennzahlen über alle Teamtypen und Rollen hinweg waren beispielsweise:

1. Netzwerkverfügbarkeit (60 %)
2. Anwendungsverfügbarkeit (56 %)
3. Prozessoptimierung (40 %)
4. Mittlere Lösungszeit (39 %)

Wenn wir dies jedoch genauer aufschlüsseln und die Kennzahlen nach Teamtypen betrachten, stellen wir fest: Je kollaborativer – also DevOps-ähnlicher – ein Team strukturiert ist, desto stärker verschieben sich die Prioritäten.

Wie hängen nun die Kennzahlen, an denen Sie gemessen werden, mit Anwendungsservices zusammen? Tatsächlich ziemlich stark.

Wenn Ihr Hauptaugenmerk auf der Netzwerkverfügbarkeit liegt, werden Sie darauf hinarbeiten und Dienste bereitstellen, die diesem Ziel dienen. Gleiches gilt für die Anwendungsverfügbarkeit. Wenn diese für Sie Priorität hat, werden Sie Verfügbarkeitsdienste deutlich ernster nehmen als diejenigen, deren Leistung anhand der Bereitstellungshäufigkeit gemessen wird.

Die Auswirkungen einer Befragtenbasis, die größtenteils aus „Teams mit nur einem Funktionsbereich“ besteht, zeigen sich in unserer Studie an den Bereitstellungsplänen für Anwendungsdienste. Noch deutlicher wird dies, wenn wir die Anwendungsdienste danach kategorisieren, was sie für Anwendungen bereitstellen: Sicherheit, Leistung, Identitäts- und Zugriffsverwaltung, Verfügbarkeit und Mobilität.

Diese Ergebnisse spiegeln den Einfluss der Kennzahlen von Teams mit einzelnen Funktionsbereichen wider. Entwickler konzentrieren sich in erster Linie auf die Verfügbarkeit – die häufig auch konkrete Leistungsziele umfasst – und planen, jene Anwendungsdienste bereitzustellen, die sowohl die Verfügbarkeit als auch die Leistung unterstützen. Ebenso konzentrieren sich NetOps-Teams auf Anwendungsdienste, die die Netzwerkverfügbarkeit gewährleisten, indem sie die Netzwerkprotokolle, auf die Anwendungen angewiesen sind, optimieren, skalieren und schützen.

Die Teamstruktur ist wichtig. Nicht nur, weil eine stärker auf Zusammenarbeit ausgerichtete Kultur gefördert werden muss, sondern auch, weil sie Entscheidungen beeinflusst – einschließlich der Wahl von Technologien. Unterschiedliche Ziele führen zu Reibungen und Frustration. Das ist einer der Gründe, warum Anwendungsdienste wie der Lastenausgleich, die traditionell von NetOps bereitgestellt und betrieben werden, von DevOps übernommen und als Teil der Anwendung bereitgestellt werden. Denn in Organisationen mit Teams, die jeweils nur eine Funktion abdecken, hat die Verfügbarkeit von Anwendungen für Entwickler Priorität, nicht aber für NetOps.

Um das Potenzial von DevOps wirklich auszuschöpfen, müssen sich Teamstrukturen – und die Kennzahlen, anhand derer sie bewertet werden – hin zu stärker kollaborativen Modellen und weg von traditionellen Teams mit nur einem Funktionsbereich entwickeln.

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

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie