A Short Look Back at 2016

I have found very little in the last month and a half to add to previous posts.  CO2 continues its alarming rise, to what will in all likelihood be more than 406 ppm (yearly average) by end of year, and while global temperatures have ended their string of monthly records, we are still on course for a 1.2 degree C rise since 1850, about 0.3 degrees of it in the last 2 ½ years.  The big news in the Arctic (and Antarctic) is an unprecedented low in sea ice extent/area, plus record high temps in the Arctic in December – but that continues a smaller trend evident in most of the first half of 2016. 

Meanwhile, on the computing side, relatively little real-world innovation happened this year.  In-memory computing continued its steady rise in both performance and applicability, with smaller companies taking more of a lead as compared to 2015.  While blockchain technology and quantum computing made a big news splash early in the year, careful reading of “use cases” shows that real-world implementations of blockchain are thin on the ground or non-existent, as most companies try to figure out how best to make it work, while quantum computing is clearly far from real-world usefulness as of yet.

The big news in both areas, alas, is therefore the election of Donald Trump as President.  In the climate change area, as I predicted, he is proving to be an absolute disaster, with nominees for at least six posts that are climate change deniers with every incentive to make the American government a hindrance rather than a help in efforts to change “business as usual.” 

In the computing area, we see the spectacle of some large computing firms offering their services in public to Trump, an unprecedented move based on the calculation that while being seen as cooperative may not bring any benefits, failure to act in this way may cause serious problems for the firm.  Thus, we see Silicon Valley execs whose workforces are not at all enthused about Trump acting in meetings with him as if he offers new business opportunities, and IBM’s CEO announcing ways in which IBM technology can aid in achieving his presumed goals. 

It may seem odd to give such prominence to the personality of the President in assessing either climate change or the computing industry.  The fact is, however, that all of the moves I have cited are unprecedented, and derive from Trump’s personality.  To fail to consider this in assessing the likely long-run effects of the “new abnormal” in both the sustainability field and the computing industry is, imho, a failure to be an effective computer industry analyst.  And while no one likes a perpetually downbeat analyst, one that continually predicts rosy outcomes in this type of situation is simply not worth listening to.

I look back on 2016, and I see little that is permanent to celebrate – although the willingness of the media to begin to report on and accept climate change is, however temporary, worth noting.  I wish I could say that there is hope for better things in 2017; but as far as I can see, there isn’t.

IBM and Blockchain: Limited But Real Value

Last week, IBM announced an expansion of its blockchain capabilities to fully support secure networks for whatever uses its customers find for the blockchain technology.  Key features include support on IBM Cloud for developers, management of the environment aimed at rapid deployment via IBM Bluemix, and enhancements to the Linux Foundation open-source HyperLedger Project code for those seeking to implement blockchain use cases at least partly outside the IBM software/services umbrella.  My initial take is that IBM is laying a solid foundation for blockchain use.  More important, I find that it is likely that, with help like this, customers of blockchain technology may well find that it delivers real value-add in limited but nevertheless concrete ways.  That is, blockchain implementations with foundations such as IBM’s can deliver much less than what its most enthusiastic proponents would claim, but can provide it more reliably and immediately than, say, data lakes at this stage in its lifecycle.

It Begins With the Blockchain Technology

At present, the word “blockchain” is surrounded by clouds of hype and techie jargon that make its nature unusually difficult to understand.  However, reading between the lines, it appears that blockchain technology has two key new approaches:

1.       A “blockchain” data unit that lends itself flexibly to use in medium-scale applications involving many-to-many business-to-business processes, such as “smart contract” management or business-to-business asset exchange involving “clearing” and the like.

2.       A fully-replicated distributed database that allows each participant a full view of the “state” of the “blockchain” data and automates some of the security involved, e.g., the ability to block a single “bad actor” from altering the data by requiring “consensus” among all copies of the replicated data as to the validity of a new transaction.

More specifically, a typical “blockchain” implementation creates a string of data together with the transactions on it, each part of the string being a “block” containing a transaction and the resulting data, and each block containing a “hash” of the previous block, in effect a backward pointer to the transaction/data block previous in time/sequence to this one.  Thus, each blockchain contains its own readily accessible “audit trail”, copied to every node and hence every user.

