Blockchain Solution Architecture and Design Process

Introduction and Context

Blockchain projects rarely fail because a development team cannot write a smart contract. They fail because the proposed solution does not address a real business problem, assigns trust to the wrong parties, stores unsuitable data on-chain, or selects a platform before requirements are understood. Blockchain solution architecture is therefore a disciplined process for translating organisational objectives into a technically feasible, governable, secure, and economically justified system.

A blockchain architecture is not simply a distributed ledger. It is a socio-technical arrangement consisting of people, business processes, applications, identity services, data stores, consensus mechanisms, smart contracts, governance rules, and operational controls. The ledger is one component within this wider arrangement.

This chapter presents a practical design process for diploma-level blockchain professionals. It focuses on stakeholder analysis, use-case selection, trust and data-flow modelling, platform evaluation, architectural patterns, prototyping, and build-versus-buy decisions.

Learning Objectives

By the end of this chapter, you should be able to:

1. Translate business requirements into blockchain suitability criteria.
2. Identify stakeholders, their responsibilities, incentives, and trust relationships.
3. Select and prioritise blockchain use cases.
4. Model trust boundaries, data flows, and on-chain/off-chain responsibilities.
5. Compare permissionless, permissioned, and hybrid platforms.
6. Design reference architectures using suitable architectural patterns.
7. Plan a prototype and evaluate it against measurable acceptance criteria.
8. Make defensible build-versus-buy decisions.
9. Recognise governance, privacy, legal, ethical, and operational risks.

1. From Business Problem to Architecture

A sound design begins with a business problem rather than the statement “we need blockchain.” The problem should be expressed in terms of a measurable outcome. Examples include reducing reconciliation time, improving provenance, preventing unauthorised alteration of records, or enabling shared visibility between organisations that do not fully trust one another.

A useful problem statement identifies:

• the process currently being performed;
• the participants and their roles;
• the information that must be exchanged;
• the source of disagreement or delay;
• the desired outcome;
• legal and operational constraints; and
• measures of success.

For example, “use blockchain to track products” is incomplete. A stronger statement is: “Manufacturers, logistics providers, and retailers need a shared, tamper-evident history of custody events so that product recalls can identify affected batches within two hours rather than two days.”

1.1 Blockchain suitability questions

Blockchain is more likely to be appropriate when:

1. Several independent organisations must write to a shared record.
2. Participants have limited trust or conflicting incentives.
3. There is a need for a common history of transactions or state changes.
4. An independent central operator is undesirable, unavailable, or politically unacceptable.
5. Rules can be expressed as deterministic digital logic.
6. Auditability and provenance are important.

A conventional database is often preferable when one trusted organisation controls the process, high throughput and low latency dominate, or records must be frequently edited and deleted. Distributed ledger technology does not automatically create truthful data; it preserves accepted inputs. This is commonly expressed as the “oracle problem”: a ledger can prove what was submitted, but not necessarily whether an external event was reported honestly.

1.2 Requirements classification

Requirements should be separated into categories because each category influences architecture differently.

Quality attributes must be measurable. “Fast” should become a target such as “95% of confirmation responses within 10 seconds under 500 transactions per second.” The precise target depends on the domain and should be validated with stakeholders rather than invented by architects.

2. Stakeholder and Trust Analysis

A blockchain solution changes authority. It may distribute validation, expose information to new participants, automate decisions, or replace informal coordination with coded rules. Stakeholder analysis must therefore address both technical roles and institutional interests.

2.1 Stakeholder categories

Important stakeholder categories include:

• Business owners, who define value and accept outcomes.
• Transaction participants, who create or consume records.
• Validators or ordering services, which confirm transaction order or state changes.
• Network operators, who maintain nodes and infrastructure.
• Identity and membership authorities, which issue credentials or control admission.
• Regulators and auditors, who require evidence and compliance.
• Data subjects, whose personal or commercially sensitive information may be processed.
• Support and security teams, who handle incidents, upgrades, and key recovery.
• External service providers, such as cloud, oracle, custody, or analytics vendors.

For each stakeholder, document interests, powers, risks, information rights, responsibilities, and incentives. A participant may have the right to submit data but not to validate transactions. Another may validate transactions but be prohibited from viewing confidential payloads.

