Funktionsmodell für die Plattformentwicklung

  • 20 Minuten

Die Plattformentwicklung soll eine Journey sein. Ein schrittweiser iterativer Ansatz ist im Allgemeinen effektiver als der Versuch einer umfangreichen, sofortigen Implementierung oder das alleinige Verlassen auf Top-Down-Vorgaben. Inkrementelle Fortschritte, die mit Minimum Viable Products (MVPs) beginnen, ermöglichen es Teams, ihren Ansatz im Laufe der Zeit zu optimieren und gleichzeitig Feedback zu integrieren.

Der Lebenszyklus der Plattformentwicklung stellt einen strukturierten Ansatz dar, durch den sichergestellt wird, dass eine Plattform zuverlässig und skalierbar ist und kontinuierlich verbessert wird. Dieser Lebenszyklus umfasst verschiedene Phasen, die alle zum langfristigen Erfolg der Plattform beitragen.

Ein wesentliches Element des Lebenszyklus ist das Funktionsmodell für die Plattformentwicklung, das ein umfassendes Framework für die Bewertung, Planung und Implementierung von Maßnahmen zur Plattformentwicklung bietet. Das Modell beschreibt Reifegrade, bewährte Methoden und kritische Funktionen, die in jeder Phase des Lebenszyklus erforderlich sind, und stellt die Ausrichtung auf organisationsweite Ziele und Benutzeranforderungen sicher.

Das Modell beschreibt den Status bzw. Fortschritt bei der Weiterentwicklung der Methoden für die Plattformentwicklung in fünf Phasen: Anfang, Wiederholbar, Definiert, Verwaltet und Optimierung. In der Phase Anfang verfügen Organisationen über eine begrenzte Struktur mit Ad-hoc-Prozessen und minimalen Investitionen in Plattformfunktionen. Mit dem Erreichen der Phase Wiederholbar entstehen grundlegende Prozesse, die Einführung und Governance sind jedoch noch inkonsistent. Die Phase Definiert markiert die Einrichtung klarer Standards und Prozesse, wobei die Benutzer beginnen, Plattformlösungen bewusst zu nutzen. In der Phase Verwaltet werden Plattformen aktiv gesteuert, Ressourcen werden effizient bereitgestellt und verwaltet, und Benutzerinteraktionen sind durch standardisierte Schnittstellen konsistent. In der Phase Optimierung werden die Plattformen schließlich durch stabile Feedbackmechanismen, gemessene Ergebnisse und adaptive Funktionen, die auf die Anforderungen der Benutzer und die Unternehmensziele abgestimmt sind, kontinuierlich verbessert.

Das Modell wird basierend auf sechs Kompetenzbereichen bewertet: Investition spiegelt die Zuteilung von Ressourcen und Finanzmitteln wider. Einführung konzentriert sich auf die Entdeckung und Nutzung durch Benutzer. Governance stellt die Zugänglichkeit (Barrierefreiheit) von Ressourcen, die Kostenkontrolle und den Daten-/IP-Schutz sicher. Bereitstellung und Verwaltung definiert, wie Ressourcen bereitgestellt und verwaltet werden. Schnittstellen befasst sich mit den Benutzerinteraktionen mit der Plattform. Messung und Feedback hebt die kontinuierliche Verbesserung durch Leistungsmetriken und Benutzererkenntnisse hervor. Diese Kompetenzbereiche stimmen eng mit den wichtigsten Bereichen überein, die im Reifegradmodell für die Plattformentwicklung der Cloud Native Computing Foundation (CNCF) beschrieben sind, und spiegeln den Reifegrad der Plattformentwicklung der Organisation wider.

