Initial Creation Process
We created this quality model by applying the following methodology:
The quality model is based on the Quamoco meta model and we defined quality aspects, product factors, entities, and measures as described by this excerpt from the Quamoco meta model:
Referring to the methodology, in the following, details for the different steps (A,B,C,D,E) are presented. For the visualizations of the diagrams we used: https://app.diagrams.net/
Step A
In the first step we extracted separate statements from the following definitions for cloud-native applications:
- CNCF2018
- Fehling2014
- Gannon2017
- Kratzke2017
- Pahl2018
- Pivotal2017
- RedHat2018
- Toffetti2017
- Wurster2020
Step B
In the second step we mapped the statements to the quality aspects of the ISO25010 standard.
Step C
In the third step, we further differentiated the statements to derive quality aspects as required from the Quamoco meta model:
Step D
In the forth step we defined more specific product factors which impact and realize the found quality aspects. Therefore we relied on the following practitioner books and mapped statements and chapters to the quality aspects:
| Title | Author(s) | Year | Publisher | |
|---|---|---|---|---|
| Cloud Native Infrastructure | Justin Garrison and Kris Nova | 2017 | O’Reilly | |
| Cloud Native Java | Kenny Bastani and Josh Long | 2017 | O’Reilly | |
| Cloud Native Patterns | Cornelia Davis | 2019 | Manning | |
| Cloud Native | Boris Scholl, Trent Swanson, and Peter Jausovec | 2019 | O’Reilly | |
| Microservices Patterns | Chris Richardson | 2019 | Manning | |
| Cloud Native Transformation | Pini Reznik, Jamie Dobson, and Michelle Gienow | 2019 | O’Reilly | |
| Cloud Native DevOps with Kubernetes | John Arundel and Justin Domingus | 2019 | O’Reilly | |
| Kubernetes Patterns | Bilgin Ibryam and Roland Huß | 2020 | O’Reilly | |
| Building Secure and Reliable Systems | Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield | 2020 | O’Reilly | |
| Design Patterns for Cloud Native Applications | Kasun Indrasiri and Sriskandarajah Suhothayan | 2021 | O’Reilly | |
| Practical Process Automation | Bernd Rücker | 2021 | O’Reilly | |
| Cloud Native Architecture and Design | Shivakumar Goniwada | 2021 | Apress |
After the intial scanning of the practitioner books we had added the product factors as shown here:
After having read all books, we iterated on the found statements and refined the factor hierarchy:
Step E
In the final step we added measures to the product factors as currently available in the scientific literature. This therefore serves as an evaluation of the currently existing measures which suit our model showing for which product factors measures have already been presented and for which product factors it is necessary to propose additional measures in future work (We do not propose additional measures in this work to keep the model in its current state aligned to existing literature).
But because measures need to be based on entities which form the software architecture, suitable entities are needed. Therefore we propose the following entities which can describe the software architecture of a cloud-native application as suitable for our quality model:
| Name | Description | Relation |
|---|---|---|
| System | The cloud-native application as a whole | - |
| Component | An abstract part of the system, maps to a logical service or cloud “resource” | part-of System |
| Service | A service implementing a business functionality | is-a Component |
| Endpoint | A communication endpoint, for example a REST endpoint, message producer/listener | part-of Service |
| External Endpoint | An endpoint which is publicly available | is-a Endpoint |
| Backing Service | A component providing general functionalities needed by services, for example, messaging, logging | is-a Component |
| Storage Backing Service | An explicitly stateful component used to store business data, e.g., a database | is-a Component |
| Link | A connection between components | part-of System |
| Infrastructure | The technical foundation where components are deployed, e.g., a container orchestration system | part-of System |
| Deployment Mapping | A connection between a component or infrastructure and its (underlying) infrastructure | part-of System |
| Request Trace | The whole resulting trace of a service invocation from the outside, a collection of components and links | part-of System |
| Data Aggregate | An aggregate which needs to be persisted and is used by services, e.g., Business objects | part-of System |
| Backing Data | Non-business data, e.g., config values, secrets, logs, metrics | part-of System |
To find suitable measures, we performed a literature search, as described in more detail in Search Process.
We first collected all measures that we found and characterized them. Then we selected only those measures suitable for our quality model (that means a measure fits to a product factor of our quality model and is based on the same level of abstraction as defined by our proposed entities). The selected measures are list at Measures.
Next, we added these selected measures to our quality model:
It is important to note that up to this point our quality model has a broad scope also including aspects such as the deployment process (and fitting product factors) and runtime measures (shown in purple in the previous visualization). We deliberately included these things in our quality model to gather as much information as possible. However, because the focus of our quality model should be on the design time of a software architecture, we iterated on the quality model once more to only include aspects that can be evaluated at design time (therefore excluding runtime measures) and can be evaluated based on the entities that we have proposed (therefore excluding for example aspects considering the deployment process). It might be possible to reconsider these things in future work, but for now we want to focus on the design time and elaborate our quality model to enable quantitative evaluations of software architectures.
Our final quality model with this specific scope:
However, this visualization is problematic, because the relations between factors are difficult to see and follow. We therefore chose to change the visualization to a “star” form where the top most quality aspects are shown with a black background at the edges and product factors impacting multiple quality aspects can therefore be but in the middle. This is also the visualization shown at Overview:
