Our commitment to IoT
At Configured Things, we are committed to the provision of a richer configuration language with associated runtime, security framework and other ancillary tools. It is with these tools that continuous configuration management becomes a business enabler.
IoT version 1 – The current prototype
As we collectively come to terms with the idea of IoT version 1, bright organisations are refreshing their old tech and issuing new tech to open up new possibilities. These possibilities are quite rightly generating lots of excitement around positive and perhaps negative disruptions to our lives. However this version IoT version 1 is just the prototype. Wait until version 2 when the smart crowd – the global population – gets to apply their imagination to drive use cases for IoT. It is clear that the potential for change is huge.
The evolution of IoT
This continuous evolution of IoT use cases mandates that IoT platforms cannot be limited by baked in functionality defined by static code that matches only the imagination and purpose of the original provider. Static functionality that is exposed by a narrow, often one-time configuration schemes. These Things are costly to deploy en-masse and often financed via public funds. Society is going to be more and more sensitive to waste. Ripping out and starting again when the need changes is going to be politically non- acceptable.
Realising the potential
We believe that a well-engineered configuration management can dynamically create cyber resilient systems of things that provide ease of integration, control and a safe-space for human-machine and direct machine-to-machine interactions. It is with such a system that the hype of technologies such as AI, Blockchain 2.0 and 3.0, Mixed Reality and Robotics can not only become a reality, but widespread and not restricted to niche applications.
Configured Things believe that the configuration of Things, particularly IoT, needs to be thought of as an automated, continuous, dynamic process perhaps taking inputs from A.I. Baked-in functionality hidden in software should be limited as much as possible. General purpose functionality should be encouraged and functionality exposed via rich configurations.
This continuous configuration management needs to be aligned with a ‘DevSecOps’ approach to security so that the resulting, perhaps federated, systems are recognisably secure and automated to an extent that they add no overhead in terms of operations.