Um das Funktionsmodell für die Plattformentwicklung zu verwenden, bewerten Sie zunächst, wo Ihre Organisation derzeit in jedem der sechs Kompetenzbereiche steht. Sie können diese Bewertung manuell vornehmen oder die Umfrage zum Funktionsmodell für die Plattformentwicklung durchführen. Sobald Sie die aktuellen Phasen identifiziert haben, legen Sie zukünftige Wachstumsziele fest und zeichnen den Fortschritt Ihrer Organisation für jeden Kompetenzbereich auf. Sie müssen nicht in allen Bereichen gleichzeitig Fortschritte erzielen. Konzentrieren Sie sich auf die Bereiche, die für Ihre Organisation am sinnvollsten sind.

Diagramm: Wichtigste Faktoren und Phasen des Funktionsmodells für die Plattformentwicklung

Investitionsprojekte

Der Fokus des Kompetenzbereichs „Investition“ liegt bei seiner Weiterentwicklung in den einzelnen Phasen darauf, wie Personal und Finanzmittel Plattformfunktionen zugeordnet werden, wobei das Budget und die Personalausstattung, die Verwaltung des Projektumfangs und die Messung der Rendite (Return On Investment, ROI) im Vordergrund stehen.

  • Anfang (freiwillig): Plattformfunktionen entstehen aus der Notwendigkeit heraus, weil sich einzelne technische Fachkräfte freiwillig mit unmittelbaren taktischen Anforderungen befassen. Das Budget und die Personalausstattung sind minimal, und die Arbeit wird in der Regel nicht finanziert und neben bestehenden Aufgaben durchgeführt. Die Lösungen sind eng gefasst und zielen auf spezifische Probleme ab, wobei der Wissensaustausch zwischen Teams begrenzt ist. Der ROI wird daran gemessen, wie effektiv die unmittelbaren Anforderungen erfüllt werden und wie sie sich auf die Kernergebnisse des Projekts auswirken.
  • Wiederholbar (Ad-hoc-Beiträge): Dedizierte Teams beginnen, sich mit wiederkehrenden Herausforderungen zu befassen, z. B. inkonsistente Bereitstellung oder Sicherheitslücken, die Bemühungen sind jedoch noch weitgehend reaktiv. Die Budgets und die Personalausstattung sind auf bereichsübergreifende Belange beschränkt, und die Befugnisse innerhalb der Organisation sind eingeschränkt. Die Verwaltung des Projektumfangs konzentriert sich auf spezifische Probleme, ohne eine breitere, plattformweite Perspektive. Der ROI wird anhand von Verbesserungen bei der Bewältigung der wichtigsten Herausforderungen gemessen, z. B. dem Abbau des Rückstands.
  • Definiert (operationalisiert – dediziertes Team): Es entstehen zentral finanzierte Plattformteams, die sich darauf konzentrieren, die Softwarebereitstellung zu beschleunigen und technische Anforderungen zu erfüllen. Das Führungsteam beginnt, die Zusammenarbeit zu fördern und erste DevOps-Praktiken zu implementieren, die Messung des Teamwerts bleibt jedoch eine Herausforderung. Budget und Personalausstattung der zentralen Teams sind formalisiert, um technische Anforderungen zu erfüllen. Die Lösungen werden umfassender und befassen sich mit gemeinsamen Herausforderungen aller Teams, auch wenn der Schwerpunkt weiterhin auf kurzfristigen Zielen liegt. Der ROI wird an der Verbesserung der Bereitstellungsgeschwindigkeit gemessen.
  • Verwaltet (skalierbar – als Produkt): Es findet ein kultureller Wandel statt, bei dem Entwickler als Kunden behandelt werden und die Führungsebene Wert auf Empathie und einen produktorientierten Ansatz legt. Plattformteams arbeiten wie Produktteams und umfassen Entwickler, Produktmanager und Experten für das Benutzererlebnis. Die Verwaltung des Projektumfangs wird mit Produktroadmaps abgestimmt, die in Zusammenarbeit mit den technischen Teams überprüft werden, um die organisationsweiten Anforderungen zu erfüllen. Der ROI wird anhand der höheren Zufriedenheit der Entwickler bewertet, die kontinuierliche Verbesserungen und die Ausrichtung auf Benutzeranforderungen widerspiegelt.
  • Optimierung (aktiviertes Ökosystem): Der Schwerpunkt der Investitionen liegt auf Innovation und der Aufrechterhaltung der Relevanz der Plattform, wobei Beiträge aus der gesamten Organisation gefördert werden. Plattformteams führen fortschrittliche Funktionen wie Sicherheits- und Leistungsverbesserungen ein, die es Produktteams ermöglichen, Lösungen zu erstellen, ohne auf ein zentralisiertes Backlog zurückgreifen zu müssen. Die Budgets gehen über die zentralen Teams hinaus, und die Mittel sind in der gesamten Organisation verfügbar. Bei der Verwaltung des Projektumfangs liegt der Schwerpunkt auf einem schnellen, organisationsweiten Wissensaustausch. Der ROI wird durch die nachhaltige Verbesserung der Entwicklerzufriedenheit gemessen.