2.2 Trust is multidimensional

Trust should not be treated as a single yes-or-no property. At least four dimensions are useful:

1. Identity trust: Can a participant be identified reliably?
2. Data trust: Is submitted information accurate and authorised?
3. Process trust: Will business rules be applied consistently?
4. Institutional trust: Are governance and dispute mechanisms accepted?

Blockchain primarily supports process integrity, auditability, and shared state. Identity, data accuracy, and institutional legitimacy still require governance, credentials, controls, and human accountability.

A trust boundary is a point at which assumptions change. For example, an enterprise application may trust its own database but not a supplier’s system. A blockchain network may provide a shared state between those organisations, while each organisation remains responsible for the truthfulness of its submitted data.

2.3 RACI and authority mapping

A RACI matrix can clarify responsibility:

• Responsible: performs the activity.
• Accountable: owns the result.
• Consulted: provides expertise or approval.
• Informed: receives relevant information.

For each transaction type, identify who may propose it, who may endorse or validate it, who may view it, who may dispute it, and who may reverse or correct it. “Immutable” should not be interpreted as “impossible to correct.” A robust design defines correction transactions, versioning, compensating entries, or governed migration procedures.

3. Use-Case Selection and Prioritisation

A use case is suitable only when it provides a meaningful advantage over alternative architectures. A practical screening process can use the following questions:

1. Is there a shared process across organisational boundaries?
2. Do participants require a common source of truth?
3. Is there a material dispute, reconciliation, or provenance problem?
4. Are transactions sufficiently structured to be digitally represented?
5. Can the organisation tolerate the governance and operational complexity of a network?
6. Can privacy and regulatory requirements be satisfied?
7. Is the expected benefit greater than total lifecycle cost and risk?

3.1 Prioritisation model

Projects often begin with several candidate use cases. A transparent scoring model can support discussion. For example, a team may rate each candidate from 1 to 5 for business value, feasibility, trust need, compliance fit, and adoption readiness. If equal weights are used, the mean score is:

where S is the suitability score and B, F, T, C, and A are the five ratings. This is not a universal law; it is a decision aid. Scores are ordinal judgements, so the result should not be treated as precise measurement. Teams may use weights where some criteria are more important:

where each w is a non-negative weight and the weights sum to 1. The scoring assumptions and evidence supporting each rating should be recorded.

3.2 Use-case decomposition

A broad use case should be decomposed into:

• actors and permissions;
• assets or records being represented;
• events and state transitions;
• preconditions and postconditions;
• exceptional and dispute paths;
• privacy classifications;
• external data dependencies; and
• success measures.

For example, a certificate-verification system may include issuance, transfer, verification, revocation, expiry, and correction. Each operation may require different permissions and may store different information.

4. Trust, Data-Flow, and Asset Modelling

Architecture becomes clearer when the team models what moves through the system and where trust changes.

4.1 Asset and state modelling

An asset may be physical, digital, financial, or evidential. Examples include a shipment, title, tokenised deposit, credential, or inspection result. For each asset, define:

• unique identifier;
• owner or custodian;
• current state;
• permitted transitions;
• evidence required for transition;
• participants allowed to act; and
• retention and deletion requirements.

A state-transition model is often more useful than a simple data dictionary. For a shipment, states might be Created → Packed → Dispatched → Received → Accepted, with exception states such as Damaged or Disputed.

4.2 Data-flow modelling

A data-flow model should show systems, actors, messages, storage locations, and trust boundaries. It should distinguish:

• transaction metadata;
• business payloads;
• personal data;
• confidential commercial information;
• hashes or commitments;
• credentials and signatures; and
• external evidence.

The central architectural question is not “what can be stored on-chain?” but “what must be shared, independently verifiable, durable, and governed as ledger state?”

Figure: A reference view of participants, enterprise systems, the blockchain network, and external data services.

4.3 On-chain and off-chain design

On-chain data is replicated or made available according to the platform’s ledger model. It should normally be limited to data that participants must share and validate. Suitable examples include identifiers, timestamps, state transitions, hashes, permissions, and references to evidence.

Off-chain systems are generally more appropriate for large documents, personal information, high-volume sensor data, confidential records, and content subject to deletion or correction. The ledger may store a cryptographic hash of a document to support later integrity verification. A hash does not hide data that has already been published, and it may still create privacy concerns if it is linked to an identifiable person.

