An assessment is not there to decide what to do. It is there to establish where you are starting from, precisely enough to argue about a quote.
It is the step most often skipped, because it costs a few days and produces nothing visible. Then the project starts, and halfway through you find that the integration everybody assumed existed is a nightly CSV export, that the field three reports depend on is filled in by hand 40% of the time, and that the permission model does not support the use case that justified the project. At that point the quote reopens, and your negotiating position is the worst it will ever be: you have already signed.
The five things it has to contain
If one of these is missing, the document is not finished. This is not a matter of style: these are the five areas the day estimate comes out of.
1. The data model as it is, not as it should be
Which objects exist, which fields are actually populated and at what rate, where the duplicates are, and which relationships were built to work around a limit rather than to describe the business. A data model designed three years ago and never touched since is not a problem. A data model nobody can explain any more is.
2. The integrations, as they really run
Not the list of connected systems: the list of how they are connected. Synchronous call, queue, nightly batch, file on a server, person copying and pasting. The difference between an API and a scheduled CSV is not technical, it is months on the project plan, and on an architecture slide they are both an arrow.
3. Who can see what
The access model breaks more AI projects than anything else, because an agent inherits the permissions of whoever queries it and makes them suddenly visible. A serious assessment says which profiles exist, which shares were opened out of necessity and never closed, and what happens when a language model reads that data. If this section is missing, ask for it before signing, not after.
4. Technical debt, quantified
Overlapping automations doing the same thing three different ways, code without tests, customisations that block platform upgrades. Debt does not need to be eliminated, it needs to be measured, because it is what turns a ten-day estimate into a twenty-five-day one. A document that says "technical debt is present" without saying how much and where has told you nothing.
5. The constraints that will not move
Release windows, dependencies on other programmes already running, people who exist in a single copy, data retention requirements. Constraints determine the order of the work, and the order determines the cost more than the chosen technology does.
How to recognise a real one
The useful distinction is this: an assessment describes the current state, a proposal describes a solution. If you open the document and immediately find a target architecture, a diagram with a product name in the middle and an estimate, you are reading a proposal.
Three quick checks, none of which need technical skill:
- Look for the assumptions. An honest assessment lists what it assumed without being able to verify it. If no assumptions are stated, either everything was verified - unlikely in four days - or the assumptions exist and were not written down for you.
- Look for the exclusions. What was not examined, and why. A missing exclusions section is the most reliable sign that the document exists to sell the next phase.
- Look for the uncomfortable numbers. The fill rate of a critical field, the count of duplicate automations, how many people can see an object they should not. An assessment containing nothing awkward did not look hard enough.
When you do not need one
Not everything deserves an assessment, and saying so early saves more than the assessment itself would.
- The scope is a single process, on a single system, that one person in the company knows thoroughly. Talk to that person.
- The org is new, a few months old, with no customisation. There is nothing to assess yet.
- The decision has not been made. First you need to know whether to move at all, and that is a readiness assessment question, which comes first.
- The total budget is small enough that four days of analysis eat a disproportionate share of it. There, the risk is accepted and contained with a small scope.
What you do with it afterwards
The value is not the document. It is that from now on everyone argues about the same facts. It lets you ask two different partners to quote against the same baseline and actually compare them, recognise the inflated line when you see it, and have an answer when somebody in a steering committee asks why it costs that much.
If the document does not put you in a position to do those three things, you did not buy an assessment. You bought four days.
Frequently asked questions
How long should a data architecture assessment take?
Three or four working days for a defined scope: one org, the systems that talk to it, the data model and the access model. If someone proposes twenty, either the scope is far wider than you need or the assessment is funding the supplier's learning curve out of your budget. If someone proposes half a day, you are buying a checklist filled in on a call.
Do we need one if the technology is already chosen?
That is exactly when you need one. Choosing the platform settles the what; the assessment settles whether the how holds up: which data has to move and what state it is in, which integrations have to be rebuilt, which permissions have to be redesigned and how much internal time it takes. It is the difference between an estimated quote and a defensible one.
Can the partner who will implement it also run the assessment?
They can, and technically they often do it well. The issue is not competence, it is incentive: whoever writes the assessment also decides the size of the project that follows. If it is the same party, at minimum insist that assumptions and exclusions are written out explicitly, so somebody else can check them.
How is this different from a readiness assessment?
A readiness assessment looks at the organisation: processes, ownership, skills, data quality, and whether a use case exists that holds. An architecture assessment looks at the systems: data model, integrations, access, technical debt. The first answers "are we ready", the second answers "what are we standing on". If you can only run one, readiness usually comes first.
Related
- Architecture & Data Assessment - the version I run, with scope and price.
- What to ask a Salesforce partner before signing
- Why Salesforce AI projects fail
Sometimes the best advice I can give you is that you do not need the assessment. That is a result too.