This article, the third in the series (Feb/March 2016 and Aug/Sept 2016) about developing an Industrial Internet of Things (IIoT) solution, takes a closer look at the second phase: research and development (R&D). R&D starts with the go to development milestone, then continues to the first go live and subsequent releases until the final stop when the decision to finish the development is taken.

Figure 1: Main milestones of an IIoT solution lifecycle

Introducing Research and Development

At this point of the IIoT solution lifecycle, you should have all the outcomes of the providing a solution phase. You understand the business model and the value proposition of your product, defined the program/project structure, specified high-level solution architecture and chose technologies for product development. You have your business team in place and selected the technology partners/internal departments that will be engaged in the development.

As the outcome of the R&D phase, expect frequent releases (every 2 weeks) of an IIoT solution so your product team can contact your customers and early evangelists and engage them in the product’s evaluation. The feedback will be then used to align the value proposition of your solution with actual market needs.

On the engineering side, expect frequent solution releases, specifications, designs, tests executions and engineering inputs to the future solution development road maps. Remember, an IIoT solution is more like a marathon, not a short distance run, so it is better to get ready for it from the very start.

Program Structure

The Figure 2 diagram shows how to structure your organization’s solution in the R&D phase. A typical organizational structure consists of a business team; back end/front end project team(s); hardware project team; mobile project team; and service delivery team.

Figure 2: Sample IIoT program structure

The Business Team

The business team is responsible for providing solution road maps that transform a defined value proposition into features and functions to be implemented by the engineering teams. Within the business team, there should be a product manager who is accountable for gathering all the requests/feedback from the program’s stakeholders, filtering them with the current solution concept definition and presenting them as an input to the R&D team.

The business team takes R&D’s intermediate version of a working solution and demonstrates it to customers. The feedback is used to fine-tune the solution’s business model, as well as its further development plan. The business team is also responsible for defining and executing a sales and marketing strategy.

The Back End/Front End Project Team

Figure 2 presents a single team for both back end and front end projects. The back end component represents a service, usually hosted on the Cloud, responsible for processing service logic and data storage. The front end component represents a web application that is used to access the service by end users.

The back end team develops a service logic to handle communication with edge devices and then turns the data into information. This is the very backbone of your solution. The front end team develops a web browser or native Mac/PC application that provides access and presents your processed information. This type of application is often used by business customers who highly value mobile applications, but still like working on convenient desktop/laptop platforms.

Within this project team, these roles should be covered:

  • Project Manager – responsible for communications between the client, other program stakeholders and project execution.
  • Business Analysts – gather the solution concept from the product manager and turns it into specifications used later by the other teams. Individuals in this role should have a full understanding of the solution from the functional perspective of all IIoT program elements.
  • UI/UX Designers – design a user interface and are responsible for the user’s experience of the overall IIoT solution.
  • Software Developers – responsible for writing the code and providing designs.
    • Solution Architect – in charge of the overall solution architecture and communicating it to all program stakeholders.
    • Tech Lead – supervises the project from the technology perspective and resolves any technology questions.
  • Test Manager –defines testing strategies and tests levels crucial for the final approval of product releases.
  • Testers – test design and execution activities for software packages and any activities within project execution.
  • Configuration Managers – in charge of managing IT infrastructure and the solution’s environments.

Due to the R&D characteristics of an IIoT solution, the business analyst, UI/UX designers and solution architect roles should be shared among all project teams making up the final IIoT program. The business analyst specifies a common consistent vision of the solution shared among all projects; the UI/UX designers turn the vision into a common user experience along all IIoT elements; and the solution architect creates common solution architecture that all projects must follow.

Figure 3: Business team input into R&D phase

Hardware Project Team

The hardware team designs, implements and prepares edge devices for manufacturing. The structure of a sample hardware team is:

  • Project Manager – secures communications between the program and the hardware team and coordinates hardware development activities.
  • System Architect/Designer – in charge of design decisions, decomposition into hardware/software components and final system architecture. The individual in this role should have an in-depth knowledge of both hardware and software components of the embedded devices.
  • Electronic Hardware Designer – handles digital and analog circuit designs, printed circuit board (PCB) designs and components selection.
  • Embedded Software Developer – develops the embedded software and the corresponding automatic tests.
  • Testers – perform test strategy development for the hardware project and test designs and execution.
  • Configuration Manager – responsible for managing environments, bill of materials (BOM) for the edge device, the release of the edge device and its identification along its lifecycle.
  • Industrial Designer – designs the physical aspect of the product that will be aligned with its intended use, attractiveness and feasibility to manufacture at a reasonable cost.

