Einblick in den Software-Bereitstellungsprozess Software-First-Strategie – aber wie?

Anbieter zum Thema

OutSystems

Für andauernden Erfolg muss jedes Unternehmen ein Software-Unternehmen werden, heißt es. Eine Software-First-Strategie heißt aber mehr, als nur DevOps-Prinzipien durchzusetzen. Wichtig ist es dabei, dass Management mit ins Boot zu holen.

Moderne Unternehmen, so kann man immer häufiger lesen, müssten eine „Software-First-Strategie“ umsetzen. Das hat nicht zuletzt dazu geführt, dass sich Software-Entwickler und ihre Arbeit neuer Aufmerksamkeit und Wertschätzung erfreuen. Unterstützt von der Unternehmensleitung implementieren sie DevOps-Kulturen, bauen CI/CD-Pipelines auf, integrieren neue Tools, schulen Mitarbeiter und organisieren neue Verfahren – alles in dem Bestreben, die Software-Bereitstellung effizienter zu gestalten.

Es geht darum, wie Unternehmen die eigentliche Funktion der Software-Bereitstellung definieren und welche Priorität sie diesem Prozess einräumen. Beginnt und endet die Softwarebereitstellung im DevOps-Prozess? Oder geht sie darüber hinaus und schaut links und rechts vom eigentlichen Bereitstellungsprozess? Links: wie wird das Produkt konzipiert, geplant und priorisiert? Rechts: wie wird es vermarktet und verkauft? Bestehen schnelle Feedbackschleifen, um kontinuierlich Verbesserungen zu erzielen und bestehen End-to-End-Systeme zur Softwarebereitstellung, die alle Hindernisse beseitigen?

Viele Unternehmen versuchen es, werden aber durch die Toolsets und Prozesse, die den heutigen Softwaresektor bestimmen, eingeschränkt. Meist stoßen sie beim Übergang von DevOps zu Software-First an eine Grenze. Die Hauptursache für dieses Problem ist, dass Informationen in eigenständigen Software-Tools eingeschlossen und innerhalb von Teams und Funktionsgruppen isoliert sind.

Die Teams haben ihre eigenen individuellen Aufträge und arbeiten in Silos, ohne gemeinsame Prozesse, ein gemeinsames Datenmodell, eine gemeinsame Sprache oder universelle, gemeinsame Kenntnisse und Einsichten. Sie arbeiten untereinander zusammen, aber nicht effizient mit anderen Teams und anderen Abteilungen innerhalb des Unternehmens.

Darum benötigen Unternehmen eine Management-Ebene, die alle Funktionen im Zusammenhang mit der Software-Bereitstellung miteinander verbindet – und steuert. Hier kommt das neue Konzept des Software Delivery Management (SDM) ins Spiel. Es handelt sich nicht um eine Reihe von Tools. SDM basiert nicht auf einer proprietären Technologie. Es ist kein weiterer Prozess. Es ist die Grundlage, die Tools, Teams und Prozesse in Organisationen zusammenbringt.

Software Delivery Management

SDM ist ein Weg, Teams und Tools in einem Unternehmen zu verbinden und Transparenz, Zusammenarbeit und Governance durch einen einheitlichen Prozess und gemeinsame Daten zu ermöglichen, um bessere Software schneller auszuliefern. So wie DevOps die Mauern zwischen den Entwicklungs- und Betriebsteams einreißt, bricht SDM die Mauern zwischen Entwicklung, Produktmanagement, UIX-Teams, Dokumentationsteams, Support und Produktmarketing ein.

SDM ermöglicht es besser zu kommunizieren, die Bedürfnisse des jeweils anderen zu verstehen und letztendlich Software zu erstellen, die nicht nur fehlerfrei ist, sondern auch effektiv die Geschäftsanforderungen erfüllt und einen Mehrwert für den Kunden schafft. Ein SDM-Modell besteht im Wesentlichen aus vier Säulen: gemeinsame Daten, verbundene Prozesse, allgemein verfügbare Kenntnisse und die Zusammenarbeit aller Funktionen.

Informationsspeichersystem: Bauen oder kaufen Sie ein „Informationsspeichersystem“ mit einem gemeinsamen Datenmodell, das die verschiedenen Datenelemente zusammenführt. Dieses System sollte einen persistenten und erweiterbaren Datenspeicher umfassen, der die Entitäten des Softwarebereitstellungs-Lebenszyklus modelliert und alle Softwarebereitstellungsaktivitäten aufzeichnet, um spätere Abfragen, Transparenz, Analysen, Erkenntnisse und Workflow-Orchestrierung zu unterstützen. Ein solches System soll Daten in einem gemeinsamen Modell und einer gemeinsamen Sprache organisieren, auf die jeder zugreifen kann.

Flexibles gemeinsames Datenmodell, um allgemein verfügbare Kenntnisse zu erhalten: Um SDM zu realisieren, muss ein Unternehmen über APIs oder auf andere Weise verschiedene Tools verbinden. Die Idee ist, über die DevOps-Toolkette hinauszugehen und Informationen aus Datenquellen wie CRM, Finanzwesen und Support einzubringen.

Für SDM müssen diese Dinge zusammengebracht werden. Nur so können Informationen demokratisiert werden, damit die Entwicklungsteams verstehen, wer wann was mit den verschiedenen Komponenten macht oder gemacht hat.

