Blockchain 1 of 7 : Keep Your Solution Pure, Modest and Focused

​

Since the re-introduction of distributed ledgers, there has been tremendous misconception in what blockchain is and how it should be implemented in business centric portfolios.  Most of the misconception is a result of tremendous success of cryptocurrency implementations such as Bitcoin. Ethereum may serve a different purpose, but still has the concept of monetizing developers via its own currency to facilitate building distributed applications across its fabric.  Even Microsoft has engaged by offering “Ethereum Blockchain as a Service” (EBaaS) on Azure.

​

Let me play a game with you. What's the first thing that comes to your mind when I say, “Moses!”.  I guarantee most of you thought of Charlton Heston!  It’s only natural, Mr. Heston has been the face of Moses since 1956.  When the public hears the word “blockchain”, they immediately think of Bitcoin.  Again, it’s only natural.  The truth is that Charlton Heston is not Moses and Bitcoin is not blockchain.  Equally true is that blockchain for business has absolutely nothing to do with cryptocurrency.

 

In the first article, I talked about how consensus algorithms differ, each having their own merit. Proof of Work (POW) algorithms are designed for competitive consensus.  Incentivized consensus methods are typically CPU bound and will impact the transaction rate of the dependent application.  Bitcoin’s transaction rate is about 7 transactions per second. Ethereum is roughly 4 to 5 times faster (metrics shift but are available on the net). I have worked with business applications that demand thousands of transactions per second to achieve target performance. If I rivet CPU bound consensus onto a transaction bound application I would be foolish.  Business blockchain doesn’t need competitive consensus, it simply needs consensus.  

 

Not all applications are good candidates to be chained. If you are serious about gaining the most value of your blockchain adventure, I would encourage you to read the Assessment Phase of the ACT-IAC Blockchain Working Group, Blockchain Playbook.  The Playbook provides a weighted survey to help determine the applicability of blockchain as an appropriate solution.

​

https://www.actiac.org/act-iac-white-paper-blockchain-playbook-us-federal-government

​

If the application is a compelling candidate to be chained, begin the disciplined offer design process.  This pursuit will be driven by the Solutions Architect and they will have their own processes. However, I’ll touch on some key activities which have helped me, over the years, to keep the solution pure, modest and focused on the business requirements.

​

• Determine the stakeholders pain points and hot buttons. Spending time with my stakeholders helped me to gain an appreciation of their professional experiences. I take the time to understand 1) their business, 2) the technology supporting their portfolio, 3) industry partners I will be collaborating with and 4) overall sense of the customer's objectives and expectations. Overtime, I learn what “the win” looks like to them.  Business Development calls this “Customer Intimacy”, a key “Bid/No Bid” factor in any successful pursuit.  We will talk a lot more about this process in a couple days in a subsequent article dedicated to the process of educating myself.  

• Identify Similar Use Cases.  This is the process of finding “like” endeavors.  I have always found value in sharing successes of similar technical quests. The BWG is working on identifying use cases that can be referenced for specific industry verticals within the Playbook. GSA’s Unified Shared Services Management (USSM), Federal Integrated Business Framework (FIBF) are championing some of these use cases.  Please visit https://www.ussm.gov/fibf/ for more information of FIBF’s industry verticals.  

• Define the current AS-IS application profile.  Before I can begin to build out the new design, I must have a complete understanding of the anatomy of the candidate application.  I consider the entire IT stack, not just the upper application layer. I identified dependencies on other resources like the infrastructure, database, middleware etc.  If the application is cloud centric, I identify what components are public, private or hybrid. If distributed across multiple enclaves, I documented points of entry and firewall characteristics. I even consider the bandwidth of LAN/WAN resources.   Everything within reach of the application demands consideration.  

• Define the TO-BE application profile.   I cannot predict what your target architecture will ultimately look like. One thing that is important for me is to understand the attributes of what the customer considers a successful implementation. I document and then design for target performance metrics. I ensure that the solution is in alignment with the Enterprise Architect’s roadmap.  I always consider what a "win" looks like from the business lines perspective.

• Determine and acquire transformation enablers.  I identify all components that will enable the transformation of the application from AS-IS to the TO-BE profile.  Components are then characterized as “Enablers” and represent milestones within the critical path. Enablers could be dependent on technology, other projects, budget, people, training, skillsets, processes, policy, etc.  I focus on enablers within my sphere of influence and look to the stakeholder(s) to champion the enablers within their authority.  

 

Note the importance of customer/stakeholder engagement and partnership. Remember we are not selling a solution, rather, we are meeting a business need. Am I sounding redundant? Good!

 

The successful adoption of emerging technology for business applications will come from selecting the right solution for the right purpose.  Keep your solution pure, modest and focused.

​

Mike.Rice@CornerStoneIT-llc.com