Adopting Blockchain into Enterprise Architectures:

Key Considerations and Recommendations

—Nelson Petracek, CTO, TIBCO Strategic Enablement Group

INTRODUCTION
Blockchain and related technologies such as distributed ledgers (DLT), consensus
algorithms, cryptography/hashing strategies, and smart contracts have the
potential to change the way many organizations share data and execute
business processes across a network of companies. With a blockchain solution,
one may be able to eliminate the need for third-party clearing houses and
increase auditability, security, reliability, timeliness, and automation of business
transactions and data.
Blockchain technology is promising, and the number of use cases continues to
grow regardless of vertical. Given this growing interest—and proliferating prototypes
and early deployments to increase experience—it’s important to understand
blockchain implications and its impact on overall enterprise architecture.
This whitepaper presents questions that should be asked when assessing
blockchain technology, as well as a reference architecture that includes key
capabilities required for ensuring a successful roll out. While it isn’t possible to
include all considerations and combinations of technologies in this whitepaper,
it is hoped that the capabilities presented will assist enterprise architects in their
evaluation and architectural refinement.
 WHITEPAPER | 2

WHEN IS A BLOCKCHAIN RELEVANT?

As with any technology, it’s critical to determine the conditions under which
blockchain should be applied. Blockchain can solve many, but not all, problems.
One needs to define the criteria that should be met by using questions such as
the following:
• What are the required trust, integrity, and security levels?
• How much data would be stored in the blockchain? Does all of the data need to
be stored in the ledger or will some of it be stored outside? If off-chain storage
will be used, how will this data be referenced by the transactions in the ledger?
• How large is the business network? Will each network participant be able to
access or store all information? Do the transactions need to be partitioned
across the network?
• What are the performance and transaction processing requirements of
the network?
• Is there a need to automate business processes across the network? How
complex is the automation logic?

The answers to these types of questions will help determine if a blockchain (or
related technology) should be used and the features required. For example, if the
business network is small, or if the interactions only involve simple data passing,
then a blockchain may not be needed, and traditional B2B messaging protocols or
API-led integrations may be sufficient.
If it’s determined that a blockchain-related solution is a fit, additional components
will be necessary for a successful rollout. Just as a database is not the only
component in application architectures, a blockchain needs to be augmented with
capabilities that address questions such as those in the following diagram.

Can I provide
How do I How do I
How do I controlled,
How do I get extend smart analyze data
respond to managed, and
data in/out of contract logic contained
events from secure access
the blockchain? to my within the
my ledger? to blockchain
enterprise? ledger?
capabilities?

REFERENCE ARCHITECTURE
While many architectural views are possible, the diagram below depicts one
view that includes the components often necessary for a successful blockchain
implementation. Starting from the bottom of the diagram and working upwards, note
that the distributed ledger/blockchain, security components, blockchain APIs, and
smart contracts are capabilities typically offered by a blockchain technology stack.
Third-party vendors offer the other components.
 WHITEPAPER | 3

API Management Analytics

Microservices & Process Automation Event Handlers

Data Distribution Transport

Off-Chain Execution

Smart Contracts
Blockchain Proxy Layer
ChainCode, Solidity ...

HFC REST JSON

Web3 Blockchain APIs
SDK HTTP RPC

Off-Chain Storage

Distributed Ledger
Blockchain
Security
On-Chain Execution and Storage

DISTRIBUTED LEDGER / BLOCKCHAIN / SECURITY

The distributed ledger/blockchain/security layer represents the core blockchain
technology stack. There are various options for this layer, including common
implementations such as Hyperledger Fabric or Ethereum. For the purposes of
this whitepaper, it is assumed that a permissioned (private) blockchain technology
will be used (for example, based on a fork of a public blockchain, or via a solution
originally created as a permissioned blockchain). In most cases, the business network
participants will be known and will join the network to derive the associated benefits.
For the near future, it is likely that most organizations will approach building related
solutions in this manner.

BLOCKCHAIN APIs
Blockchain APIs are the low-level programming interfaces offered to developers
for interacting with the blockchain. The APIs exposed will depend on the
technology selected, with options such as REST/HTTP, NodeJS (e.g. Hyperledger
Fabric Client SDK), or Javascript (e.g. Ethereum Web3.js) available.

