Architecture

Architecture Drawings using the c4 model (www.c4model.com)

The C4 model (c4model.com) for visualising software architecture is followed below:

• Level 1: System Context gives a high-level overview of the platform, its purpose, and how it is linked to its primary user groups.
• Level 2: Container Diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another.
• Level 3: Component Diagrams, zooms in on the Services and API containers to give more detail about the functions and applications each provides.
• Level 4: Code is an optional level of detail and is not included in this requirements document. However, such detail will be provided in a future revision of this deliverable as an annex.

Level 1: System Context

Level 2: Container Diagram

Level 3: Component - Services Diagram

Architecture Methodology for (Micro) Services

Although the BIOFIN-EU platform may be conceptually thought of as a single technical deliverable, the project requirements and goals make clear that it will more specifically be an integration of front end and back end services. WP4 will follow a ‘Poly-Repo’ approach for managing the source code behind such services.

This decision has been taken to champion collaboration and development between multiple institutions, while avoiding the creation of unnecessary dependencies. It is also expected this approach will reduce single points of failure, by making the architecture of the platform transparent in terms of what happens behind in BIOFIN-EU, and where.

• Continuous Integration / Continuous Delivery (CI/CD) should be expected as key to supporting the BIOFIN-EU, and ‘Poly-Repo’ has a lower overhead in this area.

• ‘Mono-Repo’ is more suitable for projects including small size semi-independent sub-projects or components. In the long term, the BIOFIN-EU services will be heavily integrated to enhance the knowledge reservoir and user experience as more knowledge objects and user interactions occur.

• A ‘Mono-Repo’ approach will create unnecessary dependencies which could delay the project and causes weaknesses in the technology chain.

• Getting to a MVP version as quickly as possible is key to allowing assumptions and user experience to be tested, and in the experience of the technical partners, a ‘Mono-Repo’ is less suitable for this given the scope of the project.

• In order to support other Horizon Europe projects who wish to use the knowledge reservoir behind the BIOFIN-EU (for example, banks linking the dashboard to their own website), this would be more challenging and require more development time with a ‘Mono-Repo’ approach.

In the long term, by following a ‘Poly-Repo’ micro-service approach, the BIOFIN-EU can build a strong identity from a user interface and experience perspective, while over time, the back end services which power it can be continually improved, and where necessary, replaced. This gives the benefit of reducing cost and allows the BIOFIN-EU to benefit from expected technological advancement.