Skip to main content

Architecture

CryspIQ® has a deliberately short architecture. Data arrives from your source systems, is mapped into a single governed enterprise data model, and is consumed from there — by reports, by applications, and by people asking questions in plain language.

The thing to understand first is what is absent. There are no staging, transformation and presentation layers to build and maintain between the source and the answer. The model exists before your data arrives, so the work is connecting sources to it rather than designing somewhere for them to go.

The shape of it​

Three stages, in order.

1. Connect and map​

Sources are registered and their structures described. That can be a file upload, a database, an API or an existing raw or staging layer you already populate — CryspIQ® is happy to read from a lake or warehouse you have rather than replace it.

Each source field is then mapped to its place in the enterprise data model. Lumen proposes those mappings and a person confirms them, which is what keeps the step in business language rather than engineering.

2. Model​

Mapped data is loaded into the enterprise data model, where each incoming record is decomposed into typed elements stored against shared dimensions. Two things happen at this point rather than later:

  • Quality is assessed as data loads, against rules attached to the model — so a defect is caught at entry rather than found downstream by whoever consumed it. Records that fail are held for a steward rather than silently dropped.
  • Business meaning and security classification are attached, carried on the fact type, so both travel with the data into everything that reads it.

3. Consume​

Everything downstream reads the same model, which is what makes the answers agree:

  • a query library of saved, governed queries
  • a query builder for building new ones visually
  • natural language questions, answered by Lumen
  • dashboards and BI tools
  • application-to-application access for operational systems

Because access control is applied to the data rather than to a reporting tool, a person sees the same permitted subset whichever route they use.

Where it sits relative to what you already have​

CryspIQ® is not a replacement for your data platform. It runs alongside Databricks, Snowflake, Redshift, Synapse or BigQuery and reads from the raw or staging layers you already populate.

That matters for how a deployment starts: there is no migration to complete before value appears. Map one source, and that source is queryable through the model while everything else carries on unchanged. See co-existence for the detail.

The functional flows​

The diagram below shows the end-to-end flow through the application — from source registration and mapping, through load and quality, to the consumption surfaces described above.

CryspIQ functional flows — from source registration and mapping, through load and data quality, to query, dashboards and application access

What a deployment needs​

CryspIQ® is delivered as software as a service, running on Azure. Each customer has their own instance and their own database — your data, your mappings and everything Lumen learns from your confirmations stay within your deployment.

The diagram below shows the Azure components a deployment uses, which is also the basis for understanding the infrastructure cost involved.

Azure components required for a CryspIQ deployment

Watch​

Two short walkthroughs covering the same ground visually.

Solution architecture — how the pieces fit together.

The data model — how data is structured once it arrives. The written version is The CryspIQ® Data Model.