Keywords

1 Introduction

At the start of the TOOP project [1], the state of the Once Only Principle (OOP) in the different Member States (MS) was very different from the points of view of policy, organization (of public administrations), technology and infrastructure. The participating piloting MS found themselves at various levels of “maturity” regarding general awareness of the Once Only Principle (OOP) and the implementation of procedures, organisations and infrastructures to support this principle at the national level. Concrete experiences and developments at the international level were almost exclusively limited to bilateral interoperability agreements between nations already closely tied politically, economically and culturally (e.g., Scandinavian countries, Benelux, etc.) as well as domain-specific interoperability initiatives not centrally aimed at implementing OOP (e.g., eProcurement, BR domains).

Countries which already had some degree of national standard – architecture and infrastructure in accordance with national legislation – included Estonia, Slovenia, Italy, Greece, Sweden and Norway. Except for the Scandinavian cases, these systems were neither interconnected nor even aware of each other. They served national purposes of data exchange between public administrations with varying degrees of emphasis on creating benefits for citizens, businesses and the administrations themselves. The European dimension was not yet contemplated.

Three pilot areas were chosen for the TOOP project. Two of these focused on cross-border exchanges of company data, one in the context of cross-border services (Pilot Area 1: Cross-border eServices for Business Mobility) and the other on exchange of registry data (Pilot Area 2: Updating Connected Company Data). The third pilot area is inherently cross-border in essence (Pilot Area 3: Online Ship and Crew Certificates). The main criteria for their selection were cross-border relevance, potential to reduce administrative burden, and feasibility of implementation.

The pilot of cross-border eServices for Business Mobility was based on the assumption that government administrations from different countries expose eServices directed at Economic Operators from various countries. During the respective service provision company-related information is needed. The aim was to show how such information can be automatically retrieved from the Economic Operators’ country of origin without the business representative having to enter it again. Use cases include participation in public procurement procedures cross-border, extending business presence cross-border, administrations checking the mandates of business representatives.

The pilot of updating connected company data foresees a central role for the Business Registers. Company data are officially stored, at each MS level, in the Business Registers following the different European Company Law directives, regulations and national commercial codes. The data from the Business Registers are authoritative, up-to-date and have a recognized legal value. However, the same (or part of the same) data are also stored for other purposes by various public administrations in the same and other MS. Keeping these data up to date is a real challenge, especially when they are related to foreign companies.

The last pilot focused on online ship and crew certificates. The problem from OOP perspective with ship and crew certificates is that they are currently issued and maintained in paper format, resulting in delays in delivery to the vessel and extra costs.

The next section presents the TOOP pilot domains and the way the TOOP project worked towards piloting. Main achievements of the TOOP pilots are described in the third section. The fourth section presents the lessons learnt and the experiences of the different Members States. Main conclusions are presented in the last section of the chapter.

2 The TOOP Pilot Domains

TOOP followed an agile, iterative approach that starts from real user needs encapsulating the ambitions of pilot participants and proceeds by gradually building pilot prototypes that will ultimately result in production-level pilots capable of real transactions, which will be handed over to their owners in governmental organisations and businesses.

The starting point in the process was the compilation of use case descriptions in the form of motivational scenarios from the pilot coordinators together with the interested MSs, starting from the indicative usage scenarios identified during proposal phase when the selection of the piloting domains was done. MSs were closely involved in reviewing and validating the motivational scenarios. Each motivational scenario was subscribed to by several MSs. Taking into account the prioritizations of the MSs, six pilot use cases were identified in the three Pilot Areas (PAs):

  • PA1: Cross-border eServices for Business Mobility

  • eProcurement

  • Licenses and Permissions

  • Company Data and Mandates

  • PA2: Updating Connected Company Data

  • Business Register Data Provision

  • Business Register Interconnection

  • PA3: Online Ship and Crew Certificates

  • Online Ship and Crew Certificates

The pilot coordinators together with the MSs took the motivational scenario descriptions and followed business process modeling in order to model certain aspects that are important for arriving at the extraction of requirements. PA virtual meetings and face-to-face plenary sessions were opportunities to discuss extensively and finalize the results.

