Architecture Log

DE4A Architecture Log

#	Principle/Application collaboration	Implication/Exception	Discription	Use case/pattern
1	Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person	Implication: reauthentication	This principle assumes automated data exchange on the basis of automatic match of the used person eID with the unique identifiers used in the authentic sources. Automatic identity matching is not always possible and may require re-authentication of the users at DP.	SA1, SA2, SA3
2	Principle:Data minimisation	Implication: selection of the appropriate pieces of evidence	Multiple pieces of evidence of the same type can exist at a DP, for example when a student has two diplomas in different fields and only one of them is suitable to be submitted to the DC as part of the application.	SA1, SA2, SA3
3	Principle:Data minimisation	Deviation: additional data in evidence	Lack of common evidence schemes across EU means that more data than necessary might be included in evidence, e.g. certificate of completion of secondary education.	SA1, SA2, SA3
4	Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority	Implication: multiple authorities	The evidence can be stored at several places, for example universities issue diplomas to students, however the competent authorities for this type of evidence can also be national or regional registries of diplomas operated by Ministries or other relevant bodies.	SA1, SA2, SA3
5	Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority	Implication: single request	Member States can establish brokers that connect to different competent authorities, for examples those issuing academic (record of academic results) and non-academic (household status) evidence. In such cases, there can be only one request and transfer required for several pieces of evidence owned by different competent authorities.	SA1, SA2, SA3
6	Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person	Implication: sending an image for previewing	The DBA pilot focusses on exchange of structured and machine processable data. In some cases, for previewing purposes, the DC will present the user with the official document on screen as well. This is an image of the document the user is familiar with in current practise (like unstructured data in a PDF). As an implication of this architectural principle, the image should be integrated in the exchange of structured data. In other words, DBA expects the image to be one of the data elements in the evidence definition. The data provider should guarantee that the data incorporated in the image is identical to the structured data sent. Furthermore, the technical system should allow for swift transport of such images to prevent unacceptable waiting times for the user.	DBA1
7	Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person	Deviation: data is not concerning the user	This principle assumes the data exchanged is on the user itself and the user has authenticated with his/her eID. In the DBA pilots there are two deviations: 1.    The data exchanged is on the company and not on the user (the representative). 2.    Not in all cases the user will be authenticated, e.g. when updating company data after receiving a notification from the data provider. No matching of the natural person eID with the unique identifier from the authentic source is foreseen.	DBA1, DBA2
8	Principle:Only exchange of structured and authentic evidence that can be automatically and reliably be linked to the right person	Implication: company identification via eIDAS	It is of course crucial that information from the correct company will be provided. The member state identifying the company should provide a company identifier that the business register uses to identify the company as well. Translated to eIDAS: the eIDAS LegalPersonIdentifier should be the company identifier in the business register of the data providing member state. This way, the data consumer can send the eIDAS LegalPersonIdentifier to the data provider 1-on-1. The DBA pilot assumes no ‘company identity matching’.	DBA1, DBA2
9	Principle:Digital by default	Deviation: paper-based procedures are not accepted	This principle states ‘this does not mean that the user should be obliged to use the online administrative procedure’. This is obviously true for services to citizens, but not to companies. Some Member States, like NL, require companies to use digital services. Digital is not only default, but mandatory as well.	DBA1
10	Principle:One-Only Principle	Implication: re-design of customer journey	This principle states that multiple administrative procedures must be re-analysed in the context of the complete customer journey. Fortunately, this approach has been widely adopted by many Member States already for services to companies. Company portals (business portals / PSC) offer services to companies to be fulfilled by several service providers.	DBA1
11	Principle:Authentic sources under the sole control and responsibility of the competent evidence providing authority	Deviation: some authentic data will be copied	This principle states that data from authentic sources should preferably not be copied by the data consumer. In the doing business abroad cases, it is – for the foreseeable future – inevitable that basic company information will be copied. This information is needed for multiple services and service providers, at the time of use as well as later in the process. These DV processes cannot rely on external sources of company data fully. Fortunately, basic company information does not change often. To keep the company as updated as possible, the doing business abroad architecture defined two mechanisms for updating data: To keep the company as updated as possible, the doing business abroad architecture defined two mechanisms for updating data: 1.       Each time the user authenticates to the company portal, the company portal will retrieve up-to-date company data to check whether company attributes have been changed. 2.       When supported by the data provider: a notification mechanism from the data provider to the data consumer will be sent in case of a change in company data (subscription & notification pattern).	DBA1, DBA2
12	Principle:Mobile first	Deviation: desktop first implementation	Most of the administrative tasks performed by companies doing business abroad are performed using desktop pc’s. That will not change soon. The DBA pilot will learn from mobile design and implement mobile design elements whenever useful, e.g. implement a responsive design. But, in case mobile-first-elements may weaken the desktop-experience, the latter prevails.	DBA1
13	Principle:Data control by the user	Deviation: when updating company data, the user should not be in control	The subscription & notification pattern doesn’t involve users. In a sense, when notifying and updating in this pattern the user is not controlling the data at that point in time. Furthermore, sending data from the data provider to the data consumer is not necessarily in the interest of the user/company, e.g. when the company portal needs to be updated in order to prevent fraud, end financial support, impose additional taxes, etc. Additional legal analysis is required to examine the conditions under which use of the OOP technical system is allowed for updates.	DBA2
14	Principle:Reuse before build	Deviation: BRIS will not be used	There is a difficulty in reusing existing components built under different directives/regulations. Existing components must be extended/changed and retested. This is not always cheaper and might lead to unwanted compromises and complexity. Furthermore, this is not always legally possible. BRIS has been developed for inter-business register communication only and has been – legally – limited to certain pre-defined data-elements. Furthermore, the commission is assessing new concepts to replace the BRIS network that exists today. The DBA pilot will not use the BRIS network but will use the BRIS semantics as much as possible.	DBA1, DBA2
15	Principle:Data control by the user	Implication: requested evidences might contain user data for other natural persons than the requestor.	This principle states the user has a maximum degree of control over his personal data. In case of self-employed / sole traders / single person entities, company data will be personal as well. The company address may be the home address of the person running the company for example. The user will not be in control of this personal data in all cases. The importance of data exchange for safe economic operation might prevail over personal privacy (e.g. to prevent fraud). In any case, data exchange on any company must always comply with the GDPR requirements.	DBA1, DBA2
16	Principle:Digital by default	Deviation: Paper-based procedures are sometimes necessary	In some member states, evidences are no readily available via online services. The reasons may be national law or lagging digitalization. Evidences must in some cases be digitized from paper-based sources before they can be made available in online services.	MA1, MA2
17	Principle:Once-Only Principle	Implication: re-design of customer journey	This principle states that multiple administrative procedures must be re-analysed in the context of the complete customer journey. There are ongoing activities in many member states to take a more user-centric approach when designing services. However, much work remains to be done.	MA1
18	Principle:Mobile first	Deviation: no mobile first implementation	Designing for mobile first may not be the best solution for users where there is a lot of information to enter or preview.	MA1
19	Information Desk	The re-direct URL is now included in the information desk	Needs validation in 2nd iteration	SA1, SA2
20	Evidence Interchange Management	DBA does is not piloting the Evidence Overview	The DBA use case only deals with a single evidence - the company reghistration - and no large delays beyond several seconds is (short round trip), making a status overview less important for the overal user experience, i.e. an information that the evidence retrieval and rendering of a preview might take a coupld of seconds would suffice. In addition, the Intermediation Pattern, hence the preview is at the DC and the user exclusively interacts with the DC. Consequently, the Evidence Overview is purely informative (no user actions) and does not serve a "return to"-point as is the case in the USI pattern.	DBA 1
21	Evidence Interchange Management	SA and MA do not pilot the Evidence Overview	SA knows multiple evidence types and multiple evidence but not multiple data providers. It is coincidence that both ES and SI can provide all evidences from one provider (i.e. ES the Data Intermediation Platform). This means the second iteration will pilot multiple evidences, but will remain a single request - single response case. The same appears to apply equally to MA	SA1, SA2, MA1, MA2