Architecture

Blockchain for Business: Separating Use Cases From Hype

Updated February 20, 2018By the CalliArc team

Key takeaway

A blockchain is worth considering only when multiple parties who don't trust each other must share a record and no acceptable central operator exists. If a trusted party can hold the database — and usually one can — a conventional shared system will be faster, cheaper, and easier to change.

Few technologies have generated as many proposals with as few production deployments. That's not because the idea is worthless — it's because the conditions it requires are rarer than the enthusiasm suggests.

Three questions that settle most proposals

  • Are there multiple independent parties writing to the same record? If it's one organisation, you want a database.
  • Do those parties actually distrust each other enough to reject a central operator? Most industries already have trusted intermediaries doing exactly this job.
  • Does the record need to be immutable and independently verifiable? If corrections are routine, immutability is a liability rather than a feature.
  • A no to any of these means a shared database with good access control and an audit trail will serve you better.

Where the case is genuinely stronger

  • Multi-party supply chain provenance, where competing participants must agree on a shared history.
  • Trade finance and settlement between institutions with no common system of record.
  • Registries of ownership or certification where independent verification matters and no single authority is accepted.
  • Even here, most production systems end up as permissioned ledgers among known participants — which is a governance arrangement as much as a technical one.

The problems people underestimate

  • Garbage in, immutable garbage out. A ledger guarantees the record hasn't changed, not that it was true when written — the link to physical reality still depends on people and sensors.
  • Privacy is genuinely hard: a shared ledger means shared visibility, and commercial counterparties rarely want that.
  • Throughput and latency are far below conventional databases, which rules out high-volume transactional use.
  • Key management becomes existential — a lost private key is a lost asset with no reset link.
  • Governance: who decides on an upgrade, who joins, and what happens when participants disagree. This kills more consortium projects than technology does.

If you're asked to explore it

Run the exercise honestly: write down the participants, what each writes and reads, and why a neutral hosted system wouldn't work. Most of the value in these projects comes from the first half — getting competing parties to agree on a shared data model and process. That agreement is worth having regardless of what technology you eventually store it in, and it's frequently the only durable outcome.

Share LinkedIn X

Ready to build it right?

Get a transparent, milestone-based estimate for your project in a free consultation.

Book a free strategy call