In software development, agility typically refers to iterative and collaborative methods of working. Agile methods bring “just-in-time” to software development. But without a supporting agile architecture, timely delivery will rarely happen. And for IoT, “just-in-time” is simply not good enough. Your IoT platform needs to be ahead of time.
Software Development Lifecycles (SDLC) are impacted as software development increasingly becomes agile through Continuous Delivery and DevOps schemes.
Of course, HOW you develop your software is of importance. Yet, WHAT you build is equally important. The need to easily adapt to change drives agility. And for that same reason, software architectures must cater for future change from day one.
For years, we have striven to decouple software functions to make them less dependent on one another, which is all good. Yet, once our software moves into clouds and/or incorporates increasing numbers of intelligent “things”, decoupling is not enough.
Our E.ON case study provides an example of an IoT platform built with such architectural agility in mind. We’d be glad to share the experience with you.
IoT and edge computing
Pushing data processing to the edge, near the data source, becomes a necessity for efficient IoT platforms. And this, in turn, introduces a new type of dependency, the introduction of “unknown unknowns”. If you design your software solution based on what can be pushed to the edge of currently known and connected “things” and the capabilities they offer, your edge computing becomes hard-coded and stale from day one.
Thus, our architectures must enable the detection of new capabilities and the generation of new services at run-time. We have to automate automation. We must embed the ability to cater for change not only in the software we build ourselves, but also taking into account the change in third party services we may want to consume in the future.
IoT and Industrial Control Systems (ICS)
Legacy Industrial Control Systems (ICS) have some things in common with modern IoT platforms. They receive data points retrieved from large numbers of monitoring devices, process the information and act upon the results by sending instructions to device controllers. For this reason, industrial IT can potentially benefit from the rapidly growing availability of “smart devices” capable of monitoring and controlling industrial equipment. Yet, in industrial IT, experts have been hesitant. The requirements on “near real-time” are strict in ICS. If a controller is delayed with just a few milliseconds, the disaster may already be unavoidable. While native SCADA protocols are trusted to meet near real-time requirements, the internet protocols of IoT have (rightfully) been questioned.
Faster than real-time – ahead of time
The real-time objection is, however, becoming less relevant. For one, IoT protocols have become faster. But more important: the power you gain by collecting and analyzing vast amounts of data from (fairly cheap) standardized and componentized (IoT) actuators, enables so much more of intelligent and proactive decision making.
A parallel illustrates the problem: Airbags in cars explode in your face in case of an accident. The “real-time” requirement is literally a matter of life or death. If the sensor identifying a crash event triggers the inflation of the airbag a millisecond too late, it is useless. However, in modern cars, “IoT” adds vast amounts of additional data to help identify potential catastrophes ahead of time. The distance to other objects on the road, lane departure warnings, pedestrian detection and other “smart” features in modern cars, help ensure we become less dependent on the airbag inflation control. In similar ways, our experience from industrial IoT shows that ICS and SCADA environments greatly benefit from enhancements offered by modern IoT platforms. More data, more intelligence, more proactivity. Rather than being reactive in “real-time”, your systems become proactive ahead of time.
Our industrial kiln case study provides an example of IoT technology built with “near real-time” requirements in mind. We’d be glad to share the experience with you.