fxdemo:01-part:04-traceability-to-parent-and-source-architectures:04-1-traceability-to-sip-ra

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
fxdemo:01-part:04-traceability-to-parent-and-source-architectures:04-1-traceability-to-sip-ra [2026/06/26 15:56] – owenfxdemo:01-part:04-traceability-to-parent-and-source-architectures:04-1-traceability-to-sip-ra [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido
Line 2: Line 2:
 [[fxdemo:01-part:start | Go to Top ]] [[fxdemo:01-part:start | Go to Top ]]
  
-SIP-RA supplies the parent architecture discipline for structured information processing systems. The Financial Systems Archetype specialises in financial systems. +SIP-RA supplies the parent architecture discipline for structured information processing systems. The Financial Systems Archetype specializes in [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial Systems]]. 
-SIP-RA addresses structured information processing across domains where organisations must process structured artefacts, interpret data, govern meaning, support traceable transformations, and preserve auditability and review. The Financial Systems Archetype carries those concerns into the Finance ecosphere while preserving platform independence and implementation neutrality.+ 
 +SIP-RA addresses structured information processing across domains where organizations must process structured artifacts, interpret [[dido:99_annexes:annex-b-terms-and-definitions:d:data|Data]], govern meaning, support [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]] transformations, and preserve auditability and review. The Financial Systems Archetype carries those concerns into the [[dido:99_annexes:annex-b-terms-and-definitions:f:finance_ecosphere|Finance Ecosphere]] while preserving platform independence and implementation neutrality. 
 Part 1 preserves the following SIP-RA concerns at the conceptual level. Part 1 preserves the following SIP-RA concerns at the conceptual level.
  
-Table 3-1: SIP-RA concerns addressed by the Conceptual Architecture+Table 3-1: SIP-RA concerns addressed by the Conceptual Architecture 
 ^ SIP-RA concern ^ Part 1 treatment ^ ^ SIP-RA concern ^ Part 1 treatment ^
-| Separation of data, structure, semantics, and interpretation | Defines separation of concerns as a conceptual principle. | +| Separation of [[dido:99_annexes:annex-b-terms-and-definitions:d:data|Data]], [[dido:99_annexes:annex-b-terms-and-definitions:s:structure|Structure]], [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|Semantics]], and [[dido:99_annexes:annex-b-terms-and-definitions:i:interpretation|Interpretation]] | Defines separation of concerns as a conceptual principle. | 
-| Governed processing across boundaries | Defines runtime planes, traceability, evidence, and governance of meaning. | +| Governed processing across boundaries | Defines [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]s, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], and governance of meaning. | 
-| Explicit architectural roles and responsibilities | Defines core conceptual elements, including Node, Node Role, Communication Endpoint, Data Structure Definition, Runtime Plane, and Evidence. | +| Explicit architectural roles and responsibilities | Defines core conceptual elements, including [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], [[dido:99_annexes:annex-b-terms-and-definitions:n:node_role|Node Role]], [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_definition|Data Structure Definition]], [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]], and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. | 
-| Traceable interpretation | Defines traceability as a conceptual element and architectural principle. |+| Traceable [[dido:99_annexes:annex-b-terms-and-definitions:i:interpretation|Interpretation]] | Defines [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] as a conceptual element and architectural principle. |
 | Platform independence | Keeps DDS, IDL, Python, Kubernetes, K3s, Docker, RTI Connext DDS, and Crucible out of the conceptual layer. | | Platform independence | Keeps DDS, IDL, Python, Kubernetes, K3s, Docker, RTI Connext DDS, and Crucible out of the conceptual layer. |
-| Audit and review | Treats evidence, auditability, and provenance as architectural concerns. |+| Audit and review | Treats [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], auditability, and provenance as architectural concerns. |
 | Evolvability without loss of comparability | Preserves conceptual separation so later parts can evolve implementation and deployment profiles without redefining meaning. | | Evolvability without loss of comparability | Preserves conceptual separation so later parts can evolve implementation and deployment profiles without redefining meaning. |
 +
 +----
 +
 +<WRAP centeralign>
 +
 +© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
 +
 +</WRAP>
 +
  
  • fxdemo/01-part/04-traceability-to-parent-and-source-architectures/04-1-traceability-to-sip-ra.1782514576.txt.gz
  • Last modified: 2026/06/26 15:56
  • by owen