As a next step, pilot coordinators and piloting MSs, looking at the entire range of the motivational scenarios and engaging in a process of abstraction and synthesis, a conceptual view of the once-only principle was created, the common patterns emerged and a more generic flow of events was described that depicts the generic data exchange that takes place along all the different motivational scenarios. These generic patterns were documented as Baseline Piloting Scenarios. Each motivational scenario can be projected to the generic flow of the baseline scenarios.

As a last step in the pilot design process a deployment architecture was created which was necessary for the development and rollout of TOOP-compliant common components, and a rollout and implementation plan was made available, featuring the main milestones expected for the project implementation.

Starting from the motivational scenario description and modelling, MSs committed to their national piloting scope and produced a pilot plan including all information necessary to understand who will pilot what, and what should be expected from each country in terms of functionality and infrastructure.

Each MS pilot plan included:

  • the scope and ambition of the piloting MS including description of the national pilot scenario(s) by making reference to the Motivational Scenarios already described in the Pilot Areas but providing the national versions and possible variations and actual actors involved, and information on the data provider capability targets and data consumer functionality and system(s) to be connected as well as the data type(s) the MS intends to consume from TOOP,

  • the motivation and goals providing a list of national goals to be used for post-pilot evaluation later in the project and why the pilot is important for the country, what are the national priorities and policy objectives to be met and what is the value expected for which stakeholders,

  • the implementation strategy with details on organizations involved nationally and their role, and commitment of all relevant stakeholders, tentative planning of implementation anticipating also aspects of national readiness or dependencies on other European initiatives, and overall feasibility of the pilot including the main risks at national level but also at project level that may be factors that influence the execution of the pilot plan.

As the project was moving towards implementations that have specificities relevant to the business domains, domain ownership was needed and relevance to be manifested within the project and visible outside the project by domain stakeholders which include different MS organisations and different EC policy units. Therefore, the project decided to consider the approach of Working Groups (WGs) that complements the original approach referring to Pilot Areas (PAs) and does not contradict or substantially modify the original rationale of targeting pilots. It merely extends it, as a natural step in the evolution of pilots. PAs were use case-oriented, whereas WGs are business domain-oriented. The WG view relates to business domains where the legal basis is different, and this makes a difference in requirements, implementation, and future governance proposals when the pilot results are delivered to the MS but also the business domains.

The direct mapping from PA use cases to WGs can be seen in Fig. 1 below.

Therefore:

  • The eProcurement WG includes the eProcurement from PA1.

  • The General Business mobility (GBM) WG, which aligns well with the part of the proposed Single Digital Gateway Regulation (SDGR) that concerns company-related data includes two use cases from PA1: Licenses and Permissions and Company Data and Mandates; and two use cases from PA2: Business Register Data Provision and Business Register Interconnection.

  • The Maritime WG includes the Online Ship and Crew Certificates from PA3.

Pilot implementation has the following dimensions which are specific to business domains, as reflected in the WG view:

  1. a.

    Business stakeholders are different.

  2. b.

    Data modelling is domain-specific and therefore WG-specific.

  3. c.

    Transaction patterns are also domain-specific, hence WG-specific.

  4. d.

    Connectathons (cross-border testing events) have WG-specific scenarios due to differences in data and transaction patterns. Testing happens among implementers within each WG even though some (e.g., Business Registers) may belong in more than one WG.

Fig. 1.
figure 1

Mapping from Pilot Areas use cases to Working Groups.

Full size image

The TOOP pilot activities were therefore organised according to domains of interest defined by the business services they wished to enable: the eProcurement WG was a specific area created around eProcurement procedures (already an area of international interoperability development) and the Maritime WG was a specific area in the Maritime sector; the GBM WG was a more general area concerned government services promoting the European mobility of companies and their services.

Different MS piloted in the three workgroups. There were deviations from initial commitments, as changes in political and organizational priorities, changes in responsibilities, shortage of personnel, delays in tendering and choosing subcontractors had as a result some MS not to finally pilot in the workgroup they had initially committed. Subsections 2.1 to 2.3 present more details regarding the piloting workgroups and the MS that finally piloted.

