2.5 Architecture background

This section will describe the rationale and assumptions of the proposed architecture.

2.5.1 Design rationale

The stakeholders main concerns for deployment where a minimum amount of configuration, no changes to the existing infrastructure, conformance to existing security regulations and a minimal additional load on existing servers. In essence the SNA system should work as a non-critical standalone system integrated within the corporate infrastructure and security guidelines.

We therefore designed the SNA system on two separate physical servers within the current network infrastructure. All configuration is applied to these servers directly (eg. which tools to extract data from) and thus requires no additional maintenance of the existing servers. The SNA system behaves like a workstation client when connecting to existing tool servers and therefore stresses a minimal additional load on these servers.

The database server is separated from the application server to increase security. Clients only connect to the application server, using the API services, so the SNA system controls the authentication and authorization of who can do what.

2.5.3 Assumptions

The SNA system extracts data from existing tool servers (eg. Jira, mail, etc.); specifically, it only extracts a subset of data from these servers. So it is assumed that the workload of the SNA system is lower than existing servers (which processes the full datasets). Therefore the SNA system is deployed on a single system of two servers and there is no need for a distributed cluster of servers.