Sharing some thoughts and philosophies that have gone in towards architecting Osmosis platform.
- Device data capturing – this is perhaps the most important piece of any IoT system. How effectively and securely we can get the sensor data on to the cloud determines the success and failure of the platform. Some of the key guidelines we have followed here are
o Minimal footprint – Since M2M data is small and frequent, it is very important that we have minimum overhead when getting the data from the sensor network. We have therefore defined our REST protocols to have bare bone headers while not losing on the context and security. We are also building interfaces to support TCP / UDP as well as MQTT and other communication protocols to leverage some of their inbuilt strengths.
o Failover – Quality of Service is another very important aspect. Making sure that the sensor information is tracked and delivered effectively, is quite critical as some of the applications might have high sensitivity and losing that information can have serious implications. We have built our system to make sure that each piece of information is captured and necessary triggers activated in case there is a delay or loss through the network. This is achieved through well defined response codes as well as support for “heartbeats”
o Security – A lot has been said about the importance of security and IoT and the lack of it. We have seen numerous instances of security breaches causing some major problems in early stage IoT deployments. While the standards around security are still evolving we have taken a simple but fool proof approach so that no one can impersonate or sniff on the data being sent from the sensor networks. The approach is to achieve this through our custom security protocols while there is some standard that emerges. Thereby making sure that there is no compromise on the customer’s data security
o Interoperability – While a lot of the existing platforms claim that they are truly interoperable and they can take data from any or every device in the world. The reality is that given the state of art and the state of standardization, it is impossible to achieve it “Out of the the Box”. Here again, we have taken a simple approach of keeping the architecture modular and simple. So that the effort and time required to interface some other devices and platforms is limited to a couple of days if not a few hours while not trying to code of each and ever protocol that exists in the world. Integrators can actually use our APIs and SDK for writing their own handlers and upload to give them full flexibility to build their devices and IoT systems that suit their needs
o Flexibility – We understand that while building IoT systems, the data that comes from the sensor network can change multiple times and each domain has their own mechanism for grouping the devices / sensors and sensor data. In a sense, the data coming from sensor networks is truly “unstructured”. We have therefore defined our APIs and protocols to give a full flexibility to the system developers and integrators to generate their own hierarchies and send data. Using our state of art rules engine, you can then create your own business process workflows and triggers to notify and actionize specific events or trends.
o Business rules development and management – Being able to act at real time on data coming from the wireless sensor networks is the crux of any IoT deployment. Given the importance of this, we have put a lot of effort in building a flexible and scalable business rules management system that acts on combination of device and system configuration and sensor data. Users can build simple and complex rules and alarms that can be put into the system in real time and modified as needed to “act” on the real time information and trigger system defined and custom actions. This, we believe is one of the most important design pieces of our system and makes it hugely useful.
- Device management – With multitude of devices and across different domains and verticals being able to administer and manage them effectively plays a big role in the success as well as Total Cost of Ownership – TCO of the IoT deployment. For that reason, we have invested in a very scalable but simple device management system that does not assume a particular structure or approach. The user interface is also search driven and devices can be identified, grouped and searched through custom meta tags. The customer has full flexibility to define these meta tags, attach them to group of devices and create views and actions based on these groupings. This makes the device management and workflow a fun and easy activity. The entire UI is built on responsive and web 2.0 concepts and technologies that ensures that the simplest and most complex of use cases can be adopted and actors can perform tasks on the go.
- Analytics and Reporting – Some of the basic concepts we have adopted for reporting and analytics is that there is no report that fits all customers. Each customer would have a unique requirement that would not fit in the model that the analysts would have thought about. At the same time, having simple and uncomplicated insights should come out of the box. Using this philosophy, we have adopted a two pronged strategy.
o One is a standard customer dashboard that gives specific insights in as visual manner as possible. These are based on the type of device.
o The other is to build necessary infrastructure to quickly churn out custom reports based on customer needs. This infrastructure plugs into both the structured as well as unstructured data and provides ability to apply domain specific implementation to get the necessary insights.
o While that is all good, we also understand that our customers will have a number of other systems and ERPs in their ecosphere. Therefore all our data is accessible through intuitive REST API that can be used by the integrators to extract information from the Osmosis platform and integrate with other systems.
- Cost – As I had mentioned in a previous blog on outsourcing and IoT, costs and ROI will start playing a very important role in the adoption of IoT as we get on to the serious side of the business. Keeping that in view, we have made sure that the overall cost of the platform is maintained at the bare minimum without compromising on the security or scalability or resilience of the system. The impact on cost has been a constant thread that has governed our decisions on technology, design and usability of the system. And it is not just the cost of implementing and IoT solution but also the long term cost of ownership. Given our small, lean and agile approach, and the distinct advantage of being in Hyderabad, India we are confident that the platform we have built can be really competitive on cost front.
To sum it up, it has been an interesting learning curve building the Osmosis platform and are happy with what has come out. Its still under evolution but we are confident that it has reached a stage where we can reach out to potential customers and start using it for production deployments.