Verizon is on a roll…

Verizon is getting aggressive in growing its IoT business. Verizon’s first foray in IoT was in Smart Home when they launched a service around the solution from 4Home (acquired by Motorola, my guess is that the acquisition was influenced by Verizon?). It was a DIY service unlike its peers who had launched managed services (Comcast, AT&T, Cox, ADT), and IMO it was dead on arrival. It limped along for 4 years and finally shut down.

Verizon’s strategy also seemed uncertain when they acquired Hughes Telematics back in June of 2012. Hughes Telematics is based in Atlanta – and I have only heard of anecdotes and rumors of that division constantly losing people or being laid off since 2012. It felt that their Connected Car strategy was falling apart.

However recent events point to a different story – they are getting serious about this space. They have announced two back to back acquisitions. First with Telogis in June of this year and it was followed by Fleetmatics in August. Verizon certainly has heft between the three acquisitions in the Connected Car & Telematics space.

And to keep the momentum rolling – Verizon announced that it is acquiring Sensity Systems, a Smart City startup last week.

The question though is does it have the internal organizational strength and discipline to make the most of all of these acquisitions. Remember that they have also announced that they are acquiring Yahoo!

List of all the VZ Acquisitions as compiled by Crunchbase: https://www.crunchbase.com/organization/verizon/acquisitions

 

Here is list of analysis on the acquisitions worth reading:

CRN on the the reaction of VZ Partners

CRN on the Sensity acquisition

TechRepublic on the Sensity acquisition

 

 

 

5 Observations on IoT and Physical Web

Scott Jensen introduced The Physical Web project in October 2014. It was a result of Scott’s thinking on this subject even before he joined Google (in his own words – his thinking boiled down to 10 minutes in this TEDx video). The “launch” was covered by several blogs and being categorized as an IoT standard! It is a neat idea. I can see why Google would want to promote it whose business model is based on searching, indexing the entire web. This discussion has strong similarities to the subject of Native vs. Web Apps (for a great summary – read John Gruber’s post – summarized nicely here.). URL for Everything on the same topic (using URLs for Things/IoT)  by Duncan Cragg recently led to a Twitter conversation, and it triggered my observations on this subject.

Let’s dig deeper.

#1. It is about Category of Devices, not individual things

The motivation for Physical Web is “interaction on demand” and given the number of connected devices – “each new device will require its own application just isn’t realistic”. The following reproduced from the Physical Web’s webpage:

The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device – a vending machine, a poster, a toy, a bus stop, a rental car – and not have to download an app first. Everything should be just a tap away.

(BTW Wasn’t the QR Code – incidentally at a point of time – the answer to this? It wasn’t for Smart Devices but rather for small businesses – the concept was similar being able to go the right web page and find out more, get more information. How well did that work?)

In the examples above – barring the example of a toy – rest of them are to be encountered outside of your own home network. Bear in mind the notion that each device needs an application is absurd. The right comparison is not individual devices – an application will serve a category of devices. So while there would be trillions of devices connected – at any given point of time a consumer would be interested in interacting with a “category” – not all the bus stops but bus stops in a given city. Bus stops are a great idea to be connected.

#2. App-less Interaction Complicates the UX

Let’s think through the process continuing with the bus stop as an example. First you need to have a Bluetooth Beacon, that is advertising the URL. My SmartPhone needs to support BLE (which soon all of Smartphones will), and in a mode to listen to the Beacon. The Beacon would notify me when I am around the bus stop or physically launch into discovery mode (and hopefully it does not get drowned in the many other notifications fighting for my attention). Now I can navigate to the web page and discover information about bus arrivals. And next time I am at the bus stop – the theory goes I will bookmark the web page. Now think about the UX as you keep interacting and bookmarking this pages! Solving the app problem with URLs/Web Pages gives birth to another discovery problem (going by the same argument if you have many devices you want to interact with – you will end up having many bookmarks).

#3. Connecting and Discovering is just the start, the real challenge is in the System

Let’s look at the same example from another perspective – that of the Transport authority responsible for the Bus Stop. As I always say – Connectivity is a small step in unlocking value. The transport authority now has to integrate its scheduling/logistics backend into the Bus Stop so that the arrival time can be communicated. And the buses need to be equipped with real time tracking and two way communication (Fleet Management) to provide status on where they are, and what time they will arrive. If the Transport Authority is going to implement this system – it will be foolish for them to make discovery and interaction ad-hoc….

The City Mayor along with the Transport Authority would be touting the Connected Travel experience. At the very least they probably be using strategic real estate on that bus stop to advertise how to use their app – the citizen would not need discovery! Not to mention a native apps with QR Codes to download would be mentioned prominently – an app would be drop in the bucket if not in the ocean compared to the challenge of making the entire system work together.

#4. Separate the Data from the UI

Serving “web pages” implies some notion of the User Interface is embedded in the device – and that makes the support after launch harder. Any bugs or potential challenges with the UI will have to addressed. [Duncan’s URL for Everything is one step better in this respect]

#5. Use Cases should drive the approach

The Physical Web project cites another example of paying at the Vending Machine or renting a car:

How does this change things?

Once any smart device can have a web address, the entire overhead of an app seems a bit backward. The Physical Web approach unlocks tiny use cases that would never be practical:

• A bus stop tells you the next bus arrival
• Parking meters and vending machines all work the same way, letting you pay quickly and easily
• Any store, no matter how small, can offer an online experience when you walk in
• A ZipCar broadcasts a signup page, allowing you to immediately drive away

I don’t think so. Why would I want to pay through a complicated process of web pages or even find out that I can pay through URLs? A Vending Machine company is more likely to invest in supporting Apple Pay or Google Wallet, and it will make sure that each of its machine when it supports those payments is advertized loud and clear.

For a store to advertise it’s online presence – does it really need to be connected? If the business owner is digitally savvy – she probably has a website already, or a Facebook page or a Twitter handle.

Final Thoughts:

I am not against the premise of the Physical Web “standard”  (to leverage Beacons, URLs and Web Apps for interaction in IoT). The argument in favor of using Physical Web starts losing value once viewed in the context of the system or the entire IoT solution. I am reminded of relentless drive by Steve Jobs on Simplicity – simplicity also means avoid complicated steps.