Keywords

1 Introduction

Digital platforms are widely used in various business sectors [1, 2]. They provide foundations for others to build on, in the form of a codebase consisting of central functionality that can be extended with external systems [1, 3]. The core of a digital platform contains the stable and generic elements, while the surrounding information systems add variability and diversity [4, 5]. Boundary resources provided by a platform owner are a key instrument for this [3]. Systems connected to a platform can range from simple mobile applications to mature enterprise systems or cyber-physical systems controlling heavy machinery. Together with the platform these systems form a software ecosystem that serves a certain market [6].

Studies on business-to-business (B2B) ecosystems show that they can differ from global, consumer-focused ecosystems [7,8,9]. Foerderer et al. [10] argue that enterprise platforms are complex and with wider range of functionality compared to consumer platforms. This can be seen also in the diversity of the stakeholders as described by Petrik and Herzwurm [11]. The complexity is reflected in platform governance where governance actions are not only bilateral but involve representatives from major stakeholders [8, 12].

Platform governance actions often affect the scopes of information systems within an ecosystem. The extant research on digital platforms has concentrated on questions like how boundary resources are tuned [13], when does a platform leader absorb functionality from the periphery to the core [14], or dependencies between the components of an ecosystem [5]. These approaches typically focus on one or two distinct architectural elements at a time, missing a holistic point of view. The implementation location of software features is an aspect that has been addressed only indirectly. There is a research gap in studying what drives the implementation of new features into a certain location, when interconnected information systems are linked together through a digital platform.

We drill down to a setting where a B2B digital platform was created to serve contractors working for large forest companies in Finland. The three large forest companies sensed an opportunity and designed a business model [15], thus transforming the industry with a platform [16], while being also the future customers of the platform. They made the initial governance decisions [1] and then chose a software company for the implementation and operation of the platform. An ecosystem has formed with the software company as the leader [17].

This platform portrays the intricacies of a B2B ecosystem [7, 8]. Around the core there are multiple peripheral systems. The enterprise systems of forest companies provide a wide range of functionality for wood procurement and logistics. The control systems of forest machines used in operating the machines play another major role in the ecosystem. Although these information systems are at the periphery from the platform core point of view, they are full-fledged information systems serving important operative purposes. These purposes are realized as work systems, including humans and machines that work using information and technology to produce specific outcomes [18]. The work systems are separate for the stakeholders such as the forest companies and the harvesting contractors, yet dependent on each other.

When a new development need is recognized, it is not always evident where it should be implemented. In platform terms, the line between generic core and diverse periphery may not always be clear. We complement the existing research on digital platforms with the following research question: how are new features and their implementation situated in a platform ecosystem? Our study complements existing research on platform architecture [19, 20] by describing structures and a classification involved in the process of feature demarcation: finding a location for a new feature.

2 Background

2.1 Architectural Decisions in Platform Governance

An ecosystem can be observed from different perspectives, with Moore [17] as the seminal study in business ecosystems describing actors and evolutionary stages. Software ecosystems have various definitions [21] and digital platforms are often discussed together with ecosystems. The relationship of these two concepts is sometimes ambiguous, though it has been elucidated for instance by Hyrynsalmi [21]: a platform acts a “central technological base for the actors of the software ecosystem”, a definition we will follow.

A digital platform has a core that contains functionality fundamental to the ecosystem; it provides the stable and generic elements to be reused by the peripheral systems that provide the variability for the ecosystem [4, 5, 20]. The borderline between a core and a system residing in the periphery can be crossed with boundary resources that the leader provides for the others to build on [3]. To manage the software development activities connected to the platform, the leader can apply different tactics with boundary resources, to maintain a balance [22].

The extant model of a core and its periphery describe the essential mechanisms of digital platforms [5], yet it may not completely explain the complexity in modern digital platforms [2]. Boundary resources represent a key aspect of platform development, dynamics, and value creation [13], but the variety of stakeholders present in a B2B setting can also affect the diversity in development. The scopes of information systems and their boundary resources are under adjustment. In the existing research these scope changes are observed from the boundary resource point of view [13], as instances of the platform owner replicating existing functionality from peripheral systems into the platform core [14, 23], or strategic decisions typically made by platform owners [24]. A platform owner can limit the complementors’ use of interfaces [22]. This is an example of the architecture-related decision making reserved exclusively for the owner [20]. Also non-focal actors have their role in the governance actions and decision making [25].

