Given the immutable nature of the Smart Contracts (as well as the transactions) in a Blockchain, and the impact a (buggy) Smart Contract can have across a business network (as highlighted by The DAO Attack), Smart Contracts require extra due diligence. Having worked with Business Rules Management Systems (especially IBM Operational Decision Manager/ILOG) for the past 10+ years, I see a lot of similarities between Smart Contracts and Decision Services. Though they have different purpose (Smart Contracts are used to manage the state of an underlying asset, and Decision Services are used to make decisions), both of them are essentially a collection of business rules with rule flows, and both of them have similar needs.

Support for Custom Business Friendly Rules Language: Decision Services require a business friendly language so that they can be easily authored and maintained by business users. Since each business can have a different business vocabulary, the language needs to be customizable. Similarly, as I summarized in my last post, Smart Contracts have a legal aspect, and need a rules language, which can combine the legal prose with code. Since each industry can have different vocabulary, Smart Contracts also need a customizable rules language.

Support for Rules Templates: In case of Decision Services, Rules Templates allow a business user to create multiple instances of a business rule by parameterizing the corresponding Rules Template. A similar need exists for Smart Contracts so that common rules templates can be created for an industry, which then can be customized by each business network (as needed).

Support for Rules Analysis: Similar to a Decision Service, Smart Contract rules also require Static rules analysis as well as Semantic Query capabilities. While Static rules analysis can help identify those rules (within a Smart Contract) that might be conflicting, overlapping, may cause domain violation, or may cause the Smart Contract to use too much CPU (or Gas), Semantic Query can help identify rules (across Smart Contracts) that might be affected by a change in regulations.

Support for Business Driven Change and Release Management: Like Business Rules, Smart Contracts also requires Business Driven Change and Release Management. Based upon the agreed upon Change and Release Management process, (permissioned) parties in a business network should be able to simulate changes to a SmartContract, initiate a Change Request; approve or deny a Change Request; make the changes to the Smart Contract; test changes to the Smart Contract; approve or reject the changes; and deploy the new version of the Smart Contract.

Support for Versioning and Routing: Some of the Business Rules Management Systems use a well-defined versioning strategy to automatically route the requests for a Decision Service to the latest backward compatible version of the Decision Service (if the request does not specify a specific version). Similar capability is needed for the Smart Contracts so that the Smart Contracts requests and registered users can be automatically moved to the latest backward compatible version (with bug fixes) of the Smart Contract.

Conclusion: Given the similarities between Smart Contracts management needs and the Decision Services management needs, with some modifications, it might be possible to manage Smart Contracts using Business Rules Management Systems. For example, if Hyperledger can add support for ILOG Rule Language (IRL) then it might be possible to develop and manage Smart Contracts using IBM Operational Decision Manager – Decision Center. This requires further investigation.

For more on blockchain, join our upcoming webinar:

As I mentioned in my previous post, Blockchain is a design pattern that describes a system or network of nodes in which the ledger (i.e. a common temper-proof ledger that contains all the transactions) is maintained on multiple nodes, and there is a consensus (among the nodes) on which nodes have correct copy of the ledger (so that the system can recover even if some of the nodes are compromised). Each participating node has a piece of code that receives the transaction request, validates the request (i.e. checks the transaction pre-requisites), and executes the transaction (i.e. update the underlying asset state). Typically, this piece of code/program is called a “Smart Contract”. Depending on the underlying Blockchain implementation, this code can be written in different languages. For example, Ethereum supports Solidity, and Hyperledger currently supports Go (or GoLang).

But as Stark points out, the term “Smart Contract” is also used to represent a legal contract that can be expressed and executed in software. He distinguishes the two as – “smart contract code” and “smart legal contract”. Clack, Bakshi, and Braine combines the two aspects, and provides a more complete definition of “Smart Contract” –

“A smart contract is an agreement whose execution is both automatable and enforceable. Automatable by computer, although some parts may require human input and control. Enforceable by either legal enforcement of rights and obligations or tamper-proof execution.”

Smart Contract code have some unique characteristics.