2.1 eProcurement Pilot

The eProcurement Pilot intended to use the TOOP infrastructure in order to demonstrate how the provision of evidences during an eTendering procedure can be simplified. More specifically, the use case focuses on the automatic retrieval of the necessary evidences for a specific Economic Operator (EO) using the existing national European Single Procurement Document (ESPD) [2] or an eTendering Service implementing the ESPD. The pilot describes how an ESPD system can integrate the TOOP infrastructure to facilitate the discovery of designated data providers and evidence and send the relevant requests to retrieve the necessary information through the TOOP architecture. The retrieval may take place at any phase of the process (pre-award, award or post-award).

The provision of evidences to selection and exclusion criteria of a public procurement may be cumbersome for businesses and discourage them from participating. According to the Public Procurement Directive 2014/24/EU [3], when being awarded, an EO must provide all required evidences (declared in the ESPD at the phase of participation) in order to conclude contract with contracting authorities. Moreover, the contracting authorities can request at any time the provision of all supporting documents in order to proceed with the award and/or the contracting procedures.

Providing a pre-filled version of the ESPD may make this process more easy and less time consuming for both the EO and the contracting authorities. According to the use case, the required evidences will be automatically retrieved by the competent authority (business registry or aggregation/pre-qualification service) of the country in which the tenderer is registered. Thus, businesses will no longer have to upload information, already provided in the past, directly by their local IT infrastructure since data will be provided directly by the business registry. Moreover, the contracting authority can choose to be notified each time there is a change in the tenderer’s situation. Finally, since data is provided by an authoritative source it will be reliable, trusted and have legal validity.

The Data Consumer Agencies that participated in the eProcurement pilot in TOOP consist of the Directorate for Management, Development and Support of the National eProcurement System in Greece, Italian National Anti-Corruption Authority (ANAC) from Italy and in Germany the University of Koblenz which developed an ESPD system that can be used by Economic Operators and Contracting Authorities to request, reference and validate evidences through evidence metadata.

The Data Providers that participated in the eProcurment pilot in TOOP included BR from Norway providing company information, the Register of Financial Statements from Slovakia and AFRY (pre-qualification company) from Germany as a prequalification body providing evidence information upon request.

The following Table 1 presents the MS that initially planned to pilot either as DC or DP or both DC and DP in the area of eProcurement. The MS that confirmed their intentions are marked as YES, and the ones that were not sure are marked as TBC (To Be Confirmed).

Table 1. Overview of MS planned to pilot as DC and DP in eProcurement.
Full size table

Table 2 presents the MS that finally piloted either as DC or DP or both DC and DP. The MS that reached technical readiness and participated in connectathon are marked as YES, the ones that did not pilot are marked as NO, and the ones that worked on their pilot but did not manage to participate in a connectathon for various reasons are marked as PARTLY.

All MS that planned to pilot as DC in eProcurement participated in the eProcurement pilot. The ones that were not initially confirmed, finally did not pilot. From the 5 MS initially planning to act as DP, Romania did not connect as DP due to lack of resources. Italy started the deployment but did not have enough time to participate in the connectathon.

Table 2. Overview of MS piloted as DC and DP in eProcurement.
Full size table

2.2 GBM Pilot

The GBM WG had clear relations with the initiatives spawned by the European Services Directive [4]. Additionally, the TOOP services investigated in the GBM pilot were chosen with specific attention to those requiring data provision from cross-border Business Registers, in order to exploit the previously developed relations between EU BRs and the EU regulations on BR data exchange.

During the course of the TOOP Project, developments in the GBM pilot proceeded in strict symbiosis with the evolving Single Digital Gateway (SDG) initiative – the regulation, itself [5], as well as the conception and specification of the national and European organisations and infrastructures supporting it.

