In case you have not noticed, M2M opportunities are capturing a lot more press lately than they have in some time. The term M2M alone gets 68 million monthly searches on Google, and there are a thousand good and silly reasons why. The good reasons and their followers in solution development and deployment win out, but even the ‘winners’ in the current market environments may not be taking the time to fully investigate, understand, and tell the real story of what will drive M2M success.
At the same time, many people—both visionary and misguided—are proclaiming that they have the answer to the stuttering pace of penetration of M2M in a number of markets. Some of the ideas are actually pretty good. However, most of those ideas are focused on a handful—and subset—of real challenges in building out the next generation of functions in infrastructure for the M2M: physical, data link, access and transport layers in the open system interconnection, or OSI model.
That is all necessary, but insufficient, for any of us to realize the great human potential in M2M. We have a few other technical requirements to sort out in order to meet the market.
To-date, we have written mostly about commercial issues in these M2M markets. Today, we are going to share a bit about the technical requirements that need to be addressed—earnestly openly—in order for the M2M markets to deliver more of their promise for deployers and developers.
Killer Enabling Technologies (KETs)
KETs. We chose the term as a tip of the hat, and perhaps poke in the eye, at those that have been hawking the next killer application come to save M2M. It is our opinion that there are no killer applications on the horizon, but that intelligent implementation of killer enabling technologies is required to see the biggest and broadest adoption in these M2M markets. (We examine this idea a bit deeper with custom research in the 2013 M2M Sourcebook)
Qualifier: Any one of these KETs could form the backbone of a company strategy, or even an industry segment. We are not pretending to tell the whole story here. Rather, our goal is to define and elevate them sooner, so that we will not be discussing them as barriers later.
The five KETs are:
1. Persistent sockets
2. Resilient networks
3. Pervasive media management
4. Contextual event-based intelligence engines
5. Human factors display and visualization
We have written before about Persistent Sockets. We believe it is important enough to elevate to No.1 on this list. Our concept of a persistent socket is this simple: the technologies that we deploy to support connected unattended devices to the Internet MUST have the ability to create value for 5-10 years in MANY markets in order for those markets to materialize. To be clear, we do not believe that EVERY socket in the emerging M2M markets will require duty cycles of five, seven, 10, or 12 years, but many more sockets than most people think will. There are many reasons for this, but, we will highlight three:
1. Many of the applications will connect fleet, other mobile or remote assets. Physical maintenance and operation of these devices will be prohibitively expensive. Truck rolls and boots are really expensive. Missing the mark in reliability can destroy ROI.
2. Many of the applications will be the tip of the iceberg in terms of value potential. Deployers are still more cautious than aggressive—with most technologies. M2M can support a wide range of data feeds, decision support and value-add. We believe more deployers will roll out sequentially over time than all in one shot. Those platforms will need to support that process.
3. The duty cycle of many of the core, initial or sole applications, may be five, seven, 10, or 12 years. So, regardless of the functional footprint, the device will need to operate reliably over time. And that will require support for changing access, security and services regimes. Layering them into a persistent socket will be far more cost-effective than ripping and replacing.
Resilience is one of the most powerful, and fastest moving, trends in military, environmental, and network science today. Resilient networking is critical to the cost effective delivery of secure, reliable, value-added M2M services. Resilient networking is in many ways the future of cyber security with emphasis on:
1. Clearly defined policies—rules—not only for machines, but, for people seeking access to or value from the systems that need resilience.
2. Heterogenous regimes, where homogeneity has been the too-well documented enemy of cybersecurity for nearly a decade.
3. Automated Course of Action, or the equivalent of having PEPs (policy enforcement points) populate the edge of networks
Pervasive Media Management
This is a new term that we’ve come up with. We feel the term is fitting for the requirement for M2M solutions to support media processing. A little bit now. A lot in the future.
1. M2M is heavily reliant on context to create value. A key element of context is location. Digital location tools—often called mapping, GIS or GEOINT—are a key driver of that. And their data formats are not media formats.
2. Deployment of digital image capture devices—still or motion imagery—are growing rapidly. Some might grow exponentially. They represent an increasing source of value for deployers and operators of a wide range of tech solutions, including M2M. One of the ways that M2M will grow in power and value is through fusion with other inputs—and not just integration with ERP and CRM and such. Rather, the fusion of multiple M2M nodes, or M2M nodes with other sensors and transmitters will be critical to open some markets, grow in some markets and sustain others. And media will be a key component of the fusion play(s).
Contextual Event-Based Intelligence Engines
Warning, this might be a bit of a rant. Ever ask yourself why there is/will be a surge in demand for business analysts? Some have even called business analysts the next corporate MVPs or heroes. And why? Because we have raced to produce a ton of data that no one really knows what to do with:
a. The most valuable resource in the world is time. And the key to understanding time is predicting and deciphering events.
b. We need to stop ending our discussions with the asset. Value in asset management is limited. The real value is in predicting and managing EVENTS that the assets are supporting—or driving.
c. Event-based intelligence systems are challenging as hell to design and develop, deploy, and maintain.
d. In order to be successful with event-based intelligence, you must START with operational requirements … the actual work. What value is created? Context.
e. In order to codify this work in a digital solution, you need semantics. You need ontology. You need something more than orthogonal look up tables with regular polling schedules.
Or maybe markets are hiring business analysts to work with operations people to define the context, ontology, semantics …
Display and Visualization
People like pictures. Soon, people will need pictures. The density, complexity, and richness of more and more decision support tools will make it impossible—if it has not already—for people to apply the intelligence that M2M-enabled solutions are delivering. I am sorry, mom, for the language, but, a lot of the user interfaces that I have seen in these and other markets are butt ugly. They do not work. They slow operators down. And the hurtling forward of silicon-carbon integration will arrive us at places in time where people are the slowest parts of a number of logic chains. And yet, people will always be key, if not primary, users of the intelligence produced by M2M solutions. We need better interfaces—such as the ones Colin Ware develops. Miss that point and you miss the market.
So as many of our most talented do incredible work through OSI layers 1-4, let’s make sure that the other talent is concentrating on these five KETs. Otherwise, to use a car analogy, we will have designed and delivered a brilliant next-generation, camless, electronic value control system for out hybrid engines and integrated it with a seven-speed variable timing and torque transmission but without (a) durability to not require an overhaul once every 25,000 miles, (b) poor brakes, (c) no passive or active passenger restraint, (d) no connectivity to network’s entertainment, navigation, or safety systems, and (e) indecipherable driver controls.