• Deterministic: Since a Smart Contract code is executed on multiple distributed nodes simultaneously, it needs to be deterministic i.e. given an input, all nodes should produce the same output. That implies the Smart Contract code should not have any randomness; it should be independent of time (within a small time window because the code might get executed a slightly different time in each of the nodes); and we should be able to execute the code multiple times.
• Immutable: Smart Contract code is immutable meaning that once deployed it cannot be changed. This of course is beneficial from the trust perspective but it also raises some challenges (e.g. how to fix a code bug) and implies that Smart Contract code requires additional due diligence/governance.
• Verifiable: Once deployed, Smart Contract code gets a unique address. Before using the Smart Contract, interested parties can view or verify the code.

The Idea of Smart Contracts came from Nick Szabo who said “Many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.” In reality, it is hard to fully embed the entire contractual clause in the software – for technical and legal reasons. Let’s look at the technical reason in the context of a simple financial contract – “if the stock price goes above X then the stock should be sold”. There are two problems in embedding this clause into a Smart Contract code – first, it is time dependent (assuming the external call to get the stock price is made from within the Smart Contract which is a no-no for some people); and second, it cannot be executed multiple times (unless Stock Exchange is part of Blockchain). From a legal point of view, a contract typically contains terms and conditions (to protect the parties from damages) that cannot be converted into executed code, e.g. an indemnity clause.

Different Blockchain implementations are trying to address these problems in different ways. For example, to address the technical limitations, Ripple relies on “Smart Oracles” (or Codius) to implement the business logic which essentially moves the business logic out of Blockchain and puts it into the application layer (that can be attested by a third party). To address the legal issue, Eris/Monax uses Dual Integration which ties the Smart Contract code to the legal document and vice-a-versa. R3/Corda, on the other hand uses Smart Contract Templates  which captures a Smart Contract as Ricardian Contract triple of “prose, parameters and code”.

Conclusion: Smart Contract is a powerful concept that allows the Blockchain design pattern to be applied to complex situations. But Smart Contract has some limitations which need to be kept in mind when thinking of Blockchain use cases. In addition, given its impact, Smart Contracts require extra due diligence/governance.

For more on blockchain, join our upcoming webinar:

Hopefully by know you have heard the term “blockchain” multiple times and have come across multiple definitions. For example, Wikipedia defines it as – “a blockchain — originally, block chain — is a distributed database that maintains a continuously-growing list of records called blocks secured from tampering and revision. Each block contains a timestamp and a link to a previous block.” The Wall Street Journal defines it as, “A blockchain is a data structure that makes it possible to create a digital ledger of transactions and share it among a distributed network of computers. It uses cryptography to allow each participant on the network to manipulate the ledger in a secure way without the need for a central authority.” To lots of people, it is known as the technology that underpins Bitcoin (digital currency). Investopedia defines it as, “A blockchain is a public ledger of all Bitcoin transactions that have ever been executed.” IBM defines it as, “Blockchain is a technology for a new generation of transactional applications that establishes trust, accountability, and transparency while streamlining business processes.”

Of course all of those definitions are correct i.e. blockchain is a technology; it is a temper-proof distributed transaction database; it is a data structure; and it underpins Bitcoin. But they fail to explain the buzz around it – what is the big deal? It is not that we didn’t have distributed databases before, or the encryption technology to encrypt the transactions, or the technology to establish the trust.

In order to understand the importance of blockchain, we need to look at the problem it solves. Whenever you have multiple parties involved in a transaction (e.g. when you are buying a home, or transferring asset from one bank to another), each party keeps track of the transaction (in their private ledger), and there is usually a middle person or party to settle the transaction (to make sure that the transactions information and the transactions order matches). As you can imagine, this is inefficient, expensive, insecure, and hard to audit. One obvious alternative is a centralized database – such a solution will be efficient, less expensive, and easy to audit, but it will be less secure. Therefore, people have been trying to solve the problem using a distributed database i.e. a system in which THE ledger (i.e. a common temper-proof ledger that contains all the transactions) is maintained on multiple nodes, and there is a consensus (among the nodes) on which nodes have correct copy of THE ledger (so that the system can recover even if some of the nodes are compromised). In 2008, Satoshi Nakamoto published a research paper that defined a design pattern to distribute and effectively temper proof THE ledger. Which became the basis for Bitcoin in 2009. This design pattern is commonly known as Blockchain.