The main roles that TOOP Partners play in the GBM scenario are:

  • Data Consumers: Public agencies offering services to companies – both domestic and foreign – in compliance with regulations governing the promotion and exercise of business activities, or the establishment of businesses and services, in their territories.

  • Data Providers: Business Registers, or equivalent government-mandated authorities, that are “officially responsible” for maintaining and distributing company information required to identify and authorize the Economic Operators which are subjects of the DC services.

  • Technical agencies serving DCs and DPs: Agencies organized to serve specific administrations or agencies already charged with a transversal role in managing or interfacing National OO-Layers.

The most frequent Data Consumer Agencies represented in TOOP consist of Points of Single Contact (PSCs) for example from Slovenia and Poland. Other Data Consumers are the Tax Agency in Sweden, the Directorate for Management, Development and Support of the National eProcurement System in Greece, business Portals from Austria, Estonia and Norway. Some of the services which they offer are business registration, licenses, and other different services regarding business mobility.

The Data Providers are primarily BRs providing company information included BRs from Sweden, Norway, Italy, Estonia, and other government portals from Austria, Poland, Romania, Slovenia, and Slovakia, dealing with business promotion and regulation.

Some other actors involved in the provision of TOOP-enabled services are legal persons, the subject of the TOOP-enabled service; the authorized representative of the Legal Person; eID providers and other EU and National infrastructures for security, payments, translation, etc.

The goals of all these actors, almost independent of their roles in OO processes were established early in the project and confirmed at several checkpoints along the way as:

  • Reducing administrative burden for companies and citizens (Legal Entities) required to use cross-border DC services;

  • Increasing the efficiency of these services – saving time and costs for both subjects and administrations (Front-office and Back-office operations);

  • Automating data retrieval and procedural interoperability between administrations resulting in improved data quality and better, swifter processing;

  • Increasing trust in administrative procedures – the right data furnished at the right place at the right time; reduced complaints or even lawsuits for damages caused by administrative errors;

  • Compliance with EU regulations and a more harmonized business marketplace.

The European dimension of the project made partners acutely aware of the need to use standard technical solutions and open specifications of architectures, procedures and interfaces. Strong preference was given to CEF building blocks and interoperability standards emerging from other EC initiatives. Such standards are being continuously re-evaluated and updated at all levels of interoperability: technical, semantic, procedural, legal.

The following Table 3 presents the MS that initially planned to pilot either as DC or DP or both DC and DP in the area of GBM. The MS that confirmed their intentions are marked as YES, and the ones that were not sure are marked as TBC (To Be Confirmed).

Table 4 presents the MS that finally piloted either as DC or DP or both DC and DP. The MS that reached technical readiness and participated in connectathon are marked as YES, the ones that did not pilot are marked as NO, and the ones that worked on their pilot but did not manage to participate in a connectathon for various reasons are marked as PARTLY.

Table 3. Overview of MS planned to pilot as DC and DP in GBM.
Full size table

From the 9 MS initially planning to act as DC, finally Italy and Romania did not connect as DC. Germany which was to be confirmed, finally acted as DC with an ESPD application consuming business data. Estonia (not initially considered in the planning) also connected its business registry as DC. Turkey due to legal restrictions did not continue piloting after the 1st year. The Netherlands are marked with partly* as they did not piloted with eDelivery but with direct API connection to Sweden and Norway and with an earlier model of the TOOP Exchange Data Model and did not continue to next releases.

Table 4. Overview of MS piloted as DC and DP in GBM.
Full size table

From the 11 MS initially planning or considering to act as DP, business registries from Greece, the Netherlands and Germany finally did not connect to the TOOP architecture.

2.3 Maritime Pilot

