Analysis, Projections, Planning

The first set of Ignite | IoT design artifacts is intended to support analysis, projections, and planning. The initial problem statement or executive summary is often taken from the business model (see Ignite | IoT Strategy Execution). The detailed analysis ideally includes a site survey, which provides further insight into the asset and its environment. The IoT Solution Sketch is a one-page, high-level overview of the proposed solution design. The IoT Project Dimensions support project self-assessment. The quantity structure looks at the planned growth of key entities such as users and assets. Finally, the milestone plan defines the key milestones of the project.

Problem Statement/Executive Summary

As stated above, the problem statement and/or executive summary often comes from the business model phase. Ideally, it contains a one-page description of the problem domain and vision for the IoT solution using language that can be easily understood by business stakeholders. It also provides a simple and intuitive graphical overview of the key solution elements. See the figure below for an example.

Stakeholder Analysis

There are many best practice frameworks for stakeholder analysis in a project context (for example, see TBD:REF). Ignite | IoT builds on an IoT-specific framework for stakeholder analysis that was originally devised by Dr. Heinz Derenbach (former CEO of Bosch Software Innovations) and his team. One key lesson learned from this team is that most IoT solutions are made up of four central elements, each with associated stakeholders: the assets and corresponding devices, the related enterprise services, the solution users, and the partners. The figure below provides an overview of these four key elements of an IoT solution.

In our experience, identifying and defining these four key elements and the interdependencies between them is a very good starting point for analyzing the key aspects and stakeholders of an IoT solution. In certain cases, some of these elements may have already been included in the business model analysis, but generally without examining the interdependencies between them in any great detail.

Site Survey

As part of the IoT Initial Solution Design, we strongly recommend that a site survey is carried out. This would ideally start with a physical visit to associated sites, such as the factory where the assets are manufactured or a site where they are used. To complement this, interviews can be conducted with experts on different aspects of the assets and the sites where they are typically deployed (if applicable).

The site survey document should cover all asset- and site-specific aspects, such as the following:

• Type of asset – for example, stationary or moving
• Category of asset – industry segment, for instance manufacturing or CPG
• Behavior of asset – dumb asset (such as a beer keg or pallet) or intelligent asset (vending machine, PLC, vehicle)
• Business operations and asset lifecycle
• Solution integration – native or retrofit
• Asset interfaces – ModBus, CAN bus, MDB, serial bus, GPIO, etc.
• Internet connectivity around asset – such as a cellular, Ethernet, or Wi-Fi network
• GPS options around asset
• Environmental conditions around asset – such as operating temperature or asset location (in a moving container/vehicle, factory, retail store, outdoors, etc.)
• Power supply requirements, sensor installation requirements

Some of the survey results can later be incorporated into the IoT Project Dimensions (see below).

Solution Sketch

Based on the results of the analysis, Ignite | IoT recommends creating a high-level solution sketch using the format outlined in the figure below. This can often be created during a workshop attended by the key stakeholders, with the outcome captured in a structured format.

The IoT Solution Sketch covers all four solution elements identified in the “Stakeholder Analysis” section above and adds a number of important details. For example, the solution sketch attempts to identify or define the key events (or any other key communications) submitted from the asset to the backend. In addition, it captures key UIs, business processes, rules, and data entities (all in list form). Furthermore, databases and applications are shown, as well as external partners to be integrated.

The solution sketch is more detailed than the executive summary. However, it focuses on key entities only, and does not provide a formal and complete list of these entities. The main purpose of the solution sketch is to start narrowing down the solution scope and to create a common basis for communication between business and technical project stakeholders.

Project Dimensions

Ignite | IoT defines a set of IoT Project Dimensions that help to capture all important aspects of an IoT solution. There are currently five main dimensions, with a total of approximately 40 subdimensions. The five main dimensions are:

• Assets and Devices: Covers aspects like number and value of assets, asset complexity, required on-asset processing power, hardware requirements, and lifecycle management
• Communications and Connectivity: Focuses on technology, bandwidth, and latency both for local and remote communication
• Backend Services: Looks at the complexity of the backend business solution, as well as aspects specific to data management
• Standards and Regulatory Compliance: Relates to the external project environment
• Project Environment: Examines the internal project environment

Each project dimension has been given a scale with a range from 1 (simple) to 4 (complex), as well as a definition of the values from 1 to 4. This means that the project dimensions can be used to create a visual representation of project self-assessment, for instance by using a Kiviat diagram as depicted in the figure below.

An Excel spreadsheet containing the definition of all Ignite | IoT Project Dimensions is available online. A more detailed definition of the different dimensions is also provided later in the “Building Blocks” section. As shown in the figure below, the main purpose of the project dimensions in this phase is to provide a checklist that helps the project manager to carry out their own assessment for the project (self-assessment). The results can be used to identify critical areas and project risks as well as input for the solution architecture and design decisions. In addition, the Ignite | IoT team is currently building up a database of various projects that have provided us with the results of their self-assessments. This allows project managers to compare their project with others, and to benefit from the lessons learned.

Quantity Structure

Like every solution design, an IoT project also requires a quantity structure. The quantity structure must be closely aligned with the requirements of the business stakeholders, and should show projected growth in key areas.

From an IoT point of view, these areas should include the following: number of assets over time, number of events sent from assets to the backend, number of users (total and concurrent), and number of process instances per year (for key processes such as asset activation, incidents, etc.) This information will be of vital importance to the solution architect.

 

Milestone Plan

Finally, as with normal projects, the Initial Solution Design for an IoT-solution project should include a milestone plan. This plan will include some normal and some IoT-specific milestones:

• Make-or-buy decision
• Vendor selection
• Prototype
• Pilot/field test
• SOP/Start of production (hardware)
• Initial release of backend solution

When structuring the milestone plan, it can make sense to have two separate timelines, one for the on-asset components and one for the backend, and to include the key dependencies between them.