SFEIR analysis (consulting-firm voice, "an engineer's reading") articulating two frameworks too often conflated: the **SDLC** (Software Development Life Cycle — *building the software correctly and reliably*) and the **PDLC** (Product Development Life Cycle — *building the right product and succeeding in the market*). Central thesis: the two cycles are not competitors but **nested** — the SDLC is the subset of the PDLC **housed under its development phase**; when a product team reaches the "build" stage, a full SDLC cycle (design → build → test → review → deployment) runs inside it. The SDLC is standardized (**ISO/IEC/IEEE 12207**, 2017 and 2026 editions), with its lineage of models (Waterfall 1970, V-model, iterative/spiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) and its **DORA** metrics (throughput, stability, MTTR, change failure rate). The PDLC, being the umbrella cycle, runs from **ideation/discovery** to **market withdrawal** (not to be confused with the marketing **PLC** of Theodore Levitt, 1965, which describes a *commercial curve*, not *organized work*: "the PLC observes a curve; the PDLC organizes work"). **Tipping point**: the SDLC natively addresses **only one risk in four** — via **Marty Cagan's "Four Big Risks"** framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business viability → PM) — an organization excellent at SDLC but blind to PDLC produces "software nobody wants" — John Cutler's **"feature factory"** (success measured by output, not outcome). **Why AI changes everything**: generative AI **compresses the SDLC** (Google/JetBrains data, May 2026: **~85% of developers** regularly use coding agents, **~41% of new code** is AI-generated; implementation goes from weeks to hours), so the **bottleneck shifts upstream** — deciding *what* to build (Marty Cagan, April 2026: "when the cost of delivery collapses, the bottleneck shifts to discovery"). Consequences: DORA 2025 (~5,000 professionals, 90% AI adoption) shows a **positive correlation with throughput but a negative one with stability** (more unvalidated features means instability and rework); Andrew Ng (AI Startup School, July 2025) reports teams **reversing the "1 PM for 4 engineers" ratio to "2 PMs for 1 engineer"**; and with **spec-driven development**, the PDLC/SDLC boundary becomes **porous** (the product spec becomes directly executable by agents). **What a CIO should take away**: an augmented SDLC becomes a **market standard, not a differentiator** — the junction with the product must be instrumented, **executable specifications** demanded as input, technical metrics cross-referenced with outcome metrics, and the role of "feature supplier" **refused**. For a CPO: the shift of the bottleneck toward discovery is both a **promotion** (product judgment becomes scarce again) and a **notice to act** (industrialize discovery to reach parity with the SDLC). SFEIR's in-house framework ("Designing and building in the agentic era" — **11-phase cycle** + **Software Factory 10x**) is positioned as the answer on the engineering side, with the **articulation of the two cycles** as the next lever. Conclusion: "as code becomes a commodity, margin shifts toward product judgment and governance."
Netflix — Q2 FY2026 shareholder letter: GenAI scales up in production (≈300 titles in 2026), LLMs for discovery and natural-language search, AI tools across the entire advertising cycle (Netflix)
Primary-source tech-watch digest on the position of **Gregor Hohpe** (author of *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; former AWS & Google Cloud Enterprise Strategist, former Chief Architect at Allianz) regarding the role of the architect in the era of generative AI. Thesis: AI **does not devalue** the architect, it **shifts their value** from code to what AI does not do — **making and owning decisions, arbitrating trade-offs, "selling options," communicating with humans, producing sound abstractions**. Key formula (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". His signature thesis (the architect should not be the smartest person in the room, they should **make everyone else smarter**) grows stronger as code becomes abundant: the advantage comes from **decision discipline** and **surfacing hidden trade-offs**, not from volume. The digest also breaks down his positions by role (enterprise architect: from **cartographer to scout**; software architect: **debugging** decisions rather than writing code; platform architect: **abstractions, not illusions**), his **real options** metaphor (value increasing with technological volatility, Black-Scholes analogy), and his warnings ("*An AI-driven SDLC punishes bad habits much faster*"; the winners of AI will be defined by how fast they move from experimentation to **governed production**). ⚠️ The widely circulated formula "architects who use AI will replace those who don't" **is not from Hohpe**. Domain: software architecture, the architect's role, decision-making, real options, platforms, GenAI in the SDLC.
#Gregor Hohpe#Architect Elevator#role of the architect
Gregor Hohpe (sources primaires) — digest de veille
SFEIR analysis note that reexamines the software architect profession in the age of generative AI through the framework of **Gregor Hohpe** (*The Software Architect Elevator*). Central thesis: the « **Oracle** » architect — the holder of supreme knowledge dictating rules from an ivory tower — is obsolete, since AI generates code and proposals on demand; the modern architect becomes an **intelligence amplifier (IQ Amplifier)** who provides teams with mental models, business context, and decision tools to leverage AI while ensuring system coherence. The document breaks down the impact **floor by floor of the "Architect Elevator"** (Enterprise / Solution / Platform / Software architect) and argues for **Domain-Driven Design (DDD)** as an essential safeguard: the **ubiquitous language** serves as the basis for *system prompts* (a domain dictionary injected via `.clinerules`/templates, reducing hallucinations and business misinterpretations) and **bounded contexts** restrict the scope entrusted to AI to maximize generation reliability. Conclusion: AI is not a threat but a catalyst that relieves the architect of technical grunt work to emphasize synthesis, strategic vision, modeling, and the human link between tech and business. Domain: software architecture, the architect's role, DDD, structured prompting, enterprise AI governance.
#Software architect#architect's role#generative AI
LinkedIn post by Fred Plais (CEO of Archie, ex-Platform.sh): AI made engineers so fast that the **bottleneck moved upstream**, to a place nobody is watching. With execution no longer the slow part, the thinking time that used to exist "while the code was being built" has vanished — the right vision now has to be formed and the right decisions made in a fraction of the time. Two rare profiles are emerging: the one who can **articulate a vision precise enough** for an agent to execute without derailing, and the one who knows how to **orchestrate agents** (anticipating their failures, chaining them, catching an error before it propagates). Hiring for "code output" is becoming obsolete: that is precisely what has stopped being rare. Final thesis: "thinking clearly was always the job — speed just made it impossible to fake".
Episode #351 of the French-language podcast **If This Then Dev** (Bruno) with **Julien Lépine**, Chief Technology Officer of **AWS France** (13 years at Amazon), recorded on the sidelines of the **AWS Summit Paris** (April 1, 2026, ~10,000 attendees). Pivot thesis: in the agentic era, writing code becomes secondary, and value shifts toward **understanding context, architectural trade-offs, and human accountability**. Central proof point: the **redevelopment of Amazon Bedrock** — a critical platform handling thousands of billions of requests — by a team of **6 people in 72 days** (vs. an estimated 30 people / 18 months), **code entirely generated by AI**, without vibe coding. AWS is **standardizing internally on Kiro** (IDE + CLI, running on Claude Sonnet/Opus) for ~30,000 developers (announced by Matt Garman at re:Invent). Throughline: **keeping control** without reviewing everything — via **formal modeling (TLA+)** and **Raisonnement automatisé** to prove invariants and bound agents, **blameless post-mortem**, and the principle that "responsibility for an agent's action rests with the person operating it." Emergence of the **AI DLC** (sprints → multiple daily **Bolts**) and the risk of **cognitive overload / burn-out**.
#AWS Summit Paris#Amazon Web Services#code agents
**Julien Lépine** — Directeur de la technologie (CTO) d'Amazon Web Services France · 13+ ans chez Amazon ; ses équipes accompagnent les clients AWS sur le cloud · la data et l'IA. **Hôte** : Bruno (créateur et animateur du podcast *If This Then Dev*).
Op-ed by **Olivier Rafal** (Consulting Director Strategy at **WeNvision**) published on **February 23, 2024** on **CIO-Online** (*Tribune* section), advancing a thesis still counter-intuitive at the time: **generative AI is more a matter of technology product than an AI/data science project**. **Argument 1 — data science is not the core issue**: building a *foundation model* from scratch requires *« several months, millions of euros, and access to enormous quantities of data »* — reserved for players with specific, monetizable datasets (e.g. **Bloomberg** and its **BloombergGPT** for finance). For nearly all companies, the right reflex is therefore not to hire data scientists. **Argument 2 — skills mismatch**: what is mainly needed is **development and integration engineers** (back/front), **strong cloud skills**, and **DevOps**. Client quote: *« You don't necessarily need to be a data scientist, but you need to understand the basic concepts, have back-office development skills, and strong cloud skills. »* **Argument 3 — platform architecture (orchestrators + APIs)**: building an enterprise **plateforme d'IA générative** via orchestrators and APIs makes it *« possible to work with the best LLMs on the market and switch between them as their respective capabilities evolve, without reworking the applications »* (anti vendor lock-in). **Argument 4 — from project to product**: *« The platform […] must be regarded as a product in its own right »*; instead of a one-off investment, plan for a **monthly funding stream** (continuous iteration, ongoing innovation). **Argument 5 — governance & shadow AI**: the unprecedented democratization of GenAI generates *« as much shadow AI as strong expectations toward the CIO office »* → governance to capture business needs, **prioritize products by value**, and oversee proper operation. **Paradigm shift** announced: *« the shift is from classic algorithmic programming to agents Langchain that handle part of the decisions »*. **Relevance to the watch**: a **founding text (2 years ahead)** of WeNvision's doctrine (product > project, platform/API, flow-based funding, governance, shadow AI), later extended by [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]], and rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/token, flow-based funding → financial governance). It also foreshadows the *harness/platform around the model* (Dropbox/Okumura: *systems around the model*) and **model independence** achieved through an orchestration layer.
#generative AI#technology product#product vs project
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (cabinet de conseil FR). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Auteur déjà présent dans la veille (cf. fiches WeNvision/Atlas/Tokenomics). Publié le **23 février 2024**.