FAQ of a Business Blockchain Project

blockchain-data-ss-1920

Since the launch of our first Blockchain project in May 2018 (https://www.youtube.com/watch?v=EuUEBv12iBo), there are many people asked me the same set of questions again and again. So, I reckon maybe it’s good to sum it up all here.

First of all, “Why Blockchain ?”

My usual answer is, you know, “Why not Blockchain ?”. It’s not about whether Blockchain is the best technology on earth (as it’s not) or Blockchain can solve all sorts of business problems or not (as it can’t), but more about why not try a new technology to address an existing business pain point ?

What’s stopping you ? Is it because you have fear of failure ?

Solving a problem is hard enough, it gets much harder if you’ve decided beforehand that it can’t be done. Quite simply, there are many use cases, can be done by Blockchain technology.

“Why not the existing technology ?”

Reasons being …. Smart Contract, real time settlement / reconciliation and gamification.

These are either hard to develop in existing technology or take a long time to retool the current systems.

“What are the technical challenges ?”

It’s a very good question, as it is exactly one of the reasons you need to pick a project to try. Granted, many startups claimed they use Blockchain (or AI, Big Data, Chatbot, IOT etc.) to build their solutions, as it is the biggest buzzword for the moment. However, to an established corporation, there are other considerations before selecting a technical solution:

  1. How can we operationalise the new technical solution ?
  2. Do we know what kind of talent we need to develop the new technical solution ?
  3. What kind of infrastructure we need to deliver good performance ?
  4. What are the best practices to design, develop, test and implement the new solution ?
  5. How much is the development and operating cost ?

We cannot really solve a problem by keep talking. Just do it. Learn and improve the solution along the way.

“Why this use case ?”

Developing a good product is hard, but developing a good MVP is even harder. There are many different processes, use cases in every business. We picked one that is relatively easy to implement and yet provide good value to our stakeholders.

“Pick battles big enough to matter, small enough to win.” – Jonathan Kozol

We are not alone though, check this out from American Express … https://www.coindesk.com/american-express-upgrades-rewards-program-hyperledger-blockchain/

“How Big is the Team ?”

Check this out, it’s more or less the same. YMMV.

https://blockchaintrainingalliance.com/blogs/news/10-faces-of-blockchain

“Any lessons learnt ?”

Do not innovate for the sake of innovation. First you need to know what you want to solve.

Ignore the naysayers and develop your own solution. You can learn from your own success, you can learn more from your own failures, but you can learn nothing from your own procrastination.

Blame it on Cloud Security

It is really an easy one, I suppose … so many business and IT decision makers told me that as the reason of not implementing / migrating their systems to the cloud.

However, truth is that data and systems residing in public or private clouds are as secure as you make them. Typically, cloud-based systems can be more secure than existing internal systems if you do the upfront work required.

For example, I am pretty sure the physical security, patch management and many other security measures are better implemented by Cloud Services Providers than your own IT department.

Check out the Security Guidance from Cloud Security Alliance and COBIT from ISACA for more details and the techniques, and I am sure you can implement a secure cloud system.

Cloud experts, any thoughts ?

linkedin pic 3

Blame it on the ever-changing requirements

Whenever there is a delay in software project delivery, the usual reaction is blaming it on the unclear and ever-changing business requirements.

Edward Berard, author of the Object Oriented Software Engineering, once said “Walking on water and developing software from a specification are easy, if both are frozen.” and clearly it proved that point … or did it ?

We all know in the real world, business changes fast and therefore so are the software requirements. So it’s really no point to insist in freezing requirements before starting the software development, instead we shall consider :

1) How can we cope with changing requirements in our development lifecycle ? (Read : Scrum Development)

2) How can we make our applications more flexible and easier to change without affecting other parts of the system ? (Read : API and Micro-services)

3) How can we migrate / rollback production systems easily ? (Read : DevOps)

4) How can we lower the cost of infrastructure and failure ? (Read : Cloud infrastructure)

So, don’t blame it on the requirement changes, as change is constant. Let’s do a better job in developing the business software.

Development professionals, any thoughts ?

linkedin pic 2

Blame it on technology

It’s really easy to blame everything on technology, whenever there is a project failure, especially new ones with lots of acronyms and buzzwords.

On the other hand, have we trained up the business users to master the technology ? Have we defined the project objectives clearly ? Have we reviewed and revised the business processes to work with the technology ?

People, process, technology … technology actually comes last.

So don’t blame everything on technology, blame the project failure on how we implement a new technology.

Technology professionals, any thoughts ?

linkedin pic 1

Connecting the Dots, Connecting the Blockchain

“Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.” – Steve Jobs

Back in 1994, I joined a company who was developing a document service for the trading companies in Hong Kong. The service facilitated the trading companies to send various trading documents to the Hong Kong Government securely and with authenticity.

The technology behind all these was Public Key Infrastructure, or asymmetric cryptography. Even though back then I was the System Architect of such system, the technology was totally new to me – Hashing, Asymmetric Encryption, Digital Signing etc. For some reasons however, I was intrigued by all these fancy technologies.

Fast forward to year 2000, Hong Kong rolled out the Smart IDs for Hong Kong citizens and each of these Smart IDs had a chip embedded that in theory you could store the Private Key inside it and did your own digital signing. And of course, with the receiving party’s Public Key, we could do secure encryption as well.

Eight years later, in October 2008, Satoshi Nakamoto published a paper on The Cryptography Mailing list at metzdowd.com, described the digital currency – BitCoin. And the infrastructure that BitCoin worked above was what we call now – Blockchain (this term is not used at all in the original white-paper).

By now, you all know Blockchain is again based on hashing, cryptography and time-stamping. Did I know what I learnt back in 1994 would become the foundation of the digital currency or even future computing infrastructure ?

No of course, because as Steve Jobs said … we can only connect the dots looking backwards.

I don’t know ten, twenty years later, what dots we all can connect and find something new. However, you may be able to get some insights on the following excellent documentary on Blockchain –