BLOCKCHAIN PROXY LAYER

A blockchain proxy layer is introduced to create a level of abstraction between
the underlying core blockchain technology stack and integrated applications
or services. When communicating via this layer, all blockchains look the same,
reducing the level of dependency on the selected technology and allowing for
decoupled solution architectures. Note that given the state of today’s blockchain
technology stacks, it can be difficult to achieve a completely generic proxy layer
as capabilities and approaches often vary greatly between solutions. However, the
use of system-level microservices that bundle commonly used blockchain features
can facilitate the creation of such a proxy layer.

SMART CONTRACTS
Smart contracts are programmable constructs often used to create the business
logic that will be executed as part of a blockchain-based business network. Typically
written in languages such as Java, Javascript (for example, Ethereum’s Solidity),
or Go (Hyperledger Fabric Chaincode), smart contract logic is deployed into the
network and executed to automate business transactions across participants. Smart
contracts may use underlying state stores to store information, and they may also
add transactions to the blockchain itself (which can later be queried).
 WHITEPAPER | 4

DATA DISTRIBUTION TRANSPORT

Blockchain interactions may involve many endpoints, including user applications,
enterprise systems, or system/business APIs. Interactions may be bi-directional
(initiated by the blockchain itself or by an enterprise application), and both
synchronous and asynchronous in nature. Typically implemented as a messaging
layer that supports publish-subscribe semantics, the use of an enterprise-scale data
distribution transport layer can:
• Improve endpoint location independence
• Increase the ability of the architecture to scale (both in data volumes and number
of endpoints)
• Guarantee message delivery
• Reduce the overhead associated with polling or pure request/reply
based approaches

A data distribution transport often also forms the basis of an event-driven

blockchain architecture.

MICROSERVICES AND PROCESS AUTOMATION

Microservices and process automation (such as workflow or case management)
capabilities are typically used to implement the enterprise business services
that will use the blockchain layer for establishing a business network—or for
incorporating other blockchain-related capabilities into defined business logic.
While a complete discussion on microservices and process automation is beyond
the scope of this paper, it is important to consider the strategies and patterns
used to create and deploy business services within an enterprise architecture,
and to consider the technical, operational (DevOps) and organizational aspects.
(See http://www.melconway.com/Home/Conways_Law.html for a sample of how
organizational structure may influence software design.)

EVENT HANDLERS
Event handlers are components configured to listen for changes to the blockchain
or the connected endpoints, and to automatically invoke appropriate enterprise
logic in response to these changes. For example, event handlers may receive
notification via a callback of a new transaction on the ledger, or they may receive
a message from a connected enterprise application via the data distribution
transport. Event handlers typically work in conjunction with the blockchain APIs
and data distribution transport, and may be bundled or created as microservices
within the enterprise architecture. Events handlers also facilitate creation of the
event-driven architecture discussed previously.

API MANAGEMENT
APIs are driving the ease with which applications can share information both inside
and outside the firewall. As blockchain capabilities are deployed within and across
enterprises, and as levels of abstraction are defined (e.g. via a proxy layer, event
handlers, or microservices/process automation), it will become important to control
and manage access to these business level APIs (which subsequently access the
system or low-level blockchain APIs). To do so, an API gateway or broader API
management platform may be used. This layer allows an enterprise to:
• Define security capabilities independent of the services themselves
• Expose APIs as products, for example, for use by third party developers
• Control API contracts
• Obtain visibility into the performance and use of the APIs

These APIs may also provide access to the data (transactions) within the
blockchain, again via well-defined interfaces and security controls.
 WHITEPAPER | 5

ANALYTICS
As a blockchain is deployed across a business network, and as transactions are
added to the distributed ledger, the blockchain will soon contain (or reference) a
large amount of extremely valuable information.
• How can a business make use of this information (assuming appropriate
security and visibility) to improve business decisions?
• How can events (transactions) sent to/received from the blockchain be viewed
immediately (for example, in the case of attempted fraud), without waiting for
batch-style reports to be delivered?
• How can the results of automated business transactions and processes be
analyzed for identifying process improvements, detecting SLA violations, or
conforming to regulatory requirements?