Dann haben auch die verschiedenen Stakeholder – Produktmarketing, Vertrieb, Customer Success Management, Support – einen Einblick in diese Daten. Sie erhalten sie zum Beispiel über einen wöchentlichen Bericht, den jemand manuell erstellt und herausgibt. In jedem Fall ermöglicht SDM Transparenz, sodass die Leute vorausplanen und die großen Initiativen unterstützen können, die die Software-Entwicklung zusammenstellt.

SDM in Aktion

Nehmen wir an, der Produktleiter eines Musikanbieters möchte einen Musikplayer verbessern, indem er drei Dinge hinzufügt: eine bessere Benutzeroberfläche, verbessertes Editing und eine optimierte Art und Weise, Playlists zu verwalten. Ohne SDM entstünde wahrscheinlich ein eigenständiges Dokument, das eine Reihe komplexer Anforderungen beschreibt und dann an das Entwicklungsteam geschickt wird.

Dem Entwicklungsteam fehlt dann jeglicher Kontext, um zu verstehen, warum die Funktionen wichtig sind. Das Dev-Team würde die Anforderungen in ein Tracking-System als User Stories oder Features übersetzen, jedoch ohne ein vollständiges Verständnis der Beweggründe auf Seiten der Kunden oder des Unternehmens. Die Tatsache, dass die Anpassungswünsche aus Kundensupport-Tickets und RFEs gezogen wurden, wird komplett ausgeblendet.

Die Anzeige- und Bearbeitungsmöglichkeiten wurden im ursprünglichen Anforderungsdokument nicht klar definiert, und noch mehr Information ging bei der Übersetzung in Stories verloren. Diese Lücke bleibt unbemerkt. Entsprechend werden die Playlist-Funktionen falsch implementiert. Das Projekt wird für Kunden freigegeben, aber die Akzeptanz ist mäßig. Statt des erhofften Rückgangs der Supportanfragen erhalten die Supportteams eine Flut von Anfragen von Kunden, die die Benutzeroberfläche nicht verstehen oder Probleme haben, sie zum Laufen zu bringen.

In der Zwischenzeit veröffentlicht ein Konkurrent, der sich der gleichen Marktherausforderung gegenübersieht, neue Funktionen. Die neuen Funktionen des Mitbewerbers sind nicht genau die gleichen, aber sie erfüllen die gleichen Kundenbedürfnisse. Auch der Mitbewerber sieht zunächst eine schwache Akzeptanz, ist aber in der Lage, das Feedback der Vertriebs- und Support-Teams schnell in neue Versionen zu integrieren.

Nachdem die verwirrende Benutzeroberfläche behoben wurde und das Produktmarketingteam eine entsprechende Dokumentation erstellt hat, steigt die Akzeptanz sprunghaft an. Der Konkurrent gewinnt Innovationspreise der Branche, und unser Beispielunternehmen verliert Kunden, Umsatz und möglicherweise sogar wichtige Entwickler, die zum Konkurrenten wechseln.

Hätten die Entwickler von Anfang an gewusst, warum die neuen Funktionen entwickelt werden, hätten sie dann Verbesserungen vorschlagen können, die die gleichen Geschäftsziele erreichen? Besser noch: Hätten sie die Bedürfnisse der Kunden verstanden, hätten sie vielleicht einen alternativen Ansatz vorschlagen können, der noch besser ist. Hätten Support und Entwicklung Zugang zu gemeinsamen Informationen und verbundenen Prozessen gehabt, hätten sie dann besser zusammenarbeiten können? Aus diesem Grund ist es wichtig, die Entwicklungsteams in den Hauptstrom der Geschäftsabläufe und -planung einzubinden.

Die Post-Covid-Zukunft

Die Schaffung einer Management-Ebene über den bestehenden Prozessen und Tools ist in jeder Umgebung wichtig. Sie stellt sicher, dass die Produkte pünktlich herauskommen, dass sie mit hoher Qualität entwickelt werden, dass sie sicher sind und dass sie die Bedürfnisse der Anwender erfüllen. In Zeiten von Covid-19 ist dies sogar noch wichtiger.

Beim Blick auf den gesamten Software-Entwicklungsprozess muss die Unternehmensleitung wissen, wo die Dinge stehen, wer an welchen Prozessen arbeitet, wie die Arbeit voranschreitet und ob Hindernisse beseitigt werden müssen. Automation anstelle manueller Schritte, die vorher akzeptabel waren, ist jetzt vonnöten.

Genau hier kommt SDM ins Spiel. Bei CI/CD geht es darum, den Code zu erstellen, ihn zu testen und ihn zu veröffentlichen. SDM gibt allen Stakeholdern darüber hinaus Einblick in jeden Aspekt des Software-Bereitstellungsprozesses. Durch die Verknüpfung von Informationen, Teams und Prozessen erhalten Unternehmen diese zusätzliche Ebene der Transparenz, um sich tatsächlich zu Software-First-Unternehmen entwickeln zu können.

* Michael Baldani ist Produktmanager bei CloudBees. Er war in den letzten 20 Jahren in der Vermarktung von Software- und SaaS-Lösungen tätig und unterstützte Kunden bei der Bewältigung der Herausforderungen, die ihnen in ihrer täglichen Arbeit begegnen.

(ID:47386524)