# 3.2.2 Architecture feature, ISO 42024 ## Published contents Contents1 Scope2 Normative references3 Terms and definitions4 Architecture concepts4.1 Overview4.2 Architecture and architecting4.3 Architecture design and solution design4.4 Architecture definition and communication4.5 Stakeholder concerns and architectural aspects4.6 Architecture viewpoints and architecture views4.7 Architecture frameworks and architecture description languages4.8 Architecture descriptions and architecture models4.9 Reference architectures and reference models4.10 Life cycle and life history4.11 Architecting precepts5 Architecting principles5.1 Introduction to the principles5.2 Principles about the purpose of an architecture5.3 Principles about the focus of an architecture5.4 Principles about architecting outcomesTerms 3.2 Architecting concepts 3.2.1 Architecture3.2.2 Architecture feature3.2.3 Architecting3.2.4 Architecting principle3.2.5 Architecture principle3.2.6 Architecture framework3.2.7 Reference architecture3.3 Entity related concepts 3.3.1 Entity of interest3.3.2 Solution entity3.3.3 Environment3.3.4 Context3.3.5 Enterprise3.3.6 System3.3.7 Aspect3.3.8 Dimension3.4 Architecture design concepts 3.4.1 Design (noun)3.4.2 Architecture design3.4.3 Architecture information package3.4.4 Engineering effort3.4.5 Solution design3.4.6 Solution information package3.4.7 Stakeholder3.4.8 Stakeholder perspective3.4.9 Concern3.5 Architecture description concepts 3.5.1 Architecture description3.5.2 Solution description3.5.3 Architecture view3.5.4 Architecture viewpoint3.5.5 Model3.5.6 Metamodel3.5.7 Reference model3.6 Entity life cycle concepts 3.6.1 Life cycle3.6.2 Life cycle phase3.6.3 Life cycle stage3.6.4 Life historyAnnexes A.1 Architecture design and solution related entitiesA.2 Architecture expressed as a set of modelsA.3 Life cycle and life history conceptsA.4 Enterprise and system conceptsA.5 Duality of architectural decomposition and architectural synthesisB.1 BackgroundB.2 Aligning architecture in designB.3 Duality of architectureB.4 Pursuit of opportunities Home / Glossary Architecting concepts · 3.2.2 # Architecture feature A fundamental idea or essential quality that is tied to value, covers the whole entity rather than one part, and is enduring. A feature of a component is not automatically a feature of the entity: the entity architecture constrains its components, not the reverse. - definition - Term - ISO/IEC/IEEE DIS 42024 - Last updated: 2026-10-21 ## What this term settles The term gives the firm a way to say no to local decisions that damage a whole entity property. If a property must hold for every component, it is an architecture feature and belongs at the entity level. If it matters only inside one component, it is a component decision and belongs with that component. Most architecture disputes are really disagreements about which level a property sits at. ## What to do in your practice Create an architecture feature register with four columns: the feature, the value it protects, the components it constrains, and the owner. When a delivery team proposes a design that breaks a feature, the register gives the conversation a factual basis. Review the register once a year for features that have stopped being true. ## 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 - The feature register, with the value each feature protects. Shows that entity level properties were identified and owned, not left implicit. - A record of design exceptions, with the approving role. An auditor asks how a team was allowed to depart from a whole entity property, and who accepted the risk. - A constraint map from each feature to the components it affects. Demonstrates that the constraint was applied deliberately across the estate. - The review note that retired or changed a feature. Shows the register is maintained rather than written once. Ask your teamWhich feature in this entity, if broken by one component, would damage value for a stakeholder outside that component? ## Common gaps this page catches - The firm uses the word non functional requirement for entity properties and never links it to value. - Component teams are allowed to opt out of entity properties without a recorded decision. - The feature list has not been reviewed since it was written. ## What to prepare before publication Take the last three design exceptions the firm approved. For each, ask which entity level feature was affected and whether the exception was recorded against it. If the answer is unclear, the feature register is the first artefact to build. ## Common questions What does Architecture feature mean in ISO 42024? A fundamental idea or essential quality that is tied to value, covers the whole entity rather than one part, and is enduring. A feature of a component is not automatically a feature of the entity: the entity architecture constrains its components, not the reverse. What evidence should we keep for 3.2.2? The feature register, with the value each feature protects. A record of design exceptions, with the approving role. A constraint map from each feature to the components it affects. ## Related units - 3.2.1 - 3.3.7 - 3.4.9 Source. ISO/IEC/IEEE DIS 42024, Clause 3.2.2, 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 Source: https://iso-42024-revision-checker.theartofservice.com/glossary/architecture-feature/