The analytics layer in the proposed reference architecture may be used to answer
these types of questions. Within the strict security guidelines of the implemented
blockchain technology stack (and typically via secured APIs), users may access,
view, and analyze state and transaction data (both in batch and real time) to
identify threats or opportunities in the network.

OFF-CHAIN EXECUTION AND STORAGE

Any blockchain implementation will require an analysis of what should be done
on-chain vs. off-chain. Tradeoffs need to be considered, including storage
requirements, overall blockchain size, performance, block size limits, data
longevity/durability requirements, smart contract access to off-chain content,
and the need for a globally consistent state. The identified storage strategy
and approach may also help determine if a blockchain is truly needed, or if a
distributed storage approach like IPFS is sufficient for the use case.

REFERENCE ARCHITECTURE MAPPING TO TIBCO’S PRODUCT STACK

TIBCO customers may choose to use one or more TIBCO products to provide
the capabilities needed to support a successful blockchain deployment. Many
of these capabilities are not directly dependent on the underlying blockchain
technology (providing the ability to choose the best solution for your use cases),
and may also be used across multiple (and varying) blockchain deployments.
TIBCO products related to the proposed reference architecture are indicated in
the diagram below.

API Management Analytics

TIBCO Mashery® TIBCO Spotfire®, TIBCO® Live Datamart

Microservices & Process Automation Event Handlers

TIBCO Hybrid Integration, TIBCO ActiveMatrix® BPM TIBCO BusinessEvents®, TIBCO StreamBase®

Data Distribution Transport

Off-Chain Execution TIBCO FTL®/TIBCO eFTL™
TIBCO (Various)

Smart Contracts
Blockchain Proxy Layer
ChainCode, Solidity ...
TIBCO Hybrid Integration
TIBCO BusinessEvents

HFC REST JSON

SDK HTTP RPC
Web3 Blockchain APIs

Off-Chain Storage
TIBCO® GraphDB
ActiveSpaces®
Distributed Ledger
Blockchain
Security
On-Chain Execution and Storage
 WHITEPAPER | 6

As an example, consider a typical government use case that involves capturing

and recording property (asset) and ownership transactions over the life of the
asset. Providing an immutable, auditable, shared, and secure record of these
transactions across a network of business participants may require the use of
a blockchain in addition to many of the capabilities described in the proposed
reference architecture.

REFERENCE RELATED CAPABILITIES PROVIDED

ARCHITECTURE TIBCO PRODUCTS
COMPONENT

BLOCKCHAIN PROXY Hybrid Integration Blockchain system-level

LAYER Platform API abstraction.

SMART CONTRACTS TIBCO BusinessEvents Rule and context driven

smart contract definition.

DATA DISTRIBUTION TIBCO FTL / TIBCO eFTL Real-time, brokerless

TRANSPORT messaging and
data distribution.

MICROSERVICES & Hybrid Integration Microservice and

PROCESS AUTOMATION Platform model-driven case
management / workflow
TIBCO ActiveMatrix BPM application creation.

EVENT HANDLERS TIBCO BusinessEvents Event-driven

logic execution,
TIBCO StreamBase streaming analytics.

API MANAGEMENT TIBCO Mashery End-to-end API

definition, deployment,
and management.

ANALYTICS TIBCO Spotfire Rich visual discovery,

predictive/prescriptive
TIBCO Live Datamart analytics, real-
time visualization
and interaction.

OFF-CHAIN STORAGE TIBCO Graph Database Polyglot off-chain

persistence via native
TIBCO ActiveSpaces® graph or NoSQL storage.

Applied to the use case, and using a number of the TIBCO products outlined in
the previous table, a deployed solution may include:
• A core blockchain technology such as Hyperledger Fabric.
• Use of the TIBCO BusinessEvents contextual/stateful event processing engine
as a way of defining smart contract logic. This engine may be embedded in
the blockchain itself (for example, in a peer), or deployed separately for off-
chain execution.
• Use of the TIBCO eFTL environment (and included Javascript API) for interacting
with the Hyperledger Fabric Node.js Client SDK (HFC SDK). This messaging
technology event-enables the Node.js client (via the HFC SDK EventHub object
and the eFTL API) and allows for message-driven communications between the
data distribution transport and the rest of the architecture.
 WHITEPAPER | 7

