How to Manage Software Architecture with SonarQube | Sonar Summit 2026

Olivier Gdan, co-founder of Sonar, introduced a newly released architecture management capability for SonarQube at Sonar Summit 2026. While SonarQube has historically focused on managing technical debt at the code level—addressing maintainability, reliability, and security—the organization recognized a critical gap: structural debt. This type of debt relates to how software applications are organized, what abstractions they use, and whether components maintain single responsibility principles. When structural debt accumulates, organizations experience painful symptoms including engineer attrition, cascading side effects from even minor changes, and declining development velocity. The problem develops gradually and insidiously, beginning with well-organized architecture that erodes through accumulated shortcuts and expedient development decisions until remediation requires major refactoring.

The Three-Pillar Architecture Framework

SonarQube's new architecture management solution rests on three fundamental concepts. First is the current architecture—the actual, reverse-engineered structure of an application computed at each code analysis. This provides a live map of how components are currently organized and related. Second is the intended architecture, representing the target structure that teams aspire to achieve, whether that reflects initial design goals or evolved objectives. Third are deviations, the critical gaps between current and intended architectures that form the foundation for remediation efforts. This framework enables teams to understand not just what their application looks like, but whether it aligns with strategic architectural goals.

A Philosophy Centered on Team Understanding and Actionability

The SonarQube architecture capability prioritizes teams over specialists, recognizing that while architects play a role, successful architecture management requires organization-wide comprehension and stakeholder engagement. The solution builds on four operational pillars: enabling everyone—human and AI agents alike—to understand current architecture through accessible live documentation; formalizing intended architecture in ways that are simple to understand, define, and incrementally improve; implementing intelligent issue prioritization that reports structural problems once rather than cascading their consequences; and leveraging SonarQube's existing ecosystem of workflows, quality gates, and in-code issue visualization to make remediation deeply actionable.

Discovering and Controlling Architecture

Current architecture exploration allows teams to zoom from top-level views through detailed component relationships, examining coupling complexity and identifying critical components whose modification carries significant organizational risk. Rather than attempting to control entire applications at once, the intended architecture concept focuses on selectively defining what matters most—starting from top-level components and progressively formalizing critical relationships. This incremental, focused approach avoids the trap of maintaining documentation that requires constant updates alongside every application change. Instead, teams deliberately choose which architectural elements demand governance, making their architecture management sustainable and relevant.

Key Takeaways

• Structural debt is a distinct, erosive problem that manifests gradually through architectural degradation and cannot be addressed through code-level quality tools alone
• The SonarQube architecture capability uses three concepts—current architecture (reverse-engineered reality), intended architecture (strategic goals), and deviations (gaps requiring remediation)—to enable systematic architecture management
• Architecture management is a team responsibility, not confined to architects, requiring accessible visualization and understanding across the organization
• Intelligent prioritization and actionable workflows integrate architecture governance into existing SonarQube processes, making structural remediation practical rather than aspirational
• Incremental, focused control works better than comprehensive mapping—teams should prioritize governing critical architectural relationships rather than documenting entire applications