Infosys experts share their views on how digital is significantly impacting enterprises and consumers by redefining experiences, simplifying processes and pushing collaborative innovation to new levels

« September 2016 | Main | December 2016 »

November 9, 2016

Blockchain, Decentralization and its impact on Insurance and HealthCare - Part 2

Author: Arshad Sarfarz Ariff, Technology Architect

In my previous blog, "Blockchain, Decentralization and its impact on Insurance and HealthCare - Part 1", we explored the notion of Smart Contracts, Oracles and Dapps and how they can empower the insurance and HealthCare industries. In this blog, we will look at how Ethereum provides a platform for developers to build applications easily and sample use case on how a Dapp would provide value spanning multiple industries.

Ethereum:

Ethereum is a decentralized platform that runs smart contracts on a custom-built Blockchain with the vision to serve as a platform for the creation of Dapps. The Smart Contracts will be executed on an Ethereum Virtual Machine (EVM) whereas the Front End will be hosted on distributed Storage called Swarm. Both EVM and Swarm are decentralized technologies running on hundreds of nodes participating in the Ethereum network.

The example of Flight insurance mentioned above is already available as a Dapp running on Ethereum using an Oracle called Oraclize that fetches data using external API provided by Flight statistics.

Startups are already working on Dapps created on Ethereum that aspires to solve the problem of isolated data silos pertaining to patient records haunting the healthcare industry. These Dapps are expected to put an end to the interoperability problem in Healthcare without comprising compliance by enabling Patient records to be shared securely across the entire health care network involving Health care providers, Hospitals and Patients.

 

Embracement from Insurance and Healthcare players:

Aegon, Allianz, Munich Re, Swiss Re and Zurich have launched the Blockchain Insurance Industry Initiative B3i aiming to explore the potential of Blockchain technology to better serve clients through faster, more convenient and secure services.

"Hashed Health consortium" has been formed with the mission of bringing together leading healthcare enterprises in order to advance Blockchain solutions that address the unique issues and regulatory regimes of the healthcare industry.

"Hyperledger Healthcare Working Group" has also been formed to house and foster technical and business-level conversation about appropriate applications for Blockchain technology in the healthcare industry.

 

Thought Floor:

In future, we can expect Blockchain Dapps that would span across industries. Here is an example scenario covering Insurance, Healthcare, Pharmacy, Agriculture, Manufacturing, Banking, Shipping and Port Authorities. Herbal plants grown in a Farm in India can be shipped to China for manufacturing medicines on behalf of a Pharmaceutical company running in UK. This would involve Smart Contracts between the Pharmaceutical Company in UK, the Manufacturer in china, Farm Owner in India, the shipping company and the port authorities in the respective countries. Different set of Smart Contracts would also exist between Pharmaceutical Company, Insurance providers, Health care providers and government agencies like FDA.

Executing Smart Contracts on Blockchain would provide new plethora of information and minimizes the cost among the stakeholders besides delighting the customers.

  • Agreements between parties spanning geographies can be easily executed at low cost and minimal effort without the need for any Trust.
  • The cost and effort spent on adhering to government regulations would be minimized due to information made transparent and secure on the Blockchain.
  • Fake medicines can be easily identified, as the Smart contracts would reveal the complete lifecycle starting from the source to the destination.
  • Health care provider, payer, patients and governments would have complete gamut of information starting from ingredients gone into the production until delivery. Though contracts would reveal the parties and the products involved, confidential information between the different parties would still be private. For example, the pharmaceutical company could be a selling an antidote at a special price with a particular hospital or vendor and at a standard price with others. Smart contracts would keep this information private between the applicable parties.

 

Conclusion:

Blockchain and Decentralization are reinventing the way business is conducted and industries like Healthcare and Insurance will leave no stone unturned in applying Blockchain to their Business. This marvel has opened the doors for new set of application development creating market and demand for new set of skills making it imperative for enterprises and software service providers to set foot on the chain early in the race.

Blockchain, Decentralization and its impact on Insurance and HealthCare - Part 1

Author: Arshad Sarfarz Ariff, Technology Architect

