07 / Data & AI advisory
Data & AI Advisory and Architecture Strategy
Data and AI advisory is the work of deciding what to build before building it. Quorlytic assesses the current estate from evidence, writes down the constraints that actually bind the architecture, compares real options against your workload, and produces a sequenced roadmap recording every decision and the options rejected along the way.
By QuorlyticUpdated
Some decisions are expensive to reverse. Platform selection, processing model, where the semantic layer lives and who operates it are all easier to get right before the first sprint than after the first year.
- 01Assess
- 02Frame
- 03Decide
- 04Sequence
The business problem
An architecture exists to serve decisions: which ones, made by whom, how often, and what changes when the answer improves. Naming those first is what makes the rest of the evaluation possible, because a requirement nobody wrote down turns every vendor comparison into an argument about preferences.
What we build
Volume, change rate, concurrency, history depth and quality are all measurable, and they are usually different from what the organisation believes. Query logs, job histories and cost reports say more in a week than a round of interviews, and they give every later recommendation something concrete to point at.
The outcome
A sequenced architecture roadmap with the decisions, the evidence behind them and the options that were rejected
When this is the right engagement
Symptoms that bring teams here.
Advisory is the right engagement when the next decision is expensive, hard to reverse, and currently being argued rather than evidenced.
Two credible platform recommendations point in opposite directions
The requirement has not been written down, so each recommendation is answering a different question.
An AI programme is announced before the data is assessed
Readiness is being assumed. It is cheaper to test that assumption than to discover it mid-build.
A modernization business case cannot be written
The constraint has not been quantified, so the cost of staying is unknown and the cost of moving looks arbitrary.
Every team is building its own data capability
There is no operating model, so duplication is the rational local choice.
A vendor decision is being made on a demonstration
Nothing has been tested against your workload, your access rules or your team's skills.
The roadmap is a list of technologies
It records intentions rather than sequenced decisions with dependencies and owners.
Capability model
The decision canvas.
Advisory turns inputs into decisions and decisions into a sequence. Select an input to see what it changes about the architecture that follows.
01 — Business requirement
State the decisions the platform exists to support, their cadence and their owners, before any technology is discussed.
What it produces
A prioritised list of decisions the platform must serve.
What usually goes wrong
- Requirements expressed as capabilities rather than decisions
- No stated priority, so everything is in scope
- Success defined as a delivery date
Technologies in this stage
- Decision inventory
- Stakeholder mapping
02 — Data and workload
Profile what actually exists — volume, structure, change rate, history and quality — and what will be asked of it.
What it produces
A measured profile of the data and the workloads it must serve.
What usually goes wrong
- Volume estimated rather than measured
- Semi-structured and event data discovered late
- Concurrency profile unknown until production
Technologies in this stage
- Data profiling
- Query log analysis
- Workload characterisation
03 — Latency and scale
Establish how current the data has to be for each decision, and what scale the architecture must absorb.
What it produces
Freshness and scale requirements per decision, with their cost stated.
What usually goes wrong
- Real time requested where daily is sufficient
- Peak load estimated from averages
- Freshness targets set without a cost comparison
Technologies in this stage
- Freshness targets
- Load profiling
- Capacity modelling
04 — Governance and security
Determine what the data's sensitivity, residency and audit requirements permit — these usually constrain the architecture more than performance does.
What it produces
The constraints the architecture has to satisfy, written down early.
What usually goes wrong
- Compliance reviewed after the architecture is chosen
- Residency requirements discovered during procurement
- Access model designed per tool rather than once
Technologies in this stage
- Classification
- Access model
- Residency review
- Audit requirements
05 — Team and operating model
Assess who will build and run this, what they know, and whether the target architecture is operable by them.
What it produces
An operating model the organisation can actually staff.
What usually goes wrong
- Architecture chosen for a team that does not exist
- Central and embedded models mixed without a boundary
- Run capacity ignored in the delivery plan
Technologies in this stage
- Skills assessment
- Operating model design
- Ownership mapping
06 — Economics and portability
Compare total operating cost under real workloads, and decide deliberately how much lock-in is acceptable.
What it produces
A cost comparison on your workload, with the lock-in position stated.
What usually goes wrong
- List pricing compared instead of workload cost
- Migration cost omitted from the comparison
- Portability claimed but never tested
Technologies in this stage
- Cost modelling
- Open table formats
- Exit assessment
Illustrative reference architecture
The architecture decision canvas
Advisory has no system to draw, so this is the model it produces instead: inputs on the left, the decisions they constrain in the middle, the sequenced roadmap on the right. Each input changes specific decisions, which is why they are gathered before any platform is named.
Inputs
What is true about the business, the data and the team.
- Requirement
- Data profile
- Latency
- Governance
- Team
- Economics
Constraints
The inputs that remove options rather than rank them.
- Residency
- Sensitivity
- Skills
- Existing agreements
Decisions
The choices that are expensive to reverse later.
- Platform
- Processing model
- Semantic layer
- Operating model
Sequencing
Dependency order, not a wish list.
- First increment
- Dependencies
- Reversibility
Roadmap
Decisions with owners, evidence and review points.
- Owners
- Evidence
- Review points
Recorded throughout
- Assumptions
- Options considered
- Reasons for rejection
- Reversibility
- Review triggers
The approach
- 01
Start from the decision, not the platform
An architecture exists to serve decisions: which ones, made by whom, how often, and what changes when the answer improves. Naming those first is what makes the rest of the evaluation possible, because a requirement nobody wrote down turns every vendor comparison into an argument about preferences.
- Decisions inventoried with their owners and cadence
- Priority stated, so not everything is in scope
- Current evidence behind each decision recorded
- 02
Measure the current position rather than describing it
Volume, change rate, concurrency, history depth and quality are all measurable, and they are usually different from what the organisation believes. Query logs, job histories and cost reports say more in a week than a round of interviews, and they give every later recommendation something concrete to point at.
- 03
Separate constraints from preferences
Data residency, classification, audit requirements and the skills of the team that will operate the platform remove options. Everything else ranks them. Keeping the two apart is what stops a compliance review at the end of the process invalidating a decision made at the start.
- Residency, sensitivity and audit requirements established early
- Existing cloud agreements and contractual commitments included
- Operability assessed against the team that will actually run it
- 04
Compare options against your workload, not against each other
Platform comparisons written in the abstract are not decisions. Running a representative workload — real volume, real concurrency, real access rules — produces a comparison specific enough to act on, including the operating cost under load rather than the list price.
- 05
Record what was rejected, and why
The value of an architecture decision record is mostly in the options that were not chosen. It lets a decision be revisited in a year without repeating the analysis, and it protects the organisation from relitigating the same question each time someone new joins.
- Options considered, with the reason each was set aside
- Assumptions stated so they can be challenged later
- Review triggers set where a decision depends on something that may change
- 06
Sequence by dependency and reversibility
A roadmap is not a list of technologies with dates against them. Work is ordered by what depends on what, and by how expensive each step is to undo, so the reversible decisions happen first and the irreversible ones happen with the most evidence available.
- 07
The operating model is part of the architecture
Central, embedded, federated or managed changes what the platform can be. An architecture that requires a capability the organisation has no plan to staff is a recommendation to fail slowly, and it is the most common way a sound technical decision produces a poor outcome.
- Skills and run capacity assessed alongside the design
- Ownership boundaries named per data product
- Managed operations considered where run capacity is the real constraint
Delivery model
How the work is sequenced.
A bounded engagement. The deliverable is a decision record you keep and can act on with any implementation partner, including none.
| Phase | Activities | Decisions made here | What you keep |
|---|---|---|---|
| AssessEstablish the current position from evidence, not from description. |
|
| Current-state assessment with evidence |
| FrameWrite the requirement down before evaluating anything. |
|
| Requirement and constraint register |
| DecideCompare real options against the criteria. |
|
| Architecture decision record with rejected options |
| SequenceTurn decisions into an order of work. |
|
| Sequenced roadmap with owners and review triggers |
Technology fit
What each technology is here to do.
Advisory is deliberately not a technology engagement. These are the categories it evaluates, and the evaluation is the product.
Platform candidates
- Snowflake
- Databricks
- BigQuery
- Microsoft Fabric
Compared against your workload, access model and existing cloud agreements rather than against each other in the abstract.
Platform detailProcessing model
- Batch
- Change data capture
- Streaming
- Hybrid
Follows the freshness requirement per decision. Most estates need more than one, with the boundary stated.
Consumption
- Semantic layer
- BI platform
- ML and AI
- Applications
Who consumes the platform decides its concurrency profile and its governance requirements.
Platform detailGovernance
- Classification
- Access model
- Lineage
- Residency
Usually the binding constraint. Cheaper to design for than to retrofit after a platform is chosen.
Operating model
- Central
- Embedded
- Federated
- Managed
The architecture has to be operable by the team that will actually have it.
Platform detail
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Engineering concerns
What has to be answered before it is trusted.
What makes an advisory output usable rather than decorative.
- Evidence over assertion
- Every recommendation traces to something measured — a profile, a query log, a cost model or a stated constraint.
- Rejected options recorded
- What was considered and why it was not chosen, so the decision can be revisited without repeating the work.
- Reversibility
- Each decision marked by how expensive it is to undo, so the irreversible ones get the most scrutiny.
- Operability
- The recommended architecture matched against the team that will run it, not an idealised one.
- Vendor neutrality
- No partnership, reseller or certification relationship influences the recommendation. There are none to disclose.
- Implementation independence
- The output is written so another party can execute it. It is a decision record, not a lead-in to a mandatory build.
Where it applies
Related work, and why it is related.
What advisory usually precedes, and what it connects to.
- Data modernizationThe most common outcome: a sequenced migration with the target chosen on measured evidence.
- AI and machine learningAI readiness is an advisory question first — the answer is often that the data work comes before the model work.
- Data engineeringWhen the assessment shows the platform is fine and the pipelines are the constraint.
- TechnologiesPlatform selection is an output of the canvas. The technology pages hold the architecture detail behind each candidate.
- Financial servicesGovernance and explainability constraints usually decide the architecture before performance does.
- Readiness assessmentA worksheet you complete yourself. It structures the same questions advisory answers with evidence, and is a good way to arrive at the first conversation prepared.
Show which evidence would change the architecture decision.
A roadmap becomes expensive when a provisional assumption quietly turns into a procurement commitment. This illustrative advisory record considers whether to retain a daily analytical feed or fund a faster path. The useful output is an evidence boundary: which business need is established, which measurement remains unknown and which discovery would justify reopening the choice.
Scope and assumptions: The options and observations below are hypothetical. They are a way to structure an advisory deliverable, not a platform recommendation, a quoted engagement or a claim that faster data improves every business decision. Existing contracts, security constraints and operating capacity still shape the available options.
| Dimension | Assumption or option | Decision evidence and reopening condition |
|---|---|---|
| Decision opportunity | Name the action that can occur between today's daily refreshes. Distinguish the age of a dashboard from the latest time an operator can still change an outcome. Ask whether the source itself exposes useful changes soon enough. | Keep a representative decision timeline: source event, available extract, publication, operator review and action deadline. A faster pipeline cannot recover an opportunity already lost upstream. |
| Lowest-change option | Consider retaining the current feed with clearer freshness information and an exception workflow. Identify which decisions this can serve and which remain unsatisfied, rather than treating the current system as an option with no value. | Record the unmet decision and the cost of keeping that limitation. If the operator cannot act more frequently, the evidence may support improving the workflow before buying additional processing capacity. |
| Faster-path option | Compare a bounded incremental path against the same decision, with source access, workload, downstream refresh and operating responsibilities included. State which assumptions come from measurements and which are estimates. | Attach dated workload evidence and its applicable range. A concurrency observation from a quiet week does not establish peak capacity; a source export demonstration does not establish permission for continuous capture. |
| Irreversible commitment | Separate a reversible evaluation from choices that create long commitments, data duplication or a second operating model. Name which contract, dependency or retention change would make the experiment expensive to undo. | Keep the options, rationale and consequences together. The MADR template supplies a structure for recording these decisions and their confirmation; the workload evidence must come from the actual estate. |
| Reopening trigger | Define a concrete event that invalidates an assumption: a new action deadline, a source-access change, materially different peak demand or a changed residency constraint. Name who collects the replacement evidence. | Link the new decision to the superseded record instead of silently editing away the earlier rationale. Preserve what was known at the time and explain how the changed evidence affects the option ordering. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: a faster feed is technically plausible, but the consumer's approval cycle still permits only one daily action. Retain the daily path for that consumer and investigate a separately owned exception workflow if it has a shorter decision window. Reopen the architecture choice when an actionable requirement changes. This avoids presenting a hypothetical streaming design as an already justified investment.
- Give each recommendation an evidence date, applicable workload and explicit unknowns. An unmeasured assumption should remain visible in the private decision record even when the final roadmap is concise.
- Keep technology choice, implementation funding and operational ownership as distinct decisions. An accepted direction does not establish an approved budget or a staffed run function.
If a faster source path is justified, compare the change semantics in CDC vs batch vs streaming before selecting the mechanism.
Official references for this example:
Questions
Questions worth asking.
How long does an advisory engagement take?
It is scoped around a decision rather than a duration, so the answer depends on how many decisions are in scope and how much evidence already exists. A single platform-selection question with accessible query logs is a short engagement; a full estate assessment across several business units is not. We scope it explicitly before starting, including what is deliberately out of scope.
Do you recommend platforms you also implement?
Yes, and that is worth being direct about. Quorlytic holds no partner status, reseller agreement or certification with any platform vendor, so no commercial incentive is attached to a particular recommendation. The mitigation is procedural: the decision record states the criteria, the evidence and the rejected options, so the reasoning can be checked by someone who was not in the room.
What do we actually receive?
A current-state assessment built from measured evidence, a written constraint register, an architecture decision record naming what was chosen and what was rejected, and a roadmap sequenced by dependency and reversibility with owners and review points. They are written to be read by your engineers, not only by your executives.
Can another partner execute the roadmap?
Yes. The output is written so it can be handed to any competent implementation team, including your own. It names decisions, constraints and acceptance criteria rather than assuming a particular delivery partner, and there is no obligation to continue with us.
How is this different from the readiness assessment on this site?
The data and AI readiness assessment is a worksheet you complete yourself to structure your own thinking. Advisory is an engagement where we gather the evidence, run the comparison and take a position on it. The worksheet is a good way to arrive at the first conversation with the right material already in hand.
What do you need from us to start?
Access to the people who make the decisions, and enough system access to measure rather than assume: query logs, job histories, cost reports and a data profile. Production data itself is rarely needed early, and sensitive records are not required to scope the work.
What if the assessment concludes we should not migrate?
Then that is the recommendation, and it is a legitimate outcome. The cost of staying on a platform is often lower than the cost of moving, particularly where the real constraint turns out to be pipeline design or metric governance rather than the platform itself. A decision not to act, made with evidence, is still worth the engagement.
Is a price given for the recommended work?
The roadmap includes the sequence, the dependencies and the shape of each increment. Implementation pricing depends on decisions the roadmap itself resolves, so we do not attach a figure to work that has not yet been scoped. Where a first increment is well defined, it is scoped and priced on its own.
Next step
Review your data architecture.
Bring the decision you are stuck on. Advisory is scoped around a decision, not a duration.