Einführung

Der Kompetenzbereich „Einführung“ konzentriert sich darauf, wie Benutzer Ihre Lösungen für die Plattformentwicklung und die zugehörigen Angebote entdecken und nutzen, was sich in der Entdeckung, Auswahl und Nutzung von Diensten, Tools und Technologien widerspiegelt. Mit zunehmendem Reifegrad der Organisation verlagert sich der Ansatz für die Einführung von der informellen und sporadischen Nutzung zu einem Modell, das umfassender strukturiert und beteiligungsorientiert ist und bei dem Benutzer aktiv mit der Plattform interagieren und zu ihrer Weiterentwicklung beitragen. Dieser Verlauf spiegelt wider, wie sich die Methoden zur Entdeckung, Entscheidungsfindung und Nutzung der Benutzer im Laufe der Zeit weiterentwickeln – von der anfänglichen informellen Entdeckung bis hin zur vollständigen Beteiligung an der Entwicklung der Plattform.

  • Anfang (informell): Die Einführung ist inkonsistent, und Teams verbessern Prozesse ohne organisationsweite Koordination unabhängig voneinander. Externe Tools werden häufig internen Tools vorgezogen. Plattformen werden informell entdeckt, hauptsächlich durch Mundpropaganda oder zufällige Begegnungen, und technische Teams wählen die Dienste nach ihren spezifischen Anforderungen aus. Jedes Team verwendet eigene Skripts und Tools, die auf seine speziellen Anforderungen zugeschnitten sind.
  • Wiederholbar (vorgeschrieben): Die Organisation schreibt die Verwendung freigegebener Plattformen vor, die Funktionen sind jedoch auf häufige Anwendungsfälle beschränkt, sodass es schwierig ist, ungewöhnliche Anforderungen zu erfüllen. Die Entdeckung durch Benutzer hängt von der Anleitung des Plattformteams ab, die oft durch interne Dokumentation oder Richtlinien erfolgt. Teams können durch informelle Diskussionen mit dem Plattformteam vorgeschriebene Dienste auswählen. Obwohl Prozesse auf der Grundlage von Plattformstandards entwickelt werden, kann es vorkommen, dass Teams diese nicht vollständig übernehmen oder mit den Ergebnissen unzufrieden sind.
  • Definiert (angekündigt): Die Plattformfunktionen werden aktiv gefördert und auf die Bedürfnisse der Teams abgestimmt. Das Plattformteam arbeitet mit technischen Teams zusammen, um qualitativ hochwertige Dienste anzubieten, die den betrieblichen Mehraufwand reduzieren. Dennoch kann es vorkommen, dass einige Teams aufgrund veralteter Praktiken und technischer Schulden immer noch einen geringen ROI erzielen. Teams entdecken Funktionen durch Anweisungen, die typische Anwendungsfälle abdecken, und das Plattformteam fördert die Nutzung durch Zusammenarbeit. Die Förderung der Plattformnutzung erfolgt auch informell durch Teambotschafter.
  • Verwaltet (wertorientiert): Produktteams erkennen und entscheiden sich für Plattformfunktionen, weil diese den kognitiven Aufwand verringern und hochwertige Dienste bieten. Plattformen werden durch eine umfassende Dokumentation, ergonomische Schnittstellen und eine Self-Service-Benutzererfahrung für die schnelle Bereitstellung unterstützt. Teams bevorzugen jetzt interne Plattformen, anstatt selbst Lösungen zu entwickeln oder sich auf externe Anbieter zu verlassen. Die Entdeckung und Entscheidungsfindung werden vereinfacht, indem Teams Vorlagen, Foren und Dokumentationen nutzen, um die Einführung der Plattform umfassend zu unterstützen.
  • Optimierung (beteiligungsorientiert): Produktteams tragen aktiv zur Verbesserung der Plattformfunktionen bei, indem sie neue Features und Fehlerbehebungen vorschlagen. Es gibt Prozesse, mit denen Benutzer Anforderungen ermitteln und an Beiträgen zusammenarbeiten können. Befürworter und Botschafter der Entwickler unterstützen eine interne Community, wodurch die Verantwortung für die Plattform auf die Mitwirkenden ausgedehnt wird. Plattformtechniker arbeiten eng mit Produktteams zusammen, um die Anforderungen zu verstehen und neue Funktionen vorzuschlagen, und ermöglichen es Benutzern, Pull Requests zu übermitteln und an Bewertungen teilzunehmen.