A common pattern is:

1. Create or receive a document.
2. Store it in an authorised repository.
3. Calculate a cryptographic digest.
4. Record the digest, document identifier, issuer, and timestamp on the ledger.
5. Later retrieve the document and recompute the digest.
6. Compare the values to detect alteration.

This pattern proves consistency between the document and its recorded digest; it does not prove that the original document was truthful.

5. Reference Architecture Layers

A reference architecture provides reusable structure without pretending that every project is identical.

5.1 Presentation and channel layer

Web applications, mobile applications, partner portals, and administrative consoles provide user interaction. This layer should not expose private keys directly to ordinary users without suitable protection. It should enforce user experience and input validation but must not be the only location where business rules are enforced.

5.2 Integration and API layer

APIs connect enterprise applications, devices, identity systems, and blockchain services. Integration should address authentication, authorisation, idempotency, error handling, message ordering, rate limits, and observability. An idempotent operation produces the same intended outcome when a request is safely retried. This is important because distributed systems may deliver messages more than once.

5.3 Blockchain application layer

This layer contains transaction orchestration, smart contracts, policy checks, event handling, and ledger queries. Smart contracts should be small, deterministic, tested, and explicit about failure conditions. They should not depend on local time, uncontrolled randomness, network calls, or inconsistent external state unless the platform provides a reliable mechanism.

5.4 Network and consensus layer

This layer provides peer communication, transaction ordering, validation, replication, and finality. The appropriate mechanism depends on the threat model and governance model. Permissionless networks typically support open participation and economic or cryptographic resistance to abuse. Permissioned networks usually identify participants and may use authorised validators or enterprise consensus mechanisms.

5.5 Data, identity, and operations layers

Identity services manage keys, credentials, certificates, roles, and revocation. Data services manage off-chain records, indexes, archives, and analytics. Operations include monitoring, backup, disaster recovery, incident response, upgrades, key rotation, and configuration management.

6. Platform Evaluation

Platform selection should follow requirements analysis. Important criteria include:

Performance claims must be tested in the target configuration. A benchmark on a laboratory network may not represent production conditions. Test variables should include transaction size, endorsement or validation policy, number of nodes, network latency, failure rates, concurrent clients, and database configuration.

6.1 Permissionless, permissioned, and hybrid models

A permissionless network allows broad participation and commonly provides public verifiability. It may be suitable for public assets, open verification, or applications requiring censorship resistance. It may introduce transaction fees, privacy challenges, uncertain governance, and variable confirmation times.

A permissioned network restricts participation through identities or membership rules. It is often suitable for regulated consortia and enterprise workflows. It may provide stronger privacy and predictable governance but requires an admission authority and may reproduce centralisation risks.

A hybrid design may keep proofs or selected events publicly verifiable while retaining sensitive payloads and operational processing in a permissioned environment. Hybrid systems increase integration and governance complexity, so their additional value must be demonstrated.

7. Architectural Patterns

7.1 Shared ledger pattern

Multiple organisations write authorised transactions to a common ledger. The pattern reduces reconciliation where participants need the same transaction history. It requires agreed data models, governance, identity, and dispute procedures.

7.2 Tokenisation pattern

A digital token represents an asset, right, claim, or obligation. The design must define legal meaning, ownership, transfer restrictions, custody, redemption, and what happens if the underlying asset is lost or misrepresented. A token is not automatically legal title.

7.3 Credential and verification pattern

An issuer signs a credential, a holder stores or presents it, and a verifier checks authenticity, issuer authority, status, and relevant claims. Privacy-preserving designs may reveal only necessary attributes rather than the complete credential.

7.4 Notarisation and proof-of-integrity pattern

A system records a hash or commitment to establish that a document or event existed in a particular form at a particular time. This is appropriate when the full content should remain outside the ledger.

7.5 Escrow and workflow pattern

A smart contract holds or controls an asset until specified conditions are met. Such systems need timeout rules, exception handling, oracle governance, and a lawful dispute-resolution mechanism.

7.6 Event-log and provenance pattern

The ledger records a sequence of signed events. It is useful for audit and traceability, but event logs require clear interpretation: an event shows that a participant submitted a statement, not necessarily that the statement was objectively true.