The aim of the maritime pilot was to fulfill the needs of a Port State Control Officer (PSCO) in the context of a ship inspection. Ship and crew certificates are today issued and maintained in paper format, resulting in delays on delivery to the vessel and extra costs. Certificate data exists in Maritime Administrations’ (MA). There are different associated problems:

  • The ship has to submit same certificate data for every port of call, e.g. ship submits the copy of the Tonnage Certificate, which is used for calculating port dues, pilot dues etc.

  • The Port State Control (PoSC) may not have enough time to check the certificates thoroughly during ship’s port stay or crew’s rest time is used for inspection, both resulting in increased risk of marine accident.

  • Withdrawn certificates are not removed from circulation, increasing the risk that “more favourable” certificates are being presented to the PoSC.

  • Falsification of paper certificates is rather easy.

  • Paper certificates are sent on board via courier service, which is costly (in most extreme cases, a ship may need to wait for paper documents to arrive via post up to several weeks) and an administrative burden. A ship may leave the port before the certificates arrives, thereby increasing the risk of the detention.

  • In case the vessel changes flag, the losing Flag State’s registry has to submit all relevant data to the receiving Flag State’s register. Such data is mainly concentrated onto ship certificates (Regulation (EC) 789/2004 [6] and IMO res. A. 1053(27) [7]).

The aim of the pilot was to provide a proof-of-concept that these problems can be solved.

The main roles that TOOP Partners play in the Maritime scenario are:

  • Data Consumers: The DC is the PSCO. The PSCO needs to get access to information about existence and validity of certificates and information within certificates. The required certificates are at least all the conventional certificates. In order to achieve this status, the Data Providers need to commit to providing all the required data services.

  • Data Providers: The DP (MA ship registry, MA seafarer registry, RO ship registry …) needs to provide all the information that is agreed that the PSCO requires.

The following Table 5 presents the MS that initially planned to pilot either as DC or DP or both DC and DP in the area of Maritime. The MS that confirmed their intentions are marked as YES, and the ones that were not sure are marked as TBC (To Be Confirmed). Table 6 presents the MS that finally piloted either as DC or DP or both DC and DP. The MS that reached technical readiness and participated in connectathon are marked as YES, the ones that did not pilot are marked as NO, and the ones that worked on their pilot but did not manage to participate in a connectathon for various reasons are marked as PARTLY.

Table 5. Overview of MS planned to pilot as DC and DP in maritime.
Full size table
Table 6. Overview of MS piloted as DC and DP in maritime.
Full size table

Out of the seven MS that planned to pilot as DC and DP in the Maritime pilot, the four made it to the successful connectathons. Bulgaria, due to delays in subcontracting, deployed both DC and DP capabilities as initially planned, but did not have the time to participate in Connectathon, therefore is marked as partly piloted. Greece also only partially implemented the pilot, as it encountered several difficulties, mostly related to the limited availability of online data for ship and crew certificates from the competent authorities holding such information in Greece, in paper from (a typical “network externalities” effect at the DP level). In addition, the ambivalence of the position of the government authorities has not favored the investment of specific resources in this pilot.

Latvia, due to unexpected technical and personnel problems, did not succeed to fully implement the pilot and take part in the Connectathons.

In the maritime domain, there was a good common understanding regarding once-only and semantic, organisational, legal and technical agreements on some elements and on some there was not. However, a more important question was whether sufficient business need was recognised by the participating organisations. The process the maritime domain focused on involved enough of sensed “pain” that it was quite easy to gather support for the initiative. This was also analytically confirmed in the process mapping exercise. As for all the interoperability elements, it was felt that these are not major hurdles. Since shipping is a global and historical domain there has been time to achieve a good common understanding on semantics. The organisation is there, EMSA and DG MOVE at EU level and IMO globally. Legally, the PSCO process is quite well defined both at EU level and at IMO. As regards technical aspects, there are systems existing at EU level, most notably the Thetis system. There was enough interoperability to deem the pilots’ quality goals achievable. During the project, this was confirmed. Once there was a platform to use, setting up the data exchange and testing whether it works was quite straightforward, without major issues.

3 Advances Attained in TOOP Pilot Domains

As mentioned above, the state of implementation and awareness of OO procedures was quite varied in the different Pilot Partner MS. Thus, different configurations of TOOP components/CEF building blocks were implemented according to the architectural needs of the Partners. Some partners were able to exploit existing local or national infrastructures to maximize benefits and reduce costs of implementation. The following diagram illustrates the different approaches to TOOP integration for the connection of DCs and DPs to the TOOP Federated network. Data Aggregators represent intermediate levels of implementation of OOP, for example in regional or domain-specific contexts (Fig. 2).