On the networking side, as noted, the distributed database uses pure peer-to-peer networking with no central manager or “master record”.  Thus, more or less, according to the description in Wikipedia, if one transaction comes in on one node saying the resulting block should be as follows and another disagrees, all nodes need to look at what all the other nodes are saying (step 1) and determine what the “consensus” is (step 2).  They can then all independently create a new block, because they will all come to the same conclusion.  The result is that if one “bad actor” comes in and tries to corrupt the data, the consensus will reject that attempt every time it happens, no matter what the alias of the bad actor or how many times the bad actor tries, or even if the bad actor keeps switching the node of access.

The limitations of blockchain technology also come from these two new approaches.  For one thing, the “blockchain” data unit’s use of a “chain” approach to data access means that the database is simply not as scalable in most if not all cases.  There is a reason that most databases optimize direct access to each data unit:  the time taken to go backwards through the whole chain as a series of “reads” is much greater than the time for going directly to the data unit at the end of the chain.  IBM clearly signals this limitation on scalability by noting its ability to scale to “thousands of users” – laughably small for a consumer application, but quite appropriate for many business-to-business applications.

On the networking side, the requirement of “consensus” can significantly slow the process of committing a transaction – after all, one of the participants may not be responsive at one time or another.  Therefore, blockchain technology is less appropriate where the fastest possible transaction performance is needed, and more appropriate in automating existing approaches such as “clearing” (netting out transactions between businesses and then having each participant pay/receive the differences), which can take up to 3 days in some banking apps.

What Users May Wish to Watch Out For

As noted above, blockchain technology can deliver real benefits, particularly in security, speed-to-perform, and flexibility/ease of implementation and upgrade, for business-to-business many-to-many applications – but it probably will require extra care in implementation.  One area that I believe users should consider carefully is the long-term scalability of the blockchain technology.  It should be possible to get around the limitations of a blockchain data unit by writing to a “blockchain” veneer that looks like a blockchain but acts like a regular database (in fact, this is what a relational database does at the storage level).  However, this means that the implementation must use such a veneer religiously, and avoid third-party code that “hard-codes” blockchain access.

A second implementation detail that I recommend is pre-defining the blockchain technology’s links to existing systems.  In many cases blockchain data will need to be kept in sync with parallel updates going on in IT’s existing databases.  It’s not too early to begin to think how you’re going to do that.  Moreover, the blockchain approach is not a security cure-all, and therefore requires careful integration with existing security systems.

A third implementation “key decision” is whether to use some version of Bitcoin in implementing a blockchain solution.  I would recommend against this.  First, digital currencies modeled after Bitcoin have been shown in the real world to be vulnerable to “gaming the system”; in economic terms, unlike a good paper currency, it does not serve as a good “store of value”.  Second, Bitcoin has scaled beyond the “thousands of users” consensus needed for the business-to-business apps discussed here – but, in order to do so, it is now using a very significant part of the resources of the World Wide Web.  If you use Bitcoin, you must connect to that very large Bitcoin implementation, which will mean that your network performance may well be adversely impacted by constant demands for consensus from the Internet.

A Different Viewpoint

Interestingly, Steve Wilson of Constellation Research has recently come out with a strongly worded argument against business use of blockchain technology, with two key arguments:  (1) It actually adds nothing to corporate security; and (2) It does nothing that the business’ existing database can’t do. 

While I find myself in agreement with many of his technical viewpoints, I find that he overstates the effectiveness in the use case I have described above of present corporate security and of existing business databases.  Over the years, such functions as contract management and “episode management” in health care have been relatively ill-served by being lumped in with the rest of corporate security and implemented typically in relational databases.  The blockchain model is more like an “accounting ledger”, and the ability to use such a model in business-to-business interactions as well as for security inside and outside each participating business is a key long-term source of usefulness for today’s businesses.  To put it another way, the trend in business is away from the “one size fits all” database and towards “databases for specific purposes” that can add additional “domain” security and “ease of development”.

All in all, as long as businesses are savvy about implementation, there does appear to be an important use case for blockchain technology.  In which case, support like IBM’s is right on the mark.