import random
 from visualdl import LogWriter
 logdir = "./tmp"
 logger = LogWriter(dir, sync_cycle=10)

# mark the components with 'train' label.
 with logger.mode("train"):
   # create a scalar component called 'scalars/scalar0'
   scalar0 = logger.scalar("scalars/scalar0")

# add some records during DL model running, lets start from another block.
 with logger.mode("train"):
   # add scalars
   for step in range(100):
       scalar0.add_record(step, random.random())

visuaIDL --logdir <some log dir>

So, there’s this thing called “blockchain” which is quite popular…

You know that already, of course.  I keep wondering if we’ve hit “peak hype” for blockchain and related technologies yet, but so far there’s no sign of it.  As usual for this blog, when I’m talking about blockchain, I’m going to include DLTs – Distributed Ledger Technologies – which are, by some tight definitions of the term, not really blockchains at all.  I’m particularly interested, from a professional point of view, in permissioned blockchains.  You can read more about how that’s defined in my previous post Is blockchain a security topic? – the key point here is that I’m interested in business applications of blockchain beyond cryptocurrency[1].

And, if the hype is to be believed – and some of it probably should be[2] – then there is an almost infinite set of applications for blockchain.  That’s probably correct, but that doesn’t mean that they’re all good applications for blockchain.  Some, in fact, are likely to be very bad applications for blockchain.

The hype associated with blockchain, however, means that businesses are rushing to embrace this new technology[3] without really understanding what they’re doing.  The drivers towards this move are arguably three-fold:

1. you can, if you try, make almost any application with multiple users which stores data into a blockchain-enable application;
2. there are lots of conferences and “gurus” telling people that if they don’t embrace blockchain now, they’ll go out of business within six months[4];
3. it’s not easy technology to understand fully, and lots of the proponents “on-the-ground” within organisations are techies.

I want to unpack that last statement before I get a hail of trolls flaming me[5].  I have nothing against techies – I’m one myself – but one of our characteristics tends to be enormous enthusiasm about new things (“shinies”) that we understand, but whose impact on the business we don’t always fully grok[6]. That’s not always a positive for business leaders.

The danger, then, is that the confluence of those three drivers may lead to businesses deciding to start moving to blockchain applications without fully understanding whether that’s a good idea.  I wrote in another previous post (Blockchain: should we all play?) about some tests that you can apply to decide whether a process is a good fit for blockchain and when it’s not.  They were useful, but the more I think about it, the more I’m convinced that we need some simple tests to tell us when we should definitely not move a process or an application to a blockchain.  I present my three tests.  If your answer any of these questions is “yes”, then you almost certainly don’t need a blockchain.

Test 1 – does it have a centralised controller or authority?

If the answer is “yes”, then you don’t need a blockchain.

If, for instance, you’re selling, I don’t know, futons, and you have a single ordering system, then you have single authority for deciding when to send out a futon.  You almost certainly don’t need to make this a blockchain.  If you are a purveyor of content that has to pass through a single editorial and publishing process, they you almost certainly don’t need to make this a blockchain.

The lesson is: blockchains really don’t make sense unless the tasks required in the process execution – and the trust associated with those tasks – is distributed between multiple entities.

Test 2 – could it work fine with a standard database?

If the answer to this question is “yes”, then you don’t need a blockchain.

This question and the previous one are somewhat intertwined, but don’t need to be.  There are applications where you have distributed processes, but need to store information centrally, or centralised authorities but distributed data, where one may be yes, but the other “no”.  But if this is question is a “yes”, then use a standard database.

Databases are good at what they do, they are cheaper in terms of design and operation than running a blockchain or distributed ledger, and we know how to make them work.  Blockchains are about letting everybody[8] see and hold data, but the overheads can be high, and the implications costly.

Test 3 – is adoption going to be costly, or annoying, to some stakeholders?

If the answer to this question is “yes”, then you don’t need a blockchain.

I’ve heard assertions that blockchains always benefit all users.  This is a patently false.  If you are creating an application for a process, and changing the way that your stakeholders interact with you and it, you need to consider whether that change is in their best interests.  It’s very easy to create and introduce an application, blockchain or not, which reduces business friction for the owner of the process, but increases it for other stakeholders.

If I make engine parts for the automotive industry, it may benefit me immensely to be able to track and manage the parts on a blockchain.  I may be able to see at a glance who’s supplied what, when, and the quality of the steel used in the ball-bearings.  On the other hand, if I’m a ball-bearing producer, and I have an established process which works for the forty companies to whom I sell ball-bearings, then adopting a new process for just one of them, with associated changes to my method of work, new systems and new storage and security requirements is unlikely to be in my best interests: it’s going to be both costly and annoying.

Conclusion

Tests are guidelines: they’re not fixed in stone.  One of these tests looks like a technical test (the database one), but is really as much about business roles and responsibilities as the other two.  All of them, hopefully, can be used as a counter-balance to the three drivers I mentioned.

1 – which, don’t get me wrong, is definitely interesting and a business application – it’s just not what I’m going to talk about in this post.

2 – the trick is knowing which bits.  Let me know if you work out how, OK?

3 – it’s actually quite a large set of technologies, to be honest.

4 – which is patently untrue, unless the word “they” refers there to the conferences and gurus, in which case it’s probably correct.

5 – which may happen anyway due to my egregious mixing of metaphors.

6 – there’s a word to love.  I’ve put it in to exhibit my techie credentials[7].

7 – and before you doubt them, yes, I’ve read the book, in both cut and uncut versions.

8 – within reason.