ISO 42024 Revision Checker
ISO/IEC/IEEE DIS 42024 · Enterprise, systems and software, Architecture fundamentals Stage 40.99 Planning date 15 Sep 2027, an estimate 35 terms · 20 clause areas · 9 annex sections

Home / Glossary

Architecting concepts · 3.2.1

Architecture

The fundamental ideas and the essential qualities that appear in an entity within its setting. The ideas include the decisions, principles and patterns that shape how the entity is built, how it runs and whether it lasts. The qualities are the attributes and characteristics that matter to stakeholders and that are hard to change once the entity is real.

  • definition
  • Term
  • ISO/IEC/IEEE DIS 42024
  • Last updated: 2026-10-21

What this term settles

Every entity has an architecture whether or not anyone has written it down. That single sentence changes the conversation in a firm: the question is not whether an architecture exists, but whether the one that exists is the one the firm intended. The definition also keeps the architecture separate from its description. A document is evidence of the architecture, never the architecture itself.

What to do in your practice

Take the entity your team argues about and write two lists: the decisions that would be expensive to reverse, and the qualities that stakeholders would notice if they were missing. If the lists are empty, the team is discussing a solution, not an architecture. If the lists are long, rank them by cost of reversal and keep the top ten. That ranked list is the architecture you will describe and defend.

Who it binds

The role that owns the practice area the term governs. A definition binds nobody on its own; it binds the reader who adopts the term in a method, a description or a contract.

Evidence an auditor or regulator asks for

  • A one page architecture statement per entity, with the ranked decisions and qualities.
    An auditor asks what the architecture is before asking for the description. This page answers that.
  • A decision log with a reversal cost column and the rationale for each decision.
    Shows that the hard to reverse decisions were identified while there was still a choice, and why each was taken.
  • A list of the qualities that stakeholders named, and who named them.
    Connects the architecture to the concerns it serves, rather than to the author taste.
  • A note on which parts are emergent or latent rather than designed.
    Prevents a claim of control over properties that only appear when the entity is in use.
Ask your teamWhich decision in this entity would cost the most to reverse after go live, and where is it recorded?

Common gaps this page catches

  • The architecture exists only as a diagram and no one can name the decisions behind it.
  • The description is treated as the architecture, so a change to the document is mistaken for a change to the entity.
  • No one has separated the properties that were designed from the ones that emerged in operation.

What to prepare before publication

Before the practice review, pick one entity and produce the ranked decision and quality list. Circulate it to the stakeholders who own the qualities and ask them to correct it. The corrected list becomes the reference point for every later description and for the evidence pack.

Related units

Source. ISO/IEC/IEEE DIS 42024, Clause 3.2.1, Terms and definitions. Open the official record. Retrieved 21 October 2026.

https://www.iso.org/obp/ui/en/#iso:std:iso-iec-ieee:42024:dis:ed-1:v1:en

ISO catalogue record 87510, the status, stage and page count.

Claim level: definition. The definition is in the public preview. This page states it in our own words and does not reproduce the text.

Last updated: 2026-10-21 · Markdown version · Check your practice