The reference architecture sets out both the present and the intended architecture for each domain: business, information, data, application and technology. An architecture repository keeps standards, reusable components, modelling artefacts, relationships, dependencies and views. Reference viewpoints show how each stakeholder concern is met, and for every view models are picked at a suitable level of decomposition. Descriptions of the baseline for each domain are produced, naming the building blocks that matter. A process architecture model and an information architecture model are kept within the baseline and target descriptions, documented to a standard and with defined roles. The models are checked for consistency and accuracy; the differences between baseline and target are analysed and the gaps ranked; a formal stakeholder review tests the proposal against what was originally intended; and the domain architectures are completed in an architecture definition document.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.