Blockchain - The latest disruptive hype : A different perspective

Every few years, a new concept (be it technology, be it an execution methodology, or a business process, or even a deployment strategy) comes around and everyone in the tech industry gets super excited and wants to be the first one to take it mainstream. 

Having come from a programming background at a grass root level, depicting what and how blockchain works was fairly straight forward. The concept is very good. Like everything else, it is another "option" to consider if there is an absolutely genuine use case to solve a problem.

As of today at the time of this writing, there are extremely very few such ones in the world which cannot be addressed by anything else other than blockchain.

The problem we face is this - Instead of trying to find a solution to fix a particular problem, we tend to find a problem which can be fixed with an available solution. It has become a style statement to say one is doing a lot of research on blockchain these days. Not many of them are technical enough to understand what does that mean. It is one of the modern flashing hobby to do something on blockchain and brag about it. It is a new buzz word which right from the CTO to a programmer are excited about it and I think they are all quite valid. The issue comes when we overdo it.

The same sort of thing happened multiple times in the past. Not all of them were for a specific technology though. A few of them were concepts. In short all of them were so called "disruptive trends".

I remember in the early 2000s, every other IT person I met used to be a "DOT COM consultant". Their job was to sell or guide start ups to go the .dot com way. Then came a burst to show us all the mirror of reality. The world wasn’t ready for digital and connected experience at that time. Now is the time for it and clearly we can see the success of it.

Then there was an era of Open source. Soon, every software, people wanted to build wanted to be open source and the image that was portrayed was, there is no alternative to open source. Then the extremism eventually faded and the industry has now struck the right balance of what can and needs to be open source and what is best to be a packaged or a product solution.

The same happened some time ago with Document based DB / NoSQL. Suddenly when versions of document DB started to go around, people started to believe, RDBMS is dead and it was a big mistake that it even existed. Soon quite a few of them wanted to include NoSQL in everything they do rather than thinking about the right use case, purely because they perceived it as the trend.

Then came Agile. For a few agile fanatics, every problem in the world can be fixed by Agile. I am clear in my mind, AGILE is a solution to a problem which shouldn’t have existed in the first place. 
More on this in my next blog :-)

The point here is not to demean any of these trends. They are fantastic trend changing technologies and are intended to stay. Same is with Blockchain. It is a fantastic concept and a breakthrough technology. But my worry is with the fact that we tend to take these to the extremes.

These are tools (not in literal sense, in some cases, yes) for the architects, business analysts and organisations to consider when trying to fix a business problem. The fundamental point here is - what is the business problem? If the business problem can be resolved by a simple spreadsheet, let's do it. There is no need to build an application to do that. It is a good thing to know (like any other technologies) and keep it in our back pocket to be used when the right scenario arises to put to use. There is never a one size fits all.

I am an architect by profession. Been one for more than a decade, and prior to that more than a decade long of core application and system development as a programmer. Blockchain is a superb invention and a beautiful concept and I am sure I would like to get my hands dirty on it too.  

I am fairly sure, I may not be the only one with this view. I found a few of such articles on the web and providing it here for some additional reading :
https://thenextweb.com/hardfork/2019/02/07/why-hype-is-killing-blockchain-technology/
https://channels.theinnovationenterprise.com/articles/why-blockchain-hype-must-end
https://cointelegraph.com/news/report-companies-dropping-the-term-blockchain-due-to-hype-around-technology
(There are quite a few more, just Google it, to read more)

I suspect I am going to end up ruffling some feathers and I expect quite a few reading this, who advocate Blockchain for everything will try and prove me wrong and so say the least find me completely ignorant on the subject :-).

All I would like to tell them is to look for both side of the coin and wait for the right commodity to spend it. My intention is to suggest them to think and wait for the right use case rather than trying to use it everywhere. There are a few genuine use cases currently and there will be more that will land in the future. Till then, I would hesitate to call it really disruptive.

Disclaimer: All the views expressed here are solely personal views of the author and does not reflect in any way whatsoever the company the author is associated with. The matter expressed here is AS IS with NO WARRANTY explicit or implied.

Agile, SAAS, NFRs & Architecture

For quite sometime I have been trying to get a grip of the agile methodology to develop applications. Somehow I am not 100% convinced (although I am 90% convinced) that Agile is the way forward.
I am still in a state of mind that Agile does not solve 100% of all the software development problems. This article is my effort to highlight few of my view points on this subject.

Agile : I would not go any deep in to this topic as it is a known and a well established topic.
If would like to know more about Agile, there are tons of articles on this subject. All you would need to do is google or (in Microsoft terms) bing it :-)

The Agile Mantra says...

• Individuals and Interactions - over process and tolls
• Working software - over comprehensive documentation
• Customer collaboration - over contract negotiation
• Responding to change over following a plan

In short Agile means - "Iterative Design & development".

So far so good.

But the key point to note here is - its "Design & Development". The process starts at "Design".

For large scale systems such as high availability, high concurrency, highly scalable systems, the key way forward starts at "Architecture". May be there are cases where a good Design does not require a strong architecture pre-thought but not always the case.

Architecture is NOT Design. Architecture is a process of looking at the entire system from a high level and providing a blueprint of how large scale systems are built.

Architecting a complex product such as a SAAS offering goes beyond just designing. SAAS systems invariably has stringent Non Functional requirements such as Availability (99.99% uptime), Scalability (x Thousand Concurrent users), High Performance response times (X transactions per second), Configurability (Meta data driven configuration), Extensibility (NOT CODE extensibility but product extensibility).

All the above elements have to be well thought of for a successful implementation of a high performance solution such as a SAAS offering.

As the name suggests, these are "NON-FUNCTIONAL REQUIREMENTS". They cannot be "automatically" captured as "User stories". Even if we capture these things as a part of User stories, which sprint do these stories belong to? How do we cater to this in a particular sprint? Should this be pushed to the last sprint? How do you split these requirements within each sprint? Most applications (even enterprise scale) may not worry much about these non-functional requirements. An enterprise application can wait for a half hour down time but a SAAS system, these things are fundamental. A SAAS system is a different game all-together.

There is no doubt that Design and development is key to any software development. But equally important is Architecture. This makes me wonder if there is something called as a 100% pure Agile project? If there is a 100% pure agile project, can this be used to build a SAAS solution with stringent NFRs?

To my mind the answer is NO. The first 10-20% of the time goes in conceptualising and "architecting" the system and then the system can be developed in Sprints (which is rest of the 80%). Architectural Patterns such as Zachman, RM-ODP, Rational Unified Process etc. (or fr that matter any Architectural patterns) wouldn't have existed if it had no use and the same can be done using a Agile methodology by directly jumping into design and development.

I am not sure how this article will be received, but this is just an attempt I thought I should make share my mind to fellow architects in the software world. I do love Agile. Agile is the way to go. There is no doubt about that.

The attempt here is to highlight the fact that - "There is nothing called as 100% agile software development"

Especially if you are thinking of developing a SAAS solution with extremely stringent NFRs, ensure you cover these NFRs within your Architecture and then start development using any Agile methodology.

For an Agile evangelist, a product development life cycle is - Sprint + Spint + Sprint + Sprint.

To my mind it is - Conceptualising & Detailed Architecture + Sprint + Sprint + Sprint + Sprint.

As I have been emphasizing, I am not sure if this arcticle would be well received by Agile Evangelist, but I thought this could be a good food for thought.

I have been involved in building SAAS applications with Stringent NFRs and hence I am able to relate this to agile development.

Await for my next blog on NFRs and its importance in designing a software solution.