Der Cloud-native Product Owner

Wer von Euch arbeitet agil?

Wer trifft in der agilen Arbeit die technischen Entscheidungen?

Wer hat den Hoster ausgesucht?

Wer hat über Programmiersprache und Datenbank entschieden?

Wer trifft die Make or Buy Entscheidungen?

Wer arbeitet Cloud-basiert?

Beyond Budgeting

Von CapEx zu OpEx

Vor Cloud: Capital Expenditures

  • Ich bezahle alles, was wir mal brauchen könnten
    • Overbuying ist builtin
      "Weihnachtsgeschäft mit Buffer"
       
  • Ich bezahle die Beschaffung und Einrichtung von 
    • Hardware, Infrastruktur, Environments
    • Wartung, Maintenance, Änderungen

Cloud: Operational Expenditures

  • Ich bezahle nur das, was ich gerade nutze
    • Pay as You Go
  • Flexibel und direkt anpassbar
  • Finanzielle Entwicklung nicht vorhersehbar

Cloud Native

Budgets sind
nicht mehr eh-da.

Wenn die Kosten abhängig von Nutzung sind, sollte ich dann noch in Budgets und Investments denken?

Die Architektur ist
nicht mehr eh-da.

  • Technologieentscheidungen werden on Demand getroffen 
  • Das gilt für Einführung, Beendigung, Wechsel von Technologien

"Die Applikation" ist
nicht mehr eh-da.

  • Dank SAAS, Lambda und MicroServices
    Verteilung     bis auf Featureebene hinunter

Die Grenze meiner Software
ist nicht mehr eh-da.

  • Alles ist integrierbar
     
  • Wir sind immer online
  • Alles ist eine API
  • Dank SDK und DevEx: Integration geht schnell

Non-Funktionale Capabilities
sind jetzt eh-da.

  • Früher teuer, jetzt mit in der Tüte:
    Skalieren, Security, Ausfallsicherheit, Backup uvm.

Wie arbeite ich Faktor 10 schneller?

Ich lasse 90% der Arbeit weg.

Was soll ich denn alles weglassen?

Core Domain

  • Der Kern Eures Geschäftes
  • Das Differenzierungsmerkmal
  • Flexibilität und Adaption gewinnt
  • Macht Entwicklern wenig Spaß & hat die höchste Prio

Supporting Domain

  • Unterstützt die Core-Domain
  • Kann spezifische aberunkritische Lösungen enthalten
  • Reduziert die Komplexität der Core-Domain
  • Kann flexible Off-The-Shelf-Lösungen sein

General Domain

  • Allgemeine Lösungen, die viele brauchen
  • Standardisier- und wiederverwendbar
  • Eher Pflichtübung als Kür
  • Entwickler mögen es, hat aber keine Prio

Welche Domains sollte ich selbst machen, welche nicht?

Core Domain
Supporting Domain
General Domain

Welche Domains sollte ich selbst machen, welche nicht?

Core Domain Eigene Software
Supporting Domain Services, SAAS
General Domain SAAS

Wenn ich kein Hoster bin
ist Hosting nicht meine
Core-Domain

Was bedeutet das für mich als Product Owner?

Lohnt sich das Feature?

Wenn ja: auf welcher Plattform am meisten?

Kosten pro Feature

On Premises Cloud/Container SAAS/Service
Initiale Entwicklungskosten Hoch Hoch Niedrig
Maintenance Hoch Mittel Niedrig
Operative Kosten Niedrig Niedrig Hoch

Kosten pro Feature

Blech Cloud/Container SAAS/Service
Opportunitätskosten für Leerlauf Hoch Niedrig Niedrig
Cost of Delay Hoch Niedrig Niedrig
Skalieren Hoch Niedrig Niedrig
Feature weider entfernen Hoch Niedrig Niedrig

Software LifeCycle Costs

Woher kommen die
Maintenance-Kosten?

