| Both sides previous revision Previous revision | |
| dido:01-fdis-ra:02-background-and-motivation:02-5-why-a-reference-architecture-is-needed:start [2026/07/12 13:10] – [2.5 Why a Reference Architecture Is Needed] nick_dido | dido:01-fdis-ra:02-background-and-motivation:02-5-why-a-reference-architecture-is-needed:start [2026/07/18 12:33] (current) – external edit 127.0.0.1 |
|---|
| The preceding sections establish two essential points. | The preceding sections establish two essential points. |
| |
| First, modern reporting systems already possess the core functional capabilities required to ingest, extract, represent, interpret, validate, store, and analyse reported information. | First, modern reporting systems already possess the core functional capabilities required to ingest, extract, represent, interpret, validate, store, and analyze reported information. |
| |
| Second, in the absence of an explicit coordinating architecture, organisations routinely assemble these capabilities through tool-driven, product-specific, and implementation-specific arrangements that undermine long-term [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] consistency, traceability, comparability, reproducibility, and governance. | Second, in the absence of an explicit coordinating architecture, organizations routinely assemble these capabilities through tool-driven, product-specific, and implementation-specific arrangements that undermine long-term [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] consistency, traceability, comparability, reproducibility, and governance. |
| |
| The resulting problems are not failures of individual technologies, products, or standards. They are architectural failure modes: systemic behaviours that emerge when systems implicitly distribute responsibility for semantic interpretation, versioning, provenance, rule execution, validation, and authority across components and implementations, rather than explicitly defining and governing those responsibilities. | The resulting problems are not failures of individual technologies, products, or standards. They are architectural failure modes: systemic behaviors that emerge when systems implicitly distribute responsibility for semantic interpretation, versioning, provenance, rule execution, validation, and authority across components and implementations, rather than explicitly defining and governing those responsibilities. |
| |
| These failure modes persist even in environments that use mature tooling, structured reporting formats, governed taxonomies, or widely adopted syntactic standards. Organisations cannot reliably resolve them through incremental product enhancements, additional tagging, or isolated adoption of standards, because these measures do not establish a shared system-level allocation of responsibilities, boundaries, interfaces, authority, and lifecycle controls. | These failure modes persist even in environments that use mature tooling, structured reporting formats, governed taxonomies, or widely adopted syntactic standards. Organizations cannot reliably resolve them through incremental product enhancements, additional tagging, or isolated adoption of standards, because these measures do not establish a shared system-level allocation of responsibilities, boundaries, interfaces, authority, and lifecycle controls. |
| |
| The need for a [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]] therefore arises not from missing functionality, but from the absence of a shared architectural framework that defines how existing capabilities are: | The need for a [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]] therefore arises not from missing functionality, but from the absence of a shared architectural framework that defines how existing capabilities are: |