The quality of analytics depends upon how “clean” or authentic the data is and how quickly one can obtain the data that algorithms operate on. We have already seen instances where flu epidemics were misjudged because of incomplete data and/or data assumptions, or where market opportunities were missed because relevant market facts were overlooked in the data.
For most companies, it’s virtually impossible to incorporate all data that might be relevant for the topic they plan to analyze. As organizations add the Internet of Things (IoT) into their analytics, the plot thickens because of a silent threat that few analytics managers think about: the fundamental flaws in embedded software development.
Embedded software—not traditional IT applications—runs machines, produces machine automation, and enables machines to talk to one another and to data repositories on the manufacturing floor and across great geographic spans.
Historically, embedded software was developed by engineers who did not universally employ the software development life cycle methods of traditional IT apps; this meant that detailed quality assurance (QA) testing on the programs, or ensuring that program upgrades were administered to all machines or products out in the field, didn’t always occur.
Some of this is changing because more IT grads are entering the embedded software field, but they bring their own shortcomings—these grads understand the IT life cycle and QA testing methodology, but unlike software engineers, many of them don’t grasp the roles that security, safety, and environmental “fit” play in software that is embedded in IoT products and machines.
“Embedded software can have an active life of years, and it must be continually maintained throughout that life cycle,” said Andrew Girson, CEO of Barr Group, an expert systems consultancy. “A failure to follow best practices in producing and maintaining this software can impact safety and life….It’s far less expensive to adopt embedded software practices that lower risk and reduce the potential for error than to deal with the repercussions of a software failure.