Risk and Cost Driven Architecture (RCDA)
Risk and Cost Driven Architecture (RCDA), developed by Eltjo Poort at CGI, is a pragmatic framework for enterprise and software architecture that frames every significant decision as a trade-off between risk reduction and cost. Architecture stops being a documentation exercise and becomes a continuous negotiation: which decisions warrant investment now because deferring them is expensive, and which can wait because the cost of being wrong is bounded.
The framework matters because most architectural discussions confuse activity with progress. Diagrams accumulate, ADRs get written, technology choices are debated — and meanwhile the system grows in directions nobody owns. RCDA asks a sharper question: what is the risk we are buying down, what does it cost, and is that ratio defensible against the alternatives?
The articles in this collection apply RCDA thinking to concrete situations. Technical debt is treated as a financial instrument with interest payments rather than a vague quality complaint — small shortcuts compound into dominant cost drivers three years in, and the metaphor of “forgotten pennies and lost dollars” captures the mechanism precisely. Visibility comes first: analyzers, code metrics, and Azure DevOps dashboards illuminate debt that would otherwise stay hidden in the codebase until it forces a rewrite.
A second cluster addresses retiring legacy .NET projects, where the question is no longer “how do we keep this running” but “what is the cheapest path to forward motion”. Modular extraction, strangler patterns, and risk-weighted prioritization replace the all-or-nothing rewrite that usually fails. Cost-driven decisions name the constraint explicitly rather than hiding it behind technical preference.
The voice across these articles avoids architecture astronautics. Decisions are documented, justified by risk and cost, and revisited when circumstances change. That discipline is what separates RCDA from the framework-of-the-month cycle that surrounds it.

Retiring Legacy .NET
In every mature .NET landscape, legacy projects represent both heritage and hazard. They once powered entire business models — now they silently consume time, budget, and attention. The decision to retire or modernize them isn’t about technology fashion. It’s about sustaining the organization’s capacity for value creation.

TUnit — A Pragmatic Evaluation for .NET Teams

Instruction by Design: Transforming ADRs into Actionable AI Guidance

A Tale of Forgotten Pennies and Lost Dollars
In software development, there’s a silent debt that accrues interest over time, often hidden beneath layers of code and decisions made in haste or ignorance. This debt is aptly termed technical debt. Much like the german proverb, “Wer den Pfennig nicht ehrt, ist den Taler nicht wert”, (or the english equivalent, “A penny saved is a penny earned”) technical debt reminds us that small oversights or compromises in the present can snowball into significant challenges down the road. This article critically examines the parallels between financial principles and technical debt, emphasizing the importance of addressing both direct and indirect debt while understanding its distinction from external risks such as hacking or abuse.

Illuminate Technical Debt
Whatever our role, be it developer, IT professional or architect, we try to avoid technical debt. If this is not possible from the outset, or if we decide to accept this technical debt for a limited period of time, we usually lack the tools to do so. This is where this article may help.