8. Prototyping and Validation

A prototype should answer a decision question, not merely demonstrate attractive technology. Examples include:

• Can participants exchange and validate the required transaction?
• Can confidential information be kept outside the shared ledger?
• Does the platform meet the required latency under representative load?
• Can a compromised key be revoked and replaced?
• Can a correction or dispute be handled without destroying audit history?

A useful prototype plan contains a hypothesis, scope, test data, architecture, acceptance criteria, risks, and a decision date. The prototype should include at least one failure path and one governance scenario rather than only the successful transaction.

Acceptance criteria may include:

• successful execution of defined business workflows;
• correct permission enforcement;
• measurable response time under specified load;
• recovery after node or service failure;
• evidence that unauthorised data is not disclosed;
• traceable audit records; and
• operational procedures for key loss, upgrade, and dispute.

A prototype is not production. Production readiness additionally requires security assessment, threat modelling, privacy analysis, operational ownership, support arrangements, monitoring, backup, disaster recovery, documentation, and user training.

9. Build-versus-Buy Decisions

Build-versus-buy concerns more than software licence price. It includes total cost of ownership, integration effort, control, risk, skills, and strategic importance.

9.1 Build when

Building may be justified when the capability is strategically differentiating, requirements are unusual, strong control is necessary, suitable products do not exist, or the organisation possesses the required engineering and operational capability.

9.2 Buy or reuse when

Buying or reusing a product is often preferable for commodity capabilities such as identity management, monitoring, custody infrastructure, enterprise integration, or managed node hosting. Mature products may reduce time to deployment and operational risk, but contracts must be examined for lock-in, data access, service continuity, security obligations, and exit rights.

A decision matrix can compare alternatives against weighted criteria such as functional fit, security, compliance, lifecycle cost, time to value, interoperability, and vendor risk. The weights and evidence should be documented. A low initial price may be misleading if migration, integration, audit, and support costs are substantial.

10. Detailed Applied Case: Pharmaceutical Cold-Chain Provenance

The following is an illustrative case, not a report of a specific company.

Background

A pharmaceutical manufacturer distributes temperature-sensitive vaccines through logistics providers to hospitals. Participants maintain separate systems. During a suspected temperature excursion, the manufacturer may need several days to reconcile shipment identifiers, sensor readings, custody records, and receiving data.

Problem

The organisation wants faster investigation and stronger evidence of custody. However, temperature data is high-volume, hospitals require confidentiality, and not every participant should be able to view commercial details.

Analysis

Stakeholder analysis identifies the manufacturer, logistics providers, carrier operators, hospitals, regulators, sensor vendors, and an independent network governance body. Trust is limited between commercial participants, but all require reliable event history.

The asset is a shipment or batch. Important events include packing, dispatch, custody transfer, arrival, inspection, acceptance, rejection, and recall. The ledger should not store patient information or full sensor streams. Sensors are an oracle boundary: they provide data, but the architecture must address calibration, tamper detection, device identity, and exception review.

Approach and solution

A permissioned consortium network is selected because participants are identifiable and regulatory auditability is important. Each shipment receives a unique identifier. The ledger stores authorised custody events, event timestamps, participant signatures, sensor-data references, and hashes of signed evidence packages. Detailed sensor readings remain in controlled off-chain repositories.

Smart contracts enforce that only an authorised custodian can record a transfer, that the receiving party can acknowledge or dispute receipt, and that a shipment cannot be marked accepted after a recorded critical excursion without an approved review. A governance policy defines membership, validator responsibilities, key rotation, software upgrades, evidence retention, and dispute handling.

The prototype uses simulated shipments and representative sensor files. Tests include duplicate messages, delayed delivery, invalid signatures, a lost organisational key, unavailable off-chain storage, and a disputed temperature reading.

Outcome

The proposed design improves shared visibility and reduces reconciliation effort, but it does not guarantee that sensors are accurate or that a shipment was handled correctly. Its success depends on adoption, device governance, agreed data standards, operational support, and legally accepted evidence procedures.

Learning points

1. The ledger is only one part of the solution.
2. High-volume and sensitive data may belong off-chain.
3. Oracle quality and device governance are central to trustworthy provenance.
4. Dispute and correction paths must be designed before deployment.
5. A consortium needs governance as well as technology.

