In this blog, we describe the process used to define the architecture of the EFPF platform. This process is based on IEEE 1471 "Recommended Practice for Architectural Description for Software-Intensive Systems" and ISO/IEC/IEEE 42010:2011 “Systems and software engineering - Architecture description”, by which it was superseded. The latter establishes a methodology for the architectural description of software-intensive systems. The architecture design process covered the following steps:
- Identify and record the stakeholders for the system of interest
- Identify the architecture-related concerns of identified stakeholders
- Select and document a set of architecture viewpoints which can address the stakeholder concerns
- Create architecture views (one view for each viewpoint) which contain the architectural models
- Analyse consistency of the views
- Record rationales for architectural choices taken
Viewpoints are collections of patterns, templates and conventions for constructing one type of view. One example is the functional viewpoint (and therefore a functional view) that contains all functions that the system should perform, the responsibilities and interfaces of the functional elements and the relationship between them.
According to the specification of the ISO/IEC/IEEE 42010:2011 standard, the architecture view and architecture viewpoint, are defined as follows:
- Architecture viewpoint: Work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns
- Architecture view: A representation of a whole system from the perspective of a related set of concerns
In this respect, a view conforms to a viewpoint and communicates the resolution of a number of concerns and conversely a resolution of a concern may be communicated in a number of views.
Figure 1: Architecture Description Concepts (Adapted from ISO/IEC/IEEE 42010:2011 “Systems and software engineering - Architecture description”)
During the EFPF platform architecture design process, there are several principles that were followed to ensure a high quality of the architecture design. The different stakeholders were identified and engaged; and their concerns were taken into account.
As expected, there were some conflicting or incompatible concerns from different stakeholders, which were dealt with through interactions. The whole architecture design process was flexible and pragmatic to be able to deal with the changing requirements and the iterative approach in the EFPF project. Also, the process was technology-neutral.
Figure 2: Activities Supporting Architecture Definition [RW05]
The EFPF project had a strong emphasis on the establishment of an EFPF ecosystem. This was followed by the involvement of stakeholders in the architecture design process, who expressed their needs and desires with regards to the EFPF ecosystem. The stakeholders’ input was also needed to capture quality properties that increase the success of the platform. Based on this process the global architectural of the EFPF platform is developed, as shown blow. The architecture provides a formal split of key components of the EFPF federation and depicts the interaction between them.
Figure 3 : High-level Architecture of the EFPF Ecosystem
The EFPF platform architecture follows the micro-service architecture approach in which different functional modules implement individual functionalities that can be composed based on specific user needs. In order to implement this approach, all components in the EFPF ecosystem are prescribed to implement and publish open interfaces, preferably REST interfaces (in case of synchronous communication), allowing the exchange of data and avoiding the lag-time introduced by interconnection buses.
Further details of the key components in the EFPF architecture and role of Data Spine in the EFPF ecosystem will be discussed in forthcoming blogs … watch this space!
[RW05] Rozanski, Nick, and Eoin Woods. "Software Systems Architecture: Viewpoint Oriented System Development" (2005)