Case:  Wir brauchen ein
User-Management - Optionen

  • Selbstgebaut?
  • Authentik als Container?
  • Cognito auf AWS?
  • Auth0 als Service?

Case:  Wir brauchen ein
User-Management - Faktoren

  • Entwicklungskosten
  • Anpassbarkeit / Core, Supporting, Generic?
  • Betriebskosten pro Jahr
  • Skalierbarkeit
  • Security
  • Cost of Delay

Wen muss ich dafür fragen?
Wer kennt den Bedarf?
Wer kennt das Gewicht?

  • Entwicklungskosten
  • Anpassbarkeit / Core, Supporting, Generic
  • Betriebskosten pro Jahr
  • Skalierbarkeit
  • Security: 
  • Cost of Delay

Wer kann beurteilen, wie gut die Optionen darin sind?

  • Entwicklungskosten
  • Anpassbarkeit / Core, Supporting, Generic
  • Betriebskosten pro Jahr
  • Skalierbarkeit
  • Security: 
  • Cost of Delay
  • Selbstgebaut?
  • Authentik als Container?
  • Cognito auf AWS?
  • Auth0 als Service?

Wer hat die Verantwortung, dass Value/TCO stimmen?

Gewichtete Trade-Off-Analyse

Faktor Gewicht
Initiale Kosten Development 3
Anpassbarkeit 1
Betriebskosten bei 5000 Nutzern/Jahr 2
Betrieb bei 500.000 Nutzern/Jahr 1
Skalierbarkeit 2
Security 2
Cost of Delay 2

PO-Aufgabe: Welche Faktoren mit  welches Gewicht

Bei eh-da war das noch CTO/Architektur

Faktor Gewicht Selbstgebaut Authentik Cognito Auth0
Initiale Kosten Development 3 -1 0 0 1
Anpassbarkeit 1 2 1 1 1
Betriebskosten bei 5000 Nutzern/Jahr 2 -2 -1 1 1
Betrieb bei 500.000 Nutzern/Jahr 1 0 1 -1 -2
Skalierbarkeit 2 -2 -1 2 2
Security 2 -1 0 1 1
Cost of Delay 2 -2 -1 2 2

Team-Aufgabe: wie gut ist welche Option geeignet?

Faktor Gewicht Selbstgebaut Authentik Cognito Auth0
Initiale Kosten Development 3 -1 0 0 1
Anpassbarkeit 1 2 1 1 1
Betriebskosten bei 5000 Nutzern/Jahr 2 -2 -1 1 1
Betrieb bei 500.000 Nutzern/Jahr 1 0 1 -1 -2
Skalierbarkeit 2 -2 -1 2 2
Security 2 -1 0 1 1
Cost of Delay 2 -2 -1 2 2
Bewertung  -15 -4 10 14

Resultierende Empfehlung

  • Auth0, weil Initialkosten, Skalierbarkeit und Time2Market
  • Wird aber richtig teuer, wenn da viele Kunden sind
     
  • Team: hätte es lieber selbst gebaut
  • SystemEngineer: hätte lieber Authentik selbst betreut
  • ProductOwner: hätte lieber eigene Lösung mit Time2Market und Initialkosten von Auth0
  • Scrum-Master: hätte lieber eine Lösung, die alle gut finden.

Fazit für Cloud Native
Product Owner
 

Business Agility gibt es nur, wenn der PO und das Team sie machen darf.

Fazit für Cloud Native
Product Owner
 

Nonfunktionale Anforderungen und Optionen verstehen und nutzen.

Fazit für Cloud Native
Product Owner
 

Architekturentscheidungen explizit und auf Basis von Businessvalue gemeinsam fällen.

Fazit für Cloud Native
Product Owner
 

FinOps etablieren und als Ticket-Quelle nutzen

Fazit für Cloud Native
Product Owner
 

Support für diese Themen bekommen, per Triade, Architekturgilde ...

Der PO und das Team können den Value wirklich steuern. Wenn sie Macht und Support bekommen.