The mysterious inventor of Bitcoin, Satoshi Nakamoto never saw the use of Blockchain technology limited to Bitcoin only. His vision is already turning into reality as industries and enterprises around the world are analyzing the use of Blockchain for various scenarios. As we all know, Bitcoin has already revolutionized the financial industry with the help of its underlying engine, the Blockchain.

Let us take a step backward and see why Bitcoin has become so important and how Blockchain made this possible. The unique selling propositions of Bitcoin are Trustless and Decentralization. Transactions for many ages involved a central party called a bank on whom we lay our trust for safeguarding our money. Bitcoin introduced the phenomenon of storing, securing and performing transactions without the need for a bank. Instead of relying on people and rules, Bitcoin uses cryptographic techniques to guard the money and the transactions.

One might think if a bank were not involved, then who would maintain the accounts. This is where many would refer to Bitcoin as a distributed public ledger maintained by each node involved in the network. Distributed ledger is an over simplification as a ledger is never maintained, instead it contains two Data structures, one for linking the transactions and other for linking the blocks. Each block contains list of transactions and the blocks are linked or chained hence called the Blockchain. A copy of these two data structures are maintained by nodes in the network called Full Nodes that verifies all the associated transactions to calculate the balance. This is aided by complex cryptographic techniques running on the Full Nodes that prevent anyone including the Full Node from tampering the Blockchain i.e. Data structures.

Anyone in the globe who has significant computing power can become a Full Node in the Bitcoin network by installing the bitcoin core software. This would download the complete data structure and verify all the transactions that had happened starting from the day Bitcoin went live. Bitcoin system targeted only Transactions having monetary value but people reckoned that the concept of Blockchain could be applied in many areas of life outside of digital currencies and this is where we are witnessing the emergence of Smart Contracts, Oracles and Dapps.

Blockchain currently used by Bitcoin can be referred to as a Public Blockchain as anyone in the world can become a Full node in the network. Blockchain comes in two other flavors i.e. Consortium Blockchain and Private Blockchain and this opens up even more possibilities for the enterprises.


Smart Contracts:

Blockchain invented with Bitcoin were restricted to dealing with currency transactions and does not allow any other logic to be executed based on the data or event. This is where Smart Contracts was envisioned which is a piece of custom-written logic that can be executed by the nodes in the Blockchain. From the perspective of a business user, Smart Contract stores rules for negotiating the terms of a contract, automatically verifies the contract and then executes the agreed terms. This one of the key extensions that had endowed Blockchain for use in various applications other than currencies.

Consider the following example, in Travel insurance.  A new public Blockchain can be created which employs a Smart Contract between Insurers, Airlines and the flyers that will hold information about flights of all the airlines, all the insurers and all the flyers. The policy purchased by flyers can be stored as Smart contracts on this Blockchain. The data related to departures and arrivals can be automatically fetched and the Smart Contracts would execute to determine if there is a delay and automatically trigger the payouts to customers if the delay window is breached. This would greatly reduce the efforts put in by the customers, insurers and the airlines besides resulting in cost savings for the insurers. Since the complete flight data is publicly available at one place, insurers can use Machine Learning algorithms to detect delay patterns based on various parameters and devise better policies leading to better cost savings.

 

Oracles:

In the Flight example, automation of data fetch for flight departures and arrivals was made possible using Oracles, which provides inputs about the external world to the Smart Contracts. Oracles would collect inputs from various sources, streamline and feed them to the Smart Contracts that would make the final decision. Please note Oracles do not decide the outcome, they merely provide the inputs to Smart Contracts for final decision making. This use case can be extended to cover insurance for baggage loss where oracles can collect information using IOT and feed it to the Smart Contracts.

Another example where Oracles are inevitable would be in HealthCare insurance. Currently Third Party Administrators (TPA) are involved between insurers, care providers and patients. Claims processing, as we know is time consuming and one of the key concerns of the insurers is to reduce fraudulent claims. Consider a public Blockchain created for the Health Insurance that would store policies using Smart Contracts between insurers, care providers and patients. This would eliminate the need for third parties resulting in reduced cost for the insurers and care providers ultimately in resulting faster processing and cheaper policies for the patients. This can be envisaged as an ultra-complex contract containing all the rules relating to the disease, medication and terms of the contract.

