22.ArchitectureOverview.EASE.13-08-2020.V.4_redacted

Dieses Dokument ist Teil der Anfrage „Information on the planned Commission FOI platform

/ 21
PDF herunterladen
Ref. Ares(2020)7898139 - 23/12/2020 Secretariat-General (SG) SG.DSG1.C.5 – Digital Solutions & Process Efficiency Architecture Overview Electronic Access to Commission Documents (EASE) Date:                  13/08/2020 Doc. Version:          4 RUP@EC Template V.5.0 Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11. Office:    . Telephone: direct line (32-2)      . Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.
1

Electronic Access to Commission Documents (EASE) Architecture Overview

Document Control Information

Si
Project Title: Electronic Access to Commission Documents (EASE)

Document Author:
Project Owner:

 

Project Manager:

Document Approver(s) and Reviewerls):

 

NOTE: All Approvers are required. Records of each approver must be maintained. All Reviewers in the
list are considered required unless explicitly listed as Optional.

Name Rle —— Adon —— |Dte

DC u
u

 

Document history:
The Document Author is authorized to make the following types of changes to the document without
requiring that the document be re-approved:

« Editorial, formatting, and spelling
«® Clarification

To request a change to this document, contact the Document Author or Owner.
Changes to this document are summarized in the following table.

Revision [Dete  [remtedy _____|shortDeseriptionoflhanges

04/12/2019 Revised after review of Compass Corporate
integration

19/06/2020 Update after review from development
contractor

 

Configuration Management: Document Location

The latest version of this controlled document is stored in https://myintracomm-
collab.ec.europa.eu/projects/SGISPM/PROJ_DOC%20%20EASE/Technical%20documentation/Architectu
re

 

RUP@EC Template V.5.0 Date: 13/08/2020 Version: 4 2/21
2

Electronic Access to Commission Documents (EASE) Architecture Overview Contents 1 INTRODUCTION ................................................................................................................................... 4 1.1 Purpose ............................................................................................................................................. 4 1.2 Scope ................................................................................................................................................ 4 1.3 Intended Audience ........................................................................................................................... 4 1.4 Overview of the document ............................................................................................................... 4 2 INFORMATION SYSTEM DESCRIPTION ................................................................................................. 5 2.1 Information System Position Statement ........................................................................................... 5 2.2 Information System Perspective ....................................................................................................... 6 2.3 Assumptions and Dependencies ....................................................................................................... 7 2.4 Information System Requirements and Quality Ranges ................................................................... 8 2.4.1 Availability .................................................................................................................................. 8 2.4.2 Usability ..................................................................................................................................... 8 2.4.3 Maintainability ........................................................................................................................... 9 2.4.4 Applicable Standards ................................................................................................................. 9 2.4.5 System Requirements ................................................................................................................ 9 2.4.6 Performance Requirements ..................................................................................................... 10 3 COMPLIANCE .................................................................................................................................... 10 3.1 Security Compliance ....................................................................................................................... 10 3.1.1 Security Statement .................................................................................................................. 10 3.1.2 Philosophy ................................................................................................................................ 11 3.1.3 Scope ........................................................................................................................................ 11 3.2 Document Management Compliance ............................................................................................. 11 3.3 Data Protection Compliance ........................................................................................................... 12 3.4 OLAF Compliance ............................................................................................................................ 12 3.5 Constraints (Optional)..................................................................................................................... 12 4 ARCHITECTURE OVERVIEW................................................................................................................ 13 4.1 Architectural Goals ......................................................................................................................... 13 4.2 Architecture Decisions .................................................................................................................... 13 4.2.1 Architecturally Significant Requirements ................................................................................ 13 4.2.2 Architectural Constraints ......................................................................................................... 13 4.2.3 General Findings and Recommendations ................................................................................ 14 4.3 Architecture Overview Diagram ..................................................................................................... 17 5 RE-USABLE ARCHITECTURAL ASSETS ................................................................................................. 19 APPENDIX 1: REFERENCES AND RELATED DOCUMENTS .......................................................................... 21 RUP@EC Template V.5.0                              Date: 13/08/2020                                     Version: 4                                       3 / 21
3

Electronic Access to Commission Documents (EASE) Architecture Overview 1 INTRODUCTION 1.1     Purpose This document provides an overview of the main conceptual elements of the Electronic Access to Commission Documents (EASE) components and their underlying relationships, which include candidate subsystems, components, nodes, connections, data stores, users and external systems. 1.2     Scope The scope is limited to the EASE components. Although some external systems are included in the document, the purpose of this is to illustrate the relationships between the EASE components and those systems. The architecture of those systems is out of the scope of the document. 1.3     Intended Audience This document’s intended audience is the IT governance team, the DIGIT data centre, the EASE development teams and the DIGIT solution architects. 1.4     Overview of the document The Information System Description chapter [§2] provides a high-level view of the Information System. The Compliance chapter [§3] describes how the system is compliant with the applicable standards and regulations. The Architecture Overview chapter [§4] explains the architecture of the EASE eco system. The Re-Usable Architectural Assets chapter [§5] lists all the building blocks and re-usable components used. RUP@EC Template V.5.0                    Date: 13/08/2020                  Version: 4                      4 / 21
4

Electronic Access to Commission Documents (EASE) Architecture Overview

2 INFORMATION SYSTEM DESCRIPTION

This section provides a high-level view of the Electronic Access to Commission Documents system, its
capabilities and interfaces with other applications.

2.1 Information System Position Statement

Public at large and EC access-to-documents coordinators
and case handlers

For the public at large: issue initial and confirmatory
applications for access to EC documents

EC access-to-documents coordinators and case
handlers: register, attribute and handle access-to-
documents requests

Will provide a new online portal through which citizens will
be able to submit access-to-documents requests, have an
overview of their previous requests, communicate
electronically with the Commission, search for the
previously disclosed documents etc.

Will provide EC access-to-documents coordinators and case
handlers a request management back-end that will
automate and improve the handling of requests, offer
improved search, statistics and reporting functionalities,
allow better deadline management, all while complying
with the necessary personal data protection requirements.

The GestDem system that currently supports the access-to-
documents process and the ColdFusion form on Europa
that allows the public at large to request access to
Commission documents, but not to track the advancement
or liaise with the Commission services that are handling the
request.

Will be in line with the European Commission Digital
Strategy [REF3] by providing the Commission and citizens
with a transparent, digital, efficient and user-centric
request management system and public portal.

our Information System

 

RUP@EC Template V.5.0 Date: 13/08/2020 Version: 4 5/21
5

Electronic Access to Commission Documents (EASE) Architecture Overview

2.2 Information System Perspective

The EASE information system is composed of three modules. Two web applications, one internal for
Commission staff and one external for the general public. These two modules are supported by a
common set of web services that implement the business, data access and integration logic. The third
module consists of back-end services that will support the web applications by providing access to the
database, implementing complex business logic and integrating with corporate services.

All modules will be developed by an extra-muros service provider (under DIGIT-XM QTM framework
contract), with the exception of a thin integration layer that will be developed by intra-muros service
providers (DIGIT-TM) (cf. AD-002).

It will be fully hosted within the DIGIT data centre based on standard hosting services and will leverage
the CNS, Corporate Search Service, Corporate eUl and EU Login components of the Reusable Solutions
Platform during the first phase of its deployment. It will then transition from its own instances of
Camunda to Compass Corporate and My Workplace after the move to production. The system will
integrate with the ePoetry and eTranslation set of translation services and Decide-Decision/Consultation
from 2022 onwards.

    
   
      

Messaging services EASE components Translation services

   
  

 

EASE back-end services

EASE request EASE public
management portal front-
es
Document front-end end Workflow services
management services
L
N

Business intelligence Security services

  
   
      

 

 

 

  

Corporate user Search services

interface

 

 

 

Figure 1 High-level context and component diagram

Connected with the
following information
systems / components

EASE Request SG corporate Web application based | Phase 1

Management System coordinators, on eUl that allows

(EASE-RMS) screeners and coordinators and case
attributors handlers to process
DG access-to- access to documents
documents requests in terms of
coordinators registering the request,
DG access-to- preparing the
documents documents and

request handlers drafting the reply for
Legal Service both initial and

®e EUloginfor
authentication

EASE API for
business logic and
integration

Qlik Sense to
display the
dashboards and
grant access to the

 

RUP@EC Template V.5.0 Date: 13/08/2020 Version: 4 6/21
6

Electronic Access to Commission Documents (EASE) Architecture Overview confirmatory                      reports application processes Phase 2    The UI will be integrated to the MyWorkplace ecosystem EASE Public Portal            Citizens and             Web application based            EU Login for (EASE-PP)                      organisations            on eUI/ECL that allows            authentication (students,               users to request access          EASE API for researchers,             to documents or                   business logic journalists,             searching for                     integration lobbyists…)              previously disclosed documents This will also be the main communication channel between the applicants and the Commission services that are handling the requests EASE API (EASE-API)           EASE-RMS                 Set of web resources          Phase 1     EASE-PP                  that allow both front-    EASE database end web applications    Workflow engine (EASE-RMS & EASE-PP) (Camunda) to integrate with corporate building               HRS blocks and to interact           ERS with EASE specific data          CNS    Corporate/Europa Search Service    SG NOVA (user management component & templating services) Phase 2    Workflow engine (Compass Corporate)    ePoetry    eTranslation    Decide- Consultation    Decide-Decision 2.3    Assumptions and Dependencies The current architecture solution proposal assumes the following:    That the Compass Corporate platform will be used to leverage the workflow task providers, the messaging infrastructure and reusable business-agnostic services.    That the MyWorkplace user interface framework may be used for the internal management system later. However, that the request management will be a stand-alone application at first.    That the public portal will adopt the DG COMM design language based on ECL components in alignment with the other Europa pages and information systems. RUP@EC Template V.5.0                   Date: 13/08/2020                    Version: 4                      7 / 21
7

Electronic Access to Commission Documents (EASE) Architecture Overview     That the main document repository will be the HAN family of services, but that some documents may be stored locally if they are not e-Domec compliant. The following components may not be immediately integrated but could be added later based on business prioritisation and availability of funds:     Translation services (provided by DGT): ePoetry to request official translations of outgoing correspondence and eTranslation for automatic translation of incoming correspondence.     Decide: in 2022 a project will be initiated to integrate Decide-Consultation/Decision into the confirmatory application process for DG/Legal Service consultations and for the adoption of confirmatory decisions. 2.4     Information System Requirements and Quality Ranges There are three main components for the EASE information system:     Request management system (EASE-RMS): request management web interface for Commission staff (SG/DG coordinators and case handlers).     Public portal (EASE-PP): public-facing web interface hosted on Europa that applicants use to search for disclosed documents and manage their applications.     APIs (EASE-API): set of interfaces that both the case management application and public portal rely on to retrieve and store information on the EASE business domain. 2.4.1 Availability Since the portal is a public application, it must be available at any time all year-round. The requirements for the request management system are less stringent because the system is required to be available during office hours.     EASE-RMS: standard availability requirements (Mon.-Fri., 8.00-18.00), with 99% uptime (21h54 possible downtime / 3 months).     EASE-PP: 24 hours a day, 7 days a week throughout the whole year, with 99% uptime (21h54 possible downtime / 3 months).     EASE-API: 24 hours a day, 7 days a week throughout the whole year, with 99% uptime (21h54 possible downtime / 3 months). 2.4.2 Usability As a web application, the public portal component will provide a web UI (User Interface) that adheres to usability standards of commonly available browser based application. As such:  The system will provide natural language search functionalities that will be on par (from a semantic perspective) with what nonprofessional users expect from a search engine.  The system will adhere accessibility standards put forth by the W3C WAI-ARIA Guidelines .               1 Note that these standards are already baked into the underlying UI frameworks the system will build upon; namely DIGIT’s eUI/ECL.  Proper user help material or documentation will be made available to the users for functionality that are identified as not being intuitive. Several rounds of usability tests were done on both web application prototypes, targeting specific user populations depending on the features that were being tested. The feedback from end-users was immediately integrated into the design. 1 https://www.w3.org/WAI/standards-guidelines/aria/ RUP@EC Template V.5.0                      Date: 13/08/2020                  Version: 4                      8 / 21
8

Electronic Access to Commission Documents (EASE) Architecture Overview

2.4.3 Maintainability

For both web applications, the architecture aims to have operational data and operational activities
served or driven from its database.

Key operational data that will be maintained in the database are:
® Jobschedules
® Staticreference data (language and country lists)
® Dynamic reference data (template types and categories)
«e Static texts’ translations and localized labels.

The Solution Provider and Business Manager will also have privileged access to an administration page
to manage user rights, document templates, localised labels and application runtime parameters.

A System Monitoring page and underlying component will be made available to record and visualize, in
real time, key performance, scalability and stability indicators of the API module.

Key system metrics that will be recorded are:
®e User counts over time
® Request counts over time
® _JVM Heap utilization over time
® _JVM Thread counts over time
® Job/Worker Queue sizes
« Slow queries
«e Slow services
® Error counts over time

Keeping track on these key metrics will allow for better understanding of problems when they occur and
for preventive measures to be taken when negative trends are identified.

2.4.4 Applicable Standards

The system will be compliant with data protection Regulation (EU) 2018/1725.
The system will be compliant with the Commission Decision (EU, Euratom) 2017/46 on IT
security.

® The business process model will be BPMN 2.0- compliant.

2.4.5 System Requirements

The EASE system will be fully hosted within the DIGIT data centre for acceptance and production
environments but will depend also on the contractor’s environments and AWS workspaces and servers
for development purposes.

The API gateway will help bridge the gap between the contractor’s development environments and the
corresponding integration of non-production APIs.

Üinfrastructureelement _[Predut _ [Management [Version |
LAMT stack Linux, Apache, MySQL & Linux (RHEL): 7.7

PeRIEER Apache web

server: 2.4.39

Apache Tomcat:
9.0.31

MySQL: 8.0.19

RUP@EC Template V.5.0 Date: 13/08/2020 Version: 4 9/21
9

Electronic Access to Commission Documents (EASE) Architecture Overview

Load balancer VIPs and reverse N/A
proxy mappings

Amazon Web Services Workspaces and development Cloud N/A
EC2 servers

EU Login 4.47.x for Tomcat

User interface framework eUI/ECL (Angular)
Workflow management Camunda 7.8.xX

framework

Document management & | HRS& ERS HRS 2.0

externalisation ERS12

Virtual machine OpenJDK 71

implementation

2.4.6 Performance Requirements

 

Only the public portal has noteworthy performance requirements because it is publicly available.

® The public portal will support up to 30 concurrent users against the search engine at any given
time and up to 20 concurrent users on the applicant dashboard. This component will complete
90% of all transactions within 2 seconds.

® The request management system will support up to 20 concurrent users at any given time. This
component will complete 90% of all transactions within 5 seconds.

® The APIs will support up to 50 requests per second and complete 90% of them within 2
seconds.

3 COMPLIANCE

3.1 Security Compliance

3.1.1 Security Statement

The following security business impact assessment will be confirmed when the security plan for the
information system is drafted in the second half of 2020 (according to the ITSRM? methodology).

The security plan ITSRM? Excel file is currently being filled in jointly by the Solution Provider and
Business Owner. The System Owner is expected to sign off on the Word document and its Excel annex in
Q1 2021 before the Q2 move to production.

Our Information System has a LIMITED BASIC
Confidentiality level

Our Information System has an Integrity MODERATE
level

Our Information System has an MODERATE
Availability level

RUP@EC Template V.5.0 Date: 13/08/2020 Version: 4 10/21
10

Zur nächsten Seite