Fig. 2.
figure 2

Connection of DCs and DPs via the TOOP federation network

Full size image

In any scenario of cross-border business mobility, country A (origin) could be considered the MS where a company or a professional is registered and as country B (destination) the country where the company or professional wants to do business. If the DC and the DP are in different countries, then a variety of infrastructures may sit between them, each of the two countries will have a combination of national once-only layer, aggregators or ad-hoc pairings.

If we extrapolate to an EU-27 environment that is entirely heterogeneous, it becomes clear that in order to ensure DC-DP data exchanges and implement the OOP cross-border, either a lot of ad hoc connections must be made (not a scalable option) or a federated architecture must be put in place.

TOOP was established with one core objective: to define, implement and pilot a federated architecture that enables the discovery and interconnection of data providers and consumers, so that its instantiation into a cross-border infrastructure can be used to implement the OOP cross-border.

Having adopted a basic model to describe once-only data exchanges and established the need for a federated architecture, it is necessary to project these views onto the real situation in Europe, where:

  • Architectures are heterogeneous and infrastructures rarely interoperate even inside certain countries, let alone internationally.

  • There are already certain data exchange networks deployed or emerging at European level (e.g., BRIS, Tax Authorities, EESSI [8], PEPPOL [9] etc.)

The following figure paints the landscape within which TOOP came to design a federated architecture and deploy an interoperability infrastructure to facilitate DC-DP data exchange (Fig. 3).

Fig. 3.
figure 3

The TOOP piloting landscape

Full size image

The DP side is important, since it is important that data is accessible. In business mobility processes, where mostly company-related data are involved, there are three categories of data providers:

  • The Business Registers (BRs), which are a special category since they operate under their own legal basis nationally and at EU level.

  • Domain-specific providers or aggregators (e.g., in the eProcurement domain).

  • General-purpose data sources which are not Business Registers (other base registers).

Some of these systems may already be connected to cross-border exchange networks – the BRs are connected to BRIS. The eProcurement platforms are starting to be connected to PEPPOL, the tax agencies are also interconnected, etc. These networks are not interoperable among them – even networks such as BRIS and PEPPOL, which both use eDelivery, use it in different “flavours”. At the same time, each country has its own infrastructure (combination of national OOP layers, aggregators and ad-hoc pairings).

In such a complex field, it is generally not possible to exchange data between an eService sitting in a country wishing to act as a data consumer and the sources of data which are needed in a cross-border mobility scenario. Unless a system is already connected to one of the few existing international networks, it cannot communicate outside its country. Even the ones connected to the existing networks can only communicate within their silos.

In this wider landscape, the need for the federated TOOP architecture and infrastructure becomes even more apparent. In fact, it is important that it becomes a federation of federations, being able to pull data from the existing silos if it is more difficult to connect to the original data sources. In a world of national OOP layers that extend over the vast array of data provided and consumed in each country, it would suffice to connect these layers; but this is not enough at the moment as these layers are not as widespread as it could be wished for. For some data types it might be more efficient to link TOOP to an existing network (e.g., BRIS), thereby making TOOP a cross-federation infrastructure.

TOOP pilots came to explore these scenarios and come up with solutions on the technical and the governance levels, involving the MS participants and other institutional stakeholders.

The flexibility of the TOOP architecture permits all combinations of configurations simultaneously. The Swedish Tax Authority, connected to TOOP via a national OO Layer is able to request company information from the Italian Business Register, which is directly connected to the TOOP network, in the same way as it requests information from the Slovenian Business Portal, an aggregator which connects different government authorities.

