D: Resource Acquisition

achieved through GPS systems. For indoor, a number of different technologies exist, including triangulation using a variety of frequencies and protocols (UWB, BLE, RFID, WiFi), as well as inertial approaches (Zafari et al., 2017).

Table 10: Result Set C—technology selection

At the center of such an IT solution procurement process is usually a so-called request of proposal document (RFP, or sometimes request for quotation, RFQ), followed by a vendor selection process.

Web resources like Miller (2010) provide some guidance on this process:

 Pre-RFP Planning: It is key to already involve all stakeholders during the preparation of the RFP, including business and technology, purchasing, finance, and legal experts.

 RFP Document: This document must not only include a very clear set of comprehensive requirements but also additional information like timelines and key milestones.

 RFP Process: Identifying and getting potentially suitable suppliers to answer the RFP requires careful preparation and guidance of the vendors.

 Vendor Evaluation: Especially for complex IT solutions, a solid due diligence process is required. A clear decision and governance model should be the foundation. For contract negotiations, specialized procurement experts should be involved.

 Engagement Model: Especially for custom development projects, a decision must also be made on the engagement model, e.g., fixed price, time and material, or even agile fixed price (Fewell, 2011).

As can be seen in the following, for an IoT project, the resource acquisition process might involve multiple components and specialized vendors if the project is not delivered as a turnkey solution.

3.2.4.2 IoT Perspective

Considering the discussions in sections 3.1.2.5 (“Proposed Structure for IgniteWorx Result Sets”) and 3.2.3 (“C: Technology Selection”), it can be seen that resource acquisition for an IoT project often includes the following areas:

1. Project Office: Project management, requirements management, solution architecture management, management of the sourcing process, legal support, etc.

2. Embedded Component Design and Development: Embedded hardware design, embedded software design, and development. Fowler et al. (2019) provide a study of the build-versus-buy decision in developing embedded systems.

3. Embedded Component Production: Internal manufacturing or external sourcing of embedded hardware components according to design.

4. Telecommunications Services: Usually wide-area network-based services, e.g., from mobile network operators (MNO) or mobile virtual network operators (MVNO).

5. Application Software: The software that implements the business logic of the new IoT solution.

a. Can be on-premise or a SaaS (software as a service) in a public or private cloud. Hughes (2018) provides a discussion on key differences, benefits, and risks of on-premise versus cloud.

b. Can be COTS or custom development. Ochs et al. (2000) discusses the COTS acquisition process, including definition and application experience. Shahzad et al. (2017) provides a discussion on “Build Software or Buy” from the perspective of large-scale software.

6. IoT Platform: Specialized platform with IoT-specific platform features such as device management and over-the-air (OTA) updates. Can be on-premise or as PaaS (platform as a service) in the cloud.

7. Application Platform: Provides common services such as application server, DBMS, messaging infrastructure, etc. Can be on-premise or PaaS.

8. Application Infrastructure: Physical computing resources, data storage, and networking infrastructure. Can be on-premise or cloud-based infrastructure as a service (IaaS).

9. Solution Operations: This includes the technical operations (e.g., application server availability, database and network administration, etc.), as well as support for the business functionality (e.g., capturing and fixing problems with the functional behavior of the system), including field services (see discussion in section 3.2.10).

For each of these different sourcing areas, the project team must select the best matching approach during the project setup phase. Making the sourcing decision for each individual area usually depends on the overall project strategy. For the purpose of discussion in this context, three scenarios are identified:

 [A] Turnkey solution: In this scenario, the customer would usually only retain a small project office with a focus on requirements management and managing the acquisition process. All other project aspects would be externally sourced.

 [B] Internal development, acquire & integrate: Custom solution development combined with externally sourcing as many off-the-shelf components and infrastructure services as possible.

 [C] Internal development, deep vertical integration: Full control over most aspects of the solution, including on-premise hosting, device manufacturing, etc.

Based on these three scenarios, Table 11 provides a matching to the eight sourcing areas identified above. These matchings are based on some general assumptions and must be further validated, e.g., by the approach outlined in section 6 (“Iteration II: ”).

Sourcing Area A: IoT turnkey solution

B: Internal IoT solution

development, acquire & integrate

C: Internal IoT solution

development, deep vertical integration

Project Office Internal Internal Internal

Embedded

Component Design and Development

External Internal Internal

Embedded Component Production

External External Internal

Telecommunications Services

External (MNO) External (MNO) External (MVNO)

Application Software

External (COTS or custom

development)

Internal, custom development

Internal, custom development

IoT Platform External (IoT-PaaS)

External (IoT-PaaS)

Custom solution, on premise

Application Platform

External (Paas) External (Paas) Own data center

Application Infrastructure

External (Iaas) External (Paas) Own data center

Solution Operations External Internal Internal Table 11: Resource acquisition for different project scenarios

As can be seen in this example, all three project scenarios would be similar in that they retain the project office in house. However, only B and C would do the embedded component design internally. Only C would self-manufacture the embedded hardware components. All three would rely on a global carrier for communications services. D might consider the MVNO approach, which potentially provides more control over the service quality in different regions. B and C would do customer application development, while A could choose either COTS or custom development. A and B would run the application on a public cloud stack, while C will run it on premise. Finally, solution operations would only be external in scenario A.

3.2.4.3 Result Candidates and Matching Considerations

The following result candidates are based on the definitions in Table 11.

Result Set D: Resource Acquisition

# Result Name Description and Matching Considerations

D.1 IoT turnkey solution An IoT turnkey solution approach might be selected in case time to market is important and suitable internal resources to support this requirement are not available.

In this case, IP protection and long-term availability of internal solution knowhow must be at least partially forfeited. The match between the final solution and the initial requirements might also not always be the highest.

D.2 Internal IoT solution development, acquire

& integrate

This approach will typically be chosen to achieve the best possible match between requirements and end result (Shahzad et al., 2017). Also, IP protection and internal skill building can play an important role (Jones et al., 2001).

D.3 Internal IoT solution development, deep vertical integration

This approach is taken if the company requires a high level of control over the entire solution creation process or if resources are available that must be utilized.

Another decision factor (at least for on premise versus cloud) can be data ownership. A typical example of a project with such a high level of vertical integration would be an OEM (e.g., a car manufacturer) who develops an IoT service for a mass-manufactured product.

Table 12: Result Set D—resource acquisition