To my mind there are some bits missing from the discussions about the Internet of Things that we all seem to be engaged in day-to-day. We tend to think it’s about technology – but we have to consider more than that!
We need to understand the value created, the business models and the reasons why. And, of course, we need tools to discuss the architecture and to ensure that it all fits together. In my opinion, we need 9 Exhibits to support the case.
Exhibit 1 – The Simplified Technical Stack
The discussion usually starts as a techie consideration: “Suppose we could do remote monitoring …”.
We need a non-techie, simplistic way of discussing and a capturing these thoughts. So we talk about the product, the connectivity, the cloud, as well as the security and management issues which span all levels. The product discussion covers the hardware and the software. The cloud discussion might include databases, the application (development) platform, analytics and smart or user applications.
Exhibit 2 – The Business Model
We need some way of discussing what the solution might mean in business terms. The Business Model Canvas provides a nice, high-level way of doing this.
We’re interested in the customers, what value proposition turns them on, how we reach them, what revenue streams might result. At this stage, we want to understand the mechanisms rather than the detail – this is a Business Model and not yet a business case.
On the left hand side we have the things we need to make it happen – activities, resources, partnerships and (hey!) costs.
Exhibit 3 – The Value Proposition
If necessary, we can run a discussion at a similar level of detail about the value proposition of the proposed solution.
We start by looking at the customer – what jobs does he/she do, what pains exist, what gains could be made by doing something different? Then we look at our proposed solution – what features does the product or service provide, what pain relievers and gain creators result therefrom? Basically we need to understand what the fit is between the customer and the solution.
Exhibit 4 – The Value Chain
So far, so good! But it may be that the IoT is providing entirely new opportunities – so new that the customer is not aware of them and certainly not asking for them! In that case, we need tools to help us understand and discuss the holistic view of the customer’s current and future business.
The Value Chain Model is well suited here, with its value dimensions (how is valued recognized), value chain (how does value flow) and value reference (what tasks get done).
If we need to evangelize and educate our customers, we need to be able to lead a discussion around value that they haven’t yet started. To do that, we need a model that goes far beyond the relationship we currently maintain with our customers.
Exhibit 5 – The Service Blueprint
The Service Blueprint is a tool for thinking about and designing end-to-end, multi-channel services for and with customers.
The Internet of Things provides low-level, technical services – reading the temperature, identifying a device, switching it on.
If we’re lucky the core management aspects – end-to-end communications, device availability, interoperability, security – will be in place. There may even be clever business applications available to manage usage-related billing or to initiate a service (maintenance) call.
However, there will always be people involved – users, management, service technicians, hotline, account management – and service design is about the seamless flow between them, using different channels, different applications and different devices.
Exhibit 6 – The Reference Architecture
A robust Reference Architecture is needed to provide a basis for solution design. There are various models available and which one we use is a matter of personal preference as much as anything else.
The main characteristic of IoT is interoperability – different devices, services, applications and eco-systems talking to each other, to ensure end-to-end solutions.
If we need to do that, we can be sure of two things – these systems will have different flavors from day one, and the components will most certainly change over time. To manage that situation and to protect the investments made, one needs to model generic solutions to the problem. The Architecture Model is the tool to use to do that!
Exhibit 7 – Solution Designs
Once we understand what the solution looks like generically, we need to design the concrete implementation.
This may take the form of a design template (for example, the generic company-wide solution) or a concrete instance (a customer-specific implementation, perhaps developed as a collaborative venture).
When the detail is refined at the appropriate level we can proceed to document Exhibit 8 – The Requirements to allow the solution to be built and Exhibit 9 – The Critical Success Factors that help determine how successful we’ve been as we take the solution into production.
Summary
As you can see it’s all quite complicated…
We need to cover many aspects other than the purely technical. Understanding how our business copes and how the customer’s business benefits is crucially important. Getting the Service Design aspects right are critical to ensure take-up and acceptance.
The approach taken needs to support the discussion of generic solutions that ensure longevity and security of investment. We need to be able to build – and manage – different implementations of similar solutions.
But the tools outlined above will help you focus on these areas that bring true value to the solution, for your customers and for your continued competitive advantage.
Author: Colm Toolan, Senior Consultant, Global eBusiness Excellence, Danfoss Drives A/S.
