Nilsson ends up arguing that long-successful companies sitting on neglected software need architecture driven by business decisions: map what is in production, define "legacy" as scheduled for removal, dig into each kept application with evidence before interviews, and pay down whichever kind of debt matters now.
What an architect does. Once a dream job, he now sees architecture as working within reductions set by the business, such as customer satisfaction, mergers and acquisitions, and budget and time. Quality attributes follow from the question "why": a firm growing by acquisition needs extensible APIs to integrate the software it buys.
The portfolio. At Microsoft he met companies with 25–30 years of applications, some without source code. Expensive portfolio suites disappointed him; Excel, with Entra ID-backed owner drop-downs and full running cost including support staff, does the job. The aim is a decision about each application.
Legacy and life cycles. "Legacy" carries no information, like his late-evening conference bit about local beer, so he requires a deletion date for anything called that, and tags each app retire, maintain, modernize or improve, plus how strategic it is.
The dig. "Software archaeology" partly sounds good for conferences, he admits, but it fits: deciding what to dig up. His template covers release dates, source location, hosting, dependencies, logging, documentation and knowledge gaps, ending in a recommendation. Server evidence comes first because it jogs memories. Limits such as a $1 million ceiling or a realistic uptime target shape the answer; he mocks claims of five nines from one basement server.
Handing it to developers. C4 diagrams as code, retroactive ADRs, and a census of technical, documentation, knowledge, security and operational debt. His blog is carl-henrik.se.