Verwaltung

Bei der Weiterentwicklung des Kompetenzbereichs „Governance“ liegt der Schwerpunkt darauf, den Zugriff der Benutzer auf die benötigten Ressourcen und Funktionen sicherzustellen und gleichzeitig die Kosten, Daten und geistiges Eigentum zu verwalten. Die Fortschritte in diesem Bereich werden anhand mehrerer Kategorien bewertet, darunter die Definition von Richtlinien und Frameworks, die Implementierung von Richtlinien, die Überwachung und Minimierung von Compliancerisiken sowie die Verwaltung des Zugriffs. Die Governance entwickelt sich von manuellen und reaktiven Prozessen zu einem integrierten, prädiktiven System, das ein Gleichgewicht zwischen zentraler Steuerung und adaptiver Verwaltung für sich ändernde Anforderungen schafft.

  • Anfang (unabhängig): Die Governance erfolgt manuell und beruht auf zentraler Kontrolle und Überwachung, was die Skalierbarkeit beeinträchtigt. Entwickler und Sicherheitsteams arbeiten unabhängig voneinander und reagieren reaktiv auf Richtlinienverstöße. Die Compliance wird durch minimale Standards aufrechterhalten, wobei Sicherheitsmaßnahmen oft erst nachträglich hinzugefügt werden. Zugriffsberechtigungen werden ohne standardisierten Prozess basierend auf unmittelbaren Anforderungen gewährt.
  • Wiederholbar (dokumentiert): Die Organisation beginnt, Richtlinien zu dokumentieren und zu teilen, diese Richtlinien sind jedoch nur grundlegend und werden inkonsistent angewendet. Governancetools wie Ticketsysteme werden eingeführt, um Richtlinienüberprüfungen zu verwalten, der Prozess ist jedoch weiterhin manuell und langsam. Überwachungsprozesse sind eingerichtet, aber noch immer reaktiv. Einige Rollen und Berechtigungen sind standardisiert, die Durchsetzung erfolgt jedoch noch immer uneinheitlich.
  • Definiert (standardisiert): Die Governance wird zentralisiert und standardisiert, um die Konsistenz und Effizienz teamübergreifend zu verbessern. Richtlinien werden mit einem gewissen Maß an Automatisierung im Implementierungsprozess dokumentiert und zentral verwaltet. Wichtige Governancestandards werden durch regelmäßige Überwachung aufrechterhalten, und die Zugriffssteuerung wird mit einem formalen RBAC-System (Role-Based Access Control, rollenbasierte Zugriffssteuerung) automatisiert, die Entwicklungsteams haben jedoch noch immer nur begrenzte Kontrolle über Richtlinienänderungen.
  • Verwaltet (integriert): Sicherheit und Compliance sind nahtlos in Workflows integriert, und durch Automatisierung wird sichergestellt, dass Richtlinien system- und teamübergreifend einheitlich angewendet werden. Echtzeitüberwachung und erweiterte Analysen helfen dabei, Lücken in der Governance zu erkennen und zu verhindern. Richtlinien sind in CI/CD-Pipelines (Continuous Integration und Continuous Delivery) eingebettet, und die Zugriffsverwaltung erfolgt nach den Prinzipien der geringsten Rechte mit automatisierten Überprüfungen, wodurch ein proaktiverer und integrierter Ansatz für die Governance gewährleistet wird.
  • Optimierung (prädiktiv): Die Governance wird dynamisch und kontextbezogen, reagiert auf veränderte Bedingungen und optimiert die Zugriffssteuerung. Vorhersageanalysen (Predictive Analytics) helfen, potenzielle Risiken zu identifizieren, bevor sie auftreten, wodurch eine proaktive Risikominderung möglich ist. Richtlinien werden mithilfe erweiterter Analysen kontinuierlich optimiert, und die Zugriffssteuerung wird dynamisch auf der Grundlage von Echtzeitfaktoren wie Benutzerstandort und Zugriffszeit angepasst, um die Konformität zu gewährleisten und gleichzeitig maßgeschneiderte Workflows zu ermöglichen.

