Blockchain-based deployment of product-centric information systems

Collecting and utilizing product life-cycle data is both difﬁcult and expensive for products that move between different industrial settings at various points of the product life-cycle. Product-centric approaches that present effective solutions in tightly integrated environments have been problematic to deploy across multiple industries and over longer timespans. Addressing deployment costs, incentives, and governance, this paper explores a blockchain-based approach for the deployment of product-centric information systems. Through explorative design science and systematic combining, the deployment of a permissionless blockchain system for collecting product life-cycle data is conceptualized, demonstrated, and evaluated by experts. The purpose of the blockchain-based solution is to manage product data interactions, to maintain an accurate single state of product information, and to provide an economic incentive structure for the provision and the deployment of the solution. The evaluation by knowl-edgeable researchers and practitioners identiﬁes the aspects limiting blockchain-based deployment of solutions in the current industrial landscape. Combining theory and practice, the paper lays the foundation for a blockchain-based approach to product information management, placing design priority on inter-industrial and self-sustained deployment.


Introduction
Products in use -especially durable and capital goods-are valuable sources of information in many industrial settings (Rink and Swan, 1979;Anderson and Zeithaml, 1984;Aitken et al., 2003;Kärkkäinen et al., 2003a).However, in settings where products move between systems and industrial settings at different points in the lifecycle, product data is rarely effectively collected and used (Lehtonen et al., 2012).Moreover, a combination of information asymmetries and a lack of incentives may even result in supply chain actors destroying data valuable to one another (Ala-risku, 2009).
The concept of product-centric information management (Kärkkäinen et al., 2003b;Tang and Qian, 2008;Meyer et al., 2009) was developed to enable multiple actors to share information on product individuals comprehensively over their lifecycle.While significant improvements have been observed in case studies (Rönkkö et al., 2007;Hribernik et al., 2006;Lyly-Yrjänäinen et al., 2016;Bussmann and Sieverding, 2001;Främling et al., 2013), the deployment of product-centric information management as a sustained solution has been challenging.Deployment challenges include, e.g.high initial costs, scalability (Leitão, 2009;Trentesaux, 2009;Tähtinen, 2018), and unresolved conflicts of interest regarding platform control and governance (Främling et al., 2007).Establishing more integrated platform solutions for product data management has been similarly challenging (Naphade et al., 2011).
This conceptual paper explores blockchain-based deployment of a product-centric information system.The focus is on the use of blockchain-based functionality (Nakamoto, 2008;Wood, 2013;Buterin, 2013;Poon and Buterin, 2017;Hukkinen et al., 2019), such as protocols, crypto-mining payments, and smart contracts to initiate and sustain product data collection and use.The purpose is to conceptualize and demonstrate a solution, where the design priority is on the incentivization of actors to participate in providing item-level product lifecycle information, and reimbursing their efforts by using blockchain technology.This paper contributes to research on viable inter-industrial deployment (Naphade et al., 2011;Alam and El Saddik, 2017) and self-sustained platforms (Mattila and Seppälä, 2018;Blossey et al., 2019;De Filippi and Loveluck, 2016).

Literature review
Storing and maintaining data on each product individual over its entire life cycle is not a trivial undertaking.The high initial investment has been identified as a reason for why integrated product data management systems have not been widely adopted by the industry (Leitão, 2009;Trentesaux, 2009).As an alternative, more loosely coupled peer-to-peer solutions have been proposed to share the burden (Kärkkäinen et al., 2003a;Främling et al., 2014;Kubler et al., 2015).However, while the use of a peer-to-peer approach reduces the investment cost of individual actors, it introduces a variety of new challenges for product centric information management, e.g.tracking and coordinating the global state of the system, attracting a critical mass of users, as well as facilitating authentication and trust in a decentralized manner (Trentesaux, 2009;Petkovic et al., 2007).

Product-centric information and blockchain
In the field of product lifecycle management, earlier efforts towards using a peer-to-peer network have mainly been aimed at increasing the interoperability and openness of product data systems (Kubler et al., 2017;Raggert, 2015).However, obtaining guarantees of the satisfactory performance of peer-to-peer networks has been found difficult; Due to the coordination constraints involved, evaluating the global state of a fully decentralized system-and thus predicting its behaviour-can be highly challenging (Trentesaux, 2009).Over the last decade or so, blockchain technology has provided a potential solution to this issue by enabling a single programmatic state to be maintained in peer-topeer networks in an entirely decentralized fashion (Wood, 2013;Buterin, 2013;Poon and Buterin, 2017;Hukkinen et al., 2019).
Despite the vibrant streams of publications on the issue in recent years, little attention has been paid to the challenge of combining solution deployment and sustainability at the interindustry level.For example, (Elmessiry et al., 2019;Sternberg et al., 2020;Lu et al., 2019) address the problem of successfully deploying a blockchain architecture for increased transparency and trust in inter-organizational supply chains but do not consider inter-industrial, or system-of-systems, integration.Conversely, (Özyılmaz and Yurdakul, 2019;Tijan et al., 2019;Jiang et al., 2019) discuss using a blockchain-based architecture for creating an interindustrial backend for the Internet of Things, but do not address the feasibility of solution deployment.(Katuwal et al., 2018), on the other hand, briefly acknowledges the potential suitability of using a blockchain system as an incentivization mechanism to deploy a global health information exchange but does not address the solution sustainability aspect.Respectively, (Rajala et al., 2018) points out the need for self-reinforcing business models for sustainable systems-of-systems, but does not discuss the feasibility of solution deployment.
While potentially sharing a common manufacturing supply chain, product items do not usually follow one uniform chain of ownership throughout their individual lifecycles.Therefore, an inter-industrial perspective combining both effective deployment and self-sustainability is required in order to establish a prominent product-centric information solution, enabling transformational insight into individual product behaviour across national and industrial boundaries.

