Leadership wants to buy an enterprise architecture repository tool. How do you advise?

Ask what question it will answer

Tools fail here for one reason: the content goes stale. Within a year the repository lists systems that no longer exist, omits ones that do, and attributes ownership to people who left. It is then worse than nothing, because people trust it briefly and then stop.

So the question is not which tool. It is which facts will be maintained, by whom, and what makes maintaining them cheaper than not.

Prefer harvested facts over entered ones

Anything requiring manual entry will be incomplete within a quarter. What can be harvested should be: system inventory from the cloud accounts and the service catalogue, dependencies from network flow and gateway logs, ownership from the repository metadata teams already maintain, cost from the billing export.

What genuinely cannot be harvested is the business-facing layer — capabilities, process mapping, strategic intent — and that is a much smaller set to maintain by hand.

Then judge the tool on integration, not on features

Can it ingest from those sources automatically? Can it be queried by other systems? Does it export? A tool that is a destination rather than an aggregator will diverge from reality no matter how good its modelling.

The cheaper first step

A spreadsheet or a git-backed catalogue, populated by harvesting, answering the two or three questions that are currently expensive: who owns this, what depends on it, what does it cost. If that gets used, a tool is a reasonable next step and you will know what to require of it. If it does not get used, the tool would not have been either.