Notifications
Clear all
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.
NHIMG editorial — based on content published by Cerbos: what software architects actually do and the traits that make the role work
Questions worth separating out
Q: How should teams make architecture decisions that survive business change?
A: They should treat architecture as a living governance process, not a one-time design artifact.
Q: Why do architecture standards often fail in practice?
A: They fail when they are too complex, poorly communicated, or detached from how teams actually work.
Q: How do you know if architecture is reducing operational risk?
A: Look at measurable outcomes such as incident severity, incident duration, compliance rates, delivery predictability, and integration success.
Practitioner guidance
- Tie architecture reviews to operating outcomes Use incident trends, compliance findings, delivery slips, and integration failures as the review inputs, not just design diagrams or approval forms.
- Define acceptable risk in business terms Document which risks the organisation will absorb, which require redesign, and which are non-negotiable.
- Measure control usability, not just control presence Track whether security and architecture standards are being followed, where teams work around them, and whether the guidance creates friction that leads to exceptions.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- The day-to-day responsibilities that sit behind the software architect role across business, leadership, and technical domains.
- The article's practical examples of how architects balance risk, cost, and delivery pressure when competing stakeholders disagree.
- The article's breakdown of success metrics such as incident management, compliance rates, tech debt, and integration success.
- The author's personal perspective on what separates helpful architects from the ones developers avoid.
👉 Read Cerbos' analysis of what software architects actually do →
Software architecture and governance: what makes the role work?
Explore further
12/06/2026 11:06 pm
Software architecture is an identity governance problem before it is a technical one. The article’s central claim is that architecture exists to keep technology aligned to long-term organisational success, which is the same logic that underpins mature IAM and NHI governance. When decision-making, risk acceptance, and enforcement are separated, the result is not just bad design but ungoverned complexity. Practitioners should read architecture through the lens of control ownership and lifecycle discipline.
A few things that frame the scale:
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to The 2024 State of Secrets Management Survey.
- Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Who should own architecture decisions in a complex organisation?
A: Ownership should sit with people who can translate between business goals and technical constraints, then defend the trade-offs across teams. In practice, that means shared input from engineering, security, and business leaders, with clear decision rights so the system does not drift into compromise by committee.
👉 Read our full editorial: Software architecture is really about governance, not specs
