Enterprise blockchain
The technology is rarely what makes these fail.
A permissioned network is an agreement between organisations that happens to be enforced by software. The engineering is tractable. What sinks these projects is unsettled governance — who runs it, who decides, and what happens when two members disagree in public.
Whether it fits
What has to be true first.
A shared database with good access control solves most of what people bring to a permissioned network, more cheaply and with fewer organisations in the room. These are the conditions under which it does not.
More than one organisation writes
If a single party produces every record and the others only read, a shared system of record with signed exports does the job. The interesting case is when several parties add to the same history and none of them is willing to be the custodian.
Nobody is the natural operator
Where an obvious owner exists — a regulator, a central body, the dominant buyer — a conventional system operated by them is simpler and usually wins. Permissioned networks earn their cost where appointing that operator is the problem, not the answer.
The history has to be disputable
The value is being able to demonstrate, later and to a third party, what was recorded and when, without asking the other side for their copy. If nobody ever expects to contest the record, this is expensive machinery for a problem you do not have.
Participants are known and admitted
Membership is deliberate, identity is established, and access can be withdrawn. That is what separates this from a public chain, and it is also why almost every hard question here turns out to be about the admission process.
If two or more of those are not true, we will say so on the first call rather than scoping a network around it.
Governance
The questions that decide whether this survives.
These are answered before the technical design, because each one changes it. Left until after launch, they become disputes rather than decisions.
Who runs the nodes
Every member, a subset, or a neutral operator on their behalf. This determines what any single party can do alone, and it is the question most consortiums answer by accident — whoever built it ends up running it, which quietly makes them the authority nobody agreed to appoint.
How a change is approved
Upgrading the shared logic changes the rules for everyone at once. Who proposes, what threshold carries, how long the notice is, and whether a member can decline and remain. A network that can be upgraded by one participant is that participant’s system.
How a member joins
Who admits them, on what criteria, and what they can see of the history that predates them. Admission is the point at which a technical network becomes a commercial arrangement, and the criteria need to exist before the second member asks.
How a member leaves
Voluntarily, by acquisition, or by expulsion. What happens to their records, their access, their node and their obligations. This is the question consortium agreements most often omit, and the one that arrives fastest.
Who settles a dispute
When two members disagree about what the record means rather than what it says, software does not help. The escalation path is named, and it ends somewhere outside the network.
Who pays for it
Infrastructure, operations and development have a cost that outlives the pilot. Splitting it by member, by usage or by a founding party’s subsidy is a governance decision with a long tail, and the subsidy case tends to end abruptly.
Identity
Known participants, and what that requires.
The defining property of a permissioned network is that you know who everyone is. Maintaining that is ongoing work rather than a setup step.
Organisational and individual identity are different
A member organisation holds a place in the network; the people acting for it come and go. Conflating the two produces credentials that cannot be revoked when someone changes job.
Revocation has to actually work
Withdrawing access is tested rather than assumed. A certificate that remains accepted after revocation is the failure that makes the whole permissioned model untrue.
It connects to systems that already exist
Members have their own directories and their own joiners-and-leavers processes. Identity that only lives inside the network becomes stale the first time an organisation reorganises.
Authority is recorded with the action
Not only who acted, but on whose behalf and under what mandate. In a dispute a year later, that is the part being examined.
Confidentiality
Shared does not mean visible to everyone.
Members are frequently competitors. A design where all participants see every transaction is one most consortiums cannot adopt, whatever its other merits.
Most of it should not be on the ledger
Commercial terms, documents and personal data usually stay with their owner. What is shared is enough to prove a claim about them — a commitment, a reference, a signature — rather than the content itself.
Visibility is scoped to the parties involved
A transaction between two members is not the business of the other eight. Which participants can see what is part of the data model, not an access rule bolted on above it.
Personal data and immutability conflict
A record that cannot be deleted sits badly with a right to erasure. This is resolved by keeping personal data off the shared ledger entirely, and it is resolved at design time because it cannot be resolved afterwards.
Metadata leaks more than expected
Even without contents, who transacted with whom and how often is commercially sensitive between competitors. If that matters, it constrains the design rather than being noted as a caveat.
Operations
Who runs it on a Sunday.
A network spanning several organisations has no single operations team unless one is deliberately created.
Monitoring nobody owns is monitoring nobody reads
Health of the shared network is somebody’s named responsibility, with an agreed definition of what degraded means and who is called.
Upgrades are coordinated, not announced
Members run their own infrastructure on their own change calendars. A version change is a scheduled multi-party exercise with a rehearsal, not an email.
An incident crosses organisations
Who declares it, who speaks to whom, and what each member is obliged to do. Agreed in advance, because during an incident is a poor time to discover the members disagree about escalation.
Exit is designed while things are amicable
How a member extracts their data in a usable form, and how the network continues without them. Designing this when relations are good is considerably easier than designing it when they are not.
Questions
The ones worth asking first.
Could a shared database do this instead?
Often, yes — and where it can, it should. The test is whether any participant would accept another as the custodian of the record. If one of them would be trusted to hold it, a conventional system with signed audit exports is cheaper, faster and easier to operate. The permissioned network earns its cost when that trust is precisely what is missing.
Do we need a token?
Almost never in this context. Tokens exist to incentivise strangers to maintain a network. In a permissioned network the participants are known, contractually bound and already motivated. Adding a token usually adds a regulatory question without solving an engineering one.
What if the other members are not ready?
Then the network is not ready, and building it first does not help. The realistic path is usually a narrow pilot between the parties that are ready, designed so admitting the others later does not require rebuilding it. We would rather scope that honestly than deliver infrastructure waiting for members who never arrive.
Who owns the shared code?
That is a governance decision to make early, and the options have consequences: one member, a joint vehicle, or open source under a licence the members agree. What does not work is leaving it with whoever wrote it, which is how a supplier ends up holding the network.
How does this meet regulatory requirements?
Which requirements apply is a determination for your compliance function, not for us. What we do is build to what they confirm, and tell you when a design decision has a compliance consequence — the clearest example being that personal data on an immutable shared ledger is very difficult to reconcile with erasure obligations.
Can it connect to the systems we already run?
That is usually the larger half of the work, and it is engineering in its own right rather than an afterthought to the network. The integration page covers how a chain is connected to the resource planning, identity and payments systems already in place.
Tell us who has to agree.
Describe the organisations involved and what they need to be able to prove to each other. If the honest answer is that one of them could simply hold the record, that is what you will hear.
info@eorbitt.com · We reply within one business day.