ODA User Guide
Architecture
Understand the three-layer ODA architecture and how governance and execution flow together.
From a user perspective, ODA has three connected layers. The first is the UI layer under Data Studio, where you work in pages like Workspaces, Semantic Layers, and Jobs (/data-accelerator, /data-accelerator/semantic-layers, /data-accelerator/jobs). These pages are interactive and update quickly, helping users search, navigate, create, and monitor assets without leaving the flow.
The second layer is the application layer, which applies access control and business rules. Workspaces and Jobs actions are controlled by manage_data permissions, while Semantic Layers publishing is limited to administrator users. This keeps day-to-day authoring open to the right teams while protecting high-impact semantic definitions.
The third layer is the metadata and execution layer. ODA stores ingestion settings, transformation definitions, semantic versions, and job schedules as managed objects, then tracks each execution as a run with status and timestamps. This design gives users consistency, traceability, and reliable operations as they move data from ingestion to business-ready outputs.
CRM Architecture
The CRM architecture in Optra is centered on Microsoft Dynamics 365 as the original business system of record for assets, accounts, cases, and work orders. That CRM data is first ingested by the client into Databricks bronze storage, and ODA then accesses it through Delta Share rather than connecting directly to D365. This creates a controlled handoff between the source application and Optra, while keeping the CRM pipelines aligned to client-managed ingestion, governance, and refresh schedules.
Within ODA, the CRM pipelines are organized to standardize reporting, preserve business relationships, and expose analytics-ready datasets for downstream consumption. The architecture supports linked CRM domains such as assets, child assets, accounts, cases, and work orders, so reporting can follow the same operational relationships users expect from the source system. The result is a governed CRM data foundation that supports Power BI, analytics, and operational decision-making without duplicating source-system logic in every downstream workflow.
flowchart LR A[Microsoft Dynamics 365<br/>Assets, Accounts, Cases, Work Orders] B[Client Databricks Bronze Layer] C[Delta Share] D[ODA / Optra Data Sources] E[Silver and Gold CRM Pipelines] F[Reporting and Analytics<br/>Power BI and Operational Use] A --> B B --> C C --> D D --> E E --> F
Medallion Architecture
The Medallion architecture follows a layered Bronze, Silver, and Gold design that progressively improves the quality and usability of data as it moves through the platform. Bronze serves as the raw landing layer, preserving source records with minimal transformation so replay, debugging, and schema evolution remain possible. Silver is the normalization and enrichment layer, where data is parsed, filtered, deduplicated, and standardized into a reusable canonical structure.
Gold is the curated business layer, where the normalized data is shaped into analytics-ready outputs for dashboards, reporting, and advanced data science use cases. This architecture reduces repeated transformation logic, improves consistency across downstream consumers, and creates a clear separation between raw ingestion, reusable business preparation, and final consumption datasets. In practice, it gives ODA a scalable way to manage both telemetry and CRM pipelines while maintaining traceability and performance.
flowchart LR A[Bronze<br/>Raw source data] --> B[Silver<br/>Parsed, filtered, standardized] B --> C[Gold<br/>Curated business-ready datasets] C --> D[Dashboards, Reporting,<br/>Analytics, Data Science]
Data Processing Zones (Raw to Gold)
Raw Zone
The Raw zone is the first capture point for data arriving from source systems, files, APIs, streams, or shared data products. Data is retained as close as possible to its original shape, with minimal restructuring so fidelity is preserved. This zone is primarily about ingestion reliability, timestamped capture, and traceability of what was received. It provides the historical baseline required for replay, audits, and downstream reprocessing when transformation rules evolve.
Bronze Zone
The Bronze zone is the persistent landing layer where ingested raw data is stored in a stable, queryable form. At this stage, transformations are intentionally lightweight: schema alignment, ingestion metadata, and technical normalization needed for platform consistency. Bronze protects source integrity while making data easier to operationalize in later stages. It acts as the governed handoff between inbound ingestion and business-focused transformation pipelines.
Silver Zone
The Silver zone is the standardized processing layer where data is parsed, validated, deduplicated, and enriched with required reference context. Here, inconsistent source structures are converted into clean, reusable canonical datasets that can serve many downstream workloads. Silver reduces repeated logic by centralizing common business and technical transformations once. It is the core preparation layer for dependable analytics, semantic modeling, and operational data products.
Gold Zone
The Gold zone is the curated consumption layer where data is modeled into business-ready outputs for reporting, dashboards, and advanced analytics. Datasets in this zone are optimized for usability, meaning, and performance, with domain-friendly naming and stable semantic expectations. Gold preserves alignment with governed definitions while exposing clear, decision-ready views for end users and applications. This is the final zone where prepared data is delivered for consistent enterprise consumption.