The primary outcome of a hardware project is a physical device to be manufactured. Thus, the hardware team collaborates closely with other project teams, as well as the external organizations responsible for manufacturing and assembling the edge device.

Mobile Project Team

The mobile project team designs and develops mobile applications for the IIoT solution. On the one hand, mobile applications may be used to communicate with the edge devices, such as during the initial configuration. On the other hand, they let end users utilize the solution in the immediate proximity of monitored objects and play an important role in end user communication. Mobile apps communicate with the back end component to retrieve and present data through the mobile application.

Members of the mobile project team have similar roles as the back end/front end team: project manager; business analysts; UI/UX designers; mobile apps developers; testers; and configuration managers. Organizations developing a mobile application for both iOS and Android platforms can reuse some common designs and specifications, but both applications have to be developed independently.

Agile / Maturity / Competencies Paradigms

The next area to discuss is the development paradigms. The first one is Agile/Lean approach. Embrace the fact that you are not going to fully understand your product before the Research & Development phase. Assuming that you have done a good job in the Providing a Solution phase, you have proven that your business model is going to work. Now, with the Research & Development, you should use frequent IIoT solution releases (every 2 weeks) to present your product to users and turn their feedback and information into the development roadmap and the updated solution’s value proposition. This approach to development is described more broadly in The Four Steps to the Epiphany1 book and is reflected in such development methodologies like Agile or Scrum.

With the level of complexity required to develop an IIoT solution, the agile methodologies are not sufficient to manage it alone. Five different project teams working jointly on a quite complex business/engineering program needs a structured approach to R&D processes with a strong focus on collaboration to execute efficiently. On the management side, methodologies, such as project management body of knowledge 2 and information technology infrastructure library (ITIL)3 provide that structure.

In addition, other tools should be incorporated to enhance communications and program execution, such as:

  • Confluence – wiki like team collaboration platform, with the ready-to-apply collaboration templates
  • JIRA – issue and project tracking system
  • ins2outs.com4 – a quality and know-how collaboration platform where all the roles and processes have been documented; also can be used to structure service delivery processes;
  • Amazon Web Services (AWS) – as the primary vendor of IaaS services

Developing an IIoT project requires a mix of managerial, technology and business skills. Therefore, you should look for employees or business partners that have already taken part in the development of such solutions. You should be looking for managerial competencies proven with project or program management certification. Technology competencies should be based on people who have worked on complex projects and have experience in technologies that are fit for use in IIoT solutions. Equally important is expertise in one of the Cloud platforms, as your IIoT solution will more than likely use one of them. In terms of business skills competencies, look for partners who can help you address challenges in the IIoT product lifecycle. If this is your first IIoT project, remember the flows in the business model and value proposition are the hardest to fix in the project execution, so strong business skills will be of great value.

Figure 4: Research and development execution overview

Time to Market

With some IIoT projects, the R&D phase may close within 12 months, starting from the go-to-development milestone to the go-live version release. That time includes recruitment, all program components development and releasing the solution to the IT infrastructure. That proves that the IIoT’s first version development can be accomplished in a relatively short time. However, it would be a mistake to think that the IIoT R&D phase is over then. Usually, it continues incrementally, focusing on product development beyond the minimum viable product (go live) release.

Development Process Flow

So, how should you structure a “typical” IIoT program development process flow? Figure 4 represents an example of one such.

Divide your program into three-month planning increments. For each of those phases, prepare a program road map that is agreed upon among the product manager, project managers and business analysts. At the end of each three month period, schedule a joint release from all program components.

Then, business analysts start their work preparing specifications for both back end/front end and mobile projects. The hardware project manager, together with the system architect/designer, prepares the same plan for the edge device development. The high-level plan for the next three months is agreed upon, as well as the approach for integrating all program components and their acceptance criteria specified.

Next, divide project execution into two-week sprints. Business analysts start working on more detailed specifications in the form of user interface mock-ups, user stories, requirements, or any other designs for the upcoming sprint. Each project team takes those specifications as input to plan the next two-week development period.