Since complete health insurance is tracked on the public Blockchain, it becomes easier to identify the fraudulent claims. For example, customer cannot claim from multiple vendors when the nature of the medication or policy restricts claim to be made more than once. Oracles would also be involved to provide inputs on whether a claim is genuine.

One might argue that there may be cases where Smart Contracts would not be able to decide on fraudulent vs genuine claims. Multi signature algorithm referred to as multisig can address this riddle, which would require signature or authorization from a group of people. The complete transaction becomes valid only when the designated parties sign the transaction. This might look like moving back to TPAs but the occurrences of this event can be much lesser in magnitude compared to the current scheme where all transactions go through TPAs.

 

Dapp:

Decentralized applications referred to as Dapp, need to satisfy four criteria as mentioned in the Dapp white paper. These four criteria i.e. open-source, use of Blockchain, use of cryptographic token and proof for generating tokens were clearly inspired by the technologies fueling bitcoin. Needless to mention, bitcoin is the most successful Dapp ever developed until date. History has proved that the model of centralized applications is flawed due to single point of failure, single point of attack and laying down our entire trust on a 3rd party. Yet applications were built using this paradigm due to lack of feasible alternative. With the advent of Blockchain, Dapps will soon be in the spotlight opening the floodgates for a new market of apps. Unlike traditional server architecture where an application runs on centralized servers, Dapps will run on all the nodes involved in the Blockchain network. Dapp generally comprises a Frontend and a Backend. The Frontend could be using HTML, JS and CSS technologies. The Backend will consist of Smart Contracts running on the Blockchain.

                               

                                                                To be continued....

November 7, 2016

Steer through JavaScript Framework Churn

In this Digital Era, need for more responsive user experience is more prominent. Open source JavaScript frameworks have gained broad acceptance. We are observing rise in the number of JavaScript frameworks in the market and almost weekly major release (instead of months or years). New leaders are emerging with recent rapid changes in JavaScript frameworks landscape. Recent evidence suggests that uncontrolled usage of multiple JavaScript frameworks in the enterprise is a far more pervasive problem than most people realize. Today's shiny new JavaScript Framework will become legacy in 2-3 years and it will difficult and costly to maintain legacy JavaScript frameworks. Governance will be key to manage this situation.

Rise in usage of JavaScript frameworks

In this Digital Era, need for more responsive user experience is more prominent. JavaScript frameworks help to achieve responsive user experience by supporting features like rich user interface with drag and drop capability to Two-way data binding. These Open source JavaScript frameworks have gained broad acceptance and these extremely popular JavaScript frameworks are heading for the mainstream. We are observing sudden rise in number of JavaScript frameworks in the market and almost weekly major release instead of months and years. New leaders are emerging with recent rapid changes in JavaScript frameworks landscape.


Challenges introduced by 2nd generation JavaScript frameworks

These versatile frameworks provide vital competitive advantages, but they also introduce risk when employed without adequate precautions.  Recent evidence suggests that uncontrolled usage of multiple JavaScript frameworks in the enterprise is a far more pervasive problem than most people realize.

Most of the popular JavaScript frameworks were release 5+ year back for example AngularJS and BackBone.JS were released in 2010. With paradigm shift in Web technologies most of these first generation JavaScript frameworks were not designed to handle complex single page apps, APIs and rich user interface. This is resulting second generation versions are redesigning from scratch than creating patches.


  • Lack of backward compatibility: The change in technology and complexity needed to be supported by applications resulted in tedious and inconsistent implementations with first generation of JS framework.   As a result newer versions are redesigning framework by starting from scratch. For example: AngularJS 2 is drastic change from earlier version of AngularJS. AngularJS 2 is not just upgrade of older version but rewrite of framework and design approach. For example: AngularJS 2 is focuses on component based approach or Angular2 uses Typescript which introduces concepts like Class, generics and lambda expressions.

  • Scarcity of skill set & support for older versions: With quicker rollouts of newer versions of framework is resulting in lack of community support for older versions, and scarcity of skill set for older versions. Also lack of support for older version can hurt security and robustness.

  • Ahead of adoption curve: No all mainstream browsers support ECMAScript 6 but JavaScript frameworks are already are leveraging features of ECMAScript 6.


Working with JavaScript Frameworks Churn

Rate at which new leaders are emerging and previous frameworks are abandoned requires Enterprise to understand long term business impact of JavaScript Frameworks. Today's shiny new JavaScript Framework will become legacy in2-3 years and it will difficult and costly to maintain legacy JavaScript frameworks.

Governance will be key to manage this situation.

  • It is essential to identify usage of JavaScript frameworks with in enterprise.

  • Generate a list of approved JavaScript frameworks and use case scenarios.

  • Develop policies, process, and oversight for JavaScript Framework adoption. 

  • Keep right balance between functional supported and maintainability


November 5, 2016

Are your Enterprise Applications Ready for Cloud Deployment? "Let us identify and gear up"

Author: Jitendra Jain, Senior Technology Architect (HILife - Architecture & Design Group)

Introduction

Cloud computing can be defined as "usage of high end remote servers and other virtually hosted network services over the internet to efficiently manage, process and store the data in highly scalable fashion". Cloud computing make it possible for enterprises to use highly computable network remote infrastructure and fully scalable environment for mission critical complex business applications. Resources like virtual machines (VMs), storage units, shared utilities, intelligent applications, network and infrastructure are some of the computing resources provided by cloud computing environment.

 

Cloud adoption trends

Cloud computing is emerging as a major industry trend in IT modernization and digital transformation strategies among enterprises. As per a recent survey global cloud (SaaS software) revenues are forecasted to reach $106B in 2016, increasing 21% over projected 2015 spending levels. Software-as-a-service (SaaS) and infrastructure-as-a-service (IaaS) activities are the top most cloud computing trends of 2016. It shows remarkable growth in cloud adoption across large to small enterprises.

Variety of Cloud Offerings

Img1.png























Are you Cloud-ready? " Ask this question to all stake holders" 

If you can deploy or migrate your existing enterprises applications directly without making major changes on cloud (public/private cloud platform)  such applications are known as "cloud ready" applications however it is not practically feasible in most of the cases due to architectural design limitations. If we talk about legacy enterprise business applications typically they are built on top of standard two or three tier architectural design principals with minimal focus on network topologies, optimal file system, generic session management techniques, common protocol oriented design, OS independent approach, DevOps oriented automation and infrastructure independence which is eventually key architectural considerations for building any cloud ready application infrastructure. Hence most of the applications fails in their cloud migration and deployment phase and falls under non-cloud ready category. On the other side businesses are still trying to move their existing applications on cloud or rapidly adapting cloud-ready apps. The biggest concern is how can we ensure and verify cloud readiness for existing or new enterprise applications? Let us follow below general guidelines.


General guidelines for cloud readiness- "Let us make app cloud ready"

All below guidelines and suggestions will help making our new or existing enterprise app cloud ready.

Guideline#1: Avoid using any specific topology for application code and deployment

Suggestion:  Try to build your application generic and stateless as much as possible, network attributes like IP address, Host details, number of app nodes etc. can change anytime hence don't rely. 


Guideline#2: Do not rely on local file system, storage or cache data, it may disappear

Suggestion:  It is highly recommended to build and store such valuable data remotely using any SQL or NoSQL kind of database. It will prevent duplicate and inconsistent data.


Guideline#3: Never use manual installation, configuration and deployment options for your application

Suggestion:  Always use OS specific build scripts or automation platforms like Jython scripts for IBM WAS or use automation platforms like Puppet, Chef etc.

 

Guideline#4: Avoid using any low level platform specific APIs features (e.g.  Java thread Pool, JMX) in application

Suggestion:  Use generic loosely coupled infrastructure for such API's, PaaS environment should be preferred in this use case. Let us move low level platform specific APIs on PaaS (Platform as Service) and consume it as an independent service.

 

Guideline#5: Never store session state in your application's local file system or local memory.

Suggestion:  Avoid using HTTPSession, HTML5 storage, cookies or any other kind of local session memory storage instead it is highly recommended to use any distributed caching store mechanism like Memcached, Redis or use any external distributed SQL or a NoSQL database.


Guideline#6: Let us not build your app using non-standard deprecated type of protocols (e.g. IIOP) 

Suggestion:  They always requires specific kind of configuration and tuning instead of generic configuration which creates problem when you move to cloud. Guideline is to migrate from legacy protocol (e.g. IIOP) to a newer generic HTTP based configuration with the maximum use of REST or even SOAP WS based service specifications so that your application could be cloud ready with minimal migration effort. With advanced HTTP based protocols we can also leverage multiple API Management platforms like Google Apigee, CA Layer7


Guideline#7: Never bank on Operating System specific core features (e.g. OS specific task schedulers, Batch jobs, event driven services, timer services etc.)

Suggestion:  Avoid using any such platform (Java, UNIX, Windows, Solaris) dependent core services while application development rather better to use some open source platform independent generic API's (e.g. quartz job scheduler). Such platform independent OS-neutral generic considerations will save big time on code refactoring before we move our enterprise applications to cloud based infrastructure

 

Guideline#8: Avoid using local file system configuration for application logging purposes (Server side logging)

Suggestion:  Local file system logging can be dangerous in case your whole system gets down because in such situation you have to take out the whole container/VM on which app is running which eventually causes availability and reliability issues for end users along with the loss of valuable debugging triage information. Suggestion is to use open source or commercial PaaS platform log recorder or log aggregators. They can redirect critical logging real-time information out of the box which will be best suited option for any dynamic cloud platform. Some recommended platforms are as given below:

  •  Cloud-foundry
  •  Splunk
  •  Scribe
  •  Heroku
  •  Apache Flume
  •  PureApplication Platform 


Guideline#9: Specific infrastructure dependency can create big problems, avoid it.

Suggestion:  It is highly discouraged to inject any specific dependencies in application code base and configuration like hard coding of Host-names, IP addresses, Port Numbers, Hosted or Consumed Services URL's, URIs, Endpoints, CORS (Cross Domain Resource sharing) configuration, Third Party API's calling details or any other contextual details. This information will be modified when you move your application on cloud infrastructure hence dynamic contextual information will always help breaking the application post migration.

Suggestion is to abstract any such environment specific information into a common property files however it is also a workaround not a full proof solution hence better to procure an external service registry for all such information. It could be an enterprise service bus (ESB's) or a vendor provided load balancer. It even helps in clustering environment. 

Cloud Deployment Strategy (New Apps v/s Existing Apps)

Case A: Developing a new business application from scratch for Cloud Platform?

If you are developing a business application from scratch for Cloud Platform then do follow above suggestions which gives you a cloud centric approach so that you can design and build your new app as per above cloud infrastructure requirements. In this case migration or deployment the app on cloud will be real quick with minimal effort provided you would have proactively chosen above design and architectural considerations.

Case B: Migrating an existing business application on Cloud Platform?

If you are migrating an existing business application on cloud platform then you have to do following steps to make your app cloud ready

Img44.png

































Top Cloud Platform Providers

As per Gartner's cloud computing market leaders, May 2015 report below are the top cloud leaders.

img55.png



















Other Cloud Platform Providers

Lot of other cloud provider vendors are also available. They provide various kind of cloud service offerings. We may chose any one based on their offerings, licensing cost, vendor credentials, business requirements. Couple of them are really coming up very fast with good service offerings model like Saleforce, Rack-space and Oracle cloud however they are still in improvisation phase as compare to AWS, Microsoft, Google and IBM cloud offerings

img66.png

















Conclusion

As per above details, market trends and current reports it is a clear cut indication for all the IT organizations that they do not have any other fish to fry other than start planning for cloud movement. It can not be ignored anymore. Sooner or later most of the small to large scale enterprises have to migrate on cloud infrastructure. However step by step careful planning, tech assessment, regress analysis, business need, CIO's vision, time to market  , financial situation and strong vision is the key factors. Cloud movement decision may varies based on enterprise to enterprise. 

References

http://www.webopedia.com/Blog/cloud-computing-market-leaders-2015.html