Bandwidth Driven Development and Delivery Design (B4D)

No matter how good your application is, you are always in mercy of network and its speed. When speed is low because of geographical location or due to catastrophic events, chances are your customers/clients/users could be at those very places and wanted to communicate with you through various digital means, web or mobile. You service should still be able to provide basic services. But how can we do that and promise availability and Reliability of your services?

One way to make sure our services are always Available and Reliable is by embracing Bandwidth Driven Development and Delivery Design B4D. What it means is based on network speed, our system/application should know how to adjust and what kinds of content/feature/page/item it should response with. Our System/application shall use various techniques, but not limited to followings: Various analytics processing and use of Machine Learning(I have some ideas/models still in head) in real-time to know what feature/page/components should be significance part of the given request. (User will still have ability to request for full features) Realtime situation/condition in the ground/geo-location. For instance, during hurricane, based on history, and also usages of various features in real-time, we know what features will be highly used before and after the hurricane. Such information even provides valuable information to the infrastructure to allocate appropriate resources (scale up/down) corresponding the feature beforehand.

For successful execution, the idea has to start bottom up, starting with our through process, and then how we develop our application. Just like how we think of Responsive Design or Mobile First Development or Progressive Web App before we start building our application, B4D is another paradigm, an angle of thinking how and where the application will be consumed. So, in that respect, Design should be modularized based on what features or pages can served standalone to the member without coupling to another features. Even within a single feature, how far you can go to serve the minimal pieces so that member feel they are being served and their request is in progress, for instance, after hurricane, affected members want to submit the insurance claims, but bandwidth is limited, and connection is reliable... here is how our application/system should adjust:

• If possible defer authentication process or take it to minimal with the fact that we can identify who the user is from history.
• Make sure, claim feature is on landing page, based on above techniques and what types of policy/service member has.
• Make sure you are asking for minimal information to start the claim process
• Make sure most the information is auto-filled based on user's identity and other claims that is going on from similar geo-location.

Idea is Simple. Let's make it happen.