What to bring to a customer data architecture review

Write a brief someone outside your team can follow

An architecture review should start with the work the business needs to do. Write the question in plain language, name its owner and describe the last time it was difficult to answer. Include what people did instead and what decision a better answer would support. This helps the discussion stay connected to a real use of the data.

You do not need to arrive with an approved technical design. For the first conversation with DataGlue, the question and tool names are enough; system access is not needed before the call. If your team has already done discovery, bring the existing notes so the next discussion can build on them.

1. The decision: what needs to be decided, and when?
2. The owner: who will use the answer and act on it?
3. The current method: where do people look today?
4. The gap: what is missing, disputed or slow to prepare?
5. The first check: what would show that the result is useful?

Map the sources without collecting another export

List the systems that hold each part of the history: visits, form submissions, bookings, sales activity and payments, where relevant. Beside each, name the person who can explain the records and approve access. Note which customer or account identifiers it uses and whether those identifiers appear in the next system.

Record practical constraints you already know. A source may update overnight, hold only recent history, or require another team to provide an export or API route. These details affect what a first answer can include. A short description of the constraint is more useful at this stage than a large file whose meaning is unclear.

Bring the owners of meaning and access

The business sponsor can explain why the decision matters. The process owner knows how it is made in practice. Source-system owners can explain the records, and data or engineering colleagues can review connection options. One person may cover several roles; the point is to make the relevant knowledge available.

For a larger rollout, identify who reviews privacy, security, procurement and support requirements. Bring your organisation's questions and approval dependencies early. Naming a requirement does not mean it is already supported: ask for the proposed approach and the evidence your reviewers need before treating it as resolved.

Agree what will be checked before the scope grows

Choose a small set of cases the business can explain. Include a record that should qualify for the result, one that should not, an uncertain identity link and an example with missing or late data. Agree which source is authoritative for each business event and who will decide whether the result is acceptable.

Discuss the proposed refresh timing, permissions and how the team will use the answer. If the goal is a weekly revenue review, acceptance needs to include that workflow. If it is sales preparation, the rep needs a history they can interpret before a call. A technical connection is necessary, but the business use determines what success means.

Leave with the scope and open questions written down

Use the review to agree what belongs in a first implementation and what should wait. Your scope should name the question, sources, responsible owners, dependencies and acceptance checks. Ask for clarity on delivery phases, platform access, support, data ownership and any work that would need a separate agreement.

DataGlue pricing is discussed with our team and shaped around the agreed engagement. Scope and price are agreed before work begins. If a requirement is still unresolved, keep it visible in the decision record. The next step should be understandable to the sponsor, the technical owners and the people who will use the result.