Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

DCH-RP:PoC Phase 1

From EGIWiki
Jump to navigation Jump to search
WP5: Proofs of Concept Scenarios PoC Phase 1 PoC Phase 2 DCH Glossary
Proof of Concept 1 | Belgium | Estonia | Hungary | Italy | Poland | Sweden

The first Proof of Concept phase will see mostly an assessment of the existing DCH infrastructure against the evolving Roadmap. The current infrastructure is fragmented and mostly isolated respecting national policy authority. Consequently, the first Proof of Concept is organised in six parallel, local activities.

However, in preparation for Proof of Concept 2, we need to coordinate and make contact with e-Infrastructure providers across Europe to be able to explore e-Infrastructure based DCH preservation. Excel sheet provides more detail on this. THe next steps would be to make contact via EGI's NGI International LIaisons to the local NGIs and Resource Centres offering Grid and Cloud resources.


Key activity in the Proofs of Concept is not only the planning and execution of the actual Proof of Concept, but also reporting on the findings. These findings are WP5's main and most important contribution to the project and the Roadmap in particular.

Reporting is done on a number of levels:

Documenting the Proof of Concept as a task

These reports provide evidence that a certain tool, workflow, service, etc. was assessed as part of a Proof of Concept scenario. These scenarios are managed and tested using the workpackage's Backlog and individual tests are managed as tasks or stories in the backlog. The Product Owner uses these reports as a proof of satisfaction to accept the task as accomplished.

Informing the Roadmap owners through executive reports

While task activity documentation as mentioned above is mainly used for procedural and knowledge preservation reasons as referencable items in a document database, the type and level of information conveyed to the Roadmap maintainers is different: Ir is a summary of the very detailed tests, briefly indicating the context within which the test was executed, and a written "dashboard" of the assessment. The body of this report provides more details without being a copy of the test execution documentation.

Roadmap report template

A template is available in the document repository for download that should be used for uniform reporting across teams and scenarios. The template will report on a specific component (tool, service, etc.) that is used in a scenario, and the aspects for which it was assessed. The assessed component will be graded for each assessed aspect. The current document structure provisions for the following sections:

  • Overview & context
  • Component grading
  • Aspects and grading definitions
  • Detailed report

Aspects and grading

The work package has decided to not define aspects and their grading values up-front; the team felt that the understanding and use of these need to sufficiently converge first before a common base may be established. Therefore each roadmap report template will be self-contained in its aspects and gradings.

In the future, as this work matures and reporters become more proficient, a glossary of common aspects and grades will emerge and be documented in this Wiki.