# sfeir-sdlc-pdlc-articulation-2026-07-22

## Veille

SFEIR-Analyse (Stimme eines Beratungsunternehmens, „die Lesart eines Ingenieurs“), die zwei zu oft vermischte Frameworks artikuliert: den **SDLC** (Software Development Life Cycle — *die Software korrekt und zuverlässig bauen*) und den **PDLC** (Product Development Life Cycle — *das richtige Produkt bauen und am Markt erfolgreich sein*). Zentrale These: Die beiden Zyklen sind keine Konkurrenten, sondern **verschachtelt** — der SDLC ist die Teilmenge des PDLC, **untergebracht in dessen Entwicklungsphase**; wenn ein Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Der SDLC ist standardisiert (**ISO/IEC/IEEE 12207**, Ausgaben 2017 und 2026), mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile 2001**, **DevOps/DevSecOps ab 2009**) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Der PDLC, als übergeordneter Zyklus, reicht von **Ideation/Discovery** bis zum **Marktrückzug** (nicht zu verwechseln mit dem marketingbezogenen **PLC** von Theodore Levitt, 1965, der eine *kommerzielle Kurve* beschreibt, keine *organisierte Arbeit*: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“). **Wendepunkt**: Der SDLC adressiert nativ **nur eines von vier Risiken** — über **Marty Cagans „Four Big Risks“**-Framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business Viability → PM) — eine Organisation, die im SDLC exzellent, aber gegenüber dem PDLC blind ist, produziert „Software, die niemand will“ — John Cutlers **„Feature Factory“** (Erfolg gemessen am Output, nicht am Outcome). **Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains-Daten, Mai 2026: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten, **~41 % des neuen Codes** ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden), sodass sich der **Engpass stromaufwärts verlagert** — die Entscheidung, *was* gebaut werden soll (Marty Cagan, April 2026: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery“). Konsequenzen: DORA 2025 (~5.000 Fachleute, 90 % KI-Adoption) zeigt eine **positive Korrelation mit dem Durchsatz, aber eine negative mit der Stabilität** (mehr unvalidierte Features bedeuten Instabilität und Nacharbeit); Andrew Ng (AI Startup School, Juli 2025) berichtet von Teams, die das **Verhältnis „1 PM auf 4 Ingenieure“ zu „2 PMs auf 1 Ingenieur“ umkehren**; und mit **Spec-driven Development** wird die Grenze zwischen PDLC/SDLC **durchlässig** (die Produktspezifikation wird direkt von Agenten ausführbar). **Was ein CIO mitnehmen sollte**: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal** — die Schnittstelle zum Produkt muss instrumentiert, **ausführbare Spezifikationen** als Input verlangt, technische Metriken mit Outcome-Metriken abgeglichen und die Rolle des „Feature-Lieferanten“ **abgelehnt** werden. Für einen CPO: Die Verlagerung des Engpasses zur Discovery ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) und eine **Handlungsaufforderung** (Discovery industrialisieren, um mit dem SDLC gleichzuziehen). SFEIRs eigenes Framework („Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x**) wird als Antwort auf der Engineering-Seite positioniert, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“

## Titre Article

SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

## Date

2026-07-22

## URL

https://www.sfeir.com/articles/sdlc-vs-pdlc-difference-articulation/

## Keywords

SDLC, Software Development Life Cycle, PDLC, Product Development Life Cycle, Softwarelebenszyklus, Produktlebenszyklus, PLC, Produktlebenszyklus, Theodore Levitt, ISO/IEC/IEEE 12207, 12207, Waterfall, V-Modell, iterativ, spiralförmig, Agile, DevOps, DevSecOps, CI/CD, DORA, DORA-Metriken, Durchsatz, Stabilität, MTTR, Change-Failure-Rate, Lead Time, Velocity, Discovery, Ideation, Product-Market-Fit, Adoption, Retention, NPS, Marty Cagan, Four Big Risks, vier Hauptrisiken, Value, Usability, Feasibility, Business Viability, Product Manager, CPO, Product Lead, Lead Engineer, Designer, John Cutler, Feature Factory, Output vs. Outcome, Engpass, Engpassverlagerung, stromaufwärts, was gebaut werden soll, Auslieferungskosten, generative KI, Coding-Agenten, 85 % der Entwickler, 41 % des Codes KI-generiert, Google JetBrains, vibe coding, The New SDLC With Vibe Coding, Andrew Ng, PM-zu-Ingenieur-Verhältnis, 2 PMs pro Ingenieur, Spec-driven Development, ausführbare Spezifikation, PDLC-SDLC-Durchlässigkeit, durchlässige Grenze, CIO, CIO, Differenzierungsmerkmal, Marktstandard, Produkt-Engineering-Schnittstelle, durchgängige Governance, SFEIR agentisches Framework, 11-Phasen-Zyklus, Software Factory 10x, augmentierter PM, instrumentierte Discovery, agentenbasiertes Prototyping, Verschachtelung der Zyklen, Teilmenge, Produkturteil, Code als Commodity

