#IoT2CRM: The gateway revised

Sometimes, doing activitities non CRM related, are helping you to get some new insights. This evening I was vacuum cleaning the pool and at a given moment the vacuuming stopped.
At first I didn’t notice it, but then I heard that the sound of the pump changed. I turned it off and found out that one the filter was clogged with small leafs and dirt. Then it dawned on me.

This is exactly what will happen if we connect our CRM system to the internet to collect all kinds of data from IoT devices (things) out there. Like I described before in the article “#IoT2CRM: Time to get connected – part 2: Concepts of the gateway”. I’ll explain why.

Pool

As I described before our CRM system is dealing with potentially millions of things which are sending data. In our gateway we are already handling the load by implementing a buffer in which the incoming messages are stored temporary. From our gateway, the incoming messages are injected in our CRM system by a dispatcher.

However, are we waiting for millions and millions of messages in our CRM system? Personally I think not!

The messages can be very useful to us, but I think they shouldn’t be stored in our CRM system, but in a seperate database or data warehouse in which they can be transformed and stored in a way that will provide us with all kinds of information. Information we probably won’t be able to retrieve from CRM.

Then we can define some queries/jobs that will run against the stored data, and the results of those queries/jobs may result in one of more records in CRM.

An example:

Suppose we are an elevator manufacturer and our elevators are operation all across the globe. Modern as we are, our elevators are connected to the internet and provide us with all kinds of information. Real time we can see what the elevator is doing (ascending, descending, doors opening, doors closing, read weight etc).

Our elevators are tracking the time it takes to open or close the doors. For all elevators those times should be more or less the same. Each time the door opens of closes, a message is sent to our gateway. The message contains the date and time, the elevator code and the time in milliseconds required to open or close the door.

In our data warehouse we run a query on the enormous amount of messages to calculate an average time for opening and closing doos. Furthermore we run queries to find elevators that have an anomaly. An anomaly (e.g. extreme slow doors) can mean that there is a malfunction.

In that case the job querying the data warehouse will create a sevice message in our CRM system, resulting in an engineer to be send to the elevator.

The Advantages of having the enormous amount of messages in a separated database / data warehouse are:

  • we can use standard tooling to query the data to create reports or graphs (e.g. Power Bi) without having the IT department creating those reports.
  • our CRM system will only contain relevant information, keeping it lean and mean.
  • having a separate database for storing the massive amount of incoming messages will allow us to collect data over long periods of time without being dependend of a specific CRM system (think timespans of decades).

Adding this new insight changes the high level architecture of the gateway.

Gateway2

 Sometimes it is bizar to see how the human mind works.

One thought on “#IoT2CRM: The gateway revised

Leave a Reply

Your email address will not be published. Required fields are marked *