11. Governance, Ethics, and Regulation

Blockchain architecture distributes technical authority but does not remove accountability. A governance framework should define membership, voting or decision rights, validator duties, software upgrade processes, incident response, audit access, fee allocation, data retention, and dispute resolution.

Privacy requires data minimisation, purpose limitation, access control, encryption, selective disclosure where feasible, and careful treatment of identifiers. Personal data should not be placed on a public immutable ledger without a compelling lawful basis and a rigorous assessment. Even pseudonymous addresses can become identifying when combined with external information.

Smart contracts can automate harmful outcomes if rules are incorrect or circumstances change. Human review may be necessary for high-impact decisions such as credit, employment, healthcare, or access to essential services. Automated execution should not be confused with moral or legal legitimacy.

Security controls include secure key generation and storage, least privilege, code review, dependency management, transaction monitoring, incident response, backup, recovery testing, and independent penetration or smart-contract assessment. Governance must also address insider threats and collusion among validators.

12. Contemporary Developments and Professional Practice

Current design practice increasingly combines distributed ledgers with verifiable credentials, privacy-enhancing techniques, tokenised settlement, decentralised identifiers, zero-knowledge proofs, confidential computing, and interoperability protocols. These technologies can reduce data disclosure or connect networks, but they add assumptions and complexity. Architects should evaluate maturity, standards support, implementation quality, and operational consequences rather than adopting terminology as proof of suitability.

Artificial intelligence may assist with requirements extraction, anomaly detection, code review, and operational analysis. It should not be trusted to define governance, approve legal interpretations, or generate unreviewed smart-contract code. AI-generated outputs require expert validation, security testing, licensing review, and documented accountability.

Best practice is iterative: establish the business outcome, analyse trust, model assets and data, compare alternatives, prototype critical risks, involve legal and operational stakeholders, and revise the architecture before committing to production.

Chapter Summary

Blockchain solution architecture translates business objectives into a governed socio-technical system. The process begins with a measurable problem statement and requirements classification, not with platform selection. Stakeholder and trust analysis identify who may propose, validate, view, dispute, and correct transactions. Use cases should be selected only where shared state, auditability, provenance, or reduced reconciliation provide a defensible advantage over conventional systems.

Asset, state, trust-boundary, and data-flow models guide decisions about identity, smart contracts, consensus, and on-chain versus off-chain storage. Permissionless, permissioned, and hybrid platforms offer different combinations of openness, privacy, governance, performance, and cost. Reference architectures commonly include presentation, integration, blockchain application, network, identity, data, and operations layers.

Prototypes should test explicit hypotheses, including failure and governance scenarios. Build-versus-buy decisions must consider lifecycle cost, risk, skills, integration, control, and exit rights. Finally, privacy, security, legal accountability, data quality, oracle reliability, and dispute resolution are fundamental architecture concerns rather than afterthoughts.

Key Terms

Blockchain solution architecture: The structured design of people, processes, technology, data, governance, and controls for a blockchain-enabled solution.

Business requirement: A desired organisational capability, outcome, constraint, or quality attribute.

Trust boundary: A point where assumptions about identity, authority, data accuracy, or control change.

Stakeholder: A person, group, or organisation affected by or able to influence the solution.

RACI: A responsibility model identifying who is Responsible, Accountable, Consulted, and Informed.

Use case: A defined interaction through which actors achieve a business goal.

Asset: A physical, digital, financial, or evidential item represented or referenced by a system.

State transition: A permitted change from one asset or process state to another.

On-chain data: Data recorded or represented within the distributed ledger.

Off-chain data: Data maintained outside the ledger in a separate repository or service.

Oracle: A mechanism that supplies external information to a blockchain application.

Permissionless network: A network designed for broad or open participation.

Permissioned network: A network in which participation is controlled by identity or membership rules.

Smart contract: Deterministic software that enforces or supports agreed transaction rules.

Finality: The point at which a transaction is considered settled or irreversible under a specified model.

Tokenisation: Representing an asset, right, or claim with a digital token.

Notarisation pattern: Recording a proof, often a hash, to support later integrity verification.

Build-versus-buy: A structured decision about developing a capability internally or obtaining it externally.

