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:
