The main goal of the architecture design, in iHelp, is to provide a holistic view, for health care professionals and policymakers, of the whole patient behaviour, integrating data inside the common HHR (Holistic Health Record) data model.
To reach that objective, the architecture tried to have several qualities, such as efficiency, buildability, modifiability, extensibility, and reusability.
When multiple architectural alternatives were analysed, the solution considered most efficient and, in order of priority, the easiest to realise has been adopted.
The most efficient solution for each component is the one that minimizes (i) the time requested to perform its tasks, (ii) the amount of disk space requested to store internal data enabling its normal operation, and (iii) the overhead of communications with other components to exchange requested and provided data.
When the simultaneous minimization of these three parameters has been not possible because of conflicting conditions, ‘the best’ trade-off among them has been chosen. The criteria to define the best trade-off assign the highest priority to the minimization of the execution time requested to perform the tasks, secondly to the minimization of the overhead of communication with other components, and finally to the minimization of the amount of disk space required.
For the components designed to be replicable, in case of high load, the dynamic horizontal scaling has to be taken into account (i.e., for the data ingestion pipeline components).
Other quality attributes have been taken into consideration, like the modifiability of the system, which is one of the most important quality attributes considered during the design. Indeed, the adopted incremental approach implies continuous changes to the architecture, and a highly modifiable system is strongly recommended.
According to the adopted quality model, modifiability is a complex attribute measured in terms of extensibility of capabilities, i.e. the ability to add new functionalities with less impact on the overall system, the deletion of unwanted capabilities, the portability, i.e. the ability of the system to run under different executing environment and the restructuring, i.e. the ability to support architectural configuration changes, such as rationalising system services, modularising, optimising or creating reusable components.
The reusability of some of the main components is a highly desired aspect for iHelp, even if it is not mandatory. Thus, one secondary goal of the iHelp architecture is to reduce as much as possible the coupling between components/micro-services, while keeping each component as cohesive as possible.
The whole design phase, instead of focusing on specific tools/language and techniques that development teams use, or micro-managing the internal architecture of the components/micro-services, concentrates on the protocols and interactions between the various software artifact and on the health and usefulness of the system as a whole.
The entire analysis and design phase, bring the architecture toward a mixed approach.
All the components were agreed to be containerised, but the more scalable ones, specifically the constituent components of the data ingestion building block, communicate asynchronously through a message broker. Nevertheless, to decentralise the coordination, instead of a static orchestration, choreographed transactions were designed, in particular, applying the SAGA pattern for transactions. With this choice, each software artifact has a “brain” that can decide, listening to all the other components, if an action should be taken or not. This approach simplifies the possible refinement of the pipeline without impacting the
single development of the components in the separated teams.
The rest of the platform, uses a more classical configuration, using REST API for internal data exchange.
This mixed approach, shown in the figure, coped with several constraints, trying to reach all the objectives set by the main goal, to help the health care professionals to have a holistic view of the patient’s health, in order to reduce the risk to develop pancreatic cancer or to improve their quality of life.