Bereitstellung und Verwaltung

Beim Kompetenzbereich „Bereitstellung und Verwaltung“ liegt der Fokus darauf, wie Benutzer Ressourcen erstellen, bereitstellen und verwalten. Der Prozess entwickelt sich von manuellen, isolierten Vorgängen zu einem adaptiven, automatisierten System, das ein Gleichgewicht zwischen Flexibilität und Governance herstellt und die effiziente Bereitstellung von Ressourcen unter Einhaltung der Complianceanforderungen gewährleistet. Dieser Prozess umfasst verschiedene Phasen, die sich in die Definition von Bereitstellungsprozessen, die Reaktion auf Anforderungen und deren Verwaltung sowie die Überwachung der Ressourcenzuordnung unterteilen lassen.

  • Anfang (manuell): Entwickler richten die Infrastruktur basierend auf den Anleitungen der IT- oder Architekturteams manuell ein, was zu Inkonsistenzen und Verzögerungen führt. Es gibt keine standardisierten Prozesse, sodass Anforderungen manuell überprüft werden, was das Fehlerrisiko erhöht. Dieser Ansatz ist bei zunehmenden Anforderungen nicht mehr tragbar, da isolierte Vorgänge zu Ineffizienzen führen.
  • Wiederholbar (koordiniert): Die Organisation beginnt, Bereitstellungsprozesse mithilfe von Ticketsystemen zu zentralisieren, um Infrastrukturanforderungen zu verwalten. Obwohl noch manuelle Genehmigungen erforderlich sind, werden einige Fehler reduziert. Es gibt jedoch weiterhin Engpässe. Teams beginnen mit der Verwendung von Standardtools zum Überwachen von Ressourcen, die Ansicht ist jedoch weiterhin isoliert und projektspezifisch.
  • Definiert (geebnete Wege): Bereitstellungsprozesse werden in der gesamten Organisation mithilfe von Infrastructure-as-Code (IaC) formalisiert, indem Vorlagen und Tools standardisiert werden. Anforderungen werden über strukturierte Workflows verarbeitet, die steigende Nachfrage bereitet dem Plattformteam jedoch Schwierigkeiten. Zentrale Dashboards ermöglichen die Überwachung der Ressourcenzuordnung und bieten bessere Erkenntnisse zur Leistung.
  • Verwaltet (automatisiert): Die Bereitstellung wird automatisiert und in CI/CD-Pipelines integriert, wodurch der manuelle Aufwand minimiert und konsistente Bereitstellungen sichergestellt werden. Governance- und Complianceprüfungen sind in Workflows eingebettet. Automatisierte Self-Service-Funktionen ermöglichen Benutzern die Bereitstellung von Ressourcen innerhalb kontrollierter Parameter. Die Skalierung wird basierend auf Nutzungsmustern automatisiert, um die Leistung zu optimieren.
  • Optimierung (adaptiv): Die Bereitstellung wird adaptiv und nutzt intelligente Systeme, um den Infrastrukturbedarf in Echtzeit zu antizipieren. Dieser Ansatz gewährleistet eine effiziente Ressourcenzuordnung, während gleichzeitig die Governance und Compliance aufrecht erhalten werden. Die Systeme behandeln Anforderungen proaktiv und sorgen für ein Gleichgewicht zwischen Flexibilität und Governance, während die Leistung und Kosteneffizienz durch Vorhersageanalysen optimiert werden.

