CxM in the IoT: the case for service verticals integration

Editor's Notes

• #2: First of all let me introduce myself: my name is Alfeo Pareschi and I am responsible for the Customer Solutions in Axiros. Which means that I overlook the Demand phase of our engagements with Axiros customers WW. As such, I want to mention a specific aspect which we believe is getting the right attention in terms of ability to monetize the technology.
• #3: Let’s start from the title: we are all familiar with CEM. So what’s CxM and why one more acronym ?
• #4: In the business domain of the Internet of Things we need to couple two important aspects: the Customer Experience - where the tricky part is the definition of who is the Customer and I am going to explain it in the next few slides - and the Context - which is part of the experience itself, when we think that the “Thing” connected lives in a specific environment - which is finally what we want to control.
• #5: ( click to start the transition ) They are all IP cameras, they will all carry live or still frame video but the context defines which application and management function we want to activate. The context defines the additional equipment these “Things” need to connect to, the SLA, the connectivity requirements and finally the complete control plane that needs to be activated on these devices
• #7: ( click to start the transition ) Make examples: - Communication domain: Mobile, Wireless BB over Fiber, Mesh Radio, etc. - A functional domain: Metering, Sensing, Alarming, Access&Authorization - Business need: AMI/AMR, Traffic/Load Shaping, Demand/Response, etc. - Segment in the value chain: packaging, warehouse, transport and logistic, delivery, installation, etc.
• #9: ( click to start the animation )
• #12: ( animations start at click - two phases ) emphasize the concept of the second phase where the context arise from the combination of behavior of two - or more - devices
• #13: ( click to start the transition ) just remind the key concepts
• #14: Here the concept we need to highlight is that a Customer is a pretty different concept than the usual one in the Telco industry. It might be a set of APIs that connect to external applications , plus the direct billed user of a service , plus some other notification APIs that transfer the information about the usage of a service. At the end all of these Customer concepts - including the End User - consume APIs. A user browser is today with modern web technologies accessing APIs in the same way it accesses content on the web thus making the user accessing an application really identical to an application to application interface.
• #15: ( click to start the transition ) going through the concepts to explain the different type of Customers. Some of them are not even real users, but applications to which we need to connect. Make the recent example of the use of WebHook technologies to link to workflows that use other web services - like Google Docs - to create compelling events for the application that subscribes to it.
• #16: The key concepts have been exposed So how do we related them This grphical representation is how we see it Users = Customers Network elements + Devices = Context
• #17: All of them accessible through a consistent set of APIs
• #18: ( click to start for every single item ) This time the key concept we have to transfer is the ability to extend from pure Data Collection to the Management of Device States to the Management of Contexts ( typically aggregation of states across different devices ) to the APIs that expose management functionality over the Contexts. And - since the use of those APIs can be very different - the API layer needs to be extensible.
• #19: So - after consolidating the two key concepts of: Being able to build Context(s) out of the device data, potentially combining them Being able to axpose a polymorphic set of APIs for the same service, depending from the type/profile of users willing to connect to it The next big this is to qualify some specific needs: Communication Network Aware: because - especially in Industrial IoT , but not only - service can happen of every kind of communication network, fixed or mobile. The traditional concept of having a low bandwidth mobile network only for control - which was valid in M2M , does not hold any longer Management I/F Neutral, because when it comes to the ability to build a Context, you might need to interface devices that do not have homogeneous management interface Multi-Layer / Multi-Tenancy: because the need to manage different User Profiles / Use Cases brings with it the ability to create dynamic ( eventually hierarchical ) Device groups. Web Services extendable: because our Context(s) and Customer(s) are by nature dynamic concepts and require the ability to manage consistently changes to the API layer. Not just being able to create new APIs but also the ability to expose different API behavior based on the type of User authenticating to the API Engine User Profile / Use Case agnostic: Here the concept is that no internal behavior of the API engine is designed around any specific type of user. It is not only for a management user, for a service user or for an end user. It’s for all of them
• #20: ( every topic animates with a click ) This is a very broad topic. Play the topics one by one: scalability: in terms of devices, but also transactions and distribution of server infrastructure data models: to be neutral ranging from tr style, to snap style to CLI style to netflow same as above but with even more focus on the ability to integrate new transports this is the wizard style, not only to create new interfaces to the external world, but also to connect them to the internal data models and the business logic
• #21: ( click for every element ) And finally a walk through the four key elements and map them back on how we solve the challenges