Link Search Menu Expand Document
Consortium of European Social Science Data Archives

Architectural Principles


See Naming Conventions.



Potential suppliers of software artefacts for the CESSDA Research Infrastructure (RI). In the first instance, the CESSDA Service Providers, but potentially any software development organisation.


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 RI.

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 RI.

The publication of basic standards for source code quality will ensure Service Providers know what is expected of them.

The provision of a common development toolchain (including a build server linked to the source code repository, and a continuous code inspection system) facilitates the use of fail fast techniques such as Quality Gates. This will ensure that all source code is automatically tested to check that it meets common coding standards, that there is adequate test case coverage and that basic interoperability standards are met. As a result, substandard code cannot make its way in to production, instead any necessary remedial actions will be highlighted.

Without an intentional (as opposed to ad-hoc or emergent) Technical Architecture, there is a danger that the CESSDA interoperability characteristics may be addressed in such a diverse and incompatible manner that the intended benefits do not materialise, resulting in a RI that:

  • is not joined up
  • duplicates data and/or metadata
  • contains components that can only be installed, configured or operated by the Service Providers that developed them.
  • provides a sub-optimal User experience in many ways.

The combination of a common development toolchain and the Software Maturity Levels will help to establish a development maturity level for both the RI 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 RI User Experience.

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, a style guide has been produced to help User Interface developers adopt a common look and feel. In followed, the Architectural principles should reduce the overhead of retro-fitting such a component at a later date.