Tools for Software Architects
Domain 6: Tools for software architects
This domain tests tool awareness and selection, not vendor memorization. The exam expects you to know which tool categories support modeling, documentation, decision records, dependency analysis, quality checks, collaboration, and operations, and how to choose them based on stakeholder needs, standards, and lifecycle.
Core rules
- Modeling tools support consistent views, notation, and model exchange; check whether they enforce or merely draw.
- Documentation and wiki tools make architecture accessible; version control and review keep it current.
- ADR tools capture decisions and status; link decisions to requirements and code where possible.
- Static and dependency analysis reveal cycles, layering violations, and coupling trends.
- CI/CD and monitoring tools provide evidence for quality attributes such as deployability and operability.
- Selection criteria include fitness for purpose, interoperability, licensing cost, learning curve, and long-term maintainability.
Worked example
An architect needs to document a distributed system for developers, security, and operations. A drawing-only tool produces attractive but inconsistent diagrams; a model-based UML tool supports defined views but has a steep learning curve. The architect selects a model-based repository for the core architecture, exports views to the wiki, stores ADRs in Git, and uses dependency analysis in CI. Reasoning: each tool serves a distinct communication or governance need, and exchange formats reduce lock-in. The team avoids duplicating the model in three places.
Traps
Letting the tool dictate the architecture is a failure. Do not assume a diagram is a model. Avoid tools that cannot export or integrate, and avoid stale documentation after releases. Do not choose by feature list alone; consider the team's skills and the stakeholders' actual questions.