diff --git a/search.json b/search.json index 33ffa48..8d52980 100644 --- a/search.json +++ b/search.json @@ -74,7 +74,7 @@ "href": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#architecture", "title": "IT Architecture Principles and Implementation Guidelines test", "section": "4.1 Architecture", - "text": "4.1 Architecture\nFoundational and design principles for maintaining sound infrastructure and IT solution architecture. These sub-principles addresses best-practices and industry standard design patterns.\n\n\n\n\n\n\n\nArchitecture 1 (Scalability 1):\nClient specific IT solutions should have a modular structure\n\n\n\n\nWhat:\nModular structure of client specific IT solutions is a requirement. This may be achieved using e.g. microservice architecture\n\n\nWhy:\nA modular structure is sought to ensure further development, and updates are possible. The possibility of substituting or adding modules in an IT solution will increase the lifespan of a solution and increase scalability\n\n\nConsequence:\nModular architecture of IT solutions is a requisite\n\n\nExample:\nIf the client specific IT solution has, for Example, grown its user base since the launch of the solution, then scaling up shall be possible at any time – scaling containers, vertically (more CPUs, RAM) and horizontally (more VMs)\n\n\n\n\n\n\n\n\n\n\nArchitecture 2 (Maintainability 2):\nIT solutions are to be Dockerized or similar\n\n\n\n\nWhat:\nThe use of container technology is encouraged\n\n\nWhy:\nContainerization is crucial for building scalable IT solutions and container technology eases the work of moving IT solutions around the IT infrastructure making deployment easier to automate\n\n\nConsequence:\nIT solutions are to be deployed using Docker containers or similar\n\n\nExample:\nSoftware components of the client specific IT solution shall be provided as docker containers so that deployment is flexible with respect to hardware\n\n\n\n\n\n\n\n\n\n\nArchitecture 3 (Scalability 2):\nClient specific IT solutions must be able to interface with other IT solutions\n\n\n\n\nWhat:\nThe IT deliverable must be able to be used in conjunction with other deliverables to form a composite solution\n\n\nWhy:\nTo make the most of the funds available the developed solutions should form part of an IT ecosystem making up a whole\n\n\nConsequence:\nIT deliverables must be equipped with documented APIs for interfacing with other IT applications\n\n\nExample:\nA client specific product, which can be used for extracting and manipulating data, should be accessible programmatically through e.g. well documented REST services\n\n\n\n\n\n\n\n\n\n\nArchitecture 4:\nIT solutions should be cloud agnostic\n\n\n\n\nWhat:\nIf the IT solution is built for cloud environments, measures must be taken to make the solution cloud agnostic.\n\n\nWhy:\nVendor lock-in must be avoided to remove vendor specific dependencies, making the IT solution easier to migrate to a different cloud vendor\n\n\nConsequence:\nIT solutions must minimize the usage of vendor specific functionality and non-standardized infrastructure\n\n\nExample:\nAn IT solution that makes use of serverless functions should be built in a way that allows for using another vendors serverless functionality with little or no changes in case of migrating from one platform to another" + "text": "4.1 Architecture\nFoundational and design principles for maintaining sound infrastructure and IT solution architecture. These sub-principles addresses best-practices and industry standard design patterns.\n\n\n\n\n\n\n\nArchitecture 1:\nClient specific IT solutions should have a modular structure\n\n\n\n\nWhat:\nModular structure of client specific IT solutions is a requirement. This may be achieved using e.g. microservice architecture\n\n\nWhy:\nA modular structure is sought to ensure further development, and updates are possible. The possibility of substituting or adding modules in an IT solution will increase the lifespan of a solution and increase scalability\n\n\nConsequence:\nModular architecture of IT solutions is a requisite\n\n\nExample:\nIf the client specific IT solution has, for Example, grown its user base since the launch of the solution, then scaling up shall be possible at any time – scaling containers, vertically (more CPUs, RAM) and horizontally (more VMs)\n\n\n\n\n\n\n\n\n\n\nArchitecture 2:\nIT solutions are to be Dockerized or similar\n\n\n\n\nWhat:\nThe use of container technology is encouraged\n\n\nWhy:\nContainerization is crucial for building scalable IT solutions and container technology eases the work of moving IT solutions around the IT infrastructure making deployment easier to automate\n\n\nConsequence:\nIT solutions are to be deployed using Docker containers or similar\n\n\nExample:\nSoftware components of the client specific IT solution shall be provided as docker containers so that deployment is flexible with respect to hardware\n\n\n\n\n\n\n\n\n\n\nArchitecture 3:\nClient specific IT solutions must be able to interface with other IT solutions\n\n\n\n\nWhat:\nThe IT deliverable must be able to be used in conjunction with other deliverables to form a composite solution\n\n\nWhy:\nTo make the most of the funds available the developed solutions should form part of an IT ecosystem making up a whole\n\n\nConsequence:\nIT deliverables must be equipped with documented APIs for interfacing with other IT applications\n\n\nExample:\nA client specific product, which can be used for extracting and manipulating data, should be accessible programmatically through e.g. well documented REST services\n\n\n\n\n\n\n\n\n\n\nArchitecture 4:\nIT solutions should be cloud agnostic\n\n\n\n\nWhat:\nIf the IT solution is built for cloud environments, measures must be taken to make the solution cloud agnostic.\n\n\nWhy:\nVendor lock-in must be avoided to remove vendor specific dependencies, making the IT solution easier to migrate to a different cloud vendor\n\n\nConsequence:\nIT solutions must minimize the usage of vendor specific functionality and non-standardized infrastructure\n\n\nExample:\nAn IT solution that makes use of serverless functions should be built in a way that allows for using another vendors serverless functionality with little or no changes in case of migrating from one platform to another" }, { "objectID": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#reproducibility", @@ -95,7 +95,7 @@ "href": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#transparency", "title": "IT Architecture Principles and Implementation Guidelines test", "section": "4.4 Transparency", - "text": "4.4 Transparency\nThe CLMS is funded by the EU and supports its community with data and services. As such, these products and services are to be part of the foundation for further work in the field and accessible to the community. To support this, the principle of transparency is detailed in the following subprinciples:\n\n\n\nTransparency 1*:\nSource code of client specific software to be supplied with IT solution\n\n\n\n\nWhat:\nSource code of client specific IT solution is supplied as part of the deliverable and made publicly available under the EUPL-1.21 license\n\n\nWhy:\nTo ensure transparency, it is essential to have clear insights into the client-specific software. This enables efficient future developments and modifications\n\n\nConsequence:\nSource code of client specific software must be delivered with IT solution. The source code shall include Docker recipes and scripts for building the source code and be published under the EUPL-1.2. license\n\n\nExample:\nSource code of all the components of the specific IT solution must be delivered. Any updates or developments of the source code shall be reflected in the EEA GitHub repository, which is the main repository of the system. Moreover, the specific client IT solutions shall be published under the EUPL-1.2 license, so the openness and transparency are ensured\n\n\n\n\n\n\n\n\n\n\nTransparency 2:\nInline documentation of the source code\n\n\n\n\nWhat:\nSource code of client specific IT solution must be documented in-line\n\n\nWhy:\nTo effectuate the handover from one developer to the next inline documentation are to be included to guide the developer on the job\n\n\nConsequence:\nSource code must have inline documentation. Inline code should be formatted so that it may be easily extracted to generate online documentation\n\n\nExample:\nSource code of all the components of the IT solution must have inline documentation. The documentation shall be structured, following common conventions, and kept at a minimal, but comprehensive level\n\n\n\n\n\n\n\n\n\n\nTransparency 3*:\nCommercial software used in the production must be attainable by the EEA or a third-party provider\n\n\n\n\nWhat:\nCommercial software which are prerequisites must be attainable on comparable terms. Such software is justified only if no open alternative exists\n\n\nWhy:\nTo ensure that further work may be carried out any prerequisites in the form of software must be attainable by the EEA or a supplier\n\n\nConsequence:\nGenerally attainable commercial software used in production must be listed when delivering an IT solution. Name of software, version, EOL and EOS to be supplied\n\n\nExample:\nAn IT solution is deploying various components and the set-up of the virtual machines that houses the components is done by means of an infrastructure as-a-code-tool. All the capabilities of the infrastructure as-a-code-tool, that require purchasing must be listed when delivering the IT solution" + "text": "4.4 Transparency\nThe CLMS is funded by the EU and supports its community with data and services. As such, these products and services are to be part of the foundation for further work in the field and accessible to the community. To support this, the principle of transparency is detailed in the following subprinciples:\n\n\n\nTransparency 1:\nSource code of client specific software to be supplied with IT solution\n\n\n\n\nWhat:\nSource code of client specific IT solution is supplied as part of the deliverable and made publicly available under the EUPL-1.21 license\n\n\nWhy:\nTo ensure transparency, it is essential to have clear insights into the client-specific software. This enables efficient future developments and modifications\n\n\nConsequence:\nSource code of client specific software must be delivered with IT solution. The source code shall include Docker recipes and scripts for building the source code and be published under the EUPL-1.2. license\n\n\nExample:\nSource code of all the components of the specific IT solution must be delivered. Any updates or developments of the source code shall be reflected in the EEA GitHub repository, which is the main repository of the system. Moreover, the specific client IT solutions shall be published under the EUPL-1.2 license, so the openness and transparency are ensured\n\n\n\n\n\n\n\n\n\n\nTransparency 2:\nInline documentation of the source code\n\n\n\n\nWhat:\nSource code of client specific IT solution must be documented in-line\n\n\nWhy:\nTo effectuate the handover from one developer to the next inline documentation are to be included to guide the developer on the job\n\n\nConsequence:\nSource code must have inline documentation. Inline code should be formatted so that it may be easily extracted to generate online documentation\n\n\nExample:\nSource code of all the components of the IT solution must have inline documentation. The documentation shall be structured, following common conventions, and kept at a minimal, but comprehensive level\n\n\n\n\n\n\n\n\n\n\nTransparency 3:\nCommercial software used in the production must be attainable by the EEA or a third-party provider\n\n\n\n\nWhat:\nCommercial software which are prerequisites must be attainable on comparable terms. Such software is justified only if no open alternative exists\n\n\nWhy:\nTo ensure that further work may be carried out any prerequisites in the form of software must be attainable by the EEA or a supplier\n\n\nConsequence:\nGenerally attainable commercial software used in production must be listed when delivering an IT solution. Name of software, version, EOL and EOS to be supplied\n\n\nExample:\nAn IT solution is deploying various components and the set-up of the virtual machines that houses the components is done by means of an infrastructure as-a-code-tool. All the capabilities of the infrastructure as-a-code-tool, that require purchasing must be listed when delivering the IT solution" }, { "objectID": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#maintainability", @@ -125,13 +125,6 @@ "section": "4.8 Resilience", "text": "4.8 Resilience\n\n\n\n\n\n\n\nResilience 1:\nIT solution should have a disaster recovery plan\n\n\n\n\nWhat:\nIT solution should have a well-defined process of restoring IT systems, data, and operations following a disruption\n\n\nWhy:\nTo ensure that the IT solution and data are recoverable after an unforeseen event\n\n\nConsequence:\nIT deliverables will be provided with well-prepared disaster recovery plan that will ensure a rapid restoration of services and data integrity, and minimize damage\n\n\nExample:\nA delivered IT solution has a disaster recovery plan that includes backup protocols, data replication, and recovery timelines\n\n\n\n\n\n\n\n\n\n\nResilience 2:\nEnsuring IT solution continuity\n\n\n\n\nWhat:\nIT solution is designed and implemented in a way that ensures continuous operation during a disruption\n\n\nWhy:\nTo maintain critical operations with a minimal downtime, even when confronted with unforeseen events\n\n\nConsequence:\nIT deliverables are designed for high availability, incorporating redundancy so that in case of a disruption/failure, restore service can immediately take over, minimizing downtime and ensuring continuous operation\n\n\nExample:\nIn the event of a system failure or disruption of the delivered IT solution, restore service automatically take over to maintain service continuity. For instance, if a primary system goes down, a secondary system activates, ensuring that users experience no downtime." }, - { - "objectID": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#section", - "href": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#section", - "title": "IT Architecture Principles and Implementation Guidelines test", - "section": "4.9 ", - "text": "4.9" - }, { "objectID": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#footnotes", "href": "src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html#footnotes", diff --git a/sitemap.xml b/sitemap.xml index a498591..9b5b1dc 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,18 +2,18 @@ https://eea.github.io/CLMS_documents/src/guidelines/index.html - 2025-03-07T12:18:11.949Z + 2025-03-07T12:57:24.071Z https://eea.github.io/CLMS_documents/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.html - 2025-03-07T12:18:11.948Z + 2025-03-07T12:57:24.071Z https://eea.github.io/CLMS_documents/src/index.html - 2025-03-07T12:18:11.949Z + 2025-03-07T12:57:24.071Z https://eea.github.io/CLMS_documents/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html - 2025-03-07T12:18:11.949Z + 2025-03-07T12:57:24.071Z diff --git a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.docx b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.docx index 8193ea3..b8e7cfd 100644 Binary files a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.docx and b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.docx differ diff --git a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.pdf b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.pdf index 537ddbf..1b5fed7 100644 Binary files a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.pdf and b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines.pdf differ diff --git a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.docx b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.docx index 252ab7e..ed1b540 100644 Binary files a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.docx and b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.docx differ diff --git a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html index b5b2ef9..bb2136c 100644 --- a/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html +++ b/src/guidelines/IT_Architecture_Principles_and_Implementation_Guidelines_test.html @@ -4874,7 +4874,6 @@

Index

  • 4.6 Observability
  • 4.7 IT security
  • 4.8 Resilience
    • -
  • 4.9

    • Other Formats

    @@ -5269,10 +5268,10 @@

    3 Scope and key t

    Definition of the key terms used within this document: