Content Copyright © 2014 Bloor. All Rights Reserved.
This blog was originally posted under: The Norfolk Punt
I’ve just been at a virtual round table hosted by Bret Greenstein and IBM’s systems engineering leadership team and it is clear that the Internet of Things is deeply affecting IBM’s view of the world now—for a start, Bret was speaking from an IBM-wide perspective, not just representing ‘Rational’ and he sees deep analytics as absolutely key to making IoT work. He also points out that, despite the science-fiction hype around IoT, the IoT revolution is already underway. The makers of things find it simply too useful (or financially advantageous; consider the economic benefits of the IoT for preventative maintenance, for example) to ignore. In other words, he sees customers already using IoT approaches, albeit often under the covers. And so the engineering community needs to get up to speed on IoT, and perhaps it can learn a lot from people already experienced with, say, designing preventative maintenance programs, as to how the IoT should work.
My concern, and I know that Greenstein is fully aware of the issues, is that the impact of IoT systems development rapidly spreads well outside of traditional engineering silos—and then, can company organisations cope with the ‘people issues’ around that? I think IoT is truly disruptive, more so than the web even, and, while the benefits from doing it right will be enormous, the impact of doing it wrong could well be disastrous.
Think of that IoT poster child, the driver-less car. It promises to reduce traffic accidents and time/energy wasted on commuting by 90%. It may even reduce the number of cars by 90% (think of the car as a ‘Boris bike’). What’s not to love? Well, when men lose this ‘symbol of masculinity’, God only knows where it’ll appear elsewhere. And perhaps people need risk and freedom in their lives and a large part of this will disappear with driver-less cars. Then think of the algorithms in that car—in extremis, perhaps it chooses to kill one person (possibly its driver) in order to avoid a high risk of killing several people. Are we happy with this? At the very least, the IoT engineers building the driver-less car might want to be familiar with the trolley problem—and how will engineers like dealing with philosophy rather than physics?
This leads me to two thoughts that weren’t really covered in the round table presentations. The first is that I believe Greenstein when he says that adoption of IoT has already started; and that it is likely to be adopted faster than previous technologies, in the same way that smartphones were adopted even faster than the Internet was. But the nature of IT, it seems to me, is that the new doesn’t replace the old, it coexists with it—and it can take a long time before old technologies actually disappear. How many of us, now that the web application revolution has arrived, are still using client-server mainframe applications? Probably quite a lot of us (perhaps not always directly), if we did but know it, if we use banks and insurance companies. My point is that we must be aware of ‘adoption with a long tail’ and developers should not assume that everything is an IoT thing even after IoT has been declared ubiquitous. Any more than developers should assume that everybody important to a particular business process has (or wants to use) a smartphone. It might take quite a long time before IoT is the only game in town.
My second thought is around the governance of IoT solutions. Greenstein presented a very nice model for how continuous engineering can build IoT solutions. This includes Cloud and DevOps, for agility; emphasises the place of Analytics and the need to build security in from the start (in fact, cross fertilisation between IBM’s systems engineering teams and its security organisation over IoT is already paying dividends, apparently). There are plenty of feedback loops to provide holistic governance of the process. What was missing (or, at least, not explicit) was the place of simulation to explore the (possibly unexpected) behaviours of complex IoT systems before they reach the real world—much better (safer), I’d think, than responding agilely to feedback from real-world disasters.
Earlier, I mentioned that designers of the algorithms for a driver-less car (I love the idea, by the way; I don’t drive now and when I did, I found it horribly aggressive and stressful) might have to consider the ‘trolley problem’. Well, there is a trolley problem game (it can be a little patronising, sorry), which they can use to explore the issues before putting anyone’s life at risk. I’d like to see game-like, problem-specific, simulations of resultant system behaviours (in a wide sense) as a routine part of building complex IoT systems—I’m sure IBM has the necessary technology—just because, as Greenstein says, although “the value of being right has never been greater”, unfortunately (as he also says) “the cost of being wrong has never been greater” as well.
So, Bring in The Internet of Things! Oh, it’s already here……