SANDBOX: Architecting Sandbox POCs


POC sandboxes are built rapidly in just a matter of a few weeks primarily for proof of concept and demos to investors or decision makers. The only need is of speed and to demonstrate the core value proposition. Why would anyone talk about architecting a POC implementation.

The Metron sandbox team takes a different and a slightly longer term view when building POC implementations. While we take great care to avoid gold plating (see Building successful POCs) a considerable amount of thought is put into choices of components, frameworks etc. While the implemented features are kept to as minimum and close as possible to the central minimum value proposition, considerable thought is put into the architecture to align it towards a rapid and agile evolution towards the broader longer term vision of the product.

There is a difference between building a feature or requirement versus ensuring that just the architecture has anticipated the feature and been designed to allow astonishingly rapid build out of it at a future time. Another way to look at it is that nothing has been done in the architecture which will be an obstacle (or require significant rework) to its future development.

While a seemingly simple statement, the ability to do this is based on virtually decades of experience in building products and startups, knowing what will sooner or later become essential, and what wont. The art of this lies primarily in making the right architectural decisions, appropriate framework choices and ensuring well designed place holder implementations which will “host” implementation of future features and extensions if it is to evolve into a full blown product. And doing all this with the minimal effort invested in anything not directly related to the POC scope.

Why would you do all this for a POC? The answer is that if we can be a little greedy and take an optimistic attitude towards the possibility of it evolving into a real product with very little added effort … Why Not? Simply the application of mind, clarity and a great deal experience does not add that much actual time wise effort to the POC development effort … but the result is a huge jump start to development of the product on a green signal.

The core value proposition is already implemented, the hooks are in for the rapid implementation of the the components which are increasingly peripheral. There are minimal hacks or dummy implementations for parts non-central to the POC, which have been carefully componentized and can be replaced with the real stuff, with virtually no disruption to the code base. Its a huge boost to the product development stage and can cause tremendous reductions of timelines.

It might be worth illustrating with just a few examples.

Simple example: Every product typically has registration, logins etc. You dont want to really waste effort building out the entire authentication/authorization component in the POC (waste waste waste). Nor do you want to do something where you have to rip the guts out of the system if/when you get into the product phase. Nor do you want to show a tacky demo where their is no login.

Simply ensure a clear modularization of the authentication/access control mechanisms. Dummy out the implementation and use it for authentication and access controls in the rest of the app. Its just a few lines of dummy code but its services are already plugged in and being used. Simply swap out the dummy with the real thing in just one location in your codebase, and it is already plugged in into entire code base. Not a radical idea – just a very simple example.

Sometimes from the nature of the application it is clear right in the beginning that it will be a big data application with high real time data throughput. You don.t go ahead and build complex scaling solutions in the POC itself. You simply ensure that even though it might have been simpler for the POC to use say MySQL or similar, you ensure the architecture uses and an appropriate persistence framework such as MongoDB or PostGRES which has established proven horizontal and if needed even geographically distributed scaling. That is adequate proof that in principle even the POC itself is scalable.

If the application seems from the beginning to be a highly interactive real time system such as in collaborative gaming or collaboration, you would simply ensure the an asynchronous server side framework (such as say nodejs) is part of your architecture.

There was one client for whom we were doing a POC of online interactive collaborative gym training with biometrics integration. The biometrics devices were not immediately available. What did we do? We mocked out the heart beat date generation with just a few lines of random number generation code BUT we took considerable pains to ensure the API for its utilization was designed to be clearly abstracted and componentized. The dummy heart beat code with actual biometrics integration could be introduced with one very local non disruptive implementation. However as it turned out, the biometrics devices became available just a few days before the end of the POC, and with the clean design, we managed to integrate the real thing itself into the POC with barely two days effort.

Another client who was doing a POC of a social sentiment analytics system needed to extract analytics out of over half a dozen social apps. FB, Twitter, Instagram etc etc etc where the feeds had to be collected, populated into a graph database and post processed with NLP and sentiment analytics. Do you build in all these integrations into the POC? But you DO want to show all these social integrations in the POC?  Solution: do the actual feed consumption integration for just a few of them. For the rest, dont bother to build the collectors – just fetch real data and bootstrap the graph database with static data. No investor is holding their breath wondering if integration of social media streams is possible or not. And further your POC is not about data collection – it is about what you do with it. But while taking this shortcut great care was taken in the design to ensure that a standard plugin type of architecture for feed consumption was designed. Simply because of this, the subsequent integrations of all the other streams became almost cookie cutter assembly line operations, drastically reducing timelines during subsequent product stage.

That is what strategic POC development is about. Do as little as possible, ensure the core purpose of the POC is met but at the same time create for the client a huge tactical, cost and timeline advantage in moving forward. You have ensured a good portion of the product level goals have been achieved in the POC stage in a kind of stealth mode … not through effort but simply by the way you think!

Leave a Reply

Your email address will not be published. Required fields are marked *