Another stream of research has focused on the relationship of the core and its periphery. Murmann & Frenken use the concept of pleiotropy to define the core and the periphery: a component is a core component if changes to it have greater effects to the system as a whole, compared to peripheral components where changes have smaller effects to the whole [26]. Interdependencies of the core and its periphery are not constant, the elements affect each other and their relationships develop over time [5].

There is unquestionably value in observing the scope changes or the relationships between architectural elements, but the implementation location has so far had only a minor role in research. However, the location, as a technical property of the ecosystem, is also related to value cocreation [2], justifying further research. Yet value cocreation studies like [7] have not explicitly addressed the question of feature location.

When multiple stakeholders are involved as actors in mature information systems as in large B2B contexts, the setting becomes more complex [10]. Another approach to complexity and location is through the viewpoint of work systems. Actors – both humans and machines – “perform work (processes and activities) using information, technology, and other resources to produce specific product/services for internal or external customers” [18]. In our case there are overlapping work systems: wood buyers purchasing timber with the help of their enterprise systems and contractors using forest machines and control systems to harvest wood. As the work systems overlap, it is not always clear, in which information system a new software feature should be implemented.

As platform governance is about making decisions, we continue this discussion by bringing in the location aspect: what feature gets implemented where and on what grounds. We refer to this decision of implementation location as feature demarcation. The architectural structures involved in feature demarcation are viewed together as a continuity, instead of observing the core, periphery, or boundary resources separately.

2.2 Digital Platform as an Industry Solution

Forestry is a significant industry for the Finnish economy. The market is characterized by large forest companies buying wood from forest owners, contractors of different sizes working for the wood buyers, forest management associations, and coordinating organizations. The industry has a long history taking advantage of information technology; the first information systems were introduced in 1970s [27].

Each stakeholder has their proprietary information systems: forest company specific systems are connected to the control systems of forest machines, different for each brand. This has created complex combinations of software and hardware in an industry where high-level processes are similar across different companies. The forest companies operating in Finland have outsourced most forestry operations to their contractors. The contractors are becoming bigger and this trend is likely to continue, with smaller companies facing more profitability problems than larger ones [28]. Contracting for multiple wood buyers concurrently has been cumbersome; it has required a dedicated information system for each wood buyer. At the same time, the role of a contractor is changing from simple outsourced work to a wider set of responsibilities, including detailed planning of operations, follow-up, and reporting. Existing information systems have not supported this shift well: essential features are located across different information systems or even missing. This has created overhead to contractors’ business, but also redundancy in the development efforts of the wood buyers – each large buyer has developed and maintained solutions independently for similar problems.

When the wood procurement systems of some of the large forest companies operating in Finland required renewal, they started a joint project to optimize their business processes with contractors. Instead of creating new company-specific systems, they aimed for a common digital platform that would tackle the complexity in the information systems landscape and respond to the challenges arising from the changes in the industry. With a common requirements specification and a public procurement, the wood buyers chose a software company for designing, implementing, and running the service, henceforth “Forestry Platform” (FP). In this process the software company also became the owner of FP.

3 Research Design

Digital platforms can be seen at least from the technological, economic, and organizational perspectives [2, 29]. The decision on the location of a feature is linked to all of these, but we did not have any single explaining theory or idea in the beginning of our flexible study. With the focus on a single platform, our aim was to understand the phenomenon in its natural environment, through a socio-technic lens by using interviews and publicly available documentation. For this setting grounded theory as the research method is a good fit [30]. When our research progressed, the concepts were derived from the data, further justifying the use of grounded theory [31].

The primary data source was 31 semi-structured interviews performed between February and August 2021. Interviewees were selected to cover the variety present in the stakeholders. We started by identifying key actors: the founding wood buyers. The interviewed wood buyers had an active role in FP development and/or deployment. They were involved in different levels of governance: both decision makers and subject matter experts. People from the founding wood buyers were interviewed as well as those from companies that joined FP later, to capture the characteristics of wood buyer competition and cooperation. To understand the dynamics between large wood buyer companies and their contractors, we reached out to various kind of contractors: different types of operations (harvesting or silviculture) and different sizes of the contractor company. As wood buyers have differences in their operation, which also affect the ways FP is used, care was taken to select contractors that work with different wood buyers and with multiple wood buyers at the same time. The selection of interviewees was in some cases continued with a snowballing technique. The list of interviewees is provided at https://bit.ly/3yv6ApW.

