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"
- Overbuying ist builtin
- 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.
Der Cloud-native Product Owner
By Johann-Peter Hartmann
Der Cloud-native Product Owner
Die Kostenstruktur von modernen Architekturen ist eine völlig andere als bei klassischen Applikationen. Wo früher die Infrastruktur im Rahmen eines großen Budgets "eh da" war, entsteht sie heute Sprint für Sprint, und das Team selbst entscheidet mit der Entscheidung über Cloudinfrastruktur und eingebundenen Services, wie viele Stellen die Betriebskosten haben. Damit wird einer der größten Kostenfaktor in der IT zum Spielball der Teams, und der im Team generierbare Wert für den Kunden ist unmittelbar betroffen. Wie gehe ich als PO damit um? Wie bilde ich diese operativen Kosten in meine Priorisierung ab, und wie komme ich überhaupt an die nötige Information?