Though this paper was targeted towards peer-to-peer payments from one party to another without going through a financial institution, it is equally applicable to any asset transaction between multiple parties without a settlement agent or clearing house, with some changes of course. For example, Satoshi Nakamoto’s design allowed any node to participate in the network but business-to-business networks are typically closed and require explicit permissions for participation, and in a closed/permissioned network one can use more efficient consensus algorithms like Practical Byzantine Fault Tolerance (PBFT) consensus protocol. This has led to multiple technical implementations/variations of Satoshi Nakamoto’s design (including one by Satoshi Nakamoto called Ethereum), which can be grouped under Permissionless vs Permissioned (IBM is a premier member of Linux Foundation’s Hyperledger Project, which is an open source, collaborative effort to create a blockchain for business), and to possible use cases beyond Finance. HHS recently had a contest to apply Blockchain to healthcare. They received 70 submissions and choose 15.

Source IBM

Hopefully by now you have a better understanding of Blockchain, and you are probably thinking about the potential use cases in your industry, and how that might affect your company, your business model, your business processes, your applications, and/or your data sources? Maybe Perficient can help. Through our industry expertise in Health Sciences, Financial Services, Consumer Markets, Automotive, Energy + Utilities, Telecommunications, and Manufacturing; our Organization Change Management practice; and our deep skills in Business Process Management, Information Management, and Integration, we have helped a number of customers, and we have a 90% Repeat Business Rate.

On-Demand Webinar

Many organizations are finding blockchain to be as confusing as it is promising. We cut through the hype and shared a practical way to get started, including how to determine where it fits within your organization. We covered the following in our on-demand webinar:

• Why adopt the technology?
• What makes a good use case?
• What are some specific industry applications?
• What are the best practices for getting started?

Source: Gartner (August 2016)

I have been working with IBM BPM for the past 10 years and recently started looking at Pega and Appian. In this blog, I’ll share my impression, and comparison, of IBM BPM, Pega 7, and the Appian platform.

My Impression of IBM BPM

I have been working with IBM BPM for past 10 years – first five years with WPS (WebSphere Process Server), and recently with IBM BPM Standard (i.e. Lombardi). IBM BPM has all the core capabilities needed to build and run BPM solutions (workflow as well as straight-through-processing). I find IBM BPM to be technically very powerful and flexible. But that is its strength as well as weakness, because the same power and flexibility also leads to complexity, increasing the learning curve and the development cost (good/experienced resources are expensive).

From governance and administrative perspective, I really like IBM’s approach of using a central repository. The richness of its APIs makes it easy to integrate with other products and to automate the deployment lifecycle.

IBM BPM has a very process-centric view, which is not surprising for a BPM product, but because a typical business solution also requires a data-centric view, it becomes difficult to meet business requirements with IBM BPM alone. As a result, the business generally doesn’t have a very positive first experience unless the process-centric views provided by IBM BPM (e.g. task list or dashboards) are well integrated with the data-centric views using an external portal/web front-end.

Nowadays, lines of business are also looking for ways to reduce the time to market, and (as much as possible) make the changes themselves (e.g. changes to business logic without involving IT resources). While IBM BPM includes (limited) business rules capabilities, these rules cannot be changed without IT involvement.

[IBM offers a complementary product – IBM Operation Decision Manager (ODM) that allows the business to manage the changes to business rules. IBM ODM provides a dedicated web interface that enables business users with no technology background to manage releases from Dev to Production with a built-in governance framework for managing these releases].

Overall, I feel that IBM BPM is a great fit for organizations with complex IT structure and/or complex IT requirements.

My Impression of the Pega 7 Platform

Before I looked at Pega 7 platform, I believed that it would be similar to any other BPM platform (i.e. it will have a process modeler, a way to define the business objects, create interfaces, define rules, something similar to process portal etc.), and only reason Pega is different because it has pre-built frameworks/applications for different verticals. But when I started looking into Pega 7 platform, I realized that it is much more complex – not only because it provides more BPM capabilities but because it also provides a platform to both build and manage business processes and also to build and extend business frameworks/applications. No wonder it is hard to find good Pega system architects!