Blockchain systems and smart contracts
Blockchain technology is often described as a combination of information technology elements and methods enabling the creation of decentralized, distributed, and replicated digital ledgers.To this end, the technology employs e.g.peer-to-peer networking, public-key cryptography, digital tokens, multi-version concurrency control, and a cryptographically concatenated chain of data blocks used to store database modifications (Nakamoto, 2008).
For this paper, we define blockchain systems strictly as 1) open source and open access technology compositions; 2) comprising a non-hierarchical peer-to-peer networks without single points of failure or control; 3) which maintain consensus over cryptographically concatenated, shared and replicated append-only data structures; 4) according to deterministic self-contained consensus algorithms, void of external inputs such as validation by central authorities or off-chain signalling (Slootweg, 2016).In other words, we make a clear distinction between blockchain systems and the more loosely defined concept of distributed ledgers.A strict delineation of this kind is necessary, as the latter do not exhibit the same kinds of properties essential to solution deployment, as will be discussed later in this paper in Section 4. 3.2.In a computational sense, blockchain systems can be characterized as distributed state machines: peer-to-peer networks capable of maintaining a single programmatic state-or consensus-across the entire network and its shared data, without any single participant having authority over another.By employing Turing-complete programming languages, state-changing programs known as smart contracts can be created, stored and executed in the blockchain network to facilitate diverse distributed workflows (Wood, 2013;Buterin, 2013;Poon and Buterin, 2017;Hukkinen et al., 2019;Ethereum Frontier Guide, 2020).
Smart contracts can be described as programmatic containers for tokenized assets.Essentially, they are persistent computer programs which have the ability to autonomously govern assets and to execute transactions.Once assets are deposited into a smart contract's address, they cannot be recuperated until the programming logic of the smart contract permits it.The logic of the smart contract itself is protected by the distributed blockchain network: any unauthorized attempt to tamper with its design is obvious, and easily discarded by other participants (Wood, 2013;Buterin, 2013;Poon and Buterin, 2017;Hukkinen et al., 2019;Ethereum Frontier Guide, 2020).
By default, the execution environment of blockchain-based smart contracts lifeless.In order to interact with the smart con-tract's workflow in a state-changing manner, one must compensate the network on a per-operational basis for providing service.These compensations are also used to allocate request priority and to deter aberrant behaviour, such as requesting infinite computational loops.As each network interaction is bundled with its respective payment in this manner, any state-changing activities, such as database writes, are commonly referred to as 'transactions' in the blockchain vernacular (Ethereum Frontier Guide, 2020).
For this paper, we define smart contracts as digital computer programs that: 1) are written in computer code and formulated using programming languages; 2) are stored, executed and enforced by a distributed and replicated blockchain network; 3) can receive, store, and transfer digital assets of value; and 4) can execute with varying outcomes according to their specified internal logic (Lauslahti et al., 2018).

Problem summary
Deploying product-centric information management systems over the product life-cycle is cumbersome, regardless of the technical approach, as all parties involved in the product-life-cycle also need to participate in the information management solution.Attaining a critical mass for a digital platform often requires considerable initial investments.To deploy a solution, the participation of at least one market side must be first subsidized to attract other market sides onto the platform via indirect network effects (Katz and Shapiro, 1994;Caillaud and Jullien, 2003;Armstrong, 2006;Hagiu, 2014;Hagiu and Wright, 2015).Consequently, in order to compensate the high-risk venture of establishing a solution in the first place, the pricing models often involve significant economic rent, reducing the appeal of participation (Tähtinen, 2018;Hagiu, 2014;Gawer, 2009).
Thus, understandably, the question of control and ownership of a product-centric information system has been at the centre of attention in research and development (Främling et al., 2007).Recently, however, the problem of control and ownership has increasingly become reframed as a broader question of viable inter-industry deployment, especially in the research domain of cyber-physical systems (Naphade et al., 2011;Alam and El Saddik, 2017;Porter and Heppelmann, 2014).
In addition to the problems related to deployment, another set of problems arises from the complexity of dynamic multi-industrial environments.The problem with static workflow designs is that in today's economy, supply chain structures are often complex and prone to reconfigurations (Rajala et al., 2018;Ali-Yrkkö et al., 2017).While at the industry level, the data integrations and the required reconfigurations may be manageable, at the inter-industrial level the complexity in this regard increases exponentially.Therefore, even if all the parties involved were fully motivated to co-operate to their best ability, product data regarding individual product items could still become fragmented due to the information asymmetries involved.
The third problematic dimension is related to the motivation to preserve the product data workflow.So far, neither centralized nor peer-to-peer-based solutions have been able to provide a satisfactory solution to the problem of adequately incentivizing solution sustainability beyond individual commercial interests.While centralized models have suffered from asymmetrical power structures and single-points of failure, peer-to-peer models so far have lacked proper governance models to foster sufficient network effects for the solution to perpetuate (Ahluwalia and Democracy, 2016).

Methodology
The proposal for an improved design presented in this paper was developed and evaluated by using an explorative design science research approach.Design science is a research method well suited for situations where a practical problem and its solution can effectively be examined through the development of a design artefact, such as a computer program, a system model, or a conceptual practice (Peffers et al., 2008;Holmström et al., 2009).The design science approach was selected because it enables a rigorous way of designing, building, and evaluating a conceptualization for a product-centric information management system.
The study also incorporates elements of the methodology of systematic combining where an emergent theoretical framework, the empirical fieldwork, practical demonstration, and outcome evaluation are developed in a simultaneous, iterative process (Dubois andGadde, 2002, 2014).While systematic combining is particularly useful for proposing new approaches and ideas for conceptual research, the main focus of this study is in new practice design.It assumes an integrational approach, providing a cross-disciplinary evaluation of the applicability of blockchain technology to address the challenges of introducing product-centric information management in an inter-industrial setting.
A former case study is also exploited and modified to demonstrate some of the key aspects of the conceptualized design proposal (Eisenhardt, 1989).The demonstration was iteratively developed and contextualized to a relevant product item example and industry setting.The programming of this design artefact draws from the methodologies of computer science (Ayash, 2014).
Through an evaluation procedure, design science enables research objectives to be addressed and problematic areas to be charted and pinpointed at an early phase, without waiting for large-scale implementation.To evaluate the validity of the design proposal, and to provide further in-depth insights into the conceptualization, two rounds of seven qualitative interviews were conducted in a semi-structured manner.The interviews were not intended as a substitute for field testing of the design proposal, but for evaluating the key assumptions and concepts, as well as mapping the critical issues related to the implementability of the design.In other words, the aim was to involve the interviewees in exploring what aspects of the problem situation are important from the interviewee perspective, and how these concerns relate to their view and evaluation of the design proposal.A description of how the evaluation sessions were carried out is presented in Appendix A.
The interviewees were selected in an opportunistic fashion, based on their credentials and expertise, and their heuristically evaluated ability to provide the most valuable insights on the design proposal.The first round of evaluation interviews involved a generic system-level demonstration which was not contextualized to any particular product item or industrial setting.The followup interview round involved a more detailed and contextualized iteration of the design proposal with a specified product item, a conceptual data model of the product system architecture (not to be confused with a product data model), and an improved source code artefact with more elaborate incentivization and payment mechanisms.The follow-up interviews also involved a Delphi segment (Dalkey and Helmer, 1963) which allowed the interviewees to comment on the summarized key points from the first round of interviews and to readjust their views.The interview questions around which the interviews were framed is included in Appendix B (Table 1).

Objectives for a solution
On the basis of the problem summary in Section 2.3, we determine that the main objective for a solution is a design for a product-centric information management system which can be deployed across many industries in terms of costs, coordination, and critical mass, and which can sustain its own existence independently.We postulate that in order to achieve such a design, the system should be able to satisfy the following conditions and specifications: Firstly, the design proposal should be able to a) enable participation of all the willing parties.In order to achieve this, the system should feature ahierarchical governance.Secondly, the proposal should be able to b) prevent data and workflow fragmentation in a dynamic environment.For this purpose, the system should be based on replicated and distributed architecture.Thirdly, the design proposal should be able to c) ensure data and platform sustainability over the complete lifespan of product individuals.For this reason, the system should involve an inherent incentivization mechanism.

Design principles
We address the research problem and our objectives for an improved design with an approach based on blockchain technology.The motivation for choosing this approach stems from the observation that permissionless open source blockchain systems exhibit a range of properties which conveniently line up with our objectives for a solution.Firstly, due to their ahierarchical governance structure, blockchain systems can be well-suited for enabling participation.Secondly, their blockchain data structure and consensus mechanism can be very effective in maintaining multi-version concurrency control in a decentralized fashion.And lastly, crypto-token-based incentivization mechanisms can be directly incorporated in their participation protocol.Furthermore, the chosen approach comes with a proven track record of several peer-to-peer networks already having been successfully deployed in the described manner in the past (e.g.Bitcoin, Ethereum).
In order to accomplish our objectives for a solution, the demonstration of the design proposal needs to show that blockchain systems can be used to involve new parties in the product data system.The demonstration also needs to demonstrate that blockchain systems can be used to include new information as a part of the product-centric information management system.Furthermore, the capability for facilitating adequate incentive structures also needs to be demonstrated.
In this paper, we demonstrate these abilities by employing a smart contract to facilitate a product individual's lifecycle journey.The smart contract was designed for Ethereum, as it represents a suitable deployment environment successfully established in a similar manner as conceptualized in this paper.The other option would have been to establish an entirely new blockchain network as a designated deployment environment for product-centric information management.While perhaps better suited for the actual purpose of the use case, this approach would be difficult to demonstrate in a similar capacity and therefore was not pursued in this paper.
In transitioning from product class data to product-centric information management on individual product items, the number of required transactions can be expected to increase many-fold.Furthermore, as individual product items journey through their individual product lifecycles and paths of ownership, the number of information sources and different data system interactions can also be expected to increase heavily.In order to ensure that the data regarding all the product individuals is provided by all the relevant parties, data provision should be directly rewarded at the level of the participation protocol.For seamless inter-industrial functionality, the system should be constructed so that data exchange can happen spontaneously.In other words, no premeditated ad hoc data system integrations should be required between the participants, other than with the blockchain network itself.To this end, the demonstration also illustrates how these incentivization mechanisms can be facilitated by a blockchain-based system design.Furthermore, we also conceptualize, how the provision and the development of the product-centric information system itself can be incentivized by a blockchain-based approach.

Demonstration of blockchain-based deployment: A loader crane for commercial vehicles
The demonstration of deployment concerns an illustrative product individual, a loader crane for commercial vehicles.These types of loader cranes are manufactured by companies such as Palfinger of Austria, and Hiab of Sweden.The loader crane is typically mounted on a new vehicle before delivery to the customer by the dealer.However, it may also be installed on a vehicle at a later time by the OEM of the loader crane.When the vehicle reaches the end of its life-cycle, the loader crane can be remounted to a different vehicle.This way, the life-cycle of the crane exceeds that of the vehicles to which it is mounted.Over its life-cycle, the loader has many different owners.Furthermore, not only can it be mounted to different vehicles, it can also be repurposed and refurbished by other organizations than the OEM.Product individual data on the loader crane needs to be collected in many countries due to safety regulations.

Participation protocol overview
To demonstrate the conceptualization drafted according to our specified design principles, we present an example protocol of a manufacturer deploying product-centric information management over the product life-cycle of a loader crane (see Fig. 1).We demonstrate how the relevant contractual and incentive functionalities in each step are defined in the source code that forms the smart contract in Appendix A. The complete and functional source code for the demonstration can also be found at (Valkama, 2020).
The participation protocol of the demonstration begins with the reception of a new loader crane order by the manufacturer.At this stage, we assume that the smart contract facilitating the workflow for the product life-cycle journey is already deployed in the environment consisting of e.g.vehicle manufacturers, loader crane OEMs, truck dealers, trucking firms, and service and maintenance companies.In this conceptualized implementation, after the crane has been manufactured, the manufacturer sends a transaction to the smart contract, requesting that a new product item life cycle journey representing the physical crane is established in the blockchain and its ownership assigned to the manufacturer.In addition, the request contains manufacturing information such as crane model specifiers and a serial number to be stored on the product item (1).
After this step has been executed by the smart contract (2), the manufacturer can now control the product item in the product data system.As the current owner of the product item, it is possible for the manufacturer to store additional data to the lifecycle journey or query the data already stored without any extra fee.
Upon the sale of the crane to a vehicle manufacturer the crane manufacturer initiates a new transaction in the smart contract in order to transfer the ownership of the product item to the new owner (3).Consequently, the smart contract checks for the permission to perform the request and updates the lifecycle journey accordingly (4).
Over the life-cycle of the loader crane, a multitude of information relevant to different parties is accumulated and can be linked to the smart contract.In the example scenario, once the vehicle manufacturer receives the crane from the loader crane manufacturer, the crane is required to pass an individual inspection performed by a certified authority before it can be installed and used on a vehicle.After the inspection, the vehicle manufacturer sends a transaction to the smart contract in order to store the location pointing to the inspection data (5).Upon receiving the request, the smart contract ensures that the sender of the request is the current owner of the product item and then stores the datum to the smart contract (6).
Once the crane has been mounted onto a vehicle, the vehicle manufacturer delivers the assembly to a truck dealer to fulfil a pre-existing purchase order on the vehicle.Upon the delivery, the vehicle manufacturer sends a transaction to the smart contract in order to transfer the ownership of the product item to the truck dealer (7).The smart contract once again checks for the required permissions and then executes the transfer of the ownership (8).
Before putting the vehicle out for sale, the truck dealer must complete the vehicle registration process and provide documents to the registration authority which prove the vehicle's suitability for its intended use.In order to do this, the truck dealer requires all the relevant information regarding the vehicle's life-cycle journey.To obtain this information, the dealer first sends transactions to the smart contract to pay for the access to the manufacturing and the inspection data from the smart contract (9).Upon receiving the payment transactions, the smart contract deposits credits to the accounts of both the loader crane manufacturer and the vehicle manufacturer for the data they have contributed earlier.Subsequently, the smart contract grants the truck dealer access to the data (10).After the payment transactions have been successfully completed, the truck dealer sends queries to the smart contract to read the relevant data (11).Finally, the smart contract checks that the truck dealer has the valid access and returns the requested data (12).The truck dealer can now proceed with the registration of the vehicle.

Incentivizing the provision of the product-centric information system
The successful deployment of an inter-industrial productcentric information system, such as the one outlined for the loader cranes, is intricately linked to the concept of network effects.In economics, a direct network effect occurs when the value to an agent from using a product, a service or a system depends on the extent of its use by other similar agents.Indirect network effects, in turn, occur when such an increase affects the users of a different product, service or system (Katz and Shapiro, 1994;Caillaud and Jullien, 2003;Armstrong, 2006).
Blockchain-based solutions incorporate a mechanism for a positive feedback loop of indirect network effects to incentivize solution deployment.In essence, the blockchain-based operations described in Appendix A begin by drafting a participation protocol-an elaborate set of rules of engagement to which the participants must adhere in order to be acknowledged by the peer-to-peer network.The actor who initially seeks to create the solution for loader cranes starts the deployment by formulating and publishing the participation protocol.Blockchain systems make use of this participation protocol by inherently embedding financial incentive structures for platform collaboration directly into the protocol itself.
The protocol is open, both allowing new actors to join, as well as the introduction of other types of products than loader cranes.Fig. 2 illustrates the positive feedback loop of network effects in blockchain-based deployment.The blockchain system involves a set of rules to which all participants must adhere in order to be acknowledged as members of the network.By contributing computational work, as instructed by the rules of the system, the network enforces a single state of the participation protocol (1).The participation protocol handles each product individual's lifecycle journey and the interactions with it, including the payment transactions for providing product data (2).As each payment also includes a compensation to the network operators for providing service, this incentivization attracts more participants to provide data and to operate the network (3).As the network grows larger, contributing even more computational work (1), the participation protocol grows more robust, making the data and the respective payments in the system more valuable (2).This, again, strengthens the incentives to participate (3), and so on (Mattila and Seppälä, 2018;Catalini and Gans, 2016;Athey and Roberts, 2001;Athey et al., 2016).

Incentivizing the provision of product data
A product datum regarding an individual loader crane can be of very low value to the transacting participants in itself.Therefore, it can be difficult to facilitate the corresponding payments globally in a dynamic environment by any traditional means.Furthermore, in order to maintain the decentralized quality which makes the solution appealing to all parties, the payment processing should also be executed in the same decentralized manner.
While blockchain systems can be used for direct payment processing, they do not scale well in terms of transaction throughput capacity.Therefore, directly facilitating payment transactions through smart contract workflows can quickly become infeasible in large numbers (Hukkinen et al., 2019).Blockchain systems do, how-  ever, enable an alternative microtransaction mechanism through the use of crypto-mining payments.
Crypto-mining payments are based on the fact that blockchain systems, require constant inputs of computational work to maintain their single state.Normally, providing this work entitles its contributors to rewards in the form of cryptographic tokens of value in order to incentivize participation.The rewarding is carried out via an inflationary tax on the entire network by issuing a small number of new tokens to the recipient of the reward, thus adding tokens into the token supply of the network and depreciating the value of each individual token in the process (Mattila and Seppälä, 2018).
In crypto-mining payments, the cost of the computational work contributed to the network and its respective reward are disentangled from one another to facilitate a payment transaction (see Fig. 3).Once the seller has provided the item of sale to the smart contract (1), the buyer contributes computational work to maintain the network's concurrency control, expending electricity which effectively constitutes the payment (2).The smart contract then allocates the respective mining reward issued by the network to the seller (3).Finally, the item of sale is delivered to the buyer (4).
In essence, in crypto-mining payments, the act of making a payment always simultaneously contributes to the provision of the payment processing platform itself (Rüth et al., 2018;Pearson, 2018).

Technical design
The interviewees unanimously considered the loader crane a good product example and an appropriate industrial setting for the conceptualized design proposal.Two of the interviewees commented (#2,3), however, that while the conceptualization seems well-suited for the loader crane-i.e. a product of mid-range complexity-in reality product-centric information management must be extended to far simpler products and sub-components than the crane; In such cases, tracking the material and component identities and incentivizing collaboration could become more challenging via the conceptualized design, according to the two interviewees.Mostly the interviewees agreed (#1,4,5,6,7), however, that in a full implementation, the participation protocol could be expanded to facilitate the real-world complexity of a product individual's life-cycle.
The final iteration of the participation protocol was considered a sound design and logically coherent by all of the interviewees.One of the interviewees felt (#4), however, that a better possible way of configuring the participation protocol would have been to assign the loader crane product individual with its own unique identity in an equivalent manner to the manufacturer and the owners, and to use the smart contract's workflow only as a transaction link layer for the identities, the data, and the associated payments: "This, I think, would have been more in line with the current Industry 4.0 digital twin mentality.The added benefit here would be that this participation protocol could guarantee the identities of the agents and product individuals when interacting through this kind of a link layer." As a noteworthy point for further development, one of the interviewees also remarked (#7) on the design proposal's low threshold for extensive field testing: "One good thing about this conceptualization is that it wouldn't be a huge effort to try this in practice.It's a classic example of a problem that is so complex that it's difficult to anticipate what would happen, so the easiest way to find out would be to simply try it out.And since the concept itself mainly deals with metadata, the risks for the participants would also be quite low."

Enabling participation
In Section 4.1, we postulated that in order to achieve our design objectives, the design proposal should feature ahierarchical governance to enable full participation by all the willing parties.To reflect this design principle, the solution proposal was based on a peer-to-peer blockchain architecture with no centralized authority or any designated individual or group responsible for the solution provision.
The distributed design approach was considered a good and sensible starting point for enabling open participation by all interviewees.Interviewees mostly agreed (#1,4,5,6,7) that successfully establishing an inter-industrial infrastructure at scale will require some new type of an approach.While a caveat offered (#1,6) that starting in the right place does not necessarily mean arriving at a functional solution, the proposed design was generally seen (#1,4,5,6) as a step in the right direction in the design principles.As described by interviewee #4: "If we think about the loader crane industry, this kind of a systemic approach and the entire platformbuilding way of thinking is still quite alien to them.However, I think this is the only way to enable vast collaboration between different agents around a single product individual's lifecycle.I don't think any other approach would work at such a high level of scope." The interviewees also largely agreed (#1,4,5,6,7) that the conceptualized open source, open access, and blockchain-based deployment would significantly reduce the costs of solution deployment and lower the barriers of entry into the product data market.The interviewees mostly agreed (#1,4,5,6,7) that the open access design and the role flexibility in solution provision should make participation more inviting, as its less constrictive nature means that participants are free to pursue business opportunities without restrictions by the solution provider.For inter-industrial deployment, this prospect was also considered pivotal (#1,4,6,7) because of the excessive difficulty of any solution provider anticipating all the use cases and business models in which potential participants are interested in an inter-industrial setting.However, arguments were also made (#1,4,6,7) that certain functions could still end up requiring centralized services to be offered on top of the system, involving additional fees for the users; For example, the identities of the users and the product items could turn out difficult to onboard in a completely decentralized fashion.
While the open access to become a provider for the solution architecture was also considered (#2,3,4,6) beneficial for the trustworthiness of the system, one interviewee had (#7) reservations in this regard: "With this kind of deployment, the network could end up being operated by parties not really involved in the supply chain structures at all.Of course, then you are faced with administrative questions, such as can these parties be trusted and is it really sensible that just literally anyone can start operating the data network.Or do we, after all, want to retain a little bit more control in the hands of those who actually use the data and the system?"Some concerns were also raised regarding the scalability of the conceptualized design.These concerns were mainly related to three key points.The first point of concern mentioned (#1,2,5,6) by the interviewees was the possibility of runaway costs due to system inefficiencies as the system is scaled up.This consideration stemmed from the technical properties of the conceptualized solution architecture (e.g. the requirement of constant inputs of computational work).
Another point of concern brought up (#1,5,6) regarding scalability had to do with the practical difficulty which often arises in the finer details of scaling up proofs-of-concept and other conceptual solutions.Building conventional IT solutions is a safer practice with a lot more history and experience on avoiding the potential pitfalls.A novel permissionless blockchain-based approach at scale is likely to produce a variety of unforeseeable problems and security issues, such as uncharted attack vectors, which need not have been considered in more traditional approaches.
Lastly, the third scalability-related point of concern mentioned by one interviewee (#2) was the presence of "walled gardens"-the purposeful lack of interoperability maintained by some industry actors as their competitive strategy.Some interviewees felt (#4,6), however, that this kind of a mindset was becoming less common and would be phased out by the market within the next 5-10 years; While customers have not been willing to pay extra for smart product features, market competition is making the smart product approach increasingly a necessity in maintaining a competitive product.

Preventing data and workflow fragmentation
As our second design objective we stipulated that the system should be based on replicated and distributed architecture in order to prevent data and workflow fragmentation in a dynamic network.
Contemporary solutions to product information management have often involved building case-specific ad hoc integrations between the data systems of the vendor and the client.Many of the interviewees expressed (#3,4,5,6) the opinion that due to the difficulty of indexing such ad hoc solutions in current configurations, the conceptualized design proposal could help locate the source of product data with greater ease.As explained by interviewee #6: "When a new system comes along, an integration is built to each preexisting system.And so the number of APIs absolutely skyrockets, and the system doesn't scale.And at the end of it all, the PLM people are left wondering where the master data is coming from, which systems are integrated with what, and so on.This conceptualization could provide a standard way of transferring the product data between all the various systems." The conceptualized design proposal was purposefully left agnostic in terms of the product data format and meta data standards.The interviewees largely considered (#1,2,3,4,6) this a valid decision, pointing out that specifying a universal standard suitable for the needs of all actors in a cross-industrial context would be exceedingly difficult.
Defining machine-readable formats and relevant meta data standards was, however, considered (#1,2,4,5,6) one of the most important aspects for any shared inter-industrial or even intraindustrial use to be possible.For example, as pointed out by one of the interviewees (#1): "You want the information fields to have enough flexibility to be able to cover anything, like a potential repurposing of the product, but at the same time, you need enough rigidity to pick up the elements that are important for the loader crane.You need to have the different loader crane manufacturers input similar data in comparable form.That structure is really important." Some the interviewees elaborated (#1,3,4,5,7) that determining such data ontologies was a task best left for the markets and the soft law efforts of each specific industry.As expressed by interviewee #3: "At the end of the day, everything hinges on what kinds of product data models are demanded by the customers.This way, companies could be forced to switch over to using different kinds of models." In the demonstration's participation protocol, the product data is not stored in the blockchain, as such an approach would hardly be technically feasible.This aspect aroused both positive and negative considerations.The most obvious concern was the fact that the product data still needs to be stored somewhere.While the conceptualization does not describe in detail how the product data could be stored, the interviewees were (#1,4,6,7) open to the exploration of InterPlanetary File System -style solutions.InterPlanetary File System (IPFS) is an open-access peer-to-peer network designed to store data by using content-based addressing.In other words, a given address always points to the same content, thereby preventing data fragmentation within the network1 .
As a positive side, not storing the product data into the blockchain database was seen (#2,4) to enable further access control by each data provider at their end as they see fit.One noteworthy possibility enabled by this aspect, as pointed out (#4) by one of the interviewees, would be the facilitation of product-centric data products.Differing from data-driven applications, such as software solutions using API-based data for analytics, data products are independent, self-adapting entities which combine data inputs with analytical tools and models to produce new outputs of broadly applicable refined data (Kim and Bengfort, 2016).Currently, the API-driven solutions utilized in contemporary approaches are insufficient to construct and manage data products effectively.The conceptualized design proposal could offer a way to record and track the product and user identities, ownership relations, and the relevant data ontologies in a more constructive manner.

Ensuring data and solution sustainability
As the third objective in our design approach, we stated that the system should include an incentivization structure in order to ensure data and solution sustainability over the complete lifespan of product individuals.
One potential problem in this aspect which was pointed out (#1,3,7) is that designing universal incentive structures can be overwhelmingly difficult.For example, if actors were directly compensated for performing transactions of data into product items' life cycle journey, this could lead to the said actors purposefully bloating the system.Similarly, if a generic part of lesser quality is used in maintenance, adding this information to the product data could reduce the resale value of the product.Therefore, the owner may not be inclined to do so, regardless of the incentives embedded in the participation protocol.
While many of the interviewees felt (#2,3,7) that the problems stemming from humans cutting corners cannot be mitigated by incentives embedded in the participation protocol, the resulting market mechanism could alleviate the problem, as explained (#1) by one interviewee: "If there are 100 fields which should be inputted for the loader crane, is there an incentive to update the fields that are the most popular and have the most valuable use cases?When the system has the incentive mechanism you have conceptualized, I think it will happen organically.When you leave it to a market mechanism, the market will find out which data is more valuable." Another point raised (#2,3,4,6,7) by many of the interviewees regarding the participation protocol was that the system cannot necessarily be perpetuated with internal token incentives alone.Some external motivation for preserving the product data is required outside of the system itself.The interviewees estimated (#1,4,5,6) that the stakeholders in the loader crane's lifecycle would be willing to pay in the order of magnitude of tens to hundreds of euros for relevant data on their product items to be made available upon request, depending on the specific circumstances.This was seen to be motivated by e.g.opportunities of increased sales and modernization, regulatory compliance, and reverse logistics at the end of the product lifecycle.Heuristically, the amounts were considered (#1,4,5,6) sufficient to enable the sustained facilitation of the curated workflow, as proposed by the design.
The crypto-mining payments conceptualized in the design proposal provoked a mixed reception.On the one hand, the idea was widely considered intriguing.The notion that every payment transaction also simultaneously contributes to the provision of the underlying payment processing architecture was largely seen (#1,2,4,5,6) as an interesting prospect for fostering positive network effects and producing a positive scaling effect for the deployment of the network.Also, the implications for machine-tomachine payments and the idea that smart devices equipped with some CPU capacity and an internet connection could autonomously pay other devices directly for the curation of their own product data throughout their lifecycles mostly aroused (#2,3,4,5,6) interest.
On the other hand, a majority of the interviewees was concerned (#1,4,6,7) that implementing such a payment model would create an extra layer of unnecessary complexity and token price stability issues, potentially requiring some kind of a middleman to mitigate.Also, in regard to the prospect of M2M payments, it was pointed out (#1,2,3,6) that currently, the vast majority of industrial internet devices in use do not have the required smart capacity to carry out such payments.In the words of interviewee #6: "Usually the software in products like loader cranes is quite specialized and proprietary, so I imagine adding the capability for crypto-mining payments would be quite a painful endeavour in a larger scale." Due to these considerations, mostly the interviewees largely agreed (#2,3,4,6,7) that while an interesting prospect in its own right, crypto-mining payments would not be feasible as the only possible payment option in the present configuration of industrial systems.

Discussion
Several limitations apply which should be acknowledged when interpreting this exploratory study and its findings.Firstly, this study did not explore the integration of the demonstrated design proposal with other IT systems.Secondly, the study did not consider the details of viable product data formats in product-centric information management or the heterogeneity of real-world product data in general.Thirdly, the study did not address the question of how the actor and product identities could be onboarded in a fully decentralized fashion.
The applied semi-structured interview approach is limited in comparison to the more extensive field testing needed for empirical findings and design iterations in accordance with the design science process.The purpose of the loader crane demonstration and its evaluation was not to capture the complexity of a real product lifecycle, however, but to illustrate how a blockchain-based deployment of a product-centric solution could be configured to facilitate the necessary core functionalities for handling the product data, the agent identities, and the incentivization mechanisms required for a full scale implementation.Aiming at a solution that can be deployed across different environments over a long period of time, we seek to contribute to the research on viable inter-industrial deployment (Naphade et al., 2011;Alam and El Saddik, 2017) and self-sustained platforms (Mattila and Seppälä, 2018;Blossey et al., 2019;De Filippi and Loveluck, 2016).
While the use of a blockchain-based system offers a different set of abilities than more conventional approaches, some general problematic aspects regarding its utilization remain which were also not addressed in this paper.For example, while the participation protocol can algorithmically manage the solution provision and the product data workflow, the governance of more strategic development goals remains an open question in the research of blockchain systems (Mattila and Seppälä, 2018).Also, some criticism has also been presented regarding the alleged decentralized nature of blockchain systems in the first place (Walch et al., 2019).
The proposed approach enables anyone to freely enter the system in any market role and to produce open innovations for all areas and functions of the system.This approach, we anticipate, would create power dynamics where all participants are-not necessarily de facto equally powerful-but at least algorithmically equipotent and equally privileged by default.In such a system configuration, no participant would have an obligation to participate in the development, provision, or financing of the system architecture and its auxiliary services, but respectively, no participatory role or function would be off-limits to any participant willing to engage in its provision.
The proposed design presented in this paper extends product data management beyond standard systems.In our proposed design, many such systems are linked in a controlled way, with the product individual as the focal and organizing entity.Even when different actors use their own solutions for product life cycle management information, this information is purposefully collected and distributed between these many systems and actors.Our proposed solution makes it possible to incentivize the collection and distribution of high-quality and high-value product lifecycle information for many different types of product data residing in different systems.This is achieved through a mechanism for different entities to initiate and reward this controlled linking.For example, for a composite product with different modules, the product design and manufacturing information is located in the different PLM systems of the OEMs (e.g.Windchill, Teamcenter).The asset and performance data is located in the current and previous owners' operational systems (e.g.IBM Maximo, Avantis EAM), and service delivery in the systems of different service providers maintaining and supporting the systems (e.g.SAP, Odoo).With the proposed solution, an OEM or a product owner can incentivize other parties to collect and share data on product individuals.
The results of this study suggest that while significant challenges for implementation exist in the current industrial landscape, the applicability of blockchain technology to the problem of productcentric information management has so far been perceived narrowly in academia, largely overlooking its potential significance to sustained inter-industrial deployment.This observation supports the earlier findings of (Blossey et al., 2019) where the authors state that the "[supply chain] applications of blockchain technology mostly focus on efficiency improvements and risk mitigation from a single-firm perspective.--However, this perspective largely omits the institutional innovation potential of blockchains reorganizing supply chains for collaborative ecosystem-based value creation." The insights provided by this study regarding the incentivized deployment of blockchain solutions for product-centric information management may also help the deployment of similar distributed data sharing solutions intended for other purposes and other sectors of society.The conceptualization delineated in this paper may be especially helpful in cases where the aim is to establish auxiliary services and solutions for business processes that are not core to any of the participants involved.Furthermore, the conceptualized design could also enable an approach where data products on product individuals were manufactured to order, and the curated workflow of the participation protocol served as an index on where the data product could be requested.If successful in its deployment, due to its agnostic data ontology, the system could also be expanded to house a variety of all kinds of data products.Also, the technique could be utilized to manage data in other contexts than product data management, e.g.direct from design manufacturing.

Conclusion
Our study offers a new network-effect-driven perspective on how inter-industrial data sharing solutions could be established and maintained through a blockchain-based approach, including system development, deployment, and payment processing.In most contemporary design proposals for product-centric information management, the deployment and workflow structures of digital interactions are unilaterally controlled by the service provider who is also providing the underlying technical architecture.By disentangling the solution provision from the control of the data and the workflow, hindrances in the integrational development of inter-industrial digitalization could potentially be alleviated, thus enabling more widespread adoption.Further studies are encouraged for the inter-industrial perspective to product-centric information management, with a design focus on sustained solution deployment.

Appendix A. protocol for blockchain-based deployment
In the following sections, we will present data model, and the different operations that allow the deployment of the loader crane according to the scenario described above.The complete and func-tional source code for the demonstration can also be found at (Valkama, 2020).

A.1 Product system design
The conceptual data model of the conceptualized system is illustrated in Fig. A1.The product system contains a collection of product items which are owned by actors such as manufacturers or dealers.The product items each contain a collection of item datums.
Consequently, each datum added to a system has an originating actor who is thus considered as the contributor of the datum.Only the contributor of a datum can read the particular datum without cost while all other actors in the system are subject to a fee to be able to access it.The actors who have paid the fee are represented in the figure as having the permit to read a datum.
The implementation of the conceptual data model in Solidity, the language used to describe smart contracts in the Ethereum blockchain platform, is shown below:

Product System model (Solidity code)
The actors in the system are represented simply as Ethereum addresses in the smart contract.This establishes a unique identity to each actor and allows for authentication and access control of the smart contract operations in the Ethereum platform.Furthermore, a simple associative array style data structure of string keys and (datum) values was chosen to represent the product item data.As per the objectives, this imposes minimal restrictions on how to structure and model the product item data, thus enabling different industries to develop their own standards.The requirement of using only textual formats for data also allows for better interoperability across systems and actors.Furthermore, the requirement also discourages polluting the product system with e.g.proprietary binary files that are of no use on a larger scale when considering the entire life cycle of a product item and the larger systemic perspective.
The next sections will cover the different operations that are required to implement the semantics of the smart contract, as described in the example scenario.In addition, JavaScript example code of how the smart contract could be called from the client side will be shown.

A.2 Creating a product item life cycle journey
Just as every loader crane in the physical realm goes through a journey of events over its life cycle, respectively, the life cycle of each corresponding product item object in the smart contract can be structured in the same manner.All the product items begin their life cycle journey in the smart contract when a manufacturer sends a transaction to the smart contract, requesting the creation of a new product item with the supplied manufacturing data: Client side (JavaScript code) createProductItem("4950 , {serialNumber: 4950, modelSpecifier: "KPV"}); Upon receiving the request sent by the client, the smart contract stores a new product item to the blockchain with the manufacturing data and the sender of the transaction (the manufacturer) as its initial owner.Additionally, the smart contract sends an event, that can be subscribed to by clients, signalling the creation of a new product item: Smart Contract (Solidity code)

A.3 Transferring the ownership of a product item
When the ownership of a physical loader crane is transferred, the product item in the smart contract must also undergo a transfer of ownership so that the new owner can control the product item.The ownership transfer process is initiated by the current owner by sending a transferral request transaction from the client side to the smart contract, with the product item identifier and the Ethereum address of the new owner as parameters: Client Side (JavaScript code) transferOwnership(4950, "0 × 485B48DB7e8c65E76178a4C080a7099A5780aA86 ); Before executing the transfer of the ownership, the smart contract checks that the sender address of the transaction is the same as the address of the owner of the product item.If the sender is not the same as the owner, an error is returned, and the transaction is aborted.After ensuring that the sender is the owner of the product item, the new owner is assigned to the product item and the transaction completes successfully: Smart Contract (Solidity code) A.4 Assigning new data to a product item As a loader crane journeys through its individual life cycle, it goes through a unique sequence of transformative events.Respectively, the information contained in the product item must be updated to reflect these changes accordingly.To associate new data to the product item, the owner sends a transaction to the smart contract, using the product item identifier, the key identifying a particular datum, and the datum itself as parameters: Client side (JavaScript code) setItemDatum(4950, "latestInspection", {date: "2020−04-21", result: "ipfs://. .."}); Upon receiving the request, the smart contract first checks that the sender address of the transaction is the same as the current owner and then updates the product item, associating the datum by its key.Additionally, the address of the sender is stored along the new datum so that the smart contract will later be able to identify the actor who has contributed the particular datum to the system: Smart Contract (Solidity) A.5 Paying to access product item data If an actor wants to access a particular datum but is not its contributor, the actor must first pay a fee to obtain a right to access the datum.To this end, a transaction is sent from the client side with the product item identifier, the datum key and the payment amount as parameters: Client side (JavaScript code) payDatumFee(4950, latestInspection ¨, {value: 1000000000000000 }); Upon receiving the payment request, the smart contract first checks that the sender of the transaction is not the contributor of the datum.If the contributor and the sender are the same, the transaction is aborted.Otherwise, the smart contract will deposit the paid fee to the Ethereum address of the contributor and then issue access to the sender while also associating the timestamp of the current blockchain block with the permit: Smart Contract (Solidity code) A.6 Querying product item data The product item data may be queried at various stages of the product item's life cycle by various different owners.Furthermore, queries can also be made by others actors with access to the smart contract deployment, such as public authorities or thirdparty integration systems.However, only the original contributor of a particular datum may access it without a cost, whereas other actors must pay a query fee to obtain access.To query data from a product item, a read query is sent from the client side with the product item identifier and the datum identifier as parameters: Client side (JavaScript code) getItemDatum(4950, "latestInspection"); Upon receiving the query request, the smart contract first checks whether the sender of the transaction is different than the contributor of the datum requested.If the sender and the contributor are the same, the requested datum is returned immediately to the sender.Instead, if the sender and the contributor differ from one another, the smart contract will check whether the sender has access associated with the datum, and in case access has not expired, the datum will be returned: Technical design (2nd round only) • Product example: How do you feel about the loader crane product item and the industry setting specified for this demonstration?Are they • Participation protocol: What do you think about the technical design of the participation protocol?Does it make sense to you?Is there something that jumps out as good or bad?Is there something that hasn't been considered?Is there something you would want to change about its design?
• Feasibility: How do you see the practical implementability of this design?How do you feel about its ability to scale and to facilitate the complexity and heterogeneity of real-world product data?
• Other: Is there anything else you would like to comment about the technical design?Conceptualization (1st round: without product & industry context; 2nd round: with said context) • Technology: What potential benefits and problems do you see with the use of a blockchain smart contract to facilitate the workflow of a product life-cycle journey?
•Governance: The conceptualized PCIM platform has no centralized authority or platform provider.What benefits do you see following from this design principle?What about problems?
•Data format: The concept does not specify any particular product data format.What are your thoughts on this?Benefits?Problems?
•Deployment: What do you think about viability of the suggested method of platform deployment through an incentivized open-source participation protocol?Could you also comment the cross-industrial aspect?o What kinds of problems might the concept solve in establishing a PCIM system?o What kinds of problems might the concept not solve in establishing a PCIM system?
•Payments: What do you think about the suggested method of incentivizing the provision of platform data through crypto-mining payments?
o The crypto-mining payment approach would, in principle, enable intelligent product items would be able to pay for the maintenance of their own product data with electricity and CPU power.What are your thoughts on this prospect?What are the benefits and the problems?
•Longevity: The concept suggests that due to the incentivization mechanism, the conceptualized PCIM platform could outlive product individuals and even the companies that manufactured them.What benefits and problems do you see with this idea?
•Versatility: Due to the open-access nature of blockchain systems, the concept should be able to maintain the product data workflow intact even in the case of dynamic supply chain structures.What benefits do you see to this approach?What about problems?
•Shortcomings: What do you consider the weakest aspect of the concept?Are there considerations which the concept fails to take into account?Delphi (2nd round only) Do any of these summarized key points in this list jump out to you as something you want to comment?For example, is there something in particular you strongly agree or disagree with?

Fig. 1 .
Fig. 1.Participation protocol for blockchain-based deployment of product-centric information management over the life-cycle of a loader crane.

Fig. 2 .
Fig. 2. The growth-fostering positive feedback loop of network effects in blockchain systems.

Fig. 3 .
Fig. 3.The mechanism of a crypto-mining transaction, as conceptualized in the participation protocol.

Fig. A1 .
Fig. A1.The conceptual data model of the product system modelled as an Entity-Relationship (ER) diagram.
(1st & 2nd round) •Basic information: Name, age, occupation?•Experience: In number of years, how would you describe your experience in: o product data systems?o blockchain technology?•Clarity: Do you have any questions about the concept?•Sentiment: Other initial thoughts about the concept?

Table 1
A description of the evaluation interviews.