Hello community,
Architecture analysis is now available in SonarQube Server, in all commercial editions at no additional cost, starting with 2026.4.
For a higher level introduction to architecture in SonarQube, see the original blog post announcement.
Continue reading to find out what’s new.
Current architecture
SonarQube extracts a dependency graph from your source code and renders it as an interactive visualization. No manual steps and no configuration needed. The graph updates on every analysis, so it reflects the code as it is.
This is a map of your codebase, where you can figure out how the project holds together:
- Classes/files are recursively grouped within their packages/folders/modules
- The component’s size and position represent the organization of the project
- Components are ordered left to right according to their relationships
You can open it from the navigation menu in any project.
Intended architecture
From the intended architecture view, you define what the structure should look like: which components may depend on which. This is incremental. You can define the top level first, then add detail where it matters later.
To avoid starting from zero, use “Generate draft” to bootstrap a starting point from your top-level component structure and relationships, then refine from there.
You can also specify interface design. For any component, you mark which children are accessible from outside. Code that reaches into a non-accessible child produces a deviation. This works at every level of the hierarchy and across all supported languages.
To edit the intended architecture you need the “Administer architecture” permission on the project. There is no special permission to view it.
Deviations, issues, and quality gates
Once you have an intended architecture, SonarQube detects deviations on every analysis. Deviations come in two forms: structural (something in the wrong location) and relational (a relationship that should not exist). Each produces code issues with exact source locations.
Architecture issues appear in the standard issue list and in PRs alongside regular code quality issues. You triage them the same way. Architecture deviation rules are included in the Sonar Way profile, so enforcement is active once you define an intended architecture. Because the issues are standard Sonar issues, they work with quality gate conditions.
Flaws and smells
The analysis also detects structural problems independent of any intended architecture. Tangles are groups of files caught in overlapping cyclic dependencies. Oversize flags components that have grown large relative to others. Weak Tangles and Split Responsibilities appear under Smells. These run on every analysis with no configuration.
Availability
All commercial editions of SonarQube Server 2026.4. Architecture is not included in Community Build. Supported languages: Java, C#, JavaScript, TypeScript, Python.
The architecture resource center has videos and blog posts with more detail.
Feel free to share questions and feedback in this thread.