Schnittstellen

Beim Kompetenzbereich „Schnittstellen“ geht es in erster Linie darum, wie Benutzer mit den Plattformdiensten und -produkten interagieren und diese nutzen. Die Fortschritte konzentrieren sich auf die Einrichtung von Standards, die Erhöhung der Benutzerautonomie und die nahtlose Integration von Plattformfunktionen in bestehende Workflows. Der Ansatz entwickelt sich von inkonsistenten, manuellen Prozessen hin zu einem integrierten Self-Service-System, das das Benutzererlebnis und die betriebliche Effizienz verbessert.

  • Anfang (benutzerdefinierte Prozesse): Benutzer interagieren mit der Plattform über verschiedene inkonsistente, benutzerdefinierte Prozesse, die den unmittelbaren Anforderungen entsprechen, aber nicht standardisiert sind. Technische Fachkräfte richten eigenständig Umgebungen ein, indem sie Kollegen zu Rate ziehen oder persönliche Methoden nutzen, und sie wählen Tools und Prozesse zum Diagnostizieren des Anwendungsverhaltens ohne festgelegte Richtlinien aus. Der Wissensaustausch ist informell, und die Bereitstellung von Diensten erfordert aufgrund fehlender formalisierter Prozesse häufig eine umfassende Unterstützung durch die Anbieter, was die Skalierbarkeit und Effizienz einschränkt.
  • Wiederholbar (lokale Standards): Technische Fachkräfte und Teams beginnen mit der informellen Definition von Standards, um den Wissensaustausch zu verbessern, die Konsistenz ist aufgrund der Abhängigkeit von individuellen Beiträgen jedoch weiterhin eine Herausforderung. Einige Teams verwenden vielleicht eine Dokumentation oder Container, um ihre Einrichtungsprozesse zu definieren, diese Methoden weichen jedoch im Laufe der Zeit voneinander ab, sodass sie nur schwer in Einklang zu bringen sind. Die Diagnose des Anwendungsverhaltens wird innerhalb der Teams stärker standardisiert, wobei beim Zugriff auf bereitgestellte Ressourcen eine gewisse Abhängigkeit von DevOps- oder IT-Teams besteht. Es entstehen zwar lokale Standards, diese sind jedoch nur lose definiert und von Team zu Team inkonsistent.
  • Definiert (Standardtools): Schnittstellen werden durch die Einführung von standardisierten Tools und dokumentierten Methoden konsistenter. Zentrale Teams verwalten Vorlagen und Dokumentationen und geben so genannte „geebnete Wege“ oder „goldene Pfade“ zum Bereitstellen und Überwachen von Funktionen vor. Diese Tools und Prozesse erfüllen weiter gefasste organisatorische Anforderungen, auch wenn häufig noch die Unterstützung von Experten erforderlich ist. Teams können Vorlagen ändern, die Änderungen werden jedoch nicht immer zentral integriert, was zu Ineffizienzen bei der Aufrechterhaltung der Konsistenz führen kann. Die Diagnose des Anwendungsverhaltens erfolgt nach standardisierten Methoden für den Zugriff auf bereitgestellte Ressourcen und deren Analyse, was für mehr Konsistenz zwischen den Teams sorgt.
  • Verwaltet (Self-Service-Lösungen): Die Plattform ermöglicht eine umfassendere Benutzerautonomie, indem sie Self-Service-Lösungen mit minimaler Unterstützung durch den Maintainer bietet. Benutzer haben Zugriff auf konsistente Schnittstellen, die leicht zu bedienen sind und es ihnen ermöglichen, Vorlagen zu entdecken und zu ändern, wodurch eine benutzerorientierte Umgebung geschaffen wird, die die Benutzerfreundlichkeit verbessert. Tools für die Diagnose des Anwendungsverhaltens und die Überwachung von Ressourcen werden bei Bedarf über die Plattform zur Verfügung gestellt, sodass Benutzer ohne starke Abhängigkeit von externen Teams über die benötigten Ressourcen verfügen. Der Wissensaustausch wird durch die Entdeckung und Änderung von Vorlagen erleichtert, was den Wert der Plattformfunktionen erhöht.
  • Optimierung (integrierte Dienste): Plattformfunktionen sind nahtlos in die Tools und Prozesse integriert, die die Teams bereits verwenden, z. B. die Befehlszeilenschnittstelle (Command Line Interface, CLI) oder integrierte Entwicklungsumgebungen (Integrated Development Environments, IDEs), und werden so zu einem natürlichen Bestandteil der Workflows von Benutzern. Einige Funktionen werden automatisch auf Grundlage der Benutzeranforderungen bereitgestellt, und die Plattform bietet flexible Bausteine für Anwendungsfälle auf höherer Ebene, die eine umfassendere Anpassung erfordern. Die Plattformteams bewerten kontinuierlich, welche Funktionen am effektivsten sind, und liefern Informationen, auf deren Grundlage Entscheidungen bezüglich weiterer Investitionen in die Optimierung des Plattformangebots getroffen werden können. Die Plattform richtet für bereitgestellte Anwendungen automatisch Einblicke ein, bietet Echtzeitzugriff auf Diagnosedaten und verbessert den Prozess der Überwachung und Verwaltung des Anwendungsverhaltens.