In the maritime domain, during the TOOP project, EMSA and DG MOVE had developed an alternative data exchange system, where all ship certificates would be sent to a central repository that would serve the central Thetis system. Implementing TOOP in this situation would mean that there is no central repository and all data is exchanged directly between the participating countries. A central repository allows for more control and stability in the system as well as follow the existing model where EMSA is a central service provider to the maritime authorities. Implementing TOOP would have changed that organizational/ cultural setting. Though the EMSA approach only tackles ship certificates where the exchanged data is not sensitive. If at some point it is decided to start to exchange crew certificates, which may include sensitive personal information, a decentralized TOOP approach should fit better as it takes out a central mediator and leaves control and responsibility with the DP and DC.

4 Lessons Learnt

The existence of OO infrastructures in the different MS was usually an advantage for implementation of TOOP components and services, but there were still several factors involved. Although experience in integration and interoperability at the international level helped make MS aware of the different issues involved the state of the PA procedures and information networks still heavily condition the way that OOP could be implemented. In particular, traditional PAs and their information systems are designed for vertical, bureaucratic info handling with different info silos adopting completely different approaches to information handling and service provision. The “products” of these information silos – reports, certificates, profiles, etc. - are usually specific to the administration involved, using techniques language and even concepts not widely known and used in other administrations. This is why technical integration is so very different from true interoperability which requires seamless compatibility of procedural, legal, organizational and semantic entities.

Public Administrations in Member States which had promoted National OO Layers had already faced this issue of providing information, which was useful in other administrative contexts, but working at the national level means that there is still a common legal framework and a common bureaucratic culture of certificates, procedures and the basic language and concepts being regulated. The main source of interoperability difficulties arise from the “culture shock” that occurs when cross-border procedures meet.

To create useful, fully OO-enabled applications government agencies must not only abandon their own particular “mindsets” and adapt to the needs of other administrations, but they must embrace the concept of life-cycle processes for citizens and businesses and prepare their information products to support the critical life-cycle events they entail. This will involve deconstructing existing reports and certificates, but it is not just a question of providing direct access to elementary data items. Too much semantic information would be lost in such a case.

For the maritime pilot, some lessons learnt are presented below:

  • They partners should have “gone out of the building” before they started designing and building. While they talked to maritime authorities and business partners, they didn’t sufficiently talk to the European Commission to confirm that whether their MVP met the basic requirements of the customer.

  • The good thing is that the quality goals will most probably be achieved, even though through another solution. But, a centralized approach misses out on the possibility to implement other business cases, with other types of organisations (e.g. business registers, tax authorities, toll, police etc.) and is much riskier when dealing with sensitive information.

  • When developing a data exchange layer, the close collaboration between the platform team (Technical team in TOOP’s case) and the product teams (the pilots) is vital while the platform team needs to be the more active part.

5 Conclusions

Cross-border piloting in a large-scale pilot project is definitely challenging, especially, when there is a moving target. TOOP started as a far more exploratory project, aiming to define its perimeter, its architecture and its pilots and then disseminate and exploit its results and find whether there is impact. However, when SDGR was introduced, this meant taking into account the legal requirements of a new Regulation and building a solution for its implementation. The project and particularly the pilots in PA1 and PA2 had to shift focus. The project shifted to a project implementing specifications for regulation, and therefore the impact was assured, if the specifications piloted were close to the Implementing Act.

TOOP raised to the occasion and met its objectives as well as the expectations around its pilots. For this to be done, it was necessary to have a careful and meticulous project execution. The pilots were closely monitored and supported in order to ensure that they meet their goals. The tools and support that were provided by the technical team were highly appreciated by all piloting partners. Taking into account all the different updates and incremental releases, especially in the GBM WG, this would not have happened otherwise. A structured environment for onboarding and roll out was necessary.

It is also important to mention that TOOP piloting had a big impact on OOP solutions nationally and contributed to a faster development of national OOP-functionality.

It should be mentioned that in the maritime domain, although the pilots did not go further that the proof-of-concept, the pilot was a good catalyst for dialogs with the (primarily EU) maritime legal and business domain, but met constraints and did not find the required external policy and strategy support.

Concluding, cross-border piloting is a wonderful way to show the key problems and issues and how the real issues emerge then, and it allows to provide a concrete picture/solution of a before abstract legal text and give it a realistic future. This is the most important thing that through piloting, real complex change is possible!