3.2 C ONTENT D ETAILS : R ESULT S ETS
3.2.5 E: Cost Estimation
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
(TCO). Gartner defines TCO as follows (Gartner Group, 2019): “For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses.”
Specifically the operations cost often seems to be neglected. Zarnekow and Brenner (2005) provide a multi-case study looking at the distribution of the cost over the application lifecycle: “The results show the central importance of recurring costs for production and further development. For a production time of 5 years these costs amounted to 79% of all life cycle costs, whereas only 21% of the costs were incurred during the planning and initial development stages.”
However, in order to acquire funding for the initial planning and development, it is still important to be able to provide efficient cost estimation techniques for this phase.
Menzies et al. (2014) describe current best practices in software development cost estimation as a set of parametric/regression-based techniques, including COCOMO, PRICE-S, SEER-SEM, and SLIM. The general idea is to use a database of past projects to derive an estimate for the current project. Different methods for adjusting to the need of local projects are described, e.g., by limiting the selected past projects to those most similar to the current project. The following problems with these best practices are described: poor modeling assumptions, models with superfluous attributes, noise and multiple correlations, and inadequate training or testing data.
In addition to these parametric/regression-based techniques, there are techniques that look more at the required functionality and its associated costs. One example is function points, which estimate based on the number of functional features, e.g., the number and complexity of screens, the number and complexity of database queries, and so on (Heemstra and Kusters, 1991).
3.2.5.2 IoT Perspective
Following the pattern established in section 3.2.4.2, the TCO discussion for an IoT solution must look at all relevant areas. However, this work excludes opportunity costs of downtimes and other productivity losses since they would be highly context specific.
An important cost factor of most IoT solutions is likely going to be software development.
In the case of an IoT solution, and important aspect that will have to be considered here is the typically distributed nature of IoT software components. This distributed nature can significantly increase complexity and consequently also development, test, and validation costs. Dash and Acharya (2011) propose a cost estimation approach for distributed systems using a synthesized use-case point model. Winne and Beikirch (2013) extend COCOMO to include parameters required for effort estimation for distributed embedded systems.
For cloud-based IoT solutions, the cloud operations costs are another important factor.
Kalmar and Kertesz (2017) compare IoT cloud operations costs for some of the leading public IoT cloud vendors.
From the point of view of embedded development cost estimation, it is questionable whether the aforementioned software development cost estimation methods are applicable without adjustment due to the specific nature of embedded systems.
Debardelaben et al. (1997) go as far as to propose incorporating cost modeling directly into the embedded-system design.
Giannopoulos (2006) provides an interesting case study on embedded hardware and software development cost estimations, based on experience with the Ford Motor Company. For the embedded software cost estimation, he follows the established pattern of use-case-based effort estimates. For the hardware cost estimates, he differentiates between design and development. For the design, he develops a metric based on the following complexity drivers:
1. type of components 2. number of components 3. memory type
4. memory size
5. number of interfaces 6. type of interfaces 7. functionality class 8. distributed functionality 9. test/acceptance criteria
In addition, he cites environmental factors such as:
1. Degrees of contact prevention and guarding against foreign matter (e.g., protection of persons from touching voltage-carrying parts)
2. Degrees of water protection
Especially for mission-critical embedded components, additional costs like certification must be considered. Pop et al. (2013) provide insights on certification costs for different types of embedded platforms.
From a hardware manufacturing point of view, Giannopoulos (2006) describes a model that considers material costs, labor costs, and machine costs, as well as scrap and overhead.
Finally, an IoT TCO calculation must also consider the operations side. Cisco / Jasper (2016) provide an example of the potential distribution of the operational costs of an IIoT solution for monitoring of heavy equipment (see ).
Cost Factor Percent Assumptions Network
Communication
33–50% Monthly device/subscription fee
Monthly device/overage fee Administrative
Labor
20–50% Every deployed device requires at least 15 interactions/year.
Each interaction takes at least 5 minutes.
Technical Support
10–33% 10% of deployed devices require support.
T1 MTTR: 25 minutes
T2 MTTR: 3 to 5 hours
Table 13: Distribution of operational costs of IIoT solution (Cisco / Jasper, 2016) It should be noted that the proposal from Cisco / Jasper (2016) does not include operational costs such as application runtime costs, application maintenance, etc.
However, it still helps in completing the picture since it at least shows an example of three essential IIoT operations cost drivers. Also, as can be recalled, the work from Zarnekow and Brenner (2005) shows the relationship between initial investment costs and operational costs of a typical IT solution. It is important to keep both sides in mind from a TCO point of view.
3.2.5.3 Result Candidates and Matching Considerations
While the different cost drivers of an IoT TCO calculation are now well understood, the question remains: How much does it actually cost to develop an IoT solution? And what can be recommended to users of IgniteWorx?
Unfortunately, there seems to be very little research available providing concrete cost estimates. However, Klubnikin (2016) provides some numbers:
MVP: “If you calculate and add up the costs of IoT components (including hardware, infrastructure, mobile or wearable applications and certificates), you won’t arrive at a sum smaller than $50 thousand. That’s how much an MVP version of an IoT solution costs.”
Custom EKG tracker: “The price of building a custom EKG tracker which analyzes the electrical signals of a human body and visualizes sensor data via a mobile app is estimated at only $300 thousand—but there are hidden costs you might overlook.”
Complex home automation system: “A complex Home Automation system which uses machine learning algorithms to identify and remember a home owner’s face and automatically adjusts its settings based on the person’s preferences may cost up to $5 million (hardware and software costs included).”
However, it is not clear how these numbers are calculated and what the described projects really entail. Also, it seems that the numbers do not differentiate between who is actually doing the development: a start-up is typically operating under a completely different cost framework than a large corporate organization, which usually has much higher base costs and overheads.
Consequently, the approach described here does not aim to provide predictions for the actual cost of a project. Instead, Table 14 defines a set of project categories. In the following, these project categories are then mapped against cost regions.
Result Set E: Cost Estimation
# Result Name Example Description and Matching
Considerations E.1 Small-scale
IoT Pilot
Humidity monitoring for one particular greenhouse
Small ad-hoc solution / pilot project, without real productization requirements E.2 Small-scale
IoT MVP
Start-up building humidity monitoring for greenhouses as a standard product
Single sensor, WiFi, multi-tenant cloud solution, basic mobile app; fully productized;
single market (e.g., EU) E.3 Industrial IoT
Monitoring Solution
Predictive maintenance solution for hydraulic pump
Like E.2, plus multi-sensor, advanced analytics
E.4 IoT Appliance
Connected solution for washing machine or
breath analyzer for asthma patients
Custom ECU; OTA; GSM-based connectivity; sold in >100 countries
E.5 Complex IoT Actuator
Automated manufacturing robot
Hard real time; sensor-data fusion; tightly regulated
E.6 Extremely Complex IoT Actuator
Autonomous car; plane;
warship; rocket
Huge costs because of extreme technical complexity and physical constraints
Table 14: Result Set E—cost estimation
Taking the project scenarios from Table 14 as the starting point, Figure 43 matches them against a potential cost range, using a log 10 scale. This not a scientifically proven IoT cost framework but rather the starting point for discussions and further evaluations, according to section 6 (Iteration II: ). An IgniteWorx user can use the feedback regarding
his or her project’s positioning in the cost scale from Figure 43 to validate his or her own assumptions and start a more detailed cost estimation process using one of the techniques described in this section.
Figure 43: Cost versus complexity for different IoT solution scenarios