====== 2.5 Why a Reference Architecture Is Needed ======

[[dido:01-fdis-ra:02-background-and-motivation:start|Return to 2. Background and Motivation]]

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 analyze reported information.

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 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. 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:

  * Composed
  * Separated
  * Constrained
  * Governed
  * Versioned
  * Integrated
  * Assessed
  * Evolved over time

Without such a framework, systems may function effectively in isolation while remaining opaque, brittle, difficult to compare, and difficult to align across agencies, jurisdictions, reporting periods, and independently developed implementations.

In the context of the [[dido:99_annexes:annex-b-terms-and-definitions:f:fdta|Financial Data Transparency Act (FDTA)]] and comparable regulatory initiatives, this gap represents a fundamental architectural risk. The objectives of transparency, interoperability, comparability, auditability, and long-term analytical usability depend not only on what systems do, but also on how systems define, govern, version, communicate, and preserve meaning.

A Reference Architecture is therefore needed to make these responsibilities:

  * Visible
  * Explicit
  * Analysable
  * Testable
  * Traceable
  * Governable
  * Reconstructable across time

The [[dido:99_annexes:annex-b-terms-and-definitions:f:fdis-ra|Federated Data Interpretation Systems Reference Architecture (FDIS-RA)]] provides this shared architectural framework without prescribing specific products, platforms, technologies, deployment models, or implementation mechanisms.

===== Contents =====

{{indexmenu>dido:01-fdis-ra:02-background-and-motivation:02-5-why-a-reference-architecture-is-needed#1|js navbar nocookie maxjs#1 id#fdis_ra_02_5_why_reference_architecture_nav}}

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>