Additional data sources comprised of publicly available documentation: machine manufacturer web pages, webinars, and a podcast episode about digitalization in forestry. Two communication standards provide the foundations for technical boundary resources that FP offers [32, 33]. A set of regulations created by the Finnish Forest Industry sets the rules regarding forest machine data ownership and use [34].

Semi-structured interviews with open questions were suitable for the flexible nature of this research. The questions were grouped around four themes: the idea of FP, day-to-day operation, development, and the community around FP. The questions are available at https://bit.ly/3I2pdV7. The themes provided room for elaborating when necessary [35]. Interviews were performed by the first author; the questions and the invitation letter including the informed consent [35] was checked in advance by the second author. The interviews were done remotely due to COVID-19 restrictions, recorded and transcribed. The length of the interviews varied from 0:17 h to 1:23 h, with the average of 0:51 h.

The first author has worked for FP owner in various roles in the development and operation of FP from 2013 to 2020. Built into the grounded theory is the idea of finding and hearing the voice of people that are studied and not let the researcher’s biases and assumptions take over [31]. The second author of this paper is a safety mechanism when trying to control the assumptions and biases of the first author. Without any prior connection to FP, it is easier to point out reasoning that is not grounded on the data.

Data sources were imported to a software tool for qualitative analysis, Atlas.ti 8. This tool was used for all the research work; analysis and coding were done with it by the first author. Coding followed the practices of grounded theory: no a priori coding scheme, codes and concepts emerged from the data [31]. While collecting and analyzing data it became evident that with new features it was often about the location within the ecosystem. Starting from a list of new features we then moved gradually to the setting where the development of a new feature takes place. In other words, moving from topics to processes as suggested in [30]. Interviewees were aware of system boundaries and the location of a new or improved feature within the ecosystem. For example, interviewee #15: “For contractors … [in the current planning application] handling a great number of working sites is not very fluent, it needs to be improved.” This was coded with “Improved contractor planning”, which belongs to the category “Developing functionality into the core”. Figure 1 shows examples of how new features were coded and how the demarcation classes emerged. Finally, from these categories we arrived at the process of finding an implementation location for new functionality within a digital platform.

Fig. 1.
figure 1

Examples of coded new features and the categories.

Full size image

4 Findings

4.1 Structures for Feature Demarcation

FP connects large-scale enterprise systems and control systems of heavy machinery. The platform core contains the functionality needed by all the stakeholders and it consists of two parts: client applications and an integration solution. The FP owner has retained the development of all the core client applications to itself.

Various external systems integrate with the platform core. Wood buyers have their own enterprise systems. Each forest machine brand has its own control system that is used to steer a machine: a harvester to fell and cut trees and a forwarder to transport the logs to an intermediate storage. The third type of an external system is an excavator information system that is used by those contractors who do mechanical planting of seedlings. Both forest machines and excavators are heavy machinery, but a forest machine cannot operate without a control system, while an excavator can. The latest external system connected to FP is the National Forest Inventory data. It is collected by the Finnish Forest Centre (FFC) and used by many stakeholders in planning forestry operations.

Each type of external system serves primarily a selected group of stakeholders. The enterprise systems are used only by the employees of a wood buyer company and in practice have very little or no similarities in functionality with FP core. Control systems of forest machines may have some overlap with the features present in FP core. Contractors use both FP core applications and control systems; in most harvesting operations these systems have a symbiotic relationship: one cannot function without the other.

The work systems of wood buyers and contractors meet at the FP ecosystem. The symbiotic relationship of the core and the control system is an example of the dependencies between the work systems. These dependencies are realized in the architecture as bridges: connecting entities that allow for the data transfer between an external system and the core. A bridge is based on either a technical boundary resource provided by FP, or an interface defined by an external system. While platform architecture focuses on the core and periphery, a bridge is about the interaction of two equal systems that serve different purposes. The bridges in FP are the interface for enterprise systems that is based on the Finnish Forest Data Standard (FFDS) [32], the interface for control systems defined by the StanForD standard (SFS) [33], and a custom json based interface for the excavator information system.

Together the core, the external systems, and the connecting bridges form the structures for feature demarcation. These structures are described in Fig. 2 along with the demarcation classes, that are discussed in detail in Sect. 4.2.

Fig. 2.
figure 2

Overall view of feature demarcation elements and classes.

Full size image

4.2 How is the Location of a Functionality Decided?

