I was at an Internet of Things event a couple of weeks ago and listening to the examples it was clear there is too much focus on connecting devices, and not enough focus on interconnecting devices.
Connecting devices implies building devices that are designed specifically to work within a closed ecosystem, to report back to some central hub that manages the relationship with the purpose-built device. Interconnected devices are designed in such a way that they can learn to collaborate with devices they were never designed to work with and react to events of interest to them.
So what will this look like? For one possible scenario, let’s start with the ubiquitous “smart fridge” example and expand this to look at the way we buy our food. There has been talk for years about how fridges will be telling us about the contents, how old they are, whether anything in them has been reserved for a special meal, what is on the shopping list etc. Even to the idea of placing automatic orders with the food suppliers, but what if we want to still be involved in the physical purchasing process, how will the Internet of Things, with interconnected devices work in that scenario? Here’s a chain of steps involved:
- Assuming our fridge is the central point for our shopping list, and we want to physically do the shopping ourselves, we can tap the fridge with our phones and the shopping list will be transferred to the phone.
- The fridge or our phone can tell us how busy the nearby supermarkets currently are, and based on regular shopping patterns, how many people will likely be there at certain times in the immediate future. Sensors in the checkout will let us know what the average time is for people to be cleared. Any specials that we regularly buy will be listed for us to help make the decision about which store to visit.
- We go to the supermarket and the first thing that happens is the supermarket re-orders our shopping list in accordance with the layout of the store.
- The phone notifies our family members that we are at the supermarket and lets them know we are there so they can modify our shopping list.
- We get a shopping trolley, which immediately introduces itself to our phone. It checks with our preferences in the phone as to whether we want its assistance, whether it is allowed to record our shopping experience for our use, or to assist the store with store planning
- As we walk around the store, the phone or the trolley alerts us to the fact that we are near one of the items on our shopping list.
- If we have allowed it, the trolley can make recommendations based on our shopping list of related products, compatible recipes, with current costs, and offer to place the additional products into the shopping list on the phone and even into our shopping list template stored in the fridge if we want.
- As we make our way to the checkout, the trolley checks its contents against what is on our shopping list and alerts us to anything missing. Clever incentives might also be offered at this time based on the current purchase.
- As soon as the trolley is told by the cash register that the goods have been paid for, it will clear its memory, first uploading any pertinent information you have allowed.
- Independent of the shopping experience and the identifiability of the shopper and their habits, the store will be able to store the movements of the trolley through the store, and identify how fast, any stopping points to identify interest and analyse for product placement.
- Once we get home, we stock the cupboard and the fridge, both of which update our shopping list.
- As soon as we put the empty wrapper in the trash, the trash can will read the wrapper and add the item to a provisional entry in the shopping list, unless we have explicitly pre-authorised that product for future purchase.
Another example would be linking an airline live schedule to your alarm clock and taxi booking, to give you extra sleep in the morning if the flight is delayed. Or having your car notify the home that it looks like it is heading home and to have the air conditioner check whether it should turn on.
While we focus only on pre-ordaining the way devices should work during their design, we limit their ability to improve our lives. By building devices that are capable of being interconnected with other devices in ways that can be exploited at run time we open up a world of possibilities we haven’t begun to imagine.
One of the beautiful things about Salesforce is the ability to create or modify an object’s structure with defined relationships, permissions, application contexts, business rules and page layouts.
Think about it for a second: how many frameworks do you know of that enable you to modify the data schema and automatically set:
- Relationships between objects;
- Cardinality rules, (definitions of how objects relate to each other in terms of how many of one can be related to how many of another);
- Business rules, (what fields are mandatory, what fields are dependent, default values, what fields are read only or even visible for certain users, which fields must be unique);
- Referential Integrity rules (which records will be deleted when a parent is deleted);
- A User Interface, even one that can be different for each user profile;
- Application context (which objects belong together to form a sub application;
- Access to reports; and
- A Notification engine that can share changes with subscribers or record owners, or handle task assignments.
And all with a point and click interface – no programming required (unless you want to), and all with defaults to allow you get the job done quickly. Very quickly. Read more
This article is the first in a series of articles looking at changes/improvements I would like to see happen. You will find them categorised under the category “Things I Want to See”, and also filed under specific vendors where appropriate.
An increasing number of people are coming to understand intuitively the difference between traditional peer-to-peer document sharing modes where multiple instances of documents exist, at least once on each client machine. You know the drill, you attach a document to an email, the recipient opens the attachment, edits it, saves it and then attaches the saved new version to a new email and sends it back. Before long, there are multiple copies of the document and it can be difficult to know how the document evolved. In the case of several people, it can even be difficult to know which version of the document is the current one. There may not even be one single latest version, as two people may edit two different earlier versions at once. Stitching these all back into a master document is not easy.
A lot of tools have been developed to simplify the potentially incredibly complex task of managing all these document versions. But the cloud provides a simpler way, by fundamentally only having one document location. So instead of linking people to people, you link people to documents and the problem elegantly goes away:
|Traditional Document Sharing||Cloud-based Document Sharing|
I am Alan Perkins, CIO at Altium Limited, a company that lives and breathes the philosophy that innovation is the key to a better world. Our company reflects it, our people reflect it and our products reflect it.
For the past four years we have been moving our entire business into the cloud and I am often asked to speak about our achievements and experiences. IDC recognised this last year by awarding Altium with an Enterprise Innovation award and naming me one of the top ten finalists for Asia Pacific CIO of the Year.
I intend to share my thoughts about various aspects of the cloud here. I welcome comments, and am keen to see others learn from my experiences, both the good and the not so good.