| Both sides previous revision Previous revision Next revision | Previous revision |
| dido:01-fdis-ra:01-introduction:01-3-reference-architecture-definition:start [2026/07/11 11:07] – ↷ Links adapted because of a move operation nick_dido | dido:01-fdis-ra:01-introduction:01-3-reference-architecture-definition:start [2026/07/18 12:33] (current) – external edit 127.0.0.1 |
|---|
| [[dido:01-fdis-ra:01-introduction:start|Return to 1. Introduction]] | [[dido:01-fdis-ra:01-introduction:start|Return to 1. Introduction]] |
| |
| In this specification, the term [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture (RA)]] follows established United States Department of Defense (DoD) architectural guidance. Doyle and Wilezynski (2010) describe a Reference Architecture as one that: | In this specification, the term [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture (RA)]] follows established United States Department of Defense (DoD) architectural guidance. Doyle and Wilezynski (2010) describe a Reference Architecture as one that: |
| |
| * Provides a common language for diverse stakeholder communities | * Provides a common language for diverse stakeholder communities |
| In this sense, a Reference Architecture is neither an implementation nor a detailed system design. Instead, it provides a conceptual and logical framework that establishes shared understanding, defines architectural responsibilities, and enables comparison across independently developed systems. | In this sense, a Reference Architecture is neither an implementation nor a detailed system design. Instead, it provides a conceptual and logical framework that establishes shared understanding, defines architectural responsibilities, and enables comparison across independently developed systems. |
| |
| A Reference Architecture defines where architectural authority resides for key concerns, including [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] interpretation, validation, governance, and the controlled evolution of meaning. It does not prescribe how organisations realise those concerns through specific representations, technologies, tools, or products. | A Reference Architecture defines where architectural authority resides for key concerns, including [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] interpretation, validation, governance, and the controlled evolution of meaning. It does not prescribe how organizations realize those concerns through specific representations, technologies, tools, or products. |
| |
| The Federated Data Interpretation Systems Reference Architecture (FDIS-RA) adopts this definition directly. It provides a stable architectural foundation for regulated data interpretation, including environments that support agency-specific implementation of the [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:f:fdta|Financial Data Transparency Act (FDTA)]] joint data standards. FDIS-RA clarifies how core architectural concerns, including evidence intake, information extraction, observation management, semantic representation, rule-based interpretation, and validation, relate to one another and how relevant standards apply coherently across system boundaries. | The Federated Data Interpretation Systems Reference Architecture (FDIS-RA) adopts this definition directly. It provides a stable architectural foundation for regulated data interpretation, including environments that support agency-specific implementation of the [[dido:99_annexes:annex-b-terms-and-definitions:f:fdta|Financial Data Transparency Act (FDTA)]] joint data standards. FDIS-RA clarifies how core architectural concerns, including evidence intake, information extraction, observation management, semantic representation, rule-based interpretation, and validation, relate to one another and how relevant standards apply coherently across system boundaries. |
| |
| The final FDTA joint rule establishes joint data standards for promoting interoperability among participating federal financial regulatory agencies. The rule does not itself apply those standards to specific collections of information or prescribe an interpretation architecture. Each implementing agency determines, through subsequent rulemaking or other agency action, how the joint standards apply to collections within its jurisdiction. FDIS-RA provides an architectural framework that supports such implementations without supplanting agency authority, prescribing reporting obligations, or conferring legal effect on the architecture. | The final FDTA joint rule establishes joint data standards for promoting interoperability among participating federal financial regulatory agencies. The rule does not itself apply those standards to specific collections of information or prescribe an interpretation architecture. Each implementing agency determines, through subsequent rulemaking or other agency action, how the joint standards apply to collections within its jurisdiction. FDIS-RA provides an architectural framework that supports such implementations without supplanting agency authority, prescribing reporting obligations, or conferring legal effect on the architecture. |
| |
| The Reference Architecture described in this specification provides the conceptual foundation for formalisation using SysML v2 as a [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform-Independent Model (PIM)]], aligned with [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:m:mda|Model Driven Architecture (MDA)]] principles. The explanatory material provides context and rationale, while the formally identified architectural requirements, interface definitions, models, constraints, and conformance provisions constitute the proposed normative response to the [[dido:00-sip-ra:start|Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]]. | The Reference Architecture described in this specification provides the conceptual foundation for formalization using SysML v2 as a [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform-Independent Model (PIM)]], aligned with [[dido:99_annexes:annex-b-terms-and-definitions:m:mda|Model Driven Architecture (MDA)]] principles. The explanatory material provides context and rationale, while the formally identified architectural requirements, interface definitions, models, constraints, and conformance provisions constitute the proposed normative response to the [[dido:00-sip-ra:start|Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]]. |
| |
| The formal model expresses architectural elements, relationships, interfaces, constraints, governance mechanisms, and traceability with sufficient precision to support consistent realisation, implementation assessment, and conformance evaluation across independently developed systems. | The formal model expresses architectural elements, relationships, interfaces, constraints, governance mechanisms, and traceability with sufficient precision to support consistent realization, implementation assessment, and conformance evaluation across independently developed systems. |
| |
| ---- | ---- |