The Pega 7 platform leverages an inheritance structure to reuse and extend structural as well as behavioral elements of an application (i.e. elements that describe when or how things work e.g. a case, a process, an interface, a data transformation, a business rule, a when pre-condition etc.). This not only allows Pega to deliver frameworks and applications that can be extended by customers but also allows the customers to build their own frameworks that can be reused across the organization or divisions.

[Pega has a number of industry-specific offerings (frameworks/applications) that are built on top of Pega 7 platform]

Business rules in Pega can be delegated to business for change (using the same interface that is available to IT). But the change still needs to go through the IT change management process i.e. there is no business-specific interface to manage the change.

[Pega has a complementary decision management offering – Pega Decision Management which includes Predictive and Adaptive decision management capabilities, and integrates well with the Pega 7 platform]

Case (i.e. a business transaction like a service request, a purchase order etc.) is a center piece of Pega’s BPM capabilities, and it is used to define the primary and alternate stages a business transaction goes through, and the optional steps that can be taken within each stage. Pega uses processes to describe a step within a stage. Technically, the same thing can be achieved by just using the concept of processes and ad-hoc tasks, but Pega’s approach definitely enforces the process decomposition best practices.

Apart from the typical BPM capabilities, the Pega 7 platform also includes data integration, mapping, and caching capabilities which makes it easy to use data with cases/processes and in reports. While these capabilities are impressive, I won’t recommend using them for high-volume ETL processing (because of cost, scalability, and performance concerns).

There are other complementary things that make Pega 7 complete. For example, the platform includes the requirements management capabilities (requirements, specifications, and technical artifacts can be tied to each other – providing traceability), and Pega has built an implementation methodology called Direct Capture of Objectives (DCO) around it. The platform also includes the capability to enforce best practices called Guardrails.

Overall, I am pretty impressed by the Pega 7 platform from the development perspective. While one can use the platform to build one-off applications/processes, I can’t imagine someone buying this platform for that. The value of the platform is in building business-critical applications that would need to be changed/enhanced for years.

My Impression of Appian

I started looking at Appian and Pega 7 around the same time, and the two products can’t be more different and impressive at the same time. While Pega’s focus is on development platform, Appian’s focus is business users. No wonder business users love the Appian product.

Appian is built to improve how organizations make business decisions. Appian follows a philosophy they call Business Decision Cycle which consists of  Awareness, Knowledge, and Action.

Appian includes the news/social collaboration capabilities. These capabilities are not unique to Appian (IBM BPM also includes the social collaboration capabilities) but how Appian has made this a central pillar of its product is pretty unique. News and posts can be tagged with records.  Records provide a complete view of a business entity (such as a customer, product, or a service request) across different systems in the organization. Users can start processes in the context of these records using related actions – completing the cycle of Awareness, Knowledge, and Action.

Since actions can also be taken without a context of a record (e.g. to create a record), or might be in the context of a process, Appian business user portal, called Tempo, (apart from tabs for News, Records, and Reports) also have tabs for Actions and Tasks.

In Appian, it is very easy to create custom portals for targeted users, using what is called Sites.

From the development perspective, Appian’s focus seems to be rapid development. Appian includes pre-built connectors for external systems like SAP, SFDC etc., and provides tools to quickly create Records and Reports.

Appian doesn’t have a separate concept of a Case but concepts of News, Records, Processes and Quick Tasks seems more than sufficient to handle any case management-related requirements.

[And to prove the point, Appian has a sample application called Case Management Framework. There are other case management applications, built by Appian partners, which are available from the Appian Appmarket.]

Couple of things that I found lacking in Appian are – business rules, and pre-defined application folder structure. Appian supports expression rules but no business rules (e.g. Decision Tables or Decision Trees). Appian recommends an application folder structure to capture expression rules and constants but does not create that structure automatically.

Despite the above mentioned short-comings, Appian is great fit for those organizations that lack visibility to complete information, and/or are looking for quick solution to specific workflow problems.

Conclusion

Overall, all three of these products are impressive and lead Gartner’s Magic Quadrant for Intelligent Business Process Management Suites for good reason. Any are excellent tools for organizations looking to implement BPM solutions to increase operational efficiency, but they do have different strengths depending on a business’s focus.