Topic starter
12/06/2026 9:12 pm
TL;DR: Software architects are described as business-technical leaders who align long-term technology choices with organisational continuity, balancing risk, cost, delivery, and stakeholder trust rather than simply writing specs, according to Cerbos. The role matters because architecture decisions shape incident rates, compliance, delivery, integration, and total cost of ownership across complex systems.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Practices that set great software architects apart”.
Key questions
Q: How should organisations define the software architect role in practice?
A: They should define it as a governance and decision-making role, not a spec-writing function.
Q: What should teams do when architectural standards slow delivery?
A: First, check whether the standards are too complex, poorly explained, or misaligned with how teams actually work.
Q: How do you know whether architecture governance is working?
A: Look for lower incident severity, better compliance, smoother integrations, and more predictable delivery against commitments.
Practitioner guidance
- Define architecture as a governance role Clarify that architects own decision quality, trade-off framing, and alignment across business and technical stakeholders, not just solution diagrams.
- Use decision records for material choices Capture major architecture decisions in ADRs so risk, cost, and rationale stay visible when teams change or projects evolve.
- Measure architecture with outcome metrics Track incident severity, delivery performance, compliance rates, integration success, and total cost of ownership to judge whether governance is working.
Bottom line: The article reframes software architecture as a governance discipline that links technical choices to business continuity.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
12/06/2026 11:06 pm
Software architecture is a governance function, not a specification function. The article’s core argument is that architects exist to reconcile business continuity, technical constraints, and operational risk. That is governance in practice, because the role sets decision boundaries rather than merely producing diagrams or ticket-level requirements. For identity teams, the parallel is obvious: standards only matter when they shape decisions about access, control, and accountability.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
A: Current architecture is the live picture of how code is actually structured and connected. Intended architecture is the policy layer that defines which components may exist, where they belong, and what dependencies are permitted. Comparing the two reveals deviations, which can then be tracked as governance issues and remediated through normal delivery workflows.
👉 Read our full editorial: Software architecture is really about governance, not specs
This post was modified 7 days ago by NHI Mgmt Group