Are current product development practices fit for purpose in the IOT world?

The Internet of Things (IOT) promises a step change in the added-value of tomorrow’s products. Of course the intelligent connection of product and services offers significant value-add to (companies and) users, but it’s not just the end-user that benefits. Manufacturers can enhance new products with features and services that deliver additional revenues and profit; potentially over lengthy timeframes.

At IBM’s Innovate 2014 event in Orlando (a conference focused on users of the Rational Software Brand), IBM spent much time talking on its vision for product developers. They use the phrase ‘Continuous Engineering’ to label the ecosystem in which companies develop, deliver and operate products with high levels of complexity and ‘interconnectedness’. To the topic of the IOT, IBM’s thinking about “What it means to be the maker of ‘things’ in the Internet of Things” to quote Steve Shoaf Go-to-market manager for Systems Engineering for IBM.

Focusing on what customers want/need as opposed to what your products do is of course a worthy objective, but in this case it’s one’s that’s raised some fundamental questions; the most significant being ‘are current product development practices fit for purpose in the IOT world’.

The problem is that many of our products and the environments in which they’re designed manufactured, exist and are serviced, have become complex. And the IOT accelerates and exacerbates these complexities.

Why do I say that? Well, for a number of reasons. Possibly most apparent is that the IOT changes the dimension of what was an arguably finite system into a morass of systems of systems. Take the satellite navigation system in a car as one example. Historically somewhat standalone and reliant on pre-loaded maps and GPS positioning satellites, perhaps in the more advanced cars, integrated with the radio/CD system. In todays’ world, we have numerous in-car situational, environmental and infotainment systems that need to act in party; media, mobile phones, vehicle information, car controls, environmental control; many of these communicating with over 100 ECUs that deal with the in-vehicle control systems and the like. In the IOT world the complexity goes one step further; our satellite navigation (and interconnected system) is now party to a host of other systems (of systems); local traffic and information services, road condition monitoring systems, dealer service centres, other vehicles in the proximity etc. Get the drift?

I, for one, subscribe to the vision of a more open interconnected, more cyclical and agile development environment. Change must of course be made with due diligence to compliance, however the intelligence, immediacy and flexibility that we need to develop product in the world of IOT means that people and information must work in concert, and with immediate access to information and requirements/parameters. With this in mind and given the disaggregated nature of many product design environments (mechanical, software, electronics, hydraulics etc.), the next generation of technologies must serve to counsel and direct developments, not overwhelm. I’ve long held that the lack of ‘openness’ of software products (and their data) is a limiting factor to making this an eminently practical proposition. Realistically, no single ISV can uniquely deliver all of our development needs, and customers want to spend time working on product, not on digital disconnects and the software industry needs to move on apace to allow this to happen.

An effective systems methodology will help to address some of the methodological developmental complexities, but to be practical this needs to be highly automated and augmented by technology. In current ‘systems thinking’, model based design and simulation tools fit well with this ideology; allowing users to model and integrate systems and designs early, simulate frequently and iterate often. They allow users to evaluate and optimise efficiently, and by using virtual as opposed to real tests means that they can have greater confidence of function and performance at an early stage in the lifecycle; reducing the need for expensive physical prototypes. Increasing confidence and the improving accuracy of these solutions is helping to make them a more practical proposition across a broad swathe of industries including automotive, aerospace, and medical and consumer devices. Many would argue that democratisation of these tools is now not a matter or ‘if’ but ‘when’, and the promise of new entrants and more cost-effective, practical solutions will certainly encourage adoption outside of the larger enterprises to mid-size users; their needs being no less demanding.

Back to IBM. Their rapidly evolving development vision touches on areas of social integration, Cloud, ‘Big Data’ and analytics. IBM cites these add value to the intelligence of products and their services, and, of course, their respective development environments. Some may consider this as a step too far, but given the interconnected nature of the next generation of even more complex products, for example the autonomous car, I can see where they’re coming from. As is often said “change is the only constant in life”. Changes forced on us by the complexity of modern products will definitely require change in our development practices and methods, and software suppliers and their tools must adapt rapidly to allow manufacturers to garner profit from these changes.