How to Develop IIoT Solution. Phase 1: Providing a Solution

by | Apr 10, 2017

Following my last publication “How to Develop Industrial Internet of Things Solution” on The Reliability Web and in Uptime Magazine, I would like to share with you further details about the approach to developing Industrial of Things solutions. This is the first of three articles which will be dedicated to the three phases of the IT Product Lifecycle:

  1. Providing a Solution
  2. Research and Development
  3. Service Delivery

Providing a Solution phase starts with a new product idea and is focused on evaluating market potential for a new product concept as well as understanding technical and managerial aspects behind developing it.

Research and Development phase focuses on the development of the product, its components, and subsequent product releases. It is also used for further mastering of the business model and evaluating product intermediate versions with clients.

Service Delivery phase starts at the moment when the first product version is made available to clients. The goal of this phase is uninterrupted delivery of the service and providing values to clients and users.

In these articles, I would like to share with you my own and Pro4People’s experience of designing, developing, and delivering IoT services. Ready to learn more? Let us get started.

Providing a Solution

So what is this Providing a Solution all about? Well, in my opinion, this is the most important of the product lifecycle phases. You should verify if the product idea you have is what the market expects, you have to create a shared product vision and its prototype, and finally you need both technical and managerial plans for the development and delivery. Unlike in the old approaches to product development, I would not suggest spending too much time in that phase– around three months should do. The process we will follow assumes several iterations along the whole IT Product Lifecycle, so we should spend here just enough time to make an informed go/kill decision. Eager to find our more? Please refer to The Four Steps to the Epiphany by Steve Blank.

The iconography below presents the major steps specific to that phase. Let’s start with the people and their roles. At this point, there would usually be the following roles divided into two team profiles:

Product Team

  • Product Manager
  • Sales
  • Marketing
  • Business Development

Engineering Team

  • Project Manager
  • Business Analyst
  • Architect
  • UI/UX Designer
  • Developers

Both teams will have to work very closely together; it is crucial for working out the solution that is justified from both business and engineering perspective.

Fig. 1. Main activities in Providing a Solution IoT product phase.

Business Model & Value Proposition

Business model and the Value Proposition are the most important components in the Providing a Solution phase. I would advise you to use the Business Model Canvas and Value Proposition Canvas proposed by Alexander Osterwalder. It usually takes the form of a multi-day workshop focusing on the Business Model and Value Proposition. This is a great exercise in forging a common product vision, challenging it and sharing with the whole team.

Fig. 2. The Business Model Canvas template. 

In addition to canvases, a documented hypothesis on your product, customers, channel/pricing, demand creation, market types, and competition should be the outcome of such workshop. For that purpose, you can use the Customer Discovery templates from The Four Steps to the Epiphany. The participation of the whole product team and the representatives of the engineering Team is required in order to share the product vision.

Do you think it is over when you have that documented? Well, not really. The business model, value propositions and your hypotheses will be the most often challenged, updated and modified part of your product lifecycle documents. It is just a good and solid starting point to hold direct meetings with your customers and initiate the Customer Development process. This ongoing activity, which should be executed along all the IT Product Lifecycle phases, is represented by the spiral in the iconographic.

Solution Architecture

When you have your product vision documented in its first version, it is the right moment to start working on the Internet of Things architectural solution. The goal of preparing the solution architecture is to propose how the product vision will be implemented in a technological dimension. Within the solution architecture, you will have to find answers to the following questions:

Hardware device. What type of devices will be used? Does the solution use sensors, meters or actuators? Are you going to use one of the existing hardware devices or build your own? What is the cost of such a device? Will it be running on batteries or the mains? How long is the device going to be running on batteries? What protocol will be used for the communication with the back-end system? How will the user perform its installation and configuration? Is the hardware device firmware going to be updated along its lifecycle? What security measures does it require?

Connectivity. What type of connectivity will be used to enable the hardware device to communicate with the back-end application? What is the security of the selected channels? What is cost of the selected channels, e.g. a SIM card vs. a WiFi router? Does the connectivity require any intermediate device such as a gateway or a mobile phone? What is the reliability of the selected channel? How much energy of the hardware device’s batteries is consumed by the communication system?

Back-end Application. Where are the data from the hardware devices sent? To a cloud service or to a client-deployed service? Is there a separate instance of the back-end application for each client (a multitenant) or are the data separated within one system (a single tenant)? After what time do the clients expect the processed data to be available? How long should those data and information be stored and available? What is the back-end application infrastructure cost? What does it take to make the back-end application operational (service delivery)?

Web Application. What authentication/ authorization is required? How does the client access the data from the back-end? How can they access the data and information? How will the data/information be presented? What web browsers are going to be supported? What other clients, e.g. mobile devices, will be used to access the data? What different levels of privileges should the users have?

Mobile. What mobile clients will be used to access the data (iOS, Android, phones, tables)? Are mobile clients used to execute preliminary configuration of the hardware devices at the installation site, e.g. WiFi configuration, or parameters’ setups? How is the mobile application presenting the dilemmas of asynchronous communication between hardware devices and a mobile application?

These are just a few of the questions that the architecture should provide the answers to. It does not have to be 100% ready; it should be only detailed enough to enable the Project Manager to break down each architectural decision into a work package and to let the engineering team start working on the first prototype.

Technology Selection