Within a sprint, UI/UX designers turn UI mock-ups into final UI/UX designs. Developers implement the functionalities of the solution based on the specifications, UI/UX designs and in accordance with the documented solution architecture. Testers independently verify the outcomes of that work and also extend test specifications with the new test conditions. Testers use the specifications from business analysts as the basic criteria for verifying the implemented work. The configuration manager creates/updates the environment installation manuals and version deployment manuals that later will be handed over to the service delivery team.

At the end of each sprint, release the new projects’ functionality and deploy the solution to one of the presentation environments, such as a Cloud-based web service, so it’s available to all program stakeholders.

At the outcome of each sprint, the business team has a new live solution version ready to try out and can evaluate it with customers and other IIoT solution stakeholders. Use the feedback from such meetings to adjust the product development’s direction to current market needs.

Next, prepare the final solution release. The release tests plan is executed in order to prove that the release meets specified acceptance criteria. The release package is then delivered to the service delivery team for planning the deployment/transition on the production environment. Then, a new cycle for the next three months starts with the same activities.

Research and Development Conclusion

The approach to the R&D phase poses all the challenges of developing an IIoT program with all the software, hardware and organization components. Still, with a proper team in place and the use of the agile/maturity/competencies paradigm, the development of such a system should not be a challenge to a competent and experienced team. Just remember, your first go-live IIoT solution release can be as close as only 12 months from now.

The next article in the series will focus on Phase 3: Service Delivery. Be sure to read it in the next issue of Uptime.

References

  1. Blank, Steve. The Fours Steps to the Epiphany, Second Edition. Palo Alto: K&S Ranch Publishing, 2013.
  2. Project Management Institute. Project Management Body of Knowledge (PMBoK) Guide. 2013. http://www.pmi.org/pmbok-guide-standards/foundational/pmbok
  3. AXELOS. ITIL Best Practice Solutions. https://www.axelos.com/best-practice-solutions/itil
  4. Quality and Know-how Collaboration Platform. ins2outs.com

Tomasz Puk

Tomasz Puk es CEO de la compañía Pro4People, una casa de software en Polonia. El Sr. Puk ha trabajado como desarrollador de software, manager de proyectos y manager de productos en varios proyectos industriales, desde aplicaciones de alineamiento de laser industriales a una solución compleja de IoT para la gestión de confiabilidad. www.pro4people.com

Download Article

Upcoming Events

August 9 - August 11 2022

MaximoWorld 2022

View all Events
banner
80% of Reliabilityweb.com newsletter subscribers report finding something used to improve their jobs on a regular basis.
Subscribers get exclusive content. Just released...MRO Best Practices Special Report - a $399 value!
DOWNLOAD NOW
“Steel-ing” Reliability in Alabama

A joint venture between two of the world’s largest steel companies inspired innovative approaches to maintenance reliability that incorporate the tools, technology and techniques of today. This article takes you on their journey.

Three Things You Need to Know About Capital Project Prioritization

“Why do you think these two projects rank so much higher in this method than the first method?” the facilitator asked the director of reliability.

What Is Industrial Maintenance as a Service?

Industrial maintenance as a service (#imaas) transfers the digital and/or manual management of maintenance and industrial operations from machine users to machine manufacturers (OEMs), while improving it considerably.

Three Things You Need to Know About Criticality Analysis

When it comes to criticality analysis, there are three key factors must be emphasized.

Turning the Oil Tanker

This article highlights the hidden trap of performance management systems.

Optimizing Value From Physical Assets

There are ever-increasing opportunities to create new and sustainable value in asset-intensive organizations through enhanced use of technology.

Conducting Asset Criticality Assessment for Better Maintenance Strategy and Techniques

Conducting an asset criticality assessment (ACA) is the first step in maintaining the assets properly. This article addresses the best maintenance strategy for assets by using ACA techniques.

Harmonizing PMs

Maintenance reliability is, of course, an essential part of any successful business that wants to remain successful. It includes the three PMs: predictive, preventive and proactive maintenance.

How an Edge IoT Platform Increases Efficiency, Availability and Productivity

Within four years, more than 30 per cent of businesses and organizations will include edge computing in their cloud deployments to address bandwidth bottlenecks, reduce latency, and process data for decision support in real-time.

MaximoWorld 2022

The world's largest conference for IBM Maximo users, IBM Executives, IBM Maximo Partners and Services with Uptime Elements Reliability Framework and Asset Management System is being held Aug 8-11, 2022