Messung und Feedback

Der Kompetenzbereich „Messung und Feedback“ umfasst das Sammeln, Analysieren und Integrieren von Metriken und Feedback, um den Erfolg der Methoden für die Plattformentwicklung zu bewerten. Sein Reifegrad zeigt sich im Übergang von Ad-hoc- und informellen Methoden zu einer proaktiven, datengesteuerten Kultur, in der Feedback und Erkenntnisse in kontinuierliche Verbesserungsprozesse einfließen, um Informationen für strategische Entscheidungen und die Plattformentwicklung zu liefern.

  • Anfang (Ad-hoc): In der Phase „Anfang“ sind Messungs- und Feedbackprozesse inkonsistent und fragmentiert. Metriken werden ohne klare Ausrichtung auf organisationsweite Ziele gesammelt, was zu unvollständigen und unzuverlässigen Daten führt. Feedback wird informell und häufig in Einzelberichten gesammelt, wobei die Stakeholder kaum beteiligt sind. Infolgedessen werden Entscheidungen auf der Grundlage begrenzter Informationen getroffen, und es ist schwierig, den tatsächlichen ROI von Plattformentwicklungsmethoden zu messen. Die Dokumentation von Feedback und Ergebnissen ist minimal, und Erkenntnisse werden selten erfasst oder geteilt.
  • Wiederholbar (strukturierte Prozesse): Es werden grundlegende Feedbackmechanismen (z. B. Umfragen oder Foren) eingerichtet, um Benutzererlebnisse systematischer zu erfassen, diese Prozesse variieren jedoch noch immer von Team zu Team. Die Messung des Erfolgs konzentriert sich häufig auf aktivitätsbasierte Metriken wie Bereitstellungen oder Zeitachsen, was Erkenntnisse zur Leistung, aber keine umfassendere ergebnisbasierte Perspektive bietet. Feedback bleibt informell und erfolgt von unten nach oben, beginnt jedoch, die Planung zu beeinflussen. Es wird versucht, die Stakeholder einzubeziehen, ihre Beteiligung ist jedoch noch begrenzt. Zudem wird eine erste Dokumentation der Prozesse und des Feedbacks erstellt, die aber noch nicht umfassend ist oder nicht konsequent genutzt wird.
  • Definiert (konsistent): Die Feedbacksammlung wird umfassender formalisiert und standardisiert und ermöglicht tiefere Erkenntnisse zu den Anforderungen der Benutzer und wichtigen Metriken. Die Metriken verlagern sich auf ergebnisorientierte Messungen, wie z. B. die Produktivität von Entwicklern, die Verknüpfung mit der Finanzleistung bleibt jedoch eine Herausforderung. Die Analyse des Feedbacks erfolgt systematisch mit qualitativen und quantitativen Methoden, und es werden Standardmetriken verwendet, z. B. DORA (DevOps Research and Assessment, eine Gruppe von Metriken, die die Leistung der Softwarebereitstellung messen, einschließlich Vorlaufzeit, Bereitstellungshäufigkeit, mittlerer Zeit zur Wiederherstellung und Fehlerrate bei Änderungen) oder SPACE (Satisfaction and well-being, Performance, Activity, Communication and Collaboration and Efficiency, ein Framework zur Messung der Entwicklerproduktivität in diesen fünf Dimensionen – Zufriedenheit und Wohlbefinden, Leistung, Aktivität, Kommunikation und Zusammenarbeit und Effizienz). Regelmäßige Sitzungen zur Überprüfung und Bewertung mit funktionsübergreifenden Teams gewährleisten eine aktive Beteiligung der Stakeholder. Eine umfassende Dokumentation der Feedbackprozesse, Ergebnisse und Erkenntnisse wird teamübergreifend gepflegt und geteilt.
  • Verwaltet (Erkenntnisse): In dieser Phase sind Feedbackmechanismen und Frameworks für Messungen stabil und auf strategische Geschäftsergebnisse fokussiert. Der Plattformbetrieb basiert auf datengesteuerten Erkenntnissen, und Feedback wird in die Plattformroadmaps integriert, um kontinuierliche Verbesserungen zu erzielen. Es werden erweiterte Analysen verwendet, um die Auswirkungen der Plattform auf Geschäftsergebnisse zu bewerten (z. B. Umsatzwachstum), und Feedback wird mit Leistungsmetriken korreliert, um wichtige Bereiche für strategische Verbesserungen zu identifizieren. Stakeholder in der gesamten Organisation werden in den Feedbackprozess einbezogen, wobei eine strukturierte Zusammenarbeit zur Vermeidung von Silos stattfindet. Eine dynamische Dokumentation in Echtzeit spiegelt das laufende Feedback und gewonnene Erkenntnisse wider und ist für alle Stakeholder zugänglich.
  • Optimierung (proaktiv): Feedback- und Messungsprozesse sind eng in die Organisationskultur integriert, wodurch ein proaktiver Ansatz zur Antizipation und Anpassung an künftige Herausforderungen und Chancen geschaffen wird. Vorhersageanalysen und erweiterte Metriken werden zur Vorhersage künftiger Bedürfnisse und Möglichkeiten eingesetzt, sodass die Plattform kontinuierlich auf veränderte Bedingungen reagieren und sich weiterentwickeln kann. Feedback wird vollständig in einen kontinuierlichen Verbesserungszyklus integriert, und eine Feedbackkultur ist auf allen Ebenen der Organisation etabliert. Eine dynamische Dokumentation in Echtzeit spiegelt das laufende Feedback wider und wird kontinuierlich aktualisiert, um sicherzustellen, dass gewonnene Erkenntnisse geteilt werden und für alle Stakeholder zugänglich sind.