## Authors

SFEIR (voix éditoriale du cabinet)

## Ton

**Profil**: pädagogisch-strategisches Thought-Leadership-Stück eines Beratungsunternehmens (SFEIR), gerichtet an CIOs, CPOs und technische Führungskräfte. Kanonische Struktur „Begriffsklärung → Verknüpfung → KI-Auswirkung → rollenspezifische Empfehlungen → FAQ“, mit einer **Vergleichstabelle** Dimension für Dimension (Umfang, Zweck, Fragestellung, Akteure, Metriken, Horizont, Risiken) und einem FAQ-Abschnitt, der häufige Verwechslungen klärt („ersetzt der PDLC den SDLC?“, „PDLC vs. PLC?“).

**Stil**: didaktisch und strukturiert — legt zunächst standardisierte Definitionen dar (unter Bezug auf ISO/IEC/IEEE 12207, historische Modelle), stützt sich dann auf anerkannte Autoritäten (Marty Cagan für die Four Big Risks und die Engpassverlagerung, John Cutler für die Feature Factory, Andrew Ng für die Umkehrung des PM/Ingenieur-Verhältnisses, DORA für Stabilitätsdaten). Wiederkehrende **Merksätze**: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“; „der SDLC adressiert nativ nur eines von vier Risiken“; „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“ Unterscheidet **Korrelation von Kausalität** (DORA-2025-Daten: „Korrelationen, keine Kausalität“). Schließt mit einer bewussten **Produktpositionierung** von SFEIRs eigenem Framework (11-Phasen-Zyklus, Software Factory 10x), präsentiert als den bereits gelieferten Baustein, dem nun die Verknüpfung der beiden Zyklen hinzugefügt werden muss.

## Pense-betes

- **Die Unterscheidung in einem Satz.** **SDLC** = „die Software **korrekt und zuverlässig** bauen“ (Frage: *wie ausliefern?*); **PDLC** = „das **richtige** Produkt bauen, am Markt erfolgreich sein“ (Frage: *was bauen, und warum?*). Der SDLC ist eine **Teilmenge** des PDLC, nicht dessen Konkurrent.
- **Verschachtelung, keine Ersetzung.** Der SDLC ist **untergebracht in der Entwicklungsphase** des PDLC. Wenn das Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Direkte Antwort auf die FAQ: „der PDLC ersetzt nicht den SDLC, die beiden sind verschachtelt.“
- **PDLC und PLC nicht verwechseln.** Der **PLC** (Produktlebenszyklus, Theodore Levitt, HBR 1965 — Einführung/Wachstum/Reife/Rückgang) beschreibt eine **kommerzielle Entwicklung**, die das Marketing leitet. Der **PDLC** beschreibt den **Design- und Bauprozess**. Formel: „der PLC beobachtet eine **Kurve**; der PDLC organisiert **Arbeit**.“
- **Der SDLC deckt nur eines von vier Risiken ab.** Über **Marty Cagans „Four Big Risks“**: **Value** (PM — „werden sie kommen, werden sie sich dafür entscheiden?“), **Usability** (Designer — „werden sie wissen, wie man es benutzt?“), **Feasibility** (Lead Engineer — „lässt es sich bauen?“), **Business Viability** (PM — „funktioniert es für das Unternehmen?“). Der SDLC adressiert nativ nur die **technische Machbarkeit**. SDLC-Exzellenz + PDLC-Blindheit = „Software, die niemand will“ = **John Cutlers** **Feature Factory** (Erfolg gemessen am **Output**, nicht am **Outcome**).
- **Warum KI alles verändert: die Kompression des SDLC.** **Google/JetBrains-Daten, Mai 2026**: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten; **~41 % des neuen Codes** ist KI-generiert. Die Implementierung schrumpft von **Wochen auf Stunden** — aber Anforderungen, Architektur und Verifikation bleiben im **menschlichen Tempo**.
- **Der Engpass verlagert sich stromaufwärts.** **Marty Cagan (April 2026)**: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery — die Entscheidung, **was** gebaut werden soll.“ Was knapp wird, ist nicht mehr der Code, sondern das **Produkturteil**.
- **Das DORA-2025-Signal (genau lesen).** Google-Cloud-Umfrage (~5.000 Fachleute, 90 % KI-Adoption): Korrelation **positiv mit dem Auslieferungsdurchsatz**, aber **negativ mit der Stabilität** (Korrelationen, **keine Kausalität**). Interpretation: schneller **unvalidierte Features** auszuliefern erzeugt Instabilität und Nacharbeit — genau das, was PDLC-Disziplin stromaufwärts verhindern soll.
- **Die Umkehrung des Verhältnisses.** **Andrew Ng (AI Startup School, Juli 2025)**: Manche Teams schlagen vor, das historische Verhältnis **„1 PM auf 4 Ingenieure“** je nach Kontext bis zu **„2 PMs auf 1 Ingenieur“** umzukehren. Ein Zeichen dafür, dass sich der Schwerpunkt der Anstrengung zurück zur Produktdefinition verlagert.
- **Die Grenze wird durchlässig.** Mit **Spec-driven Development** fließt das Design-Artefakt des PDLC **direkt** in den SDLC ein: „die Grenze zwischen den beiden Zyklen wird durchlässig.“ Die **Produktspezifikation wird ausführbar** durch Agenten.
- **Was ein CIO anerkennen muss.** Es reicht nicht mehr, nur den SDLC zu optimieren: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal**. Maßnahmen: (1) die **Schnittstelle** zum Produkt instrumentieren; (2) **ausführbare Spezifikationen** als Input verlangen; (3) technische Metriken mit **Outcome**-Metriken **abgleichen**; (4) die Rolle des „Feature-Lieferanten“ **ablehnen**. Benanntes Risiko: ein **handwerklicher PDLC gegenüber einem industrialisierten SDLC** schafft ein „nicht tragbares Ungleichgewicht“.
- **Was ein CPO anerkennen muss.** Die Verlagerung des Engpasses ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) **und** eine Handlungsaufforderung: **Discovery ausstatten** (agentenbasiertes Prototyping, beschleunigte Validierung der vier Risiken), um **Industrialisierungsparität** mit dem SDLC zu erreichen. „Der CPO hält nun den kritischen Pfad des Unternehmens in der Hand.“
- **SFEIRs Eigenpositionierung.** Das Framework „Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x** — klärt die Engineering-Seite; der **nächste Hebel** ist die **Verknüpfung der beiden Zyklen** (augmentierter PM, PDLC/SDLC-Durchlässigkeit, durchgängige Governance). Fazit: „während Code zur **Commodity** wird, verschiebt sich die Marge hin zu **Produkturteil und Governance**.“
- **Verwandt**: Cluster **SDLC / ADLC / agentischer Zyklus** (BMAD-Method agentische-KI-Urbanistik 2026-02-04; The New SDLC With Vibe Coding, Google Mai 2026; SFEIR „Architekt im KI-Zeitalter“ 2026-07-15; SFEIR 11-Phasen-Zyklus); **DORA** (DORA 2026-04-21 ROI/J-Kurve, State of AI-assisted Software Development 2025); **Feature Factory / Output vs. Outcome** (John Cutler); **Spec-driven / Software Factory** (StrongDM Software Factory 2026-02-06; KI-Spec-driven-Ansatz); **KDLC** (Ashish Singh, Knowledge Life Cycle, 28. Juni 2026) und **Compounding Knowledge Lifecycle** (Klaassen 2026-07-02) als benachbarte Lebenszyklus-Frameworks.

## RésuméDe400mots

SFEIR klärt zwei häufig vermischte Frameworks. Der **SDLC** (Software Development Life Cycle), standardisiert durch **ISO/IEC/IEEE 12207** (2017, 2026), strukturiert die **Softwareproduktion** — Anforderungserhebung, Design, Entwicklung, Test/QA, Deployment, Wartung — mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile** 2001, **DevOps/DevSecOps** ab 2009) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Sein Zweck: „die Software **korrekt und zuverlässig** bauen“. Der **PDLC** (Product Development Life Cycle) ist der **übergeordnete Zyklus**: von Ideation/Discovery bis zum Marktrückzug zielt er darauf ab, „das **richtige** Produkt zu bauen“. Nicht zu verwechseln mit Theodore Levitts **PLC** (1965), der eine **kommerzielle Kurve** beschreibt; „der PLC beobachtet eine Kurve, der PDLC organisiert Arbeit“.

**Verknüpfung**: Die Zyklen sind **verschachtelt** — der SDLC ist die Teilmenge des PDLC, untergebracht in dessen **Entwicklungsphase**. Kritischer Punkt über **Marty Cagans „Four Big Risks“** (Value, Usability, Feasibility, Business Viability): Der SDLC adressiert nativ nur die **technische Machbarkeit** — „eines von vier Risiken“. Eine Organisation, die im SDLC stark, aber gegenüber dem PDLC blind ist, wird zu **John Cutlers** **„Feature Factory“**, die Erfolg am **Output** statt am **Outcome** misst.

**Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains, Mai 2026: **~85 %** der Entwickler nutzen Coding-Agenten, **~41 %** des neuen Codes ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden). Der **Engpass verlagert sich stromaufwärts** — die Entscheidung, *was* gebaut werden soll (**Cagan**, April 2026). Drei Konsequenzen: **DORA 2025** (~5.000 Fachleute, 90 % Adoption) zeigt eine Korrelation, die **positiv mit dem Durchsatz, aber negativ mit der Stabilität** ist (Korrelationen, keine Kausalität) — mehr unvalidierte Features, mehr Nacharbeit; **Andrew Ng** (Juli 2025) berichtet von der Umkehrung des Verhältnisses **„1 PM / 4 Ingenieure“ zu „2 PMs / 1 Ingenieur“**; und **Spec-driven Development** macht die **Grenze zwischen PDLC/SDLC durchlässig** (die Spezifikation wird von Agenten ausführbar).

**Empfehlungen.** Für den **CIO**: Ein augmentierter SDLC ist inzwischen ein **Marktstandard, kein Differenzierungsmerkmal** — die Schnittstelle zum Produkt instrumentieren, **ausführbare Spezifikationen** verlangen, technische mit Outcome-Metriken abgleichen, die Rolle des „Feature-Lieferanten“ ablehnen; ein handwerklicher PDLC gegenüber einem industrialisierten SDLC bedeutet ein „nicht tragbares Ungleichgewicht“. Für den **CPO**: sowohl eine Aufwertung **als auch** eine Handlungsaufforderung — **Discovery ausstatten**, um mit der Industrialisierung gleichzuziehen. SFEIR positioniert sein eigenes Framework (**11-Phasen-Zyklus** + **Software Factory 10x**) als Antwort auf der Engineering-Seite, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“

## GrapheDeConnaissance

- SDLC —fait_partie_de→ PDLC (METHODOLOGIE, 0.95)
- SDLC —est_instance_de→ ISO/IEC/IEEE 12207 (DOCUMENT, 0.9)
- PDLC —s_oppose_à→ PLC (product life cycle, Theodore Levitt 1965) : le PLC observe une courbe commerciale, le PDLC organise un travail de conception (AFFIRMATION, 0.85)
- SDLC —affirme_que→ le SDLC ne traite nativement qu'un risque sur quatre (la faisabilité technique) parmi les Four Big Risks de Cagan (AFFIRMATION, 0.9)
- Marty Cagan —a_créé→ Four Big Risks (CONCEPT, 0.92)
- Four Big Risks —s_applique_à→ répartition des responsabilités produit : Valeur/Viabilité (PM), Utilisabilité (Designer), Faisabilité (Lead Engineer) (AFFIRMATION, 0.9)
- John Cutler —a_créé→ feature factory (CONCEPT, 0.9)
- feature factory —observé_dans→ organisations fortes en SDLC mais aveugles au PDLC, qui mesurent le succès à l'output plutôt qu'à l'outcome (AFFIRMATION, 0.88)
- IA générative —réduit→ le coût et la durée du SDLC : implémentation de semaines à heures (AFFIRMATION, 0.9)
- Google JetBrains —mesure→ ~85 % des développeurs utilisent régulièrement des agents de code et ~41 % du nouveau code est généré par IA (mai 2026) (MESURE, 0.9)
- Marty Cagan —affirme_que→ quand le coût du delivery s'effondre, le goulot d'étranglement se déplace vers l'amont : décider quoi construire (avril 2026) (AFFIRMATION, 0.92)
- Rapport DORA 2025 —mesure→ adoption IA à 90 % corrélée positivement au débit de livraison mais négativement à la stabilité (corrélations, non causalités) (MESURE, 0.88)
- Andrew Ng —affirme_que→ certaines équipes proposent d'inverser le ratio historique de 1 PM pour 4 ingénieurs jusqu'à 2 PM par ingénieur (juil. 2025) (AFFIRMATION, 0.85)
- approche spec-driven —permet→ rendre poreuse la frontière PDLC/SDLC : la spécification produit devient directement exécutable par des agents (AFFIRMATION, 0.85)
- SFEIR —recommande→ une DSI doit instrumenter la jonction produit, exiger des spécifications exécutables et refuser le rôle de fournisseur de features (AFFIRMATION, 0.88)
- SFEIR —affirme_que→ à mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance (AFFIRMATION, 0.9)
- cycle SFEIR à 11 phases —résout→ le versant ingénierie (SDLC augmenté) ; le levier suivant est l'articulation SDLC/PDLC (AFFIRMATION, 0.82)

---
Canonical: https://www.thekb.eu/de/fiches/sfeir-sdlc-pdlc-articulation-2026-07-22/