Technology selection is another important activity in the technological dimension. Its goal is to provide a short list of technologies – a technology stack – to be used in the project. Since at this moment we already have a product vision documented in the business model and the related document, the solution architecture, we can choose those technologies that will meet such requirements.

It is quite an important activity, as by conscious selection of the right technologies you can significantly lower the infrastructure expenditures, speed up development as well as bring its cost down. Usually, there will be the following technologies/questions to be answered:

  • Programming language and the technology stack for the hardware device
  • Infrastructure as a cloud service provider, e.g. Amazon Web Services with it IoT ready technology stack https://aws.amazon.com/iot/how-it-works/
  • Back-end programming language and the technology stack, e.g. Java
  • Relational databases – for storing processes information, e.g. mySQL
  • noSQL databases – for storing a large amount of data, e.g. mongoDB
  • A desktop client programming language and technology stack, e.g. Java + JavaScript
  • A mobile client programming language and technology stack (vendor dependent)
  • Development and continuous environment integration
  • Automatic testing technologies

It should be stressed that nowadays there are a lot of mature and reliable technologies, e.g. for database servers or development environments, which are free of charge. They are mature enough to be used for your product development without spending upfront licensing or infrastructure costs at this point.

Another advantage of specifying the technology stack here is the possibility to select an external software development company with the competencies aligned with your technology stack selection.

Program/Project Planning

OK, we have a product concept, solution architecture, and a technology stack. Now it is time to turn it into plan of actions that will take us from where we are to the GoLive (product launch) milestone. As you may already have concluded from the previous paragraphs, there will be a lot of work to do. You will have to start a program which coordinates the following projects:

  1. Hardware device development
  2. Back-end / web applications development
  3. Mobile application development
  4. Building a service delivery team

For that, you will need a Project/Program Manager on board. A Program Management Plan (PgMP) and Project Management Plans (PMP) should be prepared. As an experienced, project management professional, I have to say that the accuracy of the software development schedules and effort estimations will be quite low at this stage. Still, you need these calculations to make an informed go/kill decision.

Integration of all the projects is a very important aspect of the program/project planning. You will have three engineering teams working in parallel on the components of a single solution. Their integration should be the priority from the very first days of the project.

Another outcome of that activity is a high-level product roadmap for the program duration. It should be more detailed for the next quarter. That will enable your development teams to start working efficiently while you are preparing further details with the product team.

User Interface/User Experience Concepts

UI/UX Concepts are the first activity on the third main stream of the Solution Providing phase. The goal of that stream is to build life prototype that will be used to verify client interest in the solution, to check the technical feasibility of the assumed solution architecture, and to convince the business stakeholders to invest in the IoT solution.

You should realize that the user will be interacting with quite complex technical solution. At the same time, we want to make the technology totally transparent so they can focus on the purpose of using the IoT system e.g. monitoring a pump’s performance. The user will be interacting with various elements of the system:

  • A hardware device – installation, configuration, status identification
  • A mobile device – initial configuration, data/information feeds, notification
  • A Web application – reports, summaries, complex tasks

The goal of the UI/UX work is to design and implement the system in such a way that the user is guided all the time through various scenarios of using the system, and they can understand and use the system for its business purpose. It is not as easy as it sounds. There are some major challenges for the IoT systems, e.g. asynchronous communication. Well, what is that? If you have a traditional light bulb, when you switch the light on, it lights up immediately. If you want to do the same with a mobile app and an intelligent lightbulb, first of all it may take some time because of the communication schema/delay. You need to design the application in such a way that this approach is clear to the user. That gets even more complicated if your measurement device communicates with the back-end system e.g. only twice a day.

So this gargantuan work starts right here, just few moments before your solution prototype development.

Solution Prototype / Prototype Evaluation

It is the prototyping that differs the most modern IoT development from old product management principles. The current technology status, maturity of the available technology stacks, and ready to use both hardware and cloud platforms there should be no problem to launch a first product prototype in around three months. We have taken part in the projects where the first working systems were presented after 3 months or even 4 weeks in case a backend solution was already available.

The goal of this activity is to not only verify you technology providers but most of all to present the live and working solution prototype to customers and gather their feedback on your product concept. From that moment on the business model and product concept should be the subject of the continuous adaptation and readjustment to the market needs. You should work with your Clients on the working prototype in order to verify if the assumptions you made about the product really resonate with client expectations.

Go/Kill Decision

So finally we have come to the end of the Solution Providing phase. You should invite your IoT program sponsors, both Product and Engineering teams present the outcomes of the Providing Solution phase. The business model, value proposition, and all hypothesis made about the product together with the market research. Then explain what the Solution Architecture is going to look like, what technologies were selected, how that will impact the final cost of the overall IoT solution.

Present the live solution prototype proving the technological feasibility of the solution, and the testimonials from the first meeting with clients while presenting working prototypes.

Last but not least the program and project plans presents the time, cost, and resources required to execute the program.

If you have done well job it should be enough to take your Product Team to the next phase – Research and Development. If you failed, do not worry, IoT will surely come with another project to your organization and you have just gains a lot of experience to get ready for it.

References

  1. Osterwalder, Alexander. Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. Hoboken: John Wiley and Sons, 2010
  2. Blank, Steve. The Four Steps to the Epiphany: Successful Strategies for Products That Win. Second Edition. Pescadero: K&S Ranch Publishing Division, 2013.

You can find the article either on our websiste pro4people.com or on the www.reliabilityweb.com