Summary Report. CESSDA Technical Framework Deliverable D1: Technical Architecture (v1.0)

Transcription

1 Consortium of European Social Science Data Archives Summary Report CESSDA Technical Framework Deliverable D1: Technical Architecture (v1.0) Authors John Shepherdson (UKDS) Ørnulf Risnes (NSD) Mike Priddy (DANS) Matti Heinonen (FSD) Johan Finn (SND) Wolfgang Zenk Möltgen (GESIS) CESSDA Technical Framework Deliverable D3: Impact Analysis (v1.0) Author John Shepherdson (UKDS) Both full reports were issued on as output from Phase of the work plan task. The present summary report was published in January

2 I. Technical Architecture Management Summary Audience Potential suppliers of software artefacts for the CESSDA RI. In the first instance, the CESSDA Service Providers, but potentially any software development organisation. Purpose The ambition is to promote good software development practice across the Service Provider community, in respect of the provision of software artefacts intended for use as part of the CESSDA Research Infrastructure. It is important to ensure that the source code for every product is centrally available, so that all Service Providers can access it, thus increasing the options for maintaining and extending the various artefacts, whilst protecting CESSDA s investment in its Research Infrastructure. The publication of basic standards for source code quality will ensure Service Providers know what is expected of them. The introduction of a build server linked to the source code repository will ensure that all source code is automatically tested to ensure it meets common coding standards, that there is adequate test case coverage and that basic interoperability standards have been met. It will mean that remedial action can be highlighted well before deliverable due dates, and can act as an input to the interim and final reviews. Without an intentional (as opposed to adhoc or emergent) Technical Architecture, there is a danger that the CESSDA common interoperability characteristics may be addresses in such diverse and incompatible manner that the intended benefits do not materialise, resulting in a Research Infrastructure that is not joined up, that duplicates data and/or metadata, with components that can only be installed, configured or operated by the Service Providers that developed them. Without an intentional Technical Architecture, there is a high likelihood that the User experience of the CESSDA RI user community will be suboptimal in many ways. The combination of the development infrastructure (including the automated build and test facility) and the Technical Architecture will help establish a development maturity level for both the CESSDA Research Infrastructure and the individual Service Providers. Future work plans can contain actions specifically targeted on raising this maturity level, which will in turn reduce maintenance and development costs, whilst improving the experience of the CESSDA RI s user community. Ideally there should be a common means of accessing all of the functionality offered by the various products (i.e. a CESSDA portal with a consistent look and feel) to ensure the User Journey is uniform and predictable, regardless of the destination. Whilst the development of such a unifying user interface is yet to be agreed (much less planned or commissioned), the Technical Architecture should reduce the overhead of retrofitting such a component at a later date. 2

3 Summary Scope Software development (from requirements, through design, documentation and testing to acceptance). Deployment and inlife operations and maintenance are currently out of scope. Summary This document provides guidance for developers of components for the CESSDA Research Infrastructure. However, it does not aim to address all aspects at present, only those that are relevant to the current tranche of work plan tasks. User Interface development guidelines are one of the deliberate omissions at this stage, as the current components are headless. It does provides guidance on meeting CESSDA s common interoperability characteristics, as they apply across the board. It is envisaged that subsequent versions will address those areas that are needed by developers of the contemporary RI components, so that feedback on their completeness and usefulness can be obtained in context. In the same way, deployment will be address in a later version, as and when the first components are ready to go into production. It also lays out an approach for assessing the maturity of RI components, so that over time CESSDA can mandate minimum levels that SPs and others have to meet as a prerequisite to supplying software artefacts for the RI. Meeting CESSDA s common interoperability characteristics The software architecture is intended to meet CESSDA s five common interoperability characteristics as follows. In each case, CESSDA s objective for the characteristic is stated. Loosely coupled but coordinated enable Service Providers to retain independence, yet fully interact in an integrated service Sustainable enable medium and long term investment and business change decisions to be made Extensible enable additional services to be built on or around it, including adapting to changing functional requirements Maintainable enable components to be updated when IT specifications change Standards-based enable the coordinated and planned change to all couple, but coordinated, services. 3

4 II. Impact Analysis Introduction According to the CESSDA Work Plan Task Bidder Pack (2015), all deliverables must be: Distributed all CESSDA Service Providers can use, incorporate, or otherwise benefit from the deliverable. Integrated The deliverable is interoperable or otherwise compatible with CESSDA products and services that are in place, or are likely to be in place. Borderless The user experience of the products or services of the Deliverable is the same regardless of the location of either the researcher or the data. The bid for this task lists its deliverables and the CESSDA Key Performance Indicators (KPIs) that each addresses. For information, the complete set of CESSDA KPIs is a follows: KPI Description 1 Functionality 2 Capacity 3 User experience 4 Impact on CESSDA and SPs This document looks at how the work plan task contributes to CESSDA s vision, then examines each of the deliverables in turn to see if and how it meets the Distributed/Integrated/Borderless requirements and how it addresses the relevant KPIs. Contribution to CESSDA s vision The vision of CESSDA, as stated in its statutes, is to provide a full scale sustainable research infrastructure that enables the research community to conduct high-quality research which in turn leads to effective solutions to the major challenges facing society today. Source: Overall, the outcomes of this work plan task will provide a number of benefits to CESSDA s stakeholders, which contribute to achieving the vision. Benefits to users: Potential reduction in frustration, due to improved product quality and levels of integration. Benefits to the Consortium as a whole: Source code for all products is accessible, buildable, extensible and of demonstrable quality (via various types of compliance tests); Likelihood of KPIs being met by every software product intended to form part of the Research Infrastructure is greatly enhanced; There is some PR value in being able to demonstrate that a quality approach is being taken to the development of component of the CESSDA RI, which may help to drive adoption. 4

5 Benefits to individual CESSDA Service Providers: Greater clarity re how to ensure the products they build will incorporate the Distributed, Integrated and Borderless characteristics; Ready made development infrastructure, and potential uplift with their code development practices and quality; Will help Service Providers to reify these concepts in a consistent manner. Deliverable Assessment The deliverables produced by the Technical Framework work plan task are as follows: Deliverable description Key Performance Indicator number 1. Technical Architecture (Type: Document) 1,3 2. Development infrastructure (Type: Infrastructure) 2 3. Impact analysis, as described in section A.4 (Type: Document) 4 CESSDA AS CESSDA House Parkveien Bergen NORWAY phone: cessda@cessda.net 5