• TIBCO FTL as the data distribution transport. This messaging environment acts as
the decoupling layer between Hyperledger Fabric and other solution components.
• Use of TIBCO’s Hybrid Integration Platform (TIBCO® Cloud Integration and
TIBCO BusinessWorks™ Container Edition) to provide API contract definitions
(for example, defined via Swagger), API-led microservice creation/deployment
capabilities, and low-level system services (proxies). These components
may interact with Hyperledger Fabric in a decoupled manner, using either
synchronous (for example, for supporting ownership query requests) or
asynchronous (such as asset transaction submission) patterns.

Continuing the example, asset transactions could be submitted via the defined
REST interface (optionally managed by an API management layer such as
TIBCO Mashery) and choreographed by TIBCO Hybrid Integration Platform-
based microservices (running on a private or public cloud, within platforms
such as Docker or Cloud Foundry). The transaction could then be delivered
to a blockchain proxy layer via TIBCO FTL, and submitted to the blockchain
technology via TIBCO eFTL and the blockchain API. After any associated “smart
contracts” (implemented as native code or within TIBCO BusinessEvents) are
executed and the transaction is added to the blockchain, the event handlers
may detect the successful addition of the transaction and perform additional
enterprise processing. This example is depicted in the diagram below:

TIBCO Cloud Chaincode

Integration
API Spec
Docker Container(s) Docker Container(s)

Hyperledger
REST/JSON TCP/IP WS Fabric
TIBCO eFTL API
HFC SDK (CA, Orderer,
Peer, CLI)
TIBCO BusinessEvents
TIBCO FTL TIBCO eFTL
Swagger UI TIBCO Engine

BusinessWorks
Container Edition
Land Ownership

ParcelIdentifier
BlockLot
Address
Owner
OwenershipType
LandValue
TransferDate

The use of such a reference architecture provides a number of benefits, including:

• Secure, abstract, managed, and business-level API access to underlying
blockchain capabilities.
• Model-driven microservice creation and deployment (on-premises or in a
cloud), reducing the time needed to deploy blockchain-powered services.
• Decoupled, location-independent services for interacting with
blockchain capabilities.
• Clean separation of the exact blockchain technology used from the rest of the
enterprise. This capability is especially important at this time, given the rapid
evolution and changing landscape of blockchain technologies and vendors.
• Event-driven blockchain interactions, eliminating the need for polling or point-
to-point based communications.
 WHITEPAPER | 8

This same approach could be used with a number of blockchain use cases,
including those related to product provenance, IoT, consumer contract
automation (including insurance claim processing), energy/electricity distribution,
digital rights management, know your customer (KYC), health care, government,
and many others.

SUMMARY
Blockchain solutions will result in a substantial change in the way applications are
developed and deployed. However, as previously discussed, a blockchain is not
always the answer. Various factors must be taken into account to determine if it
is appropriate. It is also important to gain awareness through experimentation,
so that guidelines and best practices can be established early to help guide you
through your blockchain journey. Finally, as discussed, it is likely that these best
practices will include one or more components of the reference architecture
discussed in this whitepaper.

Global Headquarters TIBCO enables digital business solutions through smart technologies that interconnect everything and augment
3307 Hillview Avenue intelligence. This combination delivers faster answers, better decisions, and smarter actions. TIBCO provides
Palo Alto, CA 94304 a connected set of technologies and services, based on 20 years of innovation, to serve the needs of all parts
+1 650-846-1000 TEL of an organization—from business users to developers to data scientists. Thousands of customers around
+1 800-420-8450 the globe differentiate themselves by relying on TIBCO to power innovative business designs and compelling
+1 650-846-1005 FAX customer experiences. Learn how TIBCO makes digital smarter at www.tibco.com.
©2017, TIBCO Software Inc. All rights reserved. TIBCO, the TIBCO logo, ActiveMatrix, ActiveSpaces, BusinessWorks, Mashery, Spotfire, StreamBase, TIBCO
www.tibco.com BusinessEvents, TIBCO eFTL, and TIBCO FTL are trademarks or registered trademarks of TIBCO Software Inc. or its subsidiaries in the United States and/or
other countries. All other product and company names and marks in this document are the property of their respective owners and mentioned for identification
purposes only.
05/03/17