Governance: Rules and processes for participation, authority, change, accountability, and dispute resolution.

Review Questions

Short Answer Questions

1. Why should a blockchain project begin with a business problem rather than a technology choice?
2. What is a trust boundary, and why is it useful in architecture modelling?
3. Give two examples of information that may be better stored off-chain.
4. Distinguish between a permissionless and a permissioned network.
5. Why must a prototype include failure and governance scenarios?

Long Answer Questions

1. Explain how stakeholder analysis and a RACI matrix can shape blockchain permissions and governance.
2. Describe a systematic process for selecting and prioritising blockchain use cases.
3. Compare shared-ledger, tokenisation, credential-verification, and notarisation patterns.
4. Explain the main layers of a blockchain reference architecture and their responsibilities.
5. Discuss the security, privacy, legal, and ethical risks of immutable or automated records.

Analytical / Application Questions

1. A consortium wants to store complete customer contracts and personal details directly on a shared ledger. Analyse the proposal and recommend an alternative data architecture.
2. Design a prototype plan for a blockchain-based professional-credential verification service. Define stakeholders, trust boundaries, on-chain data, off-chain data, and acceptance criteria.
3. An organisation can either build a custom network or buy a managed permissioned platform. Develop a decision framework using functional fit, security, compliance, lifecycle cost, interoperability, governance, and vendor risk.

Multiple Choice Questions with Answers

Question 1

Which condition most strongly supports considering a blockchain solution?

A. One trusted organisation owns all data and controls every update

B. Several independent organisations need a shared, auditable transaction history

C. The application requires frequent deletion and unrestricted editing of records

D. The primary requirement is the lowest possible single-server latency

Correct Answer: B. Several independent organisations need a shared, auditable transaction history

Question 2

Which trust dimension concerns whether submitted information is accurate and authorised?

A. Identity trust

B. Data trust

C. Process trust

D. Institutional trust

Correct Answer: B. Data trust

Question 3

What is the main purpose of a RACI matrix in solution architecture?

A. To calculate transaction fees

B. To select a consensus algorithm automatically

C. To clarify responsibility and accountability for activities

D. To encrypt off-chain documents

Correct Answer: C. To clarify responsibility and accountability for activities

Question 4

Which item is generally most suitable for off-chain storage?

A. A transaction state identifier

B. A smart-contract permission rule

C. A hash of an evidence package

D. A large confidential document containing personal data

Correct Answer: D. A large confidential document containing personal data

Question 5

What does recording a document hash on a ledger primarily help demonstrate?

A. That the document was truthful when created

B. That the document is consistent with the recorded digest

C. That the document can never be deleted from every system

D. That the document was approved by every network participant

Correct Answer: B. That the document is consistent with the recorded digest

Question 6

Which feature is characteristic of a permissioned blockchain network?

A. Participation is controlled through identity or membership rules

B. No participant can be identified under any circumstances

C. Any anonymous actor may validate every transaction

D. Governance is impossible once the network launches

Correct Answer: A. Participation is controlled through identity or membership rules

Question 7

A prototype that only demonstrates a successful transaction is incomplete mainly because it does not test:

A. The colour scheme of the user interface

B. Failure, security, and governance conditions

C. Whether blockchain terminology is used in documentation

D. Whether the network has a public website

Correct Answer: B. Failure, security, and governance conditions

Question 8

Which statement about an oracle is most accurate?

A. It guarantees that external data is truthful

B. It supplies external information but introduces a trust and governance boundary

C. It replaces identity management in every blockchain network

D. It makes off-chain storage unnecessary

Correct Answer: B. It supplies external information but introduces a trust and governance boundary

Question 9

Which factor is especially important in a build-versus-buy decision?

A. The number of blockchain-related words in vendor marketing

B. Lifecycle cost, integration effort, control, and exit risk

C. Whether the product uses the newest terminology

D. Whether a prototype can avoid all operational procedures

Correct Answer: B. Lifecycle cost, integration effort, control, and exit risk

Question 10

In a weighted suitability score, what must the weights normally satisfy when they represent proportions of total importance?

A. They must all be negative

B. They must sum to 0

C. They must sum to 1

D. They must all be greater than 5

Correct Answer: C. They must sum to 1