Should DB2 have an Immutable Table Function?

I love hearing about Blockchain; if you are involved in Fintech, then surely by now you have heard a lot about it, and that it holds a tremendous amount of promise for Internet business. Fundamentally, it guarantees the validity of a transaction.  Blockchain is a ledger of all transactions; a ledger cannot be changed, making the requirement for a third party to process transaction payments unnecessary.

I find this type of technology to be very interesting; one well worth examining.  It is my belief that Blockchain will actually propel banking and Fintech forward quicker than the invention of Internet did for banking.  While transactions are simplified, as transaction costs decrease, and as they are simultaneously made more secure for the end user — well, you can see why many people are getting excited about Blockchain.

I have been fortunate to work with many CIOs from around the globe, and I can say that recently, in most of our conversations, we wind up talking about Blockchain and its impact on current systems.  The machine that is at the heart of practically all large enterprise computing – particularly in the finance market – is the mainframe.  This is for good reason.  The mainframe is a highly reliable and highly scalable platform that processes transactions at the volume and pace required by today’s rapidly changing business environments. And based on its track record, it will undoubtedly be able keep up with future demands.  Investments into the revenue producing applications that run our global banking systems are huge, so don’t believe for one second that the mainframe is going away.  This is why it is my belief that Blockchain will actually create a revival of the mainframe.

A Blockchain hyper-ledger sounds very much like a database to me.  It contains information about the transaction and all of the past transactions, and it makes it difficult, if not impossible, to fake the information required for a transaction to occur.  At the heart of most of the world’s largest banking systems are mainframe systems containing vital systems of record.  Blockchain data stores are immutable- they are completely resistant to change; consequently a Blockchain system of record is immutable.  It strikes me then, that if you can duplicate this capability with the system of record on the platform that is powering the world’s financial markets, then you make it that much easier for the widespread adoption of Blockchain to occur.

Immutability though, is not easy.  How do you actually create the system that prevents changes to a data store?  One such way you can look at this is with the concept of a room key data structure.  Kind of like a modern-day hotel room, where you get a key to the room that you and you alone can use. When you are done with the room, the key expires, and the room is available for use again.

Whereas transactional databases are systems of record, most new data stores are systems of engagement.  These new data stores are designed for analysis, whether they house Internet of Things (IoT) data, social-media comments, or other structured and unstructured data that have current or anticipated analytical value.  The new data stores are built on cloud-native architectures, and immutable files are more consistent with the cloud mentality.  At this early stage in data analytics, any web-scale architecture is a candidate for a data store that has immutable files.

This evolving technology makes sense for many niches within mainstream enterprises. Those niches are the emerging applications that enterprises might not be using much now, but will be in the future. Forward-leaning enterprises should plant one foot in the future. They need to understand the immutable option and learn to work with it. I believe life would be a lot easier if we built this into the main database most widely used by the financial industry for their systems of record: DB2.

Originally published on the MainframeDebate blog.