From Module to Application

There are pros and cons to making sws-questionnaires a standalone application. Starting from the pros:

• autonomy: sws-questionnaires will be autonomous in its development and release cycles. It will neither induce releases, redeployments, or restarts of the Input System, nor will it be systematically affected by them. The operational dependency to the Input System will remain, of course, but it will be confined to key moments in the lifecycle of specifications, questionnaires, and campaigns. At all other times, the two applications will operate autonomously.

• adequacy: sws-questionnaires will choose its own technology stack and cross-cutting infrastructure (user management, rights management, authentication framework, task management, etc.). This is particularly of value because some parts of the stack and much of the infrastructure of the Input System are either aging, have shown limits, or have proved problematic to extend and maintain. Through separation, we avoid marring new developments with the risk of technical obsolence, yet preserving the investments in old developments.

• evolvability: the physical 'distance' between the applications will require clean interfaces between the two, avoiding accidental coupling and easing their individual evolution. In particular, it will emphasize the role of the Input System as a data source\/sink for sws-questionnaires, hence the possibility that there might be other in the future. In this sense, the separation is future-proofing for design.

Now the main cons:

• performance: distribution will put more emphasis on the performance of interactions, even in the assumption of intranet deployment. Relevant data and metadata will be accessed indirectly, through application APIs. These will need to be coarse-grained and caching will need to become a key part of their design.

• security: user identities will need to be preserved across application boundaries, so that extant rights to access data and metadata in the Input System will be honored. This will add non-trivial requirements to the security infrastructure.

• complexity: the pressure on build, release, and deployment infrastructures will increase, as well as the associated resource requirements. The overall system will becomes more complex.

• testability: the scope of automated integration testing will break ultimately limited to individual applications.

We decide to accept these cons for sws-questionnaires. Our line of reasoning here has less to do with sws-questionnaires than with the overall vision for the Statistical Working Platform. We revisit the rationale as follows:

• the functionalities of input management and questionnaire management lend themselves to a separation, largely because the dependencies between the two are mono-directional, occasional, and limited in scope. In other words, the separation is not artificially induced by techical considerations.

• we have already invested in robust solutions for code management, and have the tools to reduce the complexity introduced by new applications. While we still have work to do when it comes to monitoring and dynamic deployment, the scale of operations will remain modest for the foreseeable future, and we can count on enterprises-wide tools and solutions to tackle growth.

• avoiding technological obsolence is high priority. We prefer to embrace new engineering and operational challenges than inherit and propagate technological assumptions born out of different sets of requirements.

The sdmx-browser has already exemplified the vision of the Statistical Working Platform, but sws-questionnaires is the first implementation step on a larger scale.