We define feature demarcation as the process where the location of a new functionality is decided within a digital platform. We found that the functional features in the ecosystem can be located at FP core, at external systems, or at the bridges that connect the core and external systems. Once a new functionality has found its place, this location becomes the demarcation class of the feature. The class is based on demarcation structures presented in Fig. 2. What happens in practice depends on the governance structures and mechanisms of the platform. The decision making can be guided by various objectives. For example, several interviewees representing the wood buyers mentioned that FP should primarily serve contractors. Interviewee #18 summarized: “The way I see it [FP] must be a tool for the contractors also in the future and for us [wood buyers] it is just a secondary tool”. This concept was coded with “for contractors”. Examples of each demarcation class are described in the following.

Core Feature.

In this demarcation class only FP core is changed, meaning one or more of the applications provided by the platform owner. This type of development benefits the largest user group, it is within the common interest of all stakeholders, and the data and operations that make up the feature is contained within the core. These attributes make it easier for every stakeholder to accept this type of development as something that naturally belongs to the core.

An example of this class is a major new feature mentioned by several interviewees: improving the FP planning application. Planning the operations is in the heart of the contractor business and thus of critical importance for the contractors. According to interviewee #11 the current application in FP core has eased their work considerably by providing a single tool: “earlier on it was quite a mess with working sites for the same region from different wood buyers in many different systems.” However, as the number of working sites has increased significantly, creating and updating the work schedules of forest machines becomes difficult with the current implementation. Interviewee #2 describes a key requirement for a new core feature: “when there are changes [to the working sites], it should be very easy to adjust schedules of the machines especially in the calendar … or in the map view, they are used quite a lot”.

This type of issue is not easy to solve outside the platform core as the contractors perform their planning there. The number of working sites depends on the business volumes and processes of a wood buyer. As the sizes of contractor companies and their operating volumes grow, the solution for this problem becomes more important for both the wood buyers and contractors.

Mantle Feature.

In a mantle feature, the scope is extended with changes to a bridge. The identified need contains something that cannot be implemented by just changing the core. There is data that needs to be exchanged with a specific external system. In this setting the external system itself does not need changes for the new feature. The external system provides the specifications for data exchange through the bridge, for example an API.

Several of the wood buyer interviewees mentioned an example of a mantle feature: a connection from FP to the national forest inventory managed by FFC. FFC provides an API for updating the forest inventory data. From the FFC point of view having access to the data provided by harvesters will improve the overall data quality and shorten the data update cycles. FP is a natural choice for sending inventory updates as it has already the data from several wood buyers. Interviewee #30 (FFC representative) describes the benefits of the approach: “I think having a single interface with FP that provides the data from three wood buyers is simpler compared to having three different interfaces.” Instead of making changes to three different external systems, a new mantle feature was seen as an apt solution. The wood buyers argued for the implementation as part of FP, resulting in a new bridge. Although the bridge is currently one-way from FP to FFC, the bridge provides a foundation for future development efforts as well, especially for reporting other forest related information to the government: “I think it [FFC connection] will be expanded in the future … We will likely report to authorities [via it]” (interviewee #29).

End-to-End Feature.

Sometimes a development request or an identified need requires changes not only to FP but also to a bridge and an external system, in other words end-to-end in respect to how data travels across the ecosystem. Bridge contribution – a new bridge or a modification to existing – is necessary but not sufficient; it must be accompanied by changes to the external system.

An excavator information system connection is an example of an end-to-end feature. To remove manual work and automate the data transfer a new bridge was designed along with the corresponding changes to both FP core and the excavator information system. The software company sees its role as an enabler with a mantle feature. This new functionality benefits the large group of contractors that have excavators working in mechanical planting as well as wood buyers. Interviewee #17 describes: “if we think about the [excavator information system] integration which was just released, we receive the data about planting from a system provided by another vendor, which creates added value.” Together the changes to the core, a bridge, and an external system replace the need for manual data transfer between different information systems. Changing only a single system would not have introduced the same benefits for the users.

The integration with excavator information system is the first new bridge defined by FP owner after the implementation project. It is also an example of reciprocal data exchange: FP grants the external system working site specific data and receives in return data about the seedlings.

External Feature.

Demarcation is also about leaving features out from the platform; not everything in forestry operations belongs into the core. If the data and operations are not necessary for the contractors, and a feature would not be of interest to a large user group, a natural choice for the implementation is in an external system. In these cases, no bridges are required because there are no direct dependencies between the core and an external system.

Wood buyers have some differences in their business processes in the ways working sites are allocated for contractors – how much wood is expected from a certain contractor, in which time frame, and from which working sites. With some wood buyer there was a need to implement new functionality to support this level planning, for planners inside the wood buyer organization. Due to the double role of FP owner also as a provider of an enterprise system for the wood buyer, an additional implementation option was considered: building it into the core of FP, instead of an existing enterprise system. Also, the wood buyer considered this as interviewee #24 describes: “should it be implemented in FP or in our enterprise system. But after all our view was it should be a feature in our enterprise system, managers can consider that if I’ll send these [working sites] to that contractor, how much there is wood and how long it would take.”

After some discussion the FP core option was ruled out because the functionality is not something that the contractors require, and no data exchange is necessary between the core and the external system. The decision was internal to FP owner, but the rationale was common with some other examples of demarcation presented here: FP development should be aimed primarily for the benefit of the contractors.

Undecided.

In some cases, there are arguments for implementing a feature in FP core or leaving it to an external system, with modifications to a bridge that connects them. In these cases, the functionality is useful for most user groups, but its location is not yet clear. Something similar may already exist in an external system.

The undecided class of demarcation seems especially typical with control systems of the forest machines. Some wood buyers and contractors perceived implementing something that already exists in a control system into FP as a waste of money, and with the slow development speed of FP core it would take too long. Viewing from the other side, a machine manufacturer saw the potential synergy in not having to implement some features that exist already in FP core: “This is an important deliberation, so that we don’t create solutions that overlap [with FP], in vain, but instead solutions that work well and data is transferred when necessary, in both directions.” (interviewee #31).

A prime example of this class is the optimization of forwarder work, including planning optimal routes, map-based log collection, and reporting features. Related functionality exists in more than one control systems, with some differences between machine brands. Also, FP has its version implemented in the core, but the direction for future development is not yet set. Control systems are manufacturer-specific, and they support only machines of that brand. FP is intended to support all machine brands that use the SFS standard [33]. While a useful feature exists in a control system, it is available only for the portion of the contractor’s fleet that are of the same brand. This is an issue if a contractor has machines of multiple brands, which is often the case, as explained by interviewee #20: “Machine manufacturers have made applications that are very suitable for forwarding work. But it should be kept in mind that there are a lot of contractors that operate with different brands of machines and older machines where these applications may not work but FP works.” With a mixed fleet – using machinery from different manufacturers concurrently – having similar features in FP creates value for a contractor.

5 Discussion

5.1 Complementing the Architectural View of Platforms

The feature demarcation classes present examples of why different types of development needs have been implemented in different parts of the ecosystem. They differ in their scope of changes, the way data traverses across the ecosystem, and what user groups are served. When the data flow is contained within a single element of an ecosystem, the identified need is solved within that element. When data is exchanged between systems, the bridges are involved, and development is either a mantle or end-to-end feature. Characteristics of these different demarcation classes are summarized in Table 1.

Table 1. Summary of demarcation classes.
Full size table

In the extant literature platform architecture is typically described with partitioning to core and periphery [19, 20]. These architectural elements were discovered also in our analysis. They emerged from our interview data as a side stream of the feature demarcation process. We supplement the extant architectural view of core and periphery with the introduction of a bridge between the two elements. A bridge can be based on boundary resources [3] but also on an interface defined by a complementor. The extensibility that is characteristic to platforms [1, 2, 19] can be built on instruments provided also by a non-focal actor in the ecosystem [25]. This characteristic of the bridge reflects the complexity present in B2B ecosystems [7, 10]. Furthermore, a bridge connects the work systems of the wood buyers and the harvesting contractors [18], which represents another approach to observing a platform ecosystem. The core-centric view can be juxtaposed with a setting where the relationship of information systems is more evenly balanced: one does not merely extend another, but they complement each other.

5.2 The Importance of Location

As an artifact has a design space consisting of “all possible combinations of alternative choices along its dimensions” [26], finding an implementation location for a new feature can be viewed as a choice within the design space of a platform ecosystem. While decision making in digital platforms has been studied from firm boundary and governance perspectives [22, 36], choosing the implementation location of a new feature has not received wide attention, even though technical properties play a role in value creation [2]. The question of an implementation location is about the scopes of information systems. This far scope adjustment studies have mostly observed platform leader actions [13, 14, 24], typically leading to the competition of the leader and the complementors or even aiming at the supremacy of the leader.

Yet this is not all that happens with locations and scope. We broaden the view with complexity of the ecosystem and heterogeneity of stakeholders [10, 11] that are typical in B2B settings. Software development by different stakeholders takes place in different locations, and not all decisions are made by the platform leader. In this context decision making can be described as separate practical choices lacking a strategic vision. This is particularly relevant in an ecosystem that is still in its early phases, with value creation and sharing protocols not yet settled [36].

The feature demarcation is linked to value creation – the location matters. The significance of the ‘where’ aspect in a B2B digital platform is based on two factors. First, it is important because of the limited value creation possibilities due to the semi-open nature of the platform. The stakeholder owning the implementation has access to the revenue that the implementation generates, and without agreed value sharing protocols it is not shared. Second, an incorrect decision on the implementation location leads to waste. Limited development resources should be used in a way that they provide the most value for the largest user groups of a digital platform.

5.3 Aligning Interests

The winner-takes-all condition may not apply in all B2B contexts [8]. Borders between systems can remain, and the significance of aligning interests increases. Foerderer et al. [10] describes how evolutionary dynamics can maintain boundaries based on “conflicts of interest and strategic misalignment” between platform owners and complementors – something that we observed as well, especially with control systems, where same user groups and similar features like working site planning and assisting the machine driver increased the competitive tension between the stakeholders.

Even with the conflicting interests there is a need to understand the value chain and avoid redundancy. It can be challenging due to various reasons; in our interviews both FP owner and machine manufacturers reported that finding the borderlines is approached on a case-by-case basis, without a long-term strategy. This kind of lack of predictability in a dynamic environment is similar to challenges reported by Hodapp et al. [36]. Carefully planned decisions on feature locations can help in aligning different interest of stakeholders by positioning software development in the ecosystem. This can be based on data flows in the ecosystem. The data can be contained in a single information system or it can move across boundaries. Another option is to look at user groups that the functionality would serve: are they large or small, focal or non-focal. Taking this to a more general level, feature demarcation is also about seeking a balance in a B2B ecosystem.

5.4 Limitations and Future Research

The development in and around FP is still an ongoing and extending set of activities and in this study, we have taken a snapshot of it. Regarding the internal validity of our research, we tried to mitigate risks by interviewing an extensive set of different stakeholders, including six different persons from the owner of FP. A feature of this study was the first author’s previous experience in working at FP owner. The second author acted as a safety mechanism that questioned too hasty interpretations. The previous experience gave a common language to the interviews which helped understanding the interviewees and thus reducing the threat to construct validity.

Studying the enterprise system side was limited to systems whose vendor is FP owner. This may mean that we have missed some demarcation issues between the core and an enterprise system. However, in our analysis it became clear that the border between FP core and control systems is a hot spot; both a machine manufacturer and FP owner refer to this sector of demarcation in their interviews as very topical. We have only begun to explore the area; it deserves further research.

The B2B context presents opportunities for more research about the location-related questions. There are heavy industries with similar structuring of stakeholders – for example mining – that could be observed to deepen the understanding of how features are located. The automotive industry is often mentioned as an example of digital platforms gaining more importance, and it could also be an attractive candidate for future research. Possibilities for further studies also include an in-depth look on the interaction of enterprise systems with digital platforms.

Finally, the feature demarcation has been viewed here in the software development context. The companies involved in FP have extensive support functions. Another potential research avenue is to apply demarcation concepts there as problems and support cases can cross organizational boundaries.

6 Conclusions

The digital platform we have observed presents an example of finding implementation locations for new features. The interviews and publicly available documentation provided a rich data set to study the architectural aspects of a B2B digital platform. Using the grounded theory method allowed for the emergence of feature demarcation: how do new features find their implementation location within a digital platform. Finding a location for new functionality was in the heart of the platform from the very beginning. Replacing parts of the wood buyer legacy enterprise systems with the core of the new platform was the first feature demarcation.

We contribute to the digital platform research by providing tools for identifying an implementation location of a new feature. The implementation location can be at the core of the platform, at one of the external systems, or at a bridge that connects the external system to the core. The demarcation structures complement the existing architectural research by introducing a bridge, and by offering a view where the entities in a digital platform ecosystem are observed as a continuum instead of distinct entities.

The structures for feature demarcation are the basis of the demarcation classes that describe the scope of software changes within an ecosystem. When data stays within a single information system, the development is either about core or external features. When data is transferred between systems, the bridges are needed, and development is either a mantle or an end-to-end feature. The undecided class of feature demarcation is about features for which it is not yet clear where or by whom they should be implemented.

Feature demarcation is one of the coordination activities that shape value co-creation in an ecosystem around a digital platform. The implementation location is important as it can have a direct effect on revenue. Looking at the demarcation classes, data flow, and the division of work helps in understanding the circumstances of a platform leader and complementors.