Some things are easier to imagine that they are to build. From Star Trek’s transporters and faster than light starships to The Jetsons flying cars and robot maids, some things are just really far more difficult to build than to imagine (obviously).
It took almost 8 years from the first airing of Star Trek and the use of their communicators to the introduction of the cell phone, and another 20 before the flip phone actually resembled Captain Kirk’s flip-top device.
In Information Technology, we wrestle with this every day. On today’s horizon, we see universal blockchains and multi-cloud redundant environments on this list of things we can think about and envision, which like the first cell phone, are just incredibly hard to actually build.
I’ll assume you, dear reader, understand distributed ledger technology (blockchain) at least to the depth of knowing of its promise of rock-solid security, and immutable, auditable data. I’ll also assume you have a grasp of cloud environments, if not necessarily the individual uniqueness of each providers architecture.
So why is this so hard? There are a lot of reasons.
Firstly, there are any number of competing products and platforms currently coming into being, or being developed. Who is going to make them all interoperate?
Secondly, who is going to rebuild all the existing legacy applications and systems to work in this new blockchain enabled world?
Let’s take this piece by piece. Starting with the cloud…
Interoperability across the board in IT is worth discussing because it’s a bit of a holy grail. This includes the cloud conversation.
Everyone wants redundancy and disaster recovery capability. As a customer, if you are moving to, or have investments in cloud infrastructure, why not have failover between multiple providers like AWS, Azure, and others? For starters, this really requires cooperation between the respective competing vendors. Yet there are business reasons why Amazon may not want to cooperate with IBM, Google, and Microsoft. Even if they say they want to cooperate, subtle speed bumps exist between them making this seamless integration among providers far more cumbersome than it needs to be.
Then there is application modernization.
Whether a company is just trying to move to the cloud, update their applications, or deploy some blockchain solutions, dealing with ‘old code’, legacy software to be more polite, is challenging, to say the least.
Among those challenges, there are billions of lines of old code out there, in many cases, poorly documented if documented at all, and written by people long since retired, or in many cases deceased. There are companies running servers and systems they can’t even identify. How are they to be expected to modernize these? How are they going to move that functionality to the cloud, let alone blockchain?
I’ve written elsewhere about some approaches to application modernization, so I won’t rehash that, but again, it’s not easy. In many cases, it is so hard, companies just continue to support ever aging systems until they can find new off the shelf solutions to replace application functionality. “We might not know how we built it, but we know what it does”, or so the saying goes. Thus allowing a company to replace the function, and turn off the old code once complete.
Workday leveraged this quite well when they rolled out their cloud build, cloud-based HR suite, allowing companies to avoid costly rewrites of an old system, and just sunset systems as they move to Workday’s cloud-based modules.
Then there’s Blockchain
Figuring out blockchain use cases is similarly tricky. While there are some obvious use cases where blockchain looks like a sure win, there are others that are harder to grasp. Some of the latter involve internal use cases, those not involving a consortium or group of companies, but just internal data flow within a company.
To review, blockchain is a system, or rather, DLTs are systems and a type of technology that ensures absolute certainty of a ‘thing’. The provenance of a widget, or document or chunk of data, and that the data representing that widget or ‘thing’ is unchanged from the original. So if a company is looking for an internal solution, is this certainty needed? Well, yes perhaps so if it’s a large company and we are talking about audit trails, tracking consumer goods, etc.
The use case for groups of companies becomes clearer. Certainly, dramatic value can be realized from blockchain when we are talking about an ecosystem of companies or a consortium of real estate companies, or governments or banks, where there is data moving between entities.
Building these systems requires thinking differently. There are realities of building solutions using blockchain that have no parallel in traditional application development. Again, it takes time for developers and application architects to understand this and hone the skills and design thinking required.
We’ve been building blockchain and DLT systems for companies for two years now, and we learn a little more every day.
So we’ll have to keep waiting for the flying cars and home-based robots, though some iteration of those appear to be just over the horizon.
What would you like to see built next?
Please share your thoughts in the comments below or reach out directly if you’d like to talk further.