SPL stands for Software Production Lines. With ‘production’, we designate not only the productive servers with the operative software version interfacing external and/or internal customers, but the whole value chain, starting from the moment as first tangible digital artifacts appear relating to the target software product.
These both domains are quite broad, and the topic of the question appears a little bit ambiguous. We think that in general, here are in fact two topics to discuss.
- (1) What is the impact of SPL to IoT?
- (2) What is the impact of IoT to SPL?
To address the first topic, we have to say that IoT software is normally less complex than other software artifacts where SPL approach is really worth. Still, we think that if your IoT software teams are big enough, and product complexity is high enough, SPL methods might be worth. As we always recommend, start with the low hanging fruits and assess the value chain: which teams works on what, what are tools in place, are there practices resembling Continuous Integration, Continuous Delivery and DevOps. This is where you start to establish SPL thinking in your organization; then proceed to more formal consideration how your organization implements and performs in the SPL domains Labour Automation, Analysis and Advanced Visualization.
For DevOps in context of IoT, you might also want to consider the following links:
How Docker quickly advanced development of IoT application (2014)
IoT development with Docker containers (2015)
Rapidly develop Internet of Things apps with Docker Containers (2015)
To address the second topic, we are sure that the SPL domain will be able to learn a lot from Internet of Things. From our perspective, any tool instance, or a quality gate, or even a software component could be modeled following same concepts as used for Internet of Things, only that in this case “the thing” is already a digital entity. You can read more on this topic in this post.