I would really like the IoT to work, I really would. It can make my life a lot easier. But, there are many signs that the purveyors (even the big ones) of the components (the “things”) that constitute the IoT just don’t get it. I will open this discussion by reminding everyone that the IoT is fundamentally a technical architecture. And that there are three objectives of any technical architecture:
- Customer Satisfaction—this one is easy to understand; customer satisfaction should be measured along several dimensions:
- Product Quality— At the highest level, I like to think about quality as having two attributes. One (discussed in the next bullet) is the characteristic of being able to meet the functional needs demanded by the consumer and the other relates to the number of defects a product imposes on the consumer. Obviously, this is an oversimplification of the subject, but it is satisfactory for the purposes of this discussion.
- Meeting the functional need—this is essential. If a product doesn’t do what the consumer expects it to (either missing functions or functions that don’t deliver as advertised), the customer can not be satisfied. I will note that I think that this attribute is the one that most IoT purveyors get most right.
- Ease of use—This one is relative, but the IoT is essentially a distributed incarnation of what we used to call consumer electronics, i.e. television, VCR, iPhone, Walkman. And, they should (like any good piece of consumer electronics) be easy to use—especially for anyone over 60 years old.
- Ability to enhance productivity (or at least happiness)—This is the raisond’être something we buy with our disposable income, and I have yet to find any consumer-focused IoT implementation that is really a necessity.
- Performance—this is a measurement of how well, and how consistently the product meets or exceeds the customers expectations as it performs the functions it is designed to accomplish.
- Affordability—affordability is not just measured in the initial sale price. And, if that total cost of ownership is too high, no one will buy it. But, priced properly, affordability must be considered in the context of:
- Product quality—door locks must work. They must lock the door when they are supposed to and unlock too. If the product only performs these functions 95% of the time, that is unacceptable. So, the product must meet quality expectations and still be perceived to be a good value for money.
- Maintainability—Maintainability is not just to be thought of in terms of being able to repair the product, but also update it (easily) with new features and reconfigure the product as the world changes. For instance, a streaming music player that depends on a file sever for its music content must be easily reconfigurable to adjust for the almost certain eventuality that the file server will be replaced (probably several times) during the useful life of the player. If simple and expected tasks like these can’t be easily understood and performed by the consumer, the product isn’t affordable.
- Scalability—Most people will introduce this technology in stages. They may start by implementing several IoTs-controlled light switches and then add more as the technology proves itself. If the infrastructure (network, application, etc.) can’t properly scale to support multiple devices (i.e, the application works fine with one or two devices, but gets very cumbersome to use with two dozen) the consumer is not likely to be very pleased.
- Extensibility—some of these systems involve considerable overhead (capital investment or labor to install and configure) and if they don’t have the capability to incorporate new functions and features (to give them a reasonable working life) as they become generally available, they will get a reputation for being designed for obsolescence.
- The ability to work within the relevant commercial framework—this includes:
- Interoperability—this is discussed fully in the section on standards. But, from a customer perspective, a lack of interoperability hurts the consumers ability to easily manage their environment and makes their IoT environment cumbersome and therefore frustrating to deal with.
- Resiliency—things go wrong. Power and networks fail. Without the ability to operate properly through these issues and not require constant care and feeding, IoT will be like the Christmas present that gets a lot of attention the day it arrives, but gets set aside when the child realizes the overhead required to enjoy it.
- Reliability—many folks don’t differentiate between resiliency and reliability, but they are different. While resiliency focuses on being able to bounce back from adverse conditions (like a network failure), reliability relates to the ability of the product to operate as expected under normal operating conditions. We don’t want it to break.
And, if all of this is not already complicated, there are four implementation domains that need to be considered:
- Hardware—this is the platform upon which the IoT functionality is delivered. Whether it is a door lock, a music server or a lighting control system, IoT is built on hardware.
- Software—software is the brains behind the IoT. It implements the control functions and directs the hardware to perform the functions you are expecting from the product. It is complex, must deal with a distributed (by definition) architecture and be easy to use and reliable.
- Management—these systems need a management tool. This device is necessary to configure, operate and troubleshoot the distributed environment that defines your IoT implementation.
And, finally, there are several characteristics that any architecture (defined here by the hardware, software and management domains outlined above) must have:
- High Quality—I have touched on this previously, so the only thing that I will add is that quality is situational, i.e. there are both cost and functional implications that help to define the level of quality that you might expect. For instance, as I stated previously, I assert that door locks must work, while I would also assert that an inexpensive light controller should probably not be held to that same high standard.
- Full featured—”Full featured” means that the product does what the consumer reasonably thinks it should do. I have found that on basic feature sets, designers of consumer oriented IoT product sets seem to do a good job. They tick the boxes.
- Secure— This goes without saying. And, these systems not only need to be functionally (in the context of what they do) secure (i.e. a door lock should not be able to be hacked), but they also need to be secured against being a platform for other mischief, i.e. they should be resistant to being leveraged as bot in a distributed denial of service attack.
- Well supported—there are very few (I would argue none) computer-related products that don’t need support. The concept of many IoT offerings is very attractive. There will be demand. There will also be a wide variance in the skills that the consumers of these products possess. And, these products will fail to operate properly—they are complex, distributed computer-directed products after all. So, you need support that is up to the task of keeping the installed base operating.
- Standards based—the IoTs is all about interoperability. Products from one vendor really do need to (seamlessly) operate with another. Management frameworks need to be capable of managing, in an integrated fashion, the products (I have six different products (HVAC, lighting, window coverings, security cameras and 2 separate music systems) in my house) that the consumer incorporates into their environment. This means developing (at several levels) standards that allow for this integration and fully supporting them in the context of management and operation.
OK, I have spent most of this post talking about what I think are the requirements for the IoT. Why did I do this? Because, as I look at the landscape, evaluate products and work with ones that I select, I am having a hard time thinking that the designers of the IoT’s products have thought through the product/technical design requirements that I have outlined above. And let me be very clear, I have trimmed down my list of requirements to fit the space I allocate for my posts. A comprehensive examination of the architecture would be voluminous.
My experience with the IoT on most of the requirements outlined above suggests that very little if any thought was given by the designers to a rigorous design process that included much more than a focus on checking the functional boxes required to advertise that they have functionally generous product.
As I look at IoT products, even ones developed by well established technology-to-consumer based vendors, I see attempts to provide functions that attract consumers, I even see a real attempt to build products that are designed to make people happy. What I don’t see are well architected products that are designed to be (easily) managed (configured, updated and troubleshot), that are resilient and that are really (especially at the software level) reliable.
I was recently on the phone with a vendor who was helping me troubleshoot an issue with a music server. I begin by stating that while not a network expert, I am reasonably technical. And, at one point, I said to the technician, that it seemed unreasonable to me that a consumer would be expected to know enough to install and configure this piece of consumer electronics. I was right, and he agreed. His level of competence was equal to or better than the network administrator that most small/medium businesses hire to keep their networks running and mine wasn’t. I couldn’t therefore troubleshoot the issue I was having—which was with the NetBIOS (no, I shouldn’t have to know that to install a music player) name for my Mac.
Another vendor who provides wireless hubs for my home and is one of the better (on all counts) providers of product necessary for the IoT to work properly expects that the consumer who buys their product to know: 1) that the need to turn off the DHCP service (put it into bypass mode) on their internet provider’s modem; and 2) do it. This is not the level of competence that most people buying their product have. And, this vendor is one of the best having ticked off the most requirements that I believe are essential for IoT to become truly ubiquitous.
Structures (as an engineering principle) need to be designed to bear the weight of the burden that they are designed to support. IoT is such a structure. And, if IoT vendors don’t get their collective act together:
- The IoT (not being properly designed for purpose) will collapse under its own weight because users will generally give up on the concept (it being more work than it is worth); and
- The consumer of this potentially game changing technology and will never gather the momentum it needs to be a ubiquitous and truly mass-market product offering.
Copyright 2017 Howard Niden
— you can find this (days earlier) and other posts at www.niden.com
and if you like this post: 1) please let me know; and 2) pass on your “find” to others.
Leave a Reply