Government blockchain adoption framework:
one method, twenty-plus Abu Dhabi authorities
Aetsoft contributed the technical use case evaluation and framework design to a blockchain strategy programme led by Berkeley Research Group for the Abu Dhabi government.
The work gave more than twenty government authorities one method for screening and comparing their proposals, and applied it to digital identity, trade finance and funds distribution.
001
ProgrammeAbu Dhabi government blockchain strategy
002
Programme leadBerkeley Research Group
003
Aetsoft's roleTechnical use case evaluation and framework design
Engagement lead
Pavel Sivayeu
CTO, Aetsoft Inc
Ran delivery and led the Aetsoft team across the engagement
Twenty authorities, twenty ways of judging
In 2018 Abu Dhabi was developing a blockchain strategy and asked government authorities to identify processes that might benefit. The answers covered identity, customs, procurement, social payments and land registry.
Each authority had assessed its own idea in its own way. Some had costed the work in detail without asking whether blockchain suited the problem. Others had settled on blockchain first and left the costs open. Because the proposals had been produced to different standards, the programme could not compare them.
BRG led the programme, with Aetsoft contributing the technical workstream. Our task was to give every authority the same questions, and to make the answers comparable across departments that had little else in common.
That constraint shaped the design. A method meant for more than twenty authorities has to produce comparable assessments without each team having to interpret a long technical methodology. Detail is where teams diverge. So we kept each instrument short, made the questions closed wherever we could, and left out factors that were more precise but open to reading.
BRG led the programme, with Aetsoft contributing the technical workstream. Our task was to give every authority the same questions, and to make the answers comparable across departments that had little else in common.
That constraint shaped the design. A method meant for more than twenty authorities has to produce comparable assessments without each team having to interpret a long technical methodology. Detail is where teams diverge. So we kept each instrument short, made the questions closed wherever we could, and left out factors that were more precise but open to reading.
The habit in 2018 was to choose a use case first and assemble the justification afterwards. We put the order the other way round. Before anyone discussed cost or value, a proposal had to pass a check on whether the technology suited the problem at all.
business case
A strong business case attached to the wrong technology is expensive to produce, and hard to withdraw once it has a sponsor.
The framework
Five questions
Five closed questions, answered before anything else.
1. Do several parties take part who do not fully trust one another?
2. Do they need a shared, authoritative record, rather than separate records that have to be reconciled?
3. Does something of value move, in a form a computer can hold?
4. Is there a middleman in the process worth removing?
5. Is a trusted authority already performing this function well?
Four yes answers and a no to the last, and the proposal went forward for detailed work. Anything else and it stopped here, on the view that a conventional system would serve the problem better.
We kept the questions crude on purpose. A subtler test would have been more precise and harder to apply the same way twice, because subtlety is where twenty authorities part company. The aim was comparability between departments, not identical answers inside them.
The framework
Two scores
The questions establish whether blockchain appears to fit the operating problem. Sequencing is a separate matter, so anything that survived was scored on two sides.
Impact. This score covered the time lost across the process, the duplicated checks that a shared record could remove, and the audit value of a tamper-evident transaction history.
Ease of adoption. This one covered what fails elsewhere if the process breaks, how sensitive the data is, how much of the process would need rebuilding, how much money sits in the system running it today, and whether the participants used compatible data formats.
More factors were available on both sides. Each one gives two departments another way to read the same process differently, and removing those was the point.
The framework
Four decision categories
The two scores place each candidate in one of four groups.
- Ideal. High impact and straightforward to adopt. Take it to proof of concept.
- Opportunistic. High impact, but blocked by rules, existing technology or resistance. Pilot a narrow slice.
- Selective. The process already works. Note it and revisit when the technology or the return improves.
- Avoidable. Low impact and hard to adopt. Leave it.
The last group is what earns the method its keep. Ruling work out is what a programme with twenty candidates and one budget needs most.
The framework
A six-stage roadmap
The framework closed with the route a surviving candidate would take.
Analyse the services and processes, define the technology blueprint, build a proof of concept, complete the policy and regulatory assessment, run a pilot, then deploy at scale.
Formal legal assessment sat at stage four as one of the roadmap's decision gates.
Three use cases
We ran three candidates through the framework end to end. For each one we documented the existing process and a proposed blockchain-based operating model. These were evaluation designs, not systems that were built.
Trade finance inside goods transport
Shipping documents moved on paper between many organisations, and because banks could not verify a bill of lading, the same document could support credit more than once. The proposed model placed the trade documents on a shared ledger. A smart contract would generate the invoice once importer and exporter agreed terms, the letter of credit would be drawn against the same record, inspection and customs checks would be written as they occurred, and confirmation of receipt would release payment. It scored highest for impact and lowest for ease, because most of the parties sit outside government control.
Digital identity in social services
Residents re-submitted the same documents to every service provider, and providers held personal data they had no lasting use for. The design gave residents custody of signed proofs about themselves, attested by trusted parties. A service provider would request only the attributes a transaction required, for a stated purpose and period. It scored best overall. Government would remain the trusted attester, and the use case addressed how those attestations could be reused across service providers, with residents controlling what was shared and every party relying on a common verification record.
Funds distribution in finance
Orders travelled through advisers, transfer agents, administrators, custodians and distributors, taking days to settle, with identity checks repeated at every new relationship. The model assumed a smart contract handling the order, net asset value published to the network, and settlement executing against it. It also modelled a shared verification hub that would check an investor once and answer later queries from other participants. Strong impact, limited government control, so it scored opportunistic.
What the engagement
produced
- A five-question screening checklist
- An impact and ease-of-adoption scoring model
- Four decision categories
- Three documented use cases, each with an existing process and a proposed operating model
- A six-stage evaluation roadmap
- A workshop on site involving representatives from more than twenty government authorities
- Blockchain adoption policy document
Because all three use cases had been scored the same way, the programme could compare them on the same basis.
There are no operational performance figures on this page. The engagement was advisory and it closed before anything was built.
What we took from it
The candidates that scored strongest were those where both sides stood to gain something concrete. For the authority, the expected gains included lower running costs and tighter control of sensitive data. For citizens and businesses, they included less repetition and clearer control over who could see their information.
The roadmap also pushed teams to look past a proof of concept. A pilot exposes scalability and interoperability problems. Wider deployment raises ownership, governance and operating responsibility, and those questions need owners before rollout begins.
The lasting value was not a promise that blockchain would improve every government process. It was a method for deciding which proposals deserved further work and which should stop.
Frequently asked questions about the government blockchain adoption framework
-
When should a government process stay off a blockchain?
When one body already holds the record and everyone involved trusts it. Blockchain earns its cost where several parties who do not fully trust each other need one shared, authoritative version of events. Where a trusted authority already provides that, a conventional system will usually be faster to build and cheaper to run.
-
What is a blockchain use case evaluation framework?
A test applied before a candidate blockchain project is approved for detailed business-case or technical work. Aetsoft’s version had three parts: five closed questions that removed work blockchain could not help with, a score covering impact and ease of adoption, and four categories that turned those scores into a decision.
-
How do you keep the criteria consistent across departments?
By keeping them few and blunt. Aetsoft used five closed questions and two scores, fewer than the problem strictly warranted. Every additional factor gives two teams another way to read the same process differently, and comparability between teams matters more than precision inside any one of them.
-
Is a framework from 2018 still relevant?
The framework belongs to this engagement and should not be read as Aetsoft’s complete methodology today. Its central principle holds: test the operating problem and the expected value before committing to a technology-led programme. A current assessment would also have to cover jurisdiction, data protection, governance, integration and who owns the system once it runs. That is where most of our blockchain consulting work begins.
Aetsoft